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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf