Re: bidding down attach on NAT-T

[Ari Huttunen <Ari.Huttunen@f-secure.com>]

Charlie_Kaufman@notesdev.ibm.com wrote:
> 
> 
> 
> Francis Dupont <Francis.Dupont@enst-bretagne.fr> wrote:
> 
>>Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
>>with it (I am *not*)?
> 
> 
> Please do, everyone. I tried to copy the philosophy of the NAT-T documents
> into IKEv2, but I may have gotten it wrong and the documents I copied may
> have been wrong. Proofreading by people knowledgeable in this space is
> vital.
> 
> For example, I was just rereading ESP encapsulation and it is different
> than I remembered and different than what I wrote in IKEv2-05. It's a
> detail, but it's important. How does a packet sent to UDP port 4500 get
> identified as ESP or IKE. What I remember (and wrote) was that IKE messages
> have four bytes of zero prepended and ESP SPIs are not allowed to be zero.
> This leads to no overhead for ESP and 4 bytes for IKE. But reading
> draft-ietf-udp-encaps-01.txt (April 2002), it calls for eight bytes of zero
> prepended to ESP packets and IKE SPIs are not allowed to be zero. This
> results in no overhead for IKE packets and 8 bytes for ESP. Did this change
> somewhere along the line, and if so which proposal won? Either design
> works, but they can't be mixed on a single port.

Yes, most of the design decisions have changed at least a couple
of times, along the line. That's a long line too. You should be reading
the latest documents like this
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-06.txt

> 
> 
>>   I do think that NAT-T support should be required.
>>
>>=> I have no objection but:
>> - configuration must have a knob to disable NAT-T support
>> - NAT detection must be secure.
>>
>>   You never know when there will be a NAT between you and your peer.
>>
>>=> I agree but there are some cases where you don't want to support
>>a NAT between you and your peer.
> 
> 
> Currently ikev2-05 says that NAT support is optional in an IKE
> implementation. There are other statements that could be made. It could say
> that implementations MUST support NAT-T but that it MAY be configured off.
> It could say that if an implementation supports NAT-T, then it MUST have a
> configuration switch to turn it off.
> 
> I don't have strong feelings. My priorities are keeping the MUST features
> minimal while assuring that any two implementations with the MUST features
> can be configured to interoperate. How important is it for everyone to
> support NAT-T?

I'd say the MUST part is recognizing NAT-T related payloads and being
able say to the other guy that no-NAT-T-spoken here. I'd also like there
to be no VIDs for that purpose, so you'd be able to put NAT-T payloads
in whatever message is most suitable. Still, I'd say that
it would be highly desirable for IKEv2 to just work in spite of NATs.

As to the details, I think I'll pass that. I just don't have time/interest
to do that, and I'd just get some part wrong.

Ari

-- 
I play it cool and dig all jive,
  that's the reason I stay alive.
   My motto as I live and learn,
    is dig and be dug in return. <Langston Hughes>

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com

F(ully)-Secure products: Securing the Mobile Enterprise