Subject: [tcpm] TCP-AO 09 posted

From: Joe Touch <[email-masked]>
Date: Sun, 31 Jan 2010 15:17:11 -0800

The following updates have been made to TCP-AO, and a new draft (09)
submitted.

Hi, all,

An updated version (09) of TCP-AO has been submitted.

To the WG chairs - please let me know if this version addresses the
comments raised.

The announcement should appear on the list shortly.

Joe

---------------------------------------

*) update header/footer to match title, author list

Done.

*) add an applicability statement

Done. See new Section 2.1

*) update the traffic key security strength discussion

Done, though this affects the NAT doc (status indicated separately) more
than AO.

*) addressing connectionless resets

See new Section 9.7.

*) largely editorial input from Wes, as addressed below.

> 1) editorial - in Abstract:
> "TCP-AO uses its own option identifier, even though used mutually
>  exclusive of TCP MD5 on a given TCP connection."
> could this just be:
> "TCP-AO uses a separate option identifier from TCP MD5 and the
>  two options are not capable of being used at the same time."

Updated, reworded slightly as:
"TCP-AO uses a different option identifier than TCP MD5, even though
TCP-AO and TCP MD5 are never permitted to be used simultaneously."

> 2) editorial, in Figure 1 (section 4.1):
> It's probably clear to everyone that the MD5 digest field wraps through
> the remainder of the option length, but could a "..." or "... (cont.)"
> be added to the empty areas to make that explicit?  The way it's shown
> in Figure 2 is nice, I think.'

Done.

> 3) editorial, in section 5.2:
> "derived from the MKT and the properties of a connection.  For
>  established connections, these properties include the socket pair
>  (local IP address, local TCP port, remote IP address, remote port),"
> could be:
> "derived from the MKT and the local and remote pairs of IP addresses
>  and TCP port numbers,"

Updated as:

A traffic key is a key derived from the MKT and the local and remote IP
address pairs and TCP port numbers, and, for established connections,
the TCP Initial Sequence Numbers (ISNs) in each direction. Segments
exchanged before a connection is established use the same information,
substituting zero for unknown values (e.g., ISNs not yet coordinated).

> 4) technical/editorial in section 5.2:
> I think this is just a typo, but to make sure ...:
> "A single MKT can be used to derive any of four different MKTs:"
> should be:
> "A single MKT can be used to derive any of four different traffic keys:"

Yes, fixed as noted.

> 5) editorial, in section 7.2:
> The heading is "Key Derivation Functions", I think it would be better
> as "Traffic Key Derivation Functions", as it doesn't discuss the
> derivation of master keys.

Done.

-----------

---

From: Joe Touch <[email-masked]>
Date: Sun, 31 Jan 2010 15:40:21 -0800

FYI - the NAT extensions doc has also just been updated to address the

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 31 Jan 2010 16:28:52 -0800

Additional updates (sorry I didn't get these in the previous one):

- ICMP hard error defaults included (moved out of security
considerations, now a new section 9.8)

- discuss ISN randomization in more detail

This version should include all pending WGLC items.

Joe