[tcpm] TCP-AO 10 posted

[Joe Touch <touch at ISI.EDU>]

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

Joe Touch wrote:
> 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.
> 
> -----------
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature