Re: [tcpm] closing WGLC for TCP-AO

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Anantha,

Anantha Ramaiah (ananth) wrote:
> Maybe I missing something here, I haven't seen any responses for this
> WGLC, typically if that is the case, I have seen the urge to ask folks
> to read and even they don't have any comments "I have read it, it is
> fine". No such thing seem to have happened for this case. May be I
> missed some responses.

There was one response from Donald Smith on 11/3. I didn't see any
confirming responses, but we haven't required that during last calls AFAIR.

> IMO, this TCP-AO option needs to have an "Applicability statement". The
> typical advise whenever one tries to make TCP robust or provide TCP
> security has always been "use IPSec" and such an argument has derailed
> any changes that improve TCP's robustness and resulted in endless
> debates in the past in TCPM.  The rationale of having TCP-AO stems from
> the fact that "some applications can't use IPsec due to n number of
> reasons", TCP-MD5 came into play which is now being replaced by the TCP
> AO option. But not all applications/devices would want to use this
> option neither should it be encouraged to use this option, if one were
> to go by the "IPsec mantra".  So, I would like to have an AS put in the
> doc which states the circumstances (long lived connections),
> applications (like BGP) and devices (routers) where the usage of this
> TCP option is recommended.

Although there is no section entitled "Applicability Statement", the
text you're seeking is already contained in the third paragraph of the
Introduction (sec 2).

> TCP secure document has an AS which can be
> used as a template, if needed. Also I would want a paragraph which
> explains why IPsec cannot
>  be used (even though the document contains pointers to earlier
> motivation document, I would rather prefer this to be made
> self-contained in this document.) 
> 
> The introduction does have something to this effect, but sounds too
> general and not specific.

It's quite specific. Use TCP-AO where authentication is needed and IPsec
is not desired or where keys need to be bound to connections. That's
about as specific as it gets.

> As far as the NAT document goes, there seems to be rush here in folding
> this along with the TCP-AO. The NAT document doesn't even show up in
> this TCPM charter page, FWIW.

There has always been interest in considering NAT support for TCP-AO,
and it has been discussed many times. Until we developed the
master/traffic key mechanism based on the ISNs, however, it wasn't feasible.

The NAT mechanism was posted to this list 7/30. You commented on it 8/7.
I don't understand your claim that this has been a rush. Keep in mind
that the time needed to evaluate it ought to be commensurate with its
complexity. It just zeroes out the ports, and explains why that's
feasible given how traffic keys are now derived.

> Regarding the NAT document, I have some general questions :
> 
> - how many clients are there that are behind NAT and still would want to
> use this option?. The currently used TCP-MD5 option didn't face such an
> issue, in other words NAT compatibility was the least bothering issue,
> IMO.

TCP-AO is intended to be a general mechanism. In that regard, if we can
support NAT traversal without substantial complexity, then we should.
Zeroing the ports prior to HMAC calculation seems a fairly low level of
complexity.

> - Also the document says it reduces the entropy and advises the both
> localNAT/remoteNAT should not be turned on. Hoe can you detect
> mis-configurations? What happens when someone configures this on the
> middle of the connection?

TCP-AO is not a security configuration negotiation protocol.
Misconfigurations result in dropped segments, as they would in any protocol.

If someone turns this on in the middle of a connection the port fields
aren't protected by the authentication algorithm, but it won't help much
to change them on the fly. They'll just be dropped because their traffic
keys won't match those of other connections (with very high probability).

> I have a feeling that the NAT solution proposed has not been discussed
> thoroughly (there have been lot of discussions before that, but after
> the NAT document was written, there was some support to fold this
> content with the TCP-AO, agreed)  but it seems like we are rushing this
> part, IMO.

It has been out on the list for 3 months, with discussion, and was
included in the request for the last call.

Joe

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>> Sent: Tuesday, December 01, 2009 1:42 PM
>> To: [e-mail]
>> Cc: Joe Touch
>> Subject: [tcpm] closing WGLC for TCP-AO
>>
>> The period for the working group last call on the AO 
>> documents has passed.  I didn't see any major issues that 
>> were identified.
>> Even though the response was light, given the large amount of 
>> discussion that's gone into it to reach this point, I think 
>> this is okay to proceed; we'll write the PROTO statements if 
>> the authors can rev the drafts based on any feedback they got.
>>
>> One additional question that was open was whether the NAT 
>> draft of Joe's should be rolled in.  Since several people 
>> supported this, and none were against it, I think Joe should 
>> go ahead and include it before it gets sent to the IESG.
>>
>> My late, and minor, comments on the AO and crypto drafts are 
>> below, as a WG participant.
>>
>>
>> On the main AO draft
>> ====================
>>
>> 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."
>>
>> 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.
>>
>> 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,"
>>
>> 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:"
>>
>> 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.
>>
>>
>>
>> On the AO crypto draft
>> ======================
>>
>> 1) editorial, in abstract:
>> "algorithm(s)" -> "algorithms" ?
>>
>> 2) editorial, in Section 1:
>> "to TCP-AO [TCP-AO] [I-D.ietf-tcpm-tcp-auth-opt]."
>> ->
>> "to TCP-AO [I-D.ietf-tcpm-tcp-auth-opt]."
>>
>> 3) editorial, in Section 1:
>> "two key derivations functions"
>> ->
>> "two key derivation functions"
>>
>> 4) editorial, in section 2.2:
>> "Security Area Directors"
>> ->
>> "IETF Security Area Directors"
>>
>> 5) editorial/technical, in section 2.2:
>> "especially given that the tags are truncated to 96 bits"
>> ->
>> "even though the tags are truncated to 96 bits"
>> ???
>>
>> 6) editorial/technical, in section 2.2:
>> "aren't practical on SHA-1"
>> ->
>> "aren't practical on HMAC-SHA-1"
>> ???
>>
>> 7) editorial, section 7.1:
>> use of Output_Length included here is not consistent with the 
>> way that the main auth-opt draft defines this.
>>
>> 8) editorial, section 3.1.1:
>> "Each"
>> ->
>> ""
>>
>> 9) editorial, figure 1:
>> formatting of top line is off
>>
>>
>> --
>> Wes Eddy
>> MTI Systems
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAksWIOgACgkQE5f5cImnZrtzjgCeKOafyj8D3w6gV+mbqeXidI9P
gqgAn3tUFiZjoQnFHuUmNFWQKZBcJRR7
=0xzb
-----END PGP SIGNATURE-----