Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-04 [This time for sure]

["Eddy, Wesley M. (GRC-RCN0)[Verizon]" <wesley.m.eddy at nasa.gov>]

>-----Original Message-----
>From: tcpm-bounces at ietf.org [mailto:tcpm-bounces at ietf.org] On 
>Behalf Of Joe Touch
>Sent: Monday, March 23, 2009 10:38 AM
>
> ...
>
>>>
>>> Whenever the keyID appears in a segment (sent or received), 
>that tuple
>>> is used to validate the contents. As per the most recent 
>coordination,
>>> keyIDs are bidirectional, so there is no send or receive difference.
>> 
>> It was not my understanding that we agreed that key-ids were 
>bidirectional.
>> Rather, I believe we agreed that MKTs were bidirectional and that
>> there was a separate key-id in each direction, to address Russ's
>> concern.
>
>Russ can clarify. First, let's clarify some terms:
>
>key-id = a digit in [0..255] that, together with a connection's socket
>pair (as per RFC793, i.e., srcIP, dstIP, srcport, dstport) indicates a
>single MKT.
>
>key-id field = the value in the TCP-AO option
>
>key-id fields are unidirectional - they indicate the key-id used to
>authenticate that TCP segment
>
>key-ids are bidirectional - they indicate (with the socket pair) a MKT
>that can be used in either direction
>
>However, there is no utility in referring to the same MKT with 
>different
>key-id values for the different directions of a single connection.
>


This set of definitions makes sense to me, and I think it clarifies
what we mean by bidirectional versus unidirectional, which was what
seemed to be a major point of disconnect in conversation.  Eric or
Russ, do you agree?


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------