RE: issue 34 proposal

Hi,

there is one situation where "dynamic updates" has clear
advantage: voice. Dynamic updates survives much faster 
than IKE approach and call would stay up.

And yes, I know VoIP is out of the scope, but still IPsec is used to
protect voice traffic as well, and if possible that should be taken
into account.

Regards,

Mika

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: 07 September, 2005 17:17
> To: [email protected]; [email protected]
> Subject: RE: [Mobike] issue 34 proposal
> 
> 
> Although I have earlier supported the "dynamic updates"
> approach, I'm starting to think that handling this with explicit
> IKE-level messages might be easier.  Since we already send
> the DPD messages anyway, allowing them to contain NAT_DETECTION 
> payloads is very simple (and might be worth doing even if we 
> chose dynamic updates, the two are not totally exclusive).
> 
> And if we do this, then there isn't that much need for a separate
> path test message, so perhaps it's simpler to leave it out...
> 
> So I support your proposal on issue 34.
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Jari Arkko
> > Sent: Wednesday, September 07, 2005 1:05 PM
> > To: [email protected]
> > Subject: [Mobike] issue 34 proposal
> > 
> > 
> > This is a suggestion for a potential resolution of issue 34.
> > First, it seems that issue 34 is really about two separate
> > problems:
> > 
> >    Part a: How do we survive NAT reboots? ESP vs. IKE update?
> >    Part b: Do we have a separate path test message or not?
> > 
> > For part a, we have discussed probing frequencies and hardware
> > issues. List discussion on the probing seems to converge to
> > the conclusion that IKE-based messages for this purpose would
> > be OK. I'm not sure if we have come to any conclusion on the
> > hardware/implementation problem issues: There's a difference
> > where IKE-based messaging does not need hardware support
> > for ESP address changes. On the other hand we're not quite
> > sure if lack of hardware support is an issue for the ESP-based
> > approach either -- hardware evolves while deployment of new
> > features is ongoing. And as we are talking about a special case
> > to begin with, it may not be critical to have this support in
> > all devices at all times.
> > 
> > For part b, we have discussed whether the separate message
> > is easier to describe or not, and whether the separate message
> > can be sent in cases where additional IKE messages would have
> > to be delayed due to the usual IKE processing rules (e.g., when
> > connectivity breaks during an already ongoing movement operation).
> > In the latter discussion, it seems that we came to the conclusion
> > that if this happens, the worst that can happen is delay of
> > one roundtrip.
> > 
> > Based on the above I'd like to suggest that we pick
> > IKE based messages for NAT reboot/change detection,
> > and IKE messages for the path testing. Comments?
> > 
> > I asked Pasi to write some text for this, see below.
> > 
> > 2.X Changes in NAT Mappings
> > 
> >    IKEv2 performs Dead Peer Detection (DPD) if there has 
> recently been
> >    only outgoing traffic on all of the SAs associated with 
> the IKE_SA.
> > 
> >    In MOBIKE, these messages can also be used to detect if NAT
> >    mappings have changed (for example, if the keepalive internal is
> >    too long, or the NAT box is rebooted).  More 
> specifically, if both
> >    peers support both this specification and NAT Traversal,
> >    NAT_DETECTION_*_IP payloads MAY be included in any INFORMATIONAL
> >    request; if the request includes them, the responder MUST also
> >    include them in the response (but no other action is 
> taken, unless
> >    otherwise specified).
> > 
> >    When the original initiator is behind a NAT, it SHOULD include
> >    these payloads in DPD messages, and compare the received
> >    NAT_DETECTION_DESTINATION_IP payload with the value from the
> >    previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT
> >    response).  If the values do not match, the IP address 
> and/or port
> >    seen by the responder has changed, and the initiator SHOULD send
> >    UPDATE_SA_ADDRESSES as described in Section 2.3.
> > 
> >    When MOBIKE is in use, the host not behind a NAT SHOULD 
> NOT use the
> >    dynamic updates specified in [IKEv2] Section 2.23 (where the peer
> >    address and port is updated from the last valid authenticated
> >    packet).  This ensures that both peers have a consistent view of
> >    when addresses are to be changed, and prevents conflicts between
> >    MOBIKE-originated updates and NAT-T dynamic updates.  It 
> also means
> >    that an INFORMATIONAL exchange that does not contain
> >    UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
> >    used for, e.g., testing whether a particular path works.
> > 
> > (And remove Section 2.5 about separate PATH_TEST exchange.)
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>