Re: [tcpm] Authentication Option Combined WGLC

[Joe Touch <touch at ISI.EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Donald,


...
>> > Smith, Donald wrote:
>>> > > This makes TCP-AO of little value to protect against spoofed source
>>> > > resets within the window size of the current Ack number.
>> >
>> > TCP-AO will drop spoofed resets, because the signature won't
>> > match. How
>> > is that not protected?
>
> It will drop the spoofed resets and the connectionless resets too.

That's the point - connectionless resets cannot be distinguished from
spoofed ones. Either both are dropped - which is secure, but can cause
buildup if endpoints restart frequently, or both are allowed - which is
a security hole.

> Thus many ISPs will not enable it.

I don't see this as a configurable option. It's discussed, but IMO both
MUST be dropped.

>> > (the note below focuses on connectionless resets, e.g., after
>> > a reboot,
>> > when state from previous connections - such as the ISNs on which the
>> > traffic keys are based - is lost.)
>
> ISN may be lost but a keep alive or any other packet from your peer
> has all the information you need excluding the shared secret.

The traffic key is computed using the ISN pair and the SNEs. Those are
not available in-band - they're initialized at connection start (ISNs as
exchanged, SNEs to 0) and maintained during the connection. They are not
available in any segment information.

...
>> > If you send resets without the AUTH, one of two things will be true:
>> >
>> > - - if the endpoint still thinks the connection is TCP-AO
>> > protected, it
>> > will drop the reset silently
>
> In a connectionless reset it will think the end point is still protected.
> It has no way to know that the other end has rebooted/reset its bgp.

The packets won't be ACKd - ever. There will be no RST. Eventually, TCP
will time-out and close the connection, since it has data to send and
the other end is failing to respond - see RFC 1122 Sec. 4.2.3.5.

...
>> > That presumes it has the ISNs and the SNEs. Without those -
>> > e.g., after
>> > a reboot - the reset MUST be dropped if the connection remains
>
> It has them. They are in the next packet the bgp speaker that didn't reboot/reset sends.

ISNs are sent during the SYN exchange only. They cannot be determined
from other segments. SNEs are never sent on the wire, and the BGP
speaker may know the SNEs for both ends, but there is no way to
communicate this to the receiver.

> There is even an AUTH so the rebooted bgp speaker "knows" this is coming from a neighbor with AUTH enabled.

Yes, but it doesn't have sufficient information to calculate the traffic
key needed to verify the segment, so the segment will be dropped before
*any* action is taken (including 'knowing' whether the other side has
AUTH enabled - that is on a per-connection basis only, and acting on
*any* non-verified segment would pose a security hole).

>> > protected. Such stale connections need to be cleaned up using out of
>> > band techniques (timer based garbage collection).
>> >
>> > Note that if you retain the ISNs and SNEs, as well as the MKTs - e.g.,
>> > in persistent storage - then you can recover from a reboot and
>> > authenticate resets fine.
>> >
>> > Two questions:
>> >
>> > - - does this address your concern?
>
> If you mean storing ISN and SNE (along with MKTs which have to be stored in persistent storage)
> this could address it but I don't think its required.

As per above, it seems to be. SNEs need to be updated when they
increment too.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkrw2DAACgkQE5f5cImnZrsQAgCguUy84xA+wHEtOGKpL3c3PN4A
NUIAnjSxL7T9FZasCNc2n93cvpI+5QGz
=ekXX
-----END PGP SIGNATURE-----