Re: [MEXT] new charter proposal

[[e-mail] (Arnaud Ebalard)]

Hi,

"Laganier, Julien" <[e-mail]> writes:

> Folks,
>
> For your information, below is the recharter proposal that we've put
> together and forwarded to IESG. 
>
> --julien
>
> Mobile IPv6 specifies routing support which permits an IPv6 host to
> continue using its home address as it moves around the Internet,
> enabling continuity of sessions. Mobile IPv6 supports transparency
> above the IP layer, including maintenance of active transport level
> sessions. In addition, network mobility (NEMO) mechanisms built on top
> of Mobile IPv6 allow managing the mobility of an entire network, as it
> changes its point of attachment to the Internet. The base
> specifications consist of: 
>
> o RFC 3775 (Mobile IPv6)
> o RFC 3963 (NEMO)
> o RFC 4877 (Mobile IPv6 Operation with IKEv2)

Just wondering: I thought those 3 were the base specification. Are the 4
below considered really part of the *base* specification, i.e. what does
it imply if some implementation does not support one of those
(e.g. DSMIP)?


> o RFC 5555 (Dual Stack Mobile IPv6)
> o RFC 5648 (Multiple Care-of Addresses Registration)
> o RFC 5846 (Binding Revocation) 
> o RFC-to-be (Flow Binding Policy Transport and Flow Binding Policy Format)
>
> The MEXT Working Group continues the work of the former MIP6, NEMO,
> and MONAMI6 Working Groups. 
>
> The primary goal of MEXT will be to enhance base IPv6 mobility by
> continuing work on developments that are required for wide-scale
> deployments and specific deployment scenarios. Additionally, the
> working group will ensure that any issues identified by implementation
> and interoperability experience are addressed, and that the base
> specifications are maintained. The group will also produce
> informational documentation, such as design rationale documents or
> description of specific issues within the protocol. 

I guess this is worth reasking here. MIPv6 has specific requirements to
allow a good interworking with IPsec/IKE. An interface between the
various modules is required to:

 1) Support initial negotiation of IPsec SA using IKE
 2) allow update of IPsec and IKE states regarding SP/SA

Even if the WG does not intend to document a solution/interface such as
MIGRATE [1] (or any other) I think it would be good to get the needs and
rationales documented in the context of the WG. This would make it clear
what kind of changes are needed to allow good interworking of IPsec, IKE
and MIPv6 modules. At least, this may avoid having people tell us
IPsec/IKE and MIPv6 does not work or is very complicated.

FWIW, MIGRATE document [1] describes the rationale for such a need and
provides an example of solution. For a while now, MIGRATE is implemented 
in Linux IPsec stack, racoon IKEv1 daemon, StrongSwan IKEv2 daemon and
Linux MIPv6 daemon (UMIP).

[1] http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00

> The MEXT WG will also explore experimental alternative security
> mechanisms.

Does it include work on RO for a better support of IPsec/IKE? :-)

I ask because http://tools.ietf.org/html/draft-ietf-mip6-cn-ipsec-08 is
here for a while now and (personal ad) there may be ideas worth
discussing in http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro-02.
The latter tries and solve *deployment* issues associated with RH2/HAO
and firewalls, among other things.


> The security mechanism specified in the existing standard
> track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement
> mechanism that guarantees interoperability between different
> implementations. The MEXT WG is chartered to deliver one or more
> experimental alternative mechanisms.
>
> All the alternative solutions will be published as experimental RFCs. 

This seems fair.


> Work items related to base specification maintenance include:
> Create and maintain issue lists that are generated on the basis of
> implementation and interoperability experience.

What about starting with the following:

 - Interworking between IPsec/IKE and MIPv6
 - RH2 and HAO are filtered by some firewalls: this kills mobility.
 - Additional problems with firewalls in a MIPv6 context, as discussed
   in my comments of draft-ietf-mext-firewall-{vendor,admin} [1]:
   rationale for protecting a HA (i.e. a security GW), assumption that
   ESP with null encryption is used, ...

[1] http://thread.gmane.org/gmane.ietf.nemo/7253


> Address specific issues with specific updates or revisions of the base 
> specification. One specific area of concern that should be analyzed
> and addressed relates to multilink subnets. 

Can someone provide additional context/info wrt the last sentence?


> Dec 2010 	Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard.
> Jan 2011 	Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard.
> Aug 2011	Submit I-Ds on alternative security mechanisms to the IESG for publication as experimental

ack.

Cheers,

a+

>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext