Subject: [MEXT] new charter proposal

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 28 Jul 2010 05:36:39 -0700

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)
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.

The MEXT WG will also explore experimental alternative security mechanisms. 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.

Work items related to base specification maintenance include:
Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. 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.

    Goals and Milestones

Done 	Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard
Done 	Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard
Done 	Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard.
Done 	Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational.
Done 	Submit Multiple CoA Registration to IESG
Done 	Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational.
Done 	Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments
Done 	Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments
Dec 2010 	Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard
Done 	Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard
Done 	Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational
Jun 2008 	Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard.
Done 	Submit 00 draft on Binding Revocation
Jan 2010 	Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational.
Done 	Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard
Done 	Submit Flow/binding policy transport to IESG, for Proposed Standard
Done	Submit Flow/binding policy format to IESG, for Proposed Standard
Done 	Submit draft on Binding Revocation to IESG	
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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Jul 2010 15:26:43 +0200

Yes. Comments appreciated.

Jari

---

From: <[email-masked]>
Date: Thu, 29 Jul 2010 09:41:04 +0200

Hello,

Two points:

1. Proposed rephrasing for the following paragraph:

>The MEXT WG will also explore experimental alternative security mechanisms. 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.

The MEXT WG will work on alternative (to IPsec/IKEv2) security solutions. These alternative security solution(s) will be considered as experimental to begin with and evaluated for standards track at a latertime depending on implementations, adoption and usage. 
The security mechanism specified in the existing standards track RFCs (RFC3775bis, RFC4877) remains the mandatory to implement protocols in order to ensure interoperability. The MEXT WG will deliver one or more alternative security mechanisms. 

2. The milestone of Aug 2011 is okay. But there could be proposals that are already quite mature and could be taken up by the WG now and not have to wait until mid-next year.

-Basavaraj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Laganier, Julien
Sent: Wednesday, July 28, 2010 7:37 AM
To: [email-masked]
Cc: Jari Arkko
Subject: [MEXT] new charter proposal

Folks,

--julien

o RFC 3775 (Mobile IPv6)
o RFC 3963 (NEMO)

    Goals and Milestones

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 29 Jul 2010 10:40:20 +0200

Hi,

"Laganier, Julien" <[email-masked]> writes:

> 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)

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)?

> 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.

> 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?

> Aug 2011	Submit I-Ds on alternative security mechanisms to the IESG for publication as experimental

ack.

Cheers,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 29 Jul 2010 11:15:40 +0200

Hi,

<[email-masked]> writes:

>>mechanisms. The security >mechanism specified in the existing standard
>>track RFCs (RFC3775bis, RFC4877) remains the >mandatory to implement
>>experimental alternative >mechanisms. All the alternative solutions
>>will be published as experimental RFCs. 
>
> The MEXT WG will work on alternative (to IPsec/IKEv2) security
> solutions. These alternative security solution(s) will be considered
> as experimental to begin with and evaluated for standards track at a
> latertime depending on implementations, adoption and usage.  

I think the first version was ok, i.e. I don't see the point in adding
that to the charter now but if others agree ...

> The security mechanism specified in the existing standards track RFCs
> (RFC3775bis, RFC4877) remains the mandatory to implement protocols in
> order to ensure interoperability. The MEXT WG will deliver one or more
> alternative security mechanisms. 

It is already stated in the "Goals and Milestones" section of the
charter ("Aug 2011 Submit I-Ds on alternative security mechanisms to the
IESG for publication as experimental") but this is fine with me.
 
> 2. The milestone of Aug 2011 is okay. But there could be proposals
> that are already quite mature and could be taken up by the WG now and
> not have to wait until mid-next year. 

Just a thought: regarding draft-korhonen-mext-mip6-altsec-05 you are
pushing, I think it would be interesting to get some thoughts (about the
way it reuses TLS and elements of IPsec) from people of ipsecme and tls
WG. The TLS renegotiation issue (corrected by RFC 5746) has shown us it
is not trivial to get things right, even when eveyrthing looks ok. I
think hld-sec [1] is also an another good example.

To be honest, I don't care about pushing or not the document as a WG
item. AFAICT, at the moment, it is the only alternative security
solution propose: you have no competition, so there is no rush. IMHO,
the important thing is to get *technical* reviews from security people,
familiar with the security protocols at hand. And that part takes time.

Cheers,

a+

[1]: http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Jul 2010 11:59:42 +0200

Arnaud,

o RFC 3775 (Mobile IPv6)
o RFC 3963 (NEMO)

The normative requirements are in the various RFCs (node requirements
RFC, the above RFCs, etc). Those statements and not the charter
statements dictate what is required from implementations.

(I think its reasonable for the charter to list the main pieces of
specifications to date. If you can invent some other word than "base"
to use here, that would be fine too, and might help reduce your worry
that its misinterpreted somehow.)

Jari

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 29 Jul 2010 12:58:20 +0200

Hi Jari,

Jari Arkko <[email-masked]> writes:

> The normative requirements are in the various RFCs (node requirements RFC, the
> above RFCs, etc). Those statements and not the charter statements dictate what
> is required from implementations.

ok.

> specifications to date. If you can invent some other word than "base" to use
> here, that would be fine too, and might help reduce your worry that its
> misinterpreted somehow.)

It's no big deal and probably not worth spending much time on it but I
tend to consider something like the following: MIPv6 core specifications
(3775, 3963, 4877 (and somehow 3776)) and main extensions (5555, 5648,
5846, flow-binding rfc).

Anyway, thanks for the clarification.

a+

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Jul 2010 13:01:50 +0200

Arnaud,

> (3775, 3963, 4877 (and somehow 3776)) and main extensions (5555, 5648,

This text sounds better to me than the one in our proposal. I think we 
should use it. Thanks.

Jari

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 29 Jul 2010 04:21:25 -0700

Arnaud and Jari,

> This text sounds better to me than the one in our proposal. I think we

I agree. I also think we should include RFC5026 in the extensions.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 29 Jul 2010 04:31:45 -0700

[email-masked] wrote:
> solutions. These alternative security solution(s) will be considered as
> experimental to begin with and evaluated for standards track at a

I do not like the change your proposed and prefer the earlier text. At this point we're going to define one or more experimental protocols for the Internet community, not an Internet standard of any kind. When we have feedback the WG will do what is appropriate.
 
> 2. The milestone of Aug 2011 is okay. But there could be proposals that
> are already quite mature and could be taken up by the WG now and not
> have to wait until mid-next year.

Speaking as a WG chair, from my perspective the date on a milestone is an indication of how long we expect the work to take rather than a requirement on when a WG decides that a document is ready and decides to forward it to IESG for publication. I would certainly be happy if the WG would conclude work ahead of the date indicated on a milestone.

--julien