[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] proposed additional text
In message <200405171344.i4HDiuJ54067@merlot.juniper.net>, Yakov Rekhter writes
:
> Folks,
>
> During the IESG review Steve Kent proposed the following text to
> be added to the BGP protocol spec.
>
> BGP makes use of TCP for reliable transport of its traffic between
> peer routers. To provide connection-oriented integrity and data
> origin authentication, on a point-to-point basis, BGP specifies
> use of the mechanism defined in RFC 2385. These services are intended
> to detect and reject active wiretapping attacks against the
> inter-router TCP connections. Absent use of mechanisms that effect
> these security services, attackers can disrupt these TCP connections
> and/or masquerade as a legitimate peer router. Because the mechanism
> defined in the RFC does not provide peer-entity authentication,
> these connections are still subject to some forms of replay attacks.
>
> The mechanism defined in RFC 2385 augments the normal TCP checksum
> with a 16-byte message authentication code (MAC) that is computed
> over the same data as the TCP checksum. This MAC is based on a
> one-way hash function (MD5) and use of a secret key. The key is
> shared between peer routers and is used to generate MAC values that
> are not readily computed by an attacker who does not have access
> to the key. A compliant implementation must support this mechanism,
> and must allow a network administrator to activate it on a per-peer
> basis.
>
> RFC 2385 does not specify a means of managing (e.g., generating
> and distributing) the keys used to compute the MAC. A different
> key should be used for each protected peer. If the same key is used
> for multiple peers, the offered security services are degraded.
> (In fact, the reuse of the same key with the same peer for multiple
> TCP connections already represents a vulnerability, as noted above.)
> Obviously, each key also should be chosen so as to be hard for an
> attacker to guess. The techniques specified in RFC 1750 for random
> number generation provide a guide for generation of values that
> could be used as keys. Keys also should be changed periodically,
> to minimize the impact of a key compromise or successful cryptanalytic
> attack.
>
> RFC 2385 calls for implementations to support keys "composed of a
> string of printable ASCII of 80 bytes or less ." While it is
> difficult to specify an appropriate key size for a wide range of
> environments, it is worth noting that current standards for analogous
> integrity algorithms make use of key sizes of about 128-256 bits.
> An 80-byte, printable ASCII string, falls into this range.
>
> If there are any objections to adding this text to the protocol
> spec please post them to the list by May 24, 2004.
>
> Yakov.
Yakov,
This is a stretch. Regardless, I suggest we include this exactly as
Steve suggested unless any part of it can be shown to be false.
> Because the mechanism
> defined in the RFC does not provide peer-entity authentication,
> these connections are still subject to some forms of replay
> attacks.
A replay attack involves sending information later on when it is no
longer valid. Since the TCP sequence number is covered by the TCP
checksum, and therefore MD5 digest that replaces it, a replay attack
is not possible. It also covers address and port so you can't read
from one connection and replay on another.
If Steve means that a DoS is possible by sending the same valid packet
over and over, even though TCP will ignore the resend of data prior to
the sequence number, then the above statement should either be dropped
or changed to state that a DoS attack is possible which does no damage
other than increase CPU loading.
Unless Steve can tell us how a replay attack is possible, then this
sentence should be removed. If it is a false statement, it needs to
be removed.
Curtis
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr