Re: issue 34 proposal

> 
>  In your previous mail you wrote:
> 
>    If no RR test (with NATD payloads) is done *before* switching, then
>    consider me opposed to this solution.
>    
> => we are speaking about ESP so I don't understand the "with 
> NATD payloads" (BTW with NATD payloads only the real source 
> can put a fake address as they are protected).

What I'm saying is that if I detect a NAT change at the ESP layer, I'd
want to send an IKE packet (with NATD payloads) to the peer to make SURE
he can both recv/send packets from/to that address before I start using
it.  Yes this adds a little extra latency (1 round trip).  But this
leaves no doubt that the peer is at least reachable on that address.


> 
>    In fact, I'm beginning to think that ESP detection might cause more
>    problems than it solves...
>    
> => ESP detection is in IKEv2, if you believe it you should 
> have objected during the IKEv2 last call.

I think we must be talking about different things.  I see nothing in the
ikev2-17 that describes how NAT decisions are made using ESP packets.
All I see is text describing how to use ISAKMP NAT-D payloads to detect
if a NAT box is present in the network.  The draft is rather large, so I
may have missed it.  Can you point me to some text that describes how
ESP pkts are used to detect a NAT, or a NAT mapping change?



> 
> Regards
> 
> [email protected]
> 
> PS: BTW I believe the ESP detection is the right mechanism 
> for the implicit update of NAT-T.
>