Re: issue 34 proposal

I had indeed missed that text.  Thanks.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] 
> Sent: Wednesday, September 28, 2005 2:52 AM
> To: Stephane Beaulieu (stephane)
> Cc: [email protected]; Jari Arkko; [email protected]; 
> Tero Kivinen
> Subject: Re: [Mobike] issue 34 proposal 
> 
>  In your previous mail you wrote:
> 
>    > => 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
> 
> => how NAT-T/implicit update (ESP detection is a part of it) 
> and MOBIKE/explicit update can interfere is a closed point 
> (which both has no interest for me and does what you like).
> 
>    >    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.
> 
> => it is at the end of 2.23 page 39:
> 
>       There are cases where a NAT box decides to remove mappings that
>       are still alive (for example, the keepalive interval is 
> too long,
>       or the NAT box is rebooted). To recover in these cases, 
> hosts that
>       are not behind a NAT SHOULD send all packets (including
>       retransmission packets) to the IP address and port from the last
>       valid authenticated packet from the other end (i.e., dynamically
>       update the address). A host behind a NAT SHOULD NOT do this
>       because it opens a DoS attack possibility. Any authenticated IKE
>       packet or any authenticated UDP encapsulated ESP packet can be
>       used to detect that the IP address or the port has changed.
> 
>       Note that similar but probably not identical actions will likely
>       be needed to make IKE work with Mobile IP, but such 
> processing is
>       not addressed by this document.
> 
>    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?
>    
> => now you have the text about NAT mapping change detection, 
> including IKE, ESP and implicit update. And in a past message 
> in this list you have the decision (and proposed text) about 
> application of this in a mixed NAT-T/MOBIKE context:
>     References: 
> <[email protected]>
> 
>     Based on discussion, it appears that most people prefer
>     the following:
> 
>        1) NAT-detection payload -based NAT reboot/change detection
>        as a complement to existing source address -based
>        mechanisms. This mechanism would be used if MOBIKE
>        is on, because otherwise MOBIKE probing would become
>        harder.
> 
>        Detection would be done by including NAT detection
>        payloads in dead peer detection messages.
> 
>        Existing source address -based detection is still allowed in
>        limited manner:  "MUST NOT do automatic update with
>        IKEv2 packets when MOBIKE is used (breaks the probing),
>        but you MAY do it for ESP packets."
> 
>        2) Use IKE messages for the path testing that is needed
>        in MOBIKE.
> 
>     I (Jari) have specifically left out the conclusion about whether
>     to do return routability after a NAT change is detected.
>     I'm hoping its covered by the policy that we already have
>     for return routability usage. If people disagree about this
>     we'll open a separate issue on it.
> 
> Regards
> 
> [email protected]
>