Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt
As comments are made on this, I'm planning to put any issues identified into
the issue tracker that'll be linked from our IETF tools page:
http://tools.ietf.org/wg/tcpm/
that Henrik just nicely setup for us. If there are current issues people have
with version 04 of the draft, and you send them to me or the list, I'll enter
them in.
This will be a little new for TCPM, but I think it'll help keep track of things
as we finish the document off.
________________________________________
From: tcpm-bounces at ietf.org [tcpm-bounces at ietf.org] On Behalf Of Joe Touch [touch at ISI.EDU]
Sent: Monday, March 09, 2009 3:19 PM
To: tcpm at ietf.org
Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-04.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, all,
The changes to this document are summarized in the document; they
include a major restructuring for readability, the addition of a key
change coordination mechanism, and a clearer description of the purpose
of the TSAD (now called the TAPD).
Comments welcome, of course. Please do read this through, though - most
if the doc has changed (hopefully for the better).
The primary current open issue for SFO regards whether the key
coordination mechanism requires support to prevent "backup" (changing
back to a key previously used).
FYI.
Joe
Internet-Drafts at ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.
>
>
> Title : The TCP Authentication Option
> Author(s) : J. Touch, et al.
> Filename : draft-ietf-tcpm-tcp-auth-opt-04.txt
> Pages : 48
> Date : 2009-03-09
>
> This document specifies the TCP Authentication Option (TCP-AO), which
> obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO
> specifies the use of stronger Message Authentication Codes (MACs),
> protects against replays even for long-lived TCP connections, and
> provides more details on the association of security with TCP
> connections than TCP MD5. TCP-AO is compatible with either static
> master key configuration or an external, out-of-band master key
> management mechanism; in either case, TCP-AO also protects
> connections when using the same master key across repeated instances
> of a connection, using traffic keys derived from the master key, and
> coordinates key changes between endpoints. The result is intended to
> support current infrastructure uses of TCP MD5, such as to protect
> long-lived connections (as used, e.g., in BGP and LDP), and to
> support a larger set of MACs with minimal other system and
> operational changes. TCP-AO uses its own option identifier, even
> though used mutually exclusive of TCP MD5 on a given TCP connection.
> TCP-AO supports IPv6, and is fully compatible with the requirements
> for the replacement of TCP MD5.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm1a9wACgkQE5f5cImnZrtLSACgg0pamhFBN48BfHAQiVJlfc20
DPoAoIWbj0jCdkvrXfVyG+jATgvaBC27
=2EjV
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.