[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-ikev2-04.txt

Charlie_Kaufman@xxxxxxxxxxxxxxxx wrote:
> I'd particularly like experts on NAT traversal to review what I said and
> tell me how to fix it. I tried to copy the logic from the existing I-Ds,
> but can't be sure I got it right.

You can have some comments below, and other NAT-trav. authors will be
able to fill in what's left out.

>
> It also includes only a single option for cipher suites. There is general
> agreement that we need more, but I need concrete proposals on what they
> should be. Currently specified is:
>
> 1536-bit Diffie-Hellman; 112-bit 3DES CBC; HMAC-SHA1; ESP.

Why 2-key 3DES? Why not 3-key? In my view a sufficient minimum would be these
two suites:
  1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP.
  1536-bit Diffie-Hellman; 128-bit AES CBC; HMAC-SHA1; ESP.

Before getting into NAT traversal, a comment about the configuration
payload. It's easy to see how initiator would send CFG_REQUESTs in
message 3 and receive responses in message 4, but if you allow for
CFG_SETs, their obvious location would be that responder sends
CFG_SETs in message 4, and this would force the IKEv2 exchange
to become longer. Otherwise the initiator is unable to send CFG_ACKs.

Also, IMHO, INTERNAL_ADDRESS_EXPIRY attribute should not exist. It's
a way to negotiate connection lifetime. It would be more in the spirit
of IKEv2 if the GW would enforce this by forcing a connection re-key
and would CFG_SET a new IP address if it needs to change (both in the
same message pair).

> 3.1.2 Endpoint to Endpoint Transport
>
>    It is possible in this scenario that one of the protected endpoints
                                               ^ or both

Static NAT at responder is likely relatively common.

>    will be behind a network address translation (NAT) node, in which
>    case the tunnelled packets will have to be UDP encapsulated so that
                                 ^^^^^^^^^^^^

It is unclear to me if the intention is to say that ESP packets MUST be
UDP-encapsulated when a NAT is detected. Note that ESP-tunnel mode packets
may work fine through some NATs without any UDP-encapsulation.
It would be clearest to mandate UDP-encapsulation.

>    port numbers in the UDP headers can be used to identify individual
>    endpoints "behind" the NAT.

> 3.1.3 Endpoint to Gateway Transport

>    In this scenario, it is possible that the protected endpoint will be
>    behind a NAT. In that case, the IP address as seen by the gateway
>    will not be the same as the IP address sent by the protected
>    endpoint, and packets will have to be UDP encapsulated in order to be
>    routed properly.

ditto

> 4 IKE Protocol Details and Variations
>
>    IKE normally listens on UDP port 500, though IKE messages may also be
>    received on UDP port 4500 with a slightly different format.

This is somewhat vague.. I would like this to say that IKEv2 implemenations
MUST be able to receive messages both on port 500 and port 4500, and that
they MAY initiate either to port 500 or to port 4500. If they initiate
on port 500, and NAT is detected, at some point they MUST float to port 4500
and stay there, exact details of floating TBD.

It's unclear how the NAT-trav. negotiation is supposed to work.
In IKEv1 both endpoints send two NAT-D payloads to each other, after
which they both know if there's a NAT in between or not. Then they
may float to 4500. They then negotiate to UDP-encapsulation by using
	UDP-Encapsulated-Tunnel         3
	UDP-Encapsulated-Transport      4

I wouldn't like to see a similar negotiation in IKEv2, i.e. I wouldn't
like to have these two types of suites:
  1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP.
  1536-bit Diffie-Hellman; 168-bit 3DES CBC; HMAC-SHA1; ESP-UDP.
A better way would be that in message 3 initiator sends the
NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP notifies,
and message 4 the responder also sends them. (If initiator sends
them, the responder MUST also send them.) Then, if a NAT is detected
UDP-encapsulation MUST be used, and any further IKEv2 message would
be to port 4500 (including possible messages 5,6 of the initial neg.,
maybe.)
Alternatively responder could send in message 4 that UDP-ENCAPSULATION-SELECTED.

Unsettled issues include also:
- Do we need to support transport mode for IKEv2 NAT-trav. If yes,
   NAT-OAs need to be specified and when they're to be sent.
   It may not be needed since L2TP/IPSEC MAY use tunnel mode, as
   I've recently learned.
- NAT keepalive format and sending rules are missing.
- NAT-trav. related encapsulation and decapsulation procedures
   need to be copied to this document.
- NAT traversal related security considerations need to be copied
   to this document.

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