Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30-sep-2006, at 23:28, Steven M. Bellovin wrote:

Since my earlier comments to the author were apparently ignored:

"Ignored" is not the right word; I just don't happen to agree with you...
I replied to you, both privately and on the NANOG list.

Sure. But my issues haven't been resolved.

There is explicit text in 2.2 discussing the need for integration with the
TCP timeout mechanism.

I don't think this can be robust enough, especially considering the possible alternatives.

Text I added after our exchange of messages in June discusses the need for
a MIB entry, precisely to address this issue.

How does that help?

These types of additions to the BGP protocol
are well-understood and shouldn't lead to significant additional
implementation difficulty.

Again, for that to have any utility it requires double-ended changes.

I don't have a problem with how the suggested mechanism works if only one end is changed; the problem is exactly with the case where both are changed, so this requirement isn't problematic here.

I'm afraid I do believe you about the rarity of password changes -- that's precisely what I'm trying to fix! The need for such changes is discussed
in RFC 3562.

Hm, that RFC assumes that an attacker can get hold of a packet belonging to a password-protected BGP session in order to do a brute force search for the key. That doesn't make sense because:

1. There is no obvious way in which an attacker can obtain such packets
2. Expending so much computing resources to execute an attack that only causes some temporary rerouting doesn't seem worth the effort

I agree with you completely about the need for better key management.

The main question I posed in Montreal still remains unanswered: wouldn't it be easier to just run BGP over IPsec if better security is required?



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]