Subject: RE: [mobile-ip] Draft 15

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 25 Sep 2001 10:27:02 +0200

Hello Charlie, 

> I'd rather have it that IPsec _may_ be supported 
> 
	=. But the way the draft s written it can _not_ be supported. 
	If we have it in a separate draft we will end up
	with major interoperability problems.
	Since IPsec is mandated anyway for IPv6 hosts it 
	makes sense for us to use IPsec.

> if in the
> future someone can figure out how to specify it.  In the
> meantime, we can go forward with a spec that works,
> without losing features and without having to do things
> that may in the future be found inadequate within the IPsec
> working group.  
> 
	=> We seemed to have worked it out on the mailing list 
	over several weeks. I think it will work, I haven't seen
	any objection to having IPsec. Quite the contrary. 
	The discussion as on whether piggybacking should go or stay.

> I really do think that the message we have
> received more than once, is that we need to have a way to
> do authentication without necessarily relying on IPsec.
> 
	=> OK so that's where we have different understandings. 
	The message I understood was that we can not rely on IKE
	as the only key exchange mechanism. I don't recall disallowing
	IPsec at all. The problems were highlighted by the ADs 
	but they are definitely fixable without too much trouble.

	Regards,
	Hesham

> "Hesham Soliman (ERA)" wrote:
> 
> > > As best I can figure it out, one can use IPsec for authentication
> > > if you can get the selectors to select the right security association,
> > > but some (or most) implementations aren't selective enough
> > > to be assured of always picking out the right security association
> > > depending on which destination options (or future ones) may
> > > be in use.
> > >
> > > So, I have made an authentication data sub-option that MUST be
> > > supported.  IPsec MAY be used instead, and if so I don't think
> > > that there is any additional specification within the Mobile IPv6
> > > document that is needed for this.  If IPsec is used, then the
> > > Authentication Data Sub-Option does not have to be present.
> > >
> >         => The issue is exactly what you mentioned in the first paragraph.
> >         MIPv6 needs to solve the granularity problem since it is a MIPv6
> >         specific problem. So as discussed earlier we could create
> >         a new nxt Header value for the BU option, or write some
> >         text about how to increases the selectors granularity in the
> >         MN and the CN. Either way piggybacking will be very difficult if
> >         possible at all.
> >         So unfortunately we can't leave it the way it is because if we
> >         say that IPsec MAY be supported then it has to be shown
> >         how it can be supported.
> >
> >         I believe that the concensus was that the first option (new
> >         nxt hdr) should be used.
> >
> > > I hope this is good enough to satisfy the current needs, as well
> > > as the previous discussion about how we could not count on
> > > using IPsec in its current form.  I hope you like the new Sub-Option,
> > > and if you have suggestions about how to make better wording
> > > for allowing IPsec I'd be interested in that, too.
> > >
> >         => I could help with sending you some text if you like, provided
> >         we do agree with the assumptions above.
> >
> >         Regards,
> >         Hesham

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Sep 2001 13:06:24 +0300

>     but they are definitely fixable without too much trouble.

There is very clear consensus that we can't use IKE, i.e.
the key management part. There wasn't a very good consensus
on what to do with the actual packet protection, to use -14
or AH: a very long discussion was held in the mailing list,
discussing various issues such as options vs. new next header
numbers, piggybacking pros and cons, etc.

I would like to note that the latter issue is a bit more fine-
grained that "ipsec on" or "ipsec off". For instance, we do have
the option of (1) using standard ipsec as-is (possibly giving
up something else in the process such as piggybacking), (2)
enhancing ipsec (I'm not very fond of this alternative), (3)
using just -14 and bake and forgetting PKI-based schemes
for any environment, and (4) running both -14 for BUs and
ipsec/ike for all traffic on certain areas...

Anyway, I'm presently writing an Internet Draft that tries
to summarize the packet protection discussion and describe
the alternatives we have, their pros and cons, and effects
to e.g. piggybacking. I'm nearing completion in this work
and should be able to publish it Real Soon Now.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Sep 2001 12:11:17 +0200 (CEST)

> and should be able to publish it Real Soon Now.

Jari,

Does this draft also go into issues when there is more than one
choice (e.g. IKE vs. BAKE to pick examples) and how the MN can pick on the fly?
Or are you just looking at the packet protection issue?

  Erik