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