Re: issue 34 -- ESP vs. IKE based NAT reboot detection

"Mohan Parthasarathy" <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <005801c5a45e$b978ccf0$6701a8c0@adithya>
 

> On Tue, 2005-08-16 at 09:04, Jari Arkko wrote:
> > Alt 1: The approach in -01 which retains what IKEv2 does
> > when NAT mappings change. I.e., there's a SHOULD in the
> > IKEv2 spec that allows implementations to update mappings
> > based on what they see happening for the UDP-encapsulated
> > ESP packets.
> > 
> > Alt 3: Tero's approach, which says not to use this feature
> > in IKEv2 when MOBIKE is employed, and instead relies on
> > periodic IKE probes.
> 
> Assume you're implementing both IKEv2 NAT traversal as well as mobike,
> with mobike use being optional.
> 
> Either alternative presumably needs a notification from ESP to key
> management that NAT-level "motion" has been detected, but alternative 3.
>
Why does alternative 3 require this notification ?

> also seems to require a "mode bit" in ESP indicating when you should let
> ESP handle the address updates and when it should ignore them.
> 
> I'd rather avoid that complexity.
> 
Is this not a per-SA bit ? If MOBIKE is used and the bit indicates such, then
don't update the SA and don't send the trigger to IKE if you use alt.3. If NAT
traversal is used and MOBIKE is not used, then update and send trigger.
Why is it complex ? I am missing something.

thanks
mohan

> - Bill
> 
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.