Re: [tcpm] Authentication Option Combined WGLC

["Smith, Donald" <Donald.Smith at qwest.com>]

(coffee != sleep) & (!coffee == sleep)
Donald.Smith at qwest.com gcia

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Tuesday, November 03, 2009 4:26 PM
> To: Smith, Donald
> Cc: 'Eddy, Wesley M. (GRC-MS00)[Verizon]'; 'tcpm at ietf.org'
> Subject: Re: [tcpm] Authentication Option Combined WGLC
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> 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.
Thus many ISPs will not enable it.

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

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

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

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

>
> - - if so, does the doc need to be updated to clarify?
>
> Joe
>
> >> -----Original Message-----
> >> From: tcpm-bounces at ietf.org [mailto:tcpm-bounces at ietf.org] On
> >> Behalf Of Eddy, Wesley M. (GRC-MS00)[Verizon]
> >> Sent: Tuesday, November 03, 2009 1:18 PM
> >> To: tcpm at ietf.org
> >> Subject: [tcpm] Authentication Option Combined WGLC
> >>
> >> 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
> >> ---------------------------
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm at ietf.org
> >> 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.
> > _______________________________________________
> > tcpm mailing list
> > tcpm at ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkrwvAAACgkQE5f5cImnZrvglQCfcXPiB056c/qsqihAM4iTu/iF
> O4AAn19gXhiOTvdBeNbj87uyWA36eqFp
> =sRuk
> -----END PGP SIGNATURE-----
>

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.