Re: draft-ietf-ipsec-ikev2-05.txt comments

[Tero Kivinen <kivinen@ssh.fi>]

Francis Dupont writes:
> => perhaps it is too easy:
>  - it is less secure than at the end of IKE_AUTH

Can you explain why (except that sending the discovery notifications
in clear text packet)?

>  - it doesn't work if the responder is behind a NAT

It should work fine in that case too. There is nothing special
whichever end is behind NAT. Initiator will detect if either end is
behind NAT and will then switch to new port and if the responder is
behind NAT it must either be statically configured NAT (i.e both port
500 and 4500 going to that machine behind NAT), or initiator found out
the address of the other end from some directory service and in that
case it should also put in bit saying that it is behind NAT, and the
initiator should start with port 4500 directly.

>  - it doesn't work if the responder doesn't implement NAT-T
>    (i.e., if it is not ready to receive packets on UDP 4500)

If it does not support NAT-T then there is nothing we can do if there
is NAT between. 

>  - the detection is made only by the initiator

No, both ends will know which ends are behind NAT after the
IKE_SA_INIT. 

> => in my proposal, the node behind the NAT (usually the initiator but
> this is not necessary) must send a packet as soon as SAs are up.

This complicates the state machine more...

> => it does matter if it wants to protect itself against attacks using
> a spoofed source peer address.

It has nothing to do with NAT-T, the responder must reply back to the
address where the packet was requested anyway, and it should rate
limit replies anyways. 

>    For the initiator it is also quite easy, simply switch the source and
>    destination port to 4500 when it detects NAT, and use them from that
>    on. 
>    
> => and what happens if the responder is behind the NAT? You assume
> the mapping is the same of ports 500 and 4500.

If the machine is behind NAT then there either MUST be statically
configured NAT, and it needs to map both 500 and 4500 to work or it
must be published somewhere and in those cases you can directly say
that this is behind NAT, use port 4500 directly.

>    The responder can be behind NAT, but in such case the initiator needs
>    to find the external address of the NAT box to start the exchange in
>    first place. Also the NAT must normally be kind of static NAT.
> => this is less general, i.e., we should find real world cases where
> it doesn't work.

I do not think there are real world cases where the responder is
behind NAT, especialy dynamic NATs :-)

Static NATs are not a problem as there you just map both 500 and 4500. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/