Subject: [tcpm] Authentication Option Combined WGLC

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 3 Nov 2009 14:17:30 -0600

David and I would like to start a combined Working Group Last Call on
the two documents related to the TCP Authentication Option to be
submitted for Proposed Standard:

The TCP Authentication Option
http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-08.txt

Cryptographic Algorithms for TCP's Authentication Option, TCP-AO
http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt

This WGLC will last 3 weeks, ending on November 24.  Please submit
comments the list.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 3 Nov 2009 15:45:57 -0700

This makes TCP-AO of little value to protect against spoofed source resets within the window size of the current Ack number.

"TCP-AO, like TCP MD5, may inhibit connectionless resets. Such resets
   typically occur after peer crashes, either in response to new
   connection attempts or when data is sent on stale connections; in
   either case, the recovering endpoint may lack the connection key
   required (e.g., if lost during the crash). This may result in time-
   outs, rather than more responsive recovery after such a crash. As
Touch                   Expires April 27, 2010                [Page 39]
Internet-Draft   The TCP Simple Authentication Option      October 2009
   noted in Section 7.2, such cases may also result in persistent TCP
   state for old connections that cannot be cleared, and so
   implementations should be capable of detecting an excess of such
   connections and clearing their state if needed to protect memory
   utilization [Ba09]."

The BIGGEST problem with the current MD5 implementation isn't the algorithm being used its the fact that implementers of BGP took the original md5 statement about connection resets to mean they didn't have to send resets with AUTH. It was an easy out for them and very few vendors do the lookups needed to do an authenticated reset if no connection state exists in their state table.

It is not hard for a bgp speaker to first check to see if a packet with src_port or dst_port is 179 and coming from a neighbor. In cases where a non-initial packet is coming from a neighbor if there is no current state for that connection the router has all the information needed (current packet plus M the shared key) to send an authenticated reset.

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon]
> Sent: Tuesday, November 03, 2009 1:18 PM
> To: [email-masked]
> Subject: [tcpm] Authentication Option Combined WGLC
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Nov 2009 15:25:52 -0800

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?

(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.)

> The BIGGEST problem with the current MD5 implementation isn't the
> algorithm being used its the fact that implementers of BGP took the
> original md5 statement about connection resets to mean they didn't have
> to send resets with AUTH. It was an easy out for them and very few
> vendors do the lookups needed to do an authenticated reset if no
> connection state exists in their state table.

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

- - if the endpoint doesn't think the connection is TCP-AO protected, the
reset will work as usual

> It is not hard for a bgp speaker to first check to see if a packet
> with src_port or dst_port is 179 and coming from a neighbor. In cases
> where a non-initial packet is coming from a neighbor if there is no
> current state for that connection the router has all the information
> needed (current packet plus M the shared key) to send an authenticated
> reset.

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
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 so, does the doc need to be updated to clarify?

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 3 Nov 2009 16:58:03 -0700

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, November 03, 2009 4:26 PM
> To: Smith, Donald
> Cc: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; [email-masked]'
> Subject: Re: [tcpm] Authentication Option Combined WGLC
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Smith, Donald wrote:
It will drop the spoofed resets and the connectionless resets too.
Thus many ISPs will not enable it.

> 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.

> 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.

> 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.
There is even an AUTH so the rebooted bgp speaker "knows" this is coming from a neighbor with AUTH enabled.

> - - 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.
The incoming keep alive or other traffic has all but the MKTs (shared secret).

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkrwvAAACgkQE5f5cImnZrvglQCfcXPiB056c/qsqihAM4iTu/iF
> O4AAn19gXhiOTvdBeNbj87uyWA36eqFp
> =sRuk
> -----END PGP SIGNATURE-----
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 03 Nov 2009 17:26:08 -0800

Hi, Donald,

...
> 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.

> 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.

...
> 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.

...
> 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).

> 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