Re: Issue 47: More comments from Mohan (was: Comments ondraft-ietf-mobike-protocol-03.txt)

 > > The reasoning is that updating the addresses in IPsec SAs and
> > enabling/disabling NAT Traversal go together: if you don't do RR
> > check, you do both immediately; but if you wait for the RR check to
> > finish, you also don't toggle NAT-T before you've updated the
> > addresses in the SA.
> > 
Ah! that makes sense.

> > "Enabling NAT traversal" here means starting UDP encapsulating
> > outgoing ESP packets and sending NAT-Keepalive packets (i.e., 
> > it doesn't involve sending any IKEv2 payloads, other than those
> > already explicitly specified in that section). 
> > 
> > How about adding "(i.e., enables UDP encapsulation of outgoing ESP 
> > packets and sending of NAT-Keepalive packets)" there?
> > 
Perhaps, instead of adding, just replace "enabling NAT traversal" with explicit
text like what you suggest above. At the end of the same section, there is
similar text "enable/disable NAT traversal". Perhaps, that also should say
the same thing.  

> > > >            If there are outstanding IKEv2 requests (requests for
> > > >            which the initiator has not yet received a reply),
> > > >            continues retransmitting them using the addresses in
> > > >            the IKE_SA (the new addresses).
> > > >
> > > >        This does not have a corresponding section in what the
> > > >        responder. Though, trivial would make sense to include
> > > >        them.
> > >
> > > Yes.
> > 
> > The responder processes the requests as usual: if the request
> > was CREATE_CHILD_SA, creates the new SA or something, etc. 
> > Note that the responder's part start with this text:
> > 
> >    When processing an INFORMATIONAL request containing the
> >    UPDATE_SA_ADDRESSES notification, the responder:
> > 
> > so I'm not sure what should be added here?
> > 
But this does not cover the above case. When the window is closed,
you are retransmitting requests/responses that does not contain
the UPDATE_SA_ADDRESSES. So, it has to be included somewhere
to say that "when the responder sees packets coming in with new
addresses, it should not update the SA if MOBIKE is enabled".
According to the IKEv2 base spec, the IKE SA will be updated
if a NAT was detected earlier.

> > > >- Section 4.7
> > > >
> > > >             If the initiator is behind NAT, and if he suspects
> > > >             that the peer is *dead*, he can send a DPD message
> > > >             with UPDATE_SA_ADDRESSES to recover faster.  This was
> > > >             discussed in the mailing list sometime back. But i
> > > >             don't see this suggestion. Why do we have to know that
> > > >             the NAT mapping has changed explicitly ? If the path
> > > >             still does not work with UPDATE_SA_ADDRESSES, then
> > > >             probably the path has failed.
> > >
> > > Tero, Pasi, can you say something about this?
> > 
> > Knowing that the NAT mapping has changed might be useful, since 
> > it allows you to adjust the keepalive interval. But the initiator 
> > could also send the UPDATE_SA_ADDRESSES immediately.
> > 
> > How about adding "The initiator MAY also omit the separate
> > exchange to detect the change in NAT mappings, and instead send
> > UPDATE_SA_ADDRESSES immediately when doing dead peer detection."
> > to 3rd paragraph of Section 4.7?
> > 
But we still have a problem with the current approach right ? How are we
going to fix that ? My experience with NAT keepalives has lead to a
very conservative approach :-) If it is 45 seconds,  your timer should
be around 40 seconds or less to be completely sure that it works always.


> > > >- Section 4.9
> > > >            Can we show the DPD exchange here with possible 
> > > >            payloads ?
> > >
> > > We have an example in Section 3.2. Would that be sufficient,
> > > or do you want more?
> > 
> > There is no "DPD exchange" in IKEv2; any INFORMATIONAL exchange
> > confirms the peer is alive (and thus it can include whatever
> > payloads any other INFORMATIONAL exchange includes).
> > 
But i saw some exchange earlier in the draft. My only intent is to show
the possible payloads that can be sent along with this from the MOBIKE
perspective.

-mohan

> > Best regards,
> > Pasi
> > _______________________________________________
> > Mobike mailing list
> > [email protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike