![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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