Subject: [IPsec] MIPv6 IPsec Route Optimization (IRO)

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 17 Nov 2008 00:30:57 -0800

Hi,

Sorry for crossposting but the topic discussed in the draft may be of
interest for people of the 3 lists.

> IETF I-D Submission Tool <[email-masked]> writes:
>
> A new version of I-D, draft-ebalard-mext-ipsec-ro-00.txt has been
> successfuly submitted by Arnaud Ebalard and posted to the IETF
> repository. 
>
> Filename:      draft-ebalard-mext-ipsec-ro
> Revision:      00
> Title:         Mobile IPv6 IPsec Route Optimization (IRO)
> Creation_date: 2008-11-17
> WG ID:         Independent Submission
> Number_of_pages: 44
>
> Abstract:
>
> This memo specifies an improved alternate route optimization procedure
> for Mobile IPv6 designed specifically for environments where IPsec is
> used between peers (most probably with IKE). The replacement of the
> complex Return Routability procedure for a simple mechanism and the
> removal of HAO and RH2 extensions from exchanged packets result in
> performance and security improvements.

I have just submitted a new I-D [1] which certainly requires an
introduction (and disclaimer): it specifies a MIPv6 Route Optimization
procedure *dedicated* to environments where IPsec/IKE is used between
peers (MN-HA, MN-CN, MN-MN) for protecting both signaling and data
traffic. 

Some of the improvements provided by this "IPsec Route Optimization"
mechanism (IRO) are also proposed for the IPsec communications between
the MN and its HA.

Among the features provided by IRO (introduction of the document as
a more accurate list):

  * Complete removal of RH2 and HAO (resulting in simplified packet
    handling on both sides and possibly better compatibility with
    filtering implemented in the network),
  * Per packet MTU gains between 24 and 48 bytes in comparison with
    equivalent uses of IPsec in standard RO context,
  * Improved and more generic proof of address ownership mechanism,
  * Safe by default behavior avoiding direct unprotected traffic flows,
  * No additionnal changes to IPsec or IKE protocols and limited
    changes to MIPv6 via four simple messages and a single option.

Next steps is to gather some initial feedback from interested people of
the WG. Then, I intend to spend some time implementing it (under Linux)
to challenge the ideas provided in the draft.

Comments are welcome. Note that this is a -00 which implies that some
parts are still quite raw and might deserve additional comments/work.

Cheers,

a+

[1]: http://www.ietf.org/internet-drafts/draft-ebalard-mext-ipsec-ro-00.txt
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 17 Nov 2008 14:45:54 -0800

Hi,

"Haddad, Wassim Michel" <[email-masked]> writes:

> => You can have complete removal of both options without introducing a
> new RO mode.

Sure. But there are additional reasons (and advantages, as provided in
my previous list) to introduce a new RO mode. IMHO, those advantages are
worth the introduction. But I am interested on feedback about those
specific parts of my I-D.

> Please check
> http://www.ietf.org/internet-drafts/draft-haddad-mipshop-tunneling-optimization-01.txt 

I already read version -00. I basically took a look at all I-D and
reference documents associated with tunneling optimizations and MIPv6 RO 
(always in an IPsec context): ERO, BEET, RO design history, your draft
...

Your proposal may have an interest for the common RO case if one intend
to keep the RRP. I just don't. I am convinced that removing the
duplicated states and exchanges when IPsec/IKE are used in a MIPv6
context can provide a far better solution.

>From my perspective, I just don't feel the need to introduce additional
states and exchanges (the PaT) because those are already available
locally (and synchronized over time) on the IPsec/MIPv6 entities
(SA/Bindings). Obviously, this is only true for IPsec entities, which
are (as presented before) my targets.

Thanks for your comments.

Cheers,

a+

ps: note that my -00 lacks pictures to ease the understanding of what
    happens. That's on the todo list for -01.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec