Re: [tcpm] Authentication Option Combined WGLC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?

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

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

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

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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.