Subject: [Mip6] Seeking consensus on a MIP6 charter item

From: [email-masked]
Date: Thu, 4 Sep 2003 15:05:12 -0500

Hello,

The following is a milestone identified in the current charter for
Mobile IPv6:

 o Mar 04 Submit alternate security mechanisms for HA-MN to IESG

However there is no corresponding text describing what this milestone
really means in the charter. My view of the above milestone is as
follows:
   Currently IPsec provides the means for authenticating a MN to the
   HA. This mandates the existence of an IPsec SA between the MN and
   HA. It is possible that an equivalent degree of security for the
   BU/BAck can be achieved by encapsulating an authenticator in a
   Binding data suboption. This basically falls back to the Mobile
   IPv4 model of authentication between MN-HA where the MN-HA auth
   extension is sufficient to create the binding in the HA. With this
   approach there is no reason to implement IPsec/IKE(v2) in a MIPv6
   MN, which I think is an overkill for basically doing authentication
   between two entities that are aware of each other. 

So the question is:
1. Should the Mobile IPv6 take on the work item mentioned in the
   milestone above? 

A: 
   Yes  [ ]
   No   [ ]

Reason: 

Note that if there is consensus to work on this, the above text or
some equivalent would be added to the charter.

Please express your views on this by Sept 12th, 2003.

-Basavaraj

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

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 4 Sep 2003 14:57:33 -0700

> However there is no corresponding text describing what this 
> milestone really means in the charter. My view of the above 
> milestone is as
> follows:
>    Yes  [X]

> Reason:
I trust Charles Perkins' opinion on this. At the SF IETF-56 meeting, he
seemed to think it was worthwhile to pursue the AAA extensions to MIPv6
that have previously been specified for MIPv4.

Thanks.
- Ed Remmell
Elmic Systems, USA

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 8/19/2003

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Sep 2003 06:57:02 +0300

> 1. Should the Mobile IPv6 take on the work item mentioned in the

I believe we need the work item, but I am unsure about the text
that was provided. Basically, at this time we lack two important
functions from the HA-MN interface security. Here's what the old
charter proposals said about them:

    - A bootstrap mechanism for setting up security
      associations between the MN and HA that would enable easier
      deployment of Mobile IPv6.

    - Support for the MN's changing addresses either because of
      renumbering in its home network or because it periodically
      changes addresses (perhaps via rfc3041)

Its unclear to me whether your intent was to replace the work
on these with the options work, or would both still be done?
If its the latter, is that work independent of the alternative
HA-MN security work or performed together?

Basically, I believe the bootstrap and dynamic addressing
features are more important than simply replacing current
protocol mechanism with another. Note that, as discussed in
IETF-57, taking in account these two features could well mean
replacing IPsec with something else; the choices really are
something IKEv2 based or something "application" layer based -
and I prefer the latter. But I think the charter should be
written so that we require a mechanism to be designed such
that these two features are provided, and leave more room
for the specific solution to be developed.

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 5 Sep 2003 07:18:51 +0200 (CEST)

> for the specific solution to be developed.

Agreed.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 Sep 2003 10:48:52 -0700

Yes.

Vijay

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 6 Sep 2003 13:46:21 +0900

PiBIb3dldmVyIHRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgdGV4dCBkZXNjcmliaW5nIHdoYXQgdGhpcyBtaWxlc3RvbmUNCj4gcmVhbGx5IG1lYW5zIGluIHRoZSBjaGFydGVyLiBNeSB2aWV3IG9mIHRoZSBhYm92ZSBtaWxlc3RvbmUgaXMgYXMNCj4gZm9sbG93czoNCj4gICAgQ3VycmVudGx5IElQc2VjIHByb3ZpZGVzIHRoZSBtZWFucyBmb3IgYXV0aGVudGljYXRpbmcgYSBNTiB0byB0aGUNCj4gICAgSEEuIFRoaXMgbWFuZGF0ZXMgdGhlIGV4aXN0ZW5jZSBvZiBhbiBJUHNlYyBTQSBiZXR3ZWVuIHRoZSBNTiBhbmQNCj4gICAgSEEuIEl0IGlzIHBvc3NpYmxlIHRoYXQgYW4gZXF1aXZhbGVudCBkZWdyZWUgb2Ygc2VjdXJpdHkgZm9yIHRoZQ0KPiAgICBCVS9CQWNrIGNhbiBiZSBhY2hpZXZlZCBieSBlbmNhcHN1bGF0aW5nIGFuIGF1dGhlbnRpY2F0b3IgaW4gYQ0KPiAgICBCaW5kaW5nIGRhdGEgc3Vib3B0aW9uLiBUaGlzIGJhc2ljYWxseSBmYWxscyBiYWNrIHRvIHRoZSBNb2JpbGUNCj4gICAgSVB2NCBtb2RlbCBvZiBhdXRoZW50aWNhdGlvbiBiZXR3ZWVuIE1OLUhBIHdoZXJlIHRoZSBNTi1IQSBhdXRoDQo+ICAgIGV4dGVuc2lvbiBpcyBzdWZmaWNpZW50IHRvIGNyZWF0ZSB0aGUgYmluZGluZyBpbiB0aGUgSEEuIFdpdGggdGhpcw0KPiAgICBhcHByb2FjaCB0aGVyZSBpcyBubyByZWFzb24gdG8gaW1wbGVtZW50IElQc2VjL0lLRSh2MikgaW4gYSBNSVB2Ng0KPiAgICBNTiwgd2hpY2ggSSB0aGluayBpcyBhbiBvdmVya2lsbCBmb3IgYmFzaWNhbGx5IGRvaW5nIGF1dGhlbnRpY2F0aW9uDQo+ICAgIGJldHdlZW4gdHdvIGVudGl0aWVzIHRoYXQgYXJlIGF3YXJlIG9mIGVhY2ggb3RoZXIuIA0KPiANCj4gU28gdGhlIHF1ZXN0aW9uIGlzOg0KPiAxLiBTaG91bGQgdGhlIE1vYmlsZSBJUHY2IHRha2Ugb24gdGhlIHdvcmsgaXRlbSBtZW50aW9uZWQgaW4gdGhlDQo+ICAgIG1pbGVzdG9uZSBhYm92ZT8gDQo+IA0KPiBBOiANCj4gICAgWWVzICBbT10NCj4gICAgTm8gICBbIF0NCj4gDQo+IFJlYXNvbjogDQo+IA0KPiBOb3RlIHRoYXQgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIHdvcmsgb24gdGhpcywgdGhlIGFib3ZlIHRleHQgb3INCj4gc29tZSBlcXVpdmFsZW50IHdvdWxkIGJlIGFkZGVkIHRvIHRoZSBjaGFydGVyLg0KIA0KQmVzdCBSZWdhcmRzDQoNCkppbkh5ZW9jayBDaG9p_______________________________________________Mip6 mailing [email-masked]://www.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Mon, 8 Sep 2003 10:35:34 -0700

I agree with Jari on this point, with the exception that I am not sure
whether the right solution is IKEv2 or an application specific mechanism.

I think we should be looking toward one mechanism for securing the HA-MN
link, and it should support bootstrapping and the MN changing address, with
the possibility of setting up a "security association" (which may or may not
be IKE-related) dynamically for dynamic home agent selection. Another
requirement I believe is important, not listed below, is ease of deployment
and maintenance. If the currently specified IKE mechanism turns out to be
too cumbersome or not adaptable to support these requirements, then we
should replace it, but it is not clear to me at this point whether that is
so. Having more than one mechanism leaves open the possibility for
interoperability problems on the host, especially if dynamic home agent
selection is to be supported.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Sep 2003 21:17:38 +0300

> selection is to be supported.

I probably shouldn't claim I'm sure about what the right solution is
either. I agree with the issues you mention above. I guess it boils
down to the fact that concrete proposals are needed before we can
figure out what solution is the right one.

--Jari