Subject: RE: [mobile-ip] Draft 15

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 25 Sep 2001 09:21:39 +0200

> 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: Charlie Perkins <[email-masked]>
Date: Tue, 25 Sep 2001 00:55:18 -0700

Hello Hesham,

I'd rather have it that IPsec _may_ be supported 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.  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.
This doesn't mean that IPsec can not be used.  I would
hope that the specification for using it would be in a
separate document, and that it would not delay the progress
of Mobile IPv6.

I'd have to go back and study a number of old messages
to figure out whether getting a new next header for
Binding Update was the consensus position.  I do recall
reading a lot of different opinions on the subject, ranging
from encapsulation, to putting all the Mobile IPv6 options
in the same header as suboptions, and probably a lot of
others that I can't remember right now.  I thought that
making the Sub-Option was the most middle-of-the
road course.

Regards,
Charlie P.

---

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

> separate document, and that it would not delay the progress

The use of the term "IPsec" might be inexact.
There is clearly a requirement to do authentication without relying on a PKI
and I think that this translates into being able to do authentication
without relying on IKE. (While IKE in theory doesn't assume certificates or
pre-shared secrets I suspect implementations do assume this.)
But it doesn't necessarily follow that authentication can not rely on
using AH and/or ESP. So what did "IPsec" mean above :-)

> making the Sub-Option was the most middle-of-the

I think there are two areas where the WG needs to make rough consensus
decisions: key management and packet authentication

For key management there needs to be a method that doesn't require a PKI
but I've also seen emails I've interpreted as a desire to use a PKI when
it is available. Thus it seems like there needs to be at least
two mechanisms here: IKE plus one that works without a PKI.
With more than one mechanism to choose there must also be a mechanism
for a MN to choose which one to use that is secure enough so that the MN
can't be tricked into using a less secure method when the more secure
one is indeed available.

For packet authentication there are also choices.
But if the desire to use a PKI when it is available is in fact WG rough 
consensus (something which the chairs get to guage), then
it seems like it would be a requirement to make MIPv6 work with the
constraints of AH/ESP and the IPsec architecture.
(Using IKE to create security associations for something other than
AH and ESP seems like it would require additional standards work in the
form of a DOI as I understand it.)
Once this work is done, it isn't obvious to me whether or not it makes
sense to also use AH/ESP for BUs when the key management is done without IKE.
It might be that AH/ESP is the simpler one. Or it might be that using
the sub-option when IKE isn't used is the best path.

But too me it seems a bit too early to have this last part
of the discussion - I don't feel I understand the tradeoffs yet and 
I haven't seen any discussion how a MN can choose between the PKI/IKE
key management and the alternate one before sending a BU. Do folks
have any ideas in that area?

  Erik

---

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

(I'm changing the subject line to match what we discuss.)

>have any ideas in that area?

There are multiple ways of doing this, depending on what the
underlying BU packet protection scheme really is. In any case,
it is likely that the PKI/VPN policy mechanisms are relied upon in
making the decision you mention above.

For instance, let's assume we decide to use solely the BU suboption
for the authentication of BUs, and key this through BAKE. Then,
we might apply *in addition* PKI/IKE/IPsec on a particular organization
to allow for strong authentication of *all* traffic, including
the BUs. The IPsec policies would be set up, for instance, to
require IPsec for all traffic between all nodes. Or to require
IPsec for all traffic within the organization's own address space,
and nothing to the outside.

Another alternative would be to extend things like BAKE to
allow also for PKI authentication. This would require extending
them also to have some sort of policy mechanisms to decide
when to do this or not. (And the protocols might have to be
extended with the various authentication schemes people for
some reason want to use in their organizations, see what the
IPSRA group is doing as an example.)

A third alternative would be to use AH for protecting the
BUs, and allow the policy rules to dictate when to use IKE
and when e.g. BAKE. 

In any of these schemes, choosing dynamically between "weak"
and traditional authentication is tricky. It is easy to require
implementations to support both, and to configure one or the
other globally on. It is possible to configure both mechanisms
on at the same time, but given that the selection has to be
done without cryptographic authentication we need to rely to
the correctness of the IP addresses to an extent. Of course,
this may be the tradeoff the user wanted as he configured to
allow same traffic to be protected in different ways towards
different addresses. But the security implications should
be documented, so that users don't mistakenly trust the
functionality too much.

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

Yes. Though the security implications of the picking propably
deserve some discussion, and I haven't thought out all the
issues through yet.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Sep 2001 17:12:33 +0200

I support Hersham's position:
 - drop piggybacking
 - document a way to use IPsec
 - the simplest fix to the selector problem is a new next header value
   (or a well known UDP port if the previous solution is not available)

Thanks

[email-masked]

PS: the random correspondent case is only one part of the whole picture,
MN-HA stuff is at least as important.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 25 Sep 2001 08:38:20 -0700

Hello Francis,

> I support Hersham's position:

I think this is far premature.  It has the potential to be a very
important improvement, and once gone it would be difficult to restore.

Sending Binding Updates along with data packets has many advantages:
- reduces number of media acquistions
- in the most natural implementations, reduces the total number
  of Binding Updates sent
- reduces number of bytes sent.

The crucial thing is to prevent Binding Updates from being sent
unnecessarily.  Any implementation which sends Binding Updates at
every change in point of connection to the Internet (or, even worse,
on every movement detection) is potentially doing a lot of
unnecessary signalling.  In contrast, an implementation that sends
Binding Updates in the first data packet going out after detecting
a change in the mobile node's point of attachment, is going to have
a lot less overheat.

This is a very important point.  Avoiding unnecessary signaling
should be one of our prime goals, considering that Mobile IPv6
is likely to be used over bandwidth-constrained media.

>  - document a way to use IPsec

That can be done separately, and it would be nice to avoid the
dangers of somehow running afoul of the sort of technical difficulties
that have brought us to this point.  I'm speaking as someone who was
(it seemed to me) the lone defender of using IPsec AH, during the
discussions at the end of last year.  I was told that doing this
could take a long time, which I thought was strange since we have
already had IPsec AH working in our prototype for a long time.
We can do things a lot faster by saying just exactly what we need,
and leaving it for later, or for others, to get agreement from
IPsec folks about how to use their protocol.

>    (or a well known UDP port if the previous solution is not available)

I don't have any problem with getting a new next header unless that
will somehow introduce (yet!) another delay factor.

Regards,
Charlie P.

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 25 Sep 2001 19:12:08 +0300

(Changing subject line again...)

> important improvement, and once gone it would be difficult to restore.

I agree that we need to understand the implications of keeping/removing
piggybacking.

> a change in the mobile node's point of attachment, is going to have

This optimization is indeed a crucial one. But perhaps it is not
tied to the concept of piggybacking itself but rather its about
the trigger that makes a MIP implementation send a BU? Even
an implementation that sends separate BUs and payload data
could achieve the above behavior, if the BU was sent at the
time we first see some traffic.

The effects of piggybacking are more related to complexity, and
the bandwidth consumed for the signaling. On a LAN, the bandwidth
doesn't matter but on a cellular link you do care. The trouble is that
there are many complicating factors on these links that make it less
easy to understand the bandwidth implications. 

On first look at the ROHC header compression, for instance,
it appears that an additional option within the Dest Opts
header (remember that it will always be present as it carries
the HA option on all packets) can be sent as a diff, while a
separate packet with a different protocol number will cause
a complete new header to be transmitted.

On the other hand, a very specific QoS channel may have been
reserved for e.g. a voice call stream and it is simply impossible
to squeze in additional bytes without forcing the packet to go
through best effort channels, delaying the packet long enough
to make it effectively useless when it arrives. Ok, maybe your
IPv6 mobile phone could use some intelligence to avoid this,
but the server at the other end wouldn't have a clue that it should
be avoiding piggybacked signals on the stream coming towards
the phone.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Sep 2001 09:12:01 -0700 (PDT)

> a change in the mobile node's point of attachment, is going to have

   I see no reason why an implementation cannot
   have the exact same behavior you suggest (which
   I think is correct) but instead of sending one
   packet, it sends two. With layer two header
   compression and blocking both the overhead and
   latency can be minimized where that's a concern.

 > that have brought us to this point.

   I too am in agreement with Francis that this should both
   be a baseline requirement for MIPv6 given the threats
   against the HA/MN and that we should be able to use
   IPsec with no issues if we follow the set of rules
   outlined.
   
	Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 25 Sep 2001 09:32:02 -0700

Hello Jari,

>> a change in the mobile node's point of attachment, is going to have

(I meant overhead :-)

> time we first see some traffic.

This is generally true, except that it would be better to have
the Binding Update applied to the data which needed to be sent
at the same time.  If the Binding Update arrives first, all is
well and good, at the expense of delaying the data for another
slot or medium acquisition time.  If the Binding Update arrives
later, then smooth data delivery will be the casualty.

> easy to understand the bandwidth implications.

True enough -- and, we have to build a Mobile IPv6 that can work
well with all of them.

> a complete new header to be transmitted.

Good point.

> be avoiding piggybacked signals on the stream coming towards

I would expect this to be part of the QoS negotiation.  Furthermore,
it depends on very special properties of the voice encoding and
channel utilization.  Thus, we need to make it so that such applications
are supported well, and still so that other applications with different
constraints are equally well supported.

Thus, I again suggest that we really need to allow Binding Updates
and data to live in the same IPv6 packet.  Making data streams fit
into reserved channels of exactly prescribed bandwidth is a very
interesting problem; I am sure we can make a solution to that
problem which handles Binding Updates correctly -- likely as part
of a separable ("non-piggybacked") signaling algorithm.  This should
not penalize the other applications that do not have the same
constraint.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Sep 2001 09:56:43 -0700 (PDT)

> IPSRA group is doing as an example.)

   In fact, I believe that the basic mechanism for
   weak authentication SHOULD NOT include keying at
   all. The reason is that the actual security property
   being enforced by all of these proposals is the return
   routability test, *not* the keying. The keying is an
   optimization for subsequent updates so that it does
   not need to perform the full return routability test
   each time.

   In interest of getting this spec done soon, I urge
   the working group to keep the weak test as simple
   as possible which means that it must not include
   any provisions for keying and/or proxying binding
   updates return routability tests on things like
   the home agent. The second you start adding
   lots of crypto, people's eyes glaze over and
   there is a real threat that route optimization
   will be ignored if its security module is
   considered too onerous. Considering that the
   crypto is an optmization, that would be a real
   shame.

   This may seem strange coming from somebody
   who's written a draft which proposes a solution
   with the base test along with the two
   optimizations, but I've also had time to
   reflect on what is necessary and what is 
   optional. I still think that both of the 
   optimiztions would be useful additions to
   MIPv6 (along with MR support as well), but 
   at this point I think it would be far more
   prudent to pursue those optimizations as a 
   separate WG item so that we can finish the
   current MIPv6 draft as soon as possible.

	    Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Sep 2001 19:27:00 +0200

important improvement

=> IMHO for the moment it was only a burden.

   and once gone it would be difficult to restore.

=> from my point of view this is not a bad point (:-)!

=> ?

=> I believe the argument is delayed BUs, isn't it? This relies on
a specific traffic pattern, for instance no request-like traffic from
correspondents.

=> you have to prove this when MTU discovery and ROHC compression
is broken.

   unnecessary signalling.

=> see my answer to the last point.

   In contrast, an implementation that sends
   Binding Updates in the first data packet going out after detecting
   a change in the mobile node's point of attachment, is going to have
   a lot less overheat.
   
=> until one of its poor correspondents sends a packet to its previous
location which is no more valid...

=> if you need to optimise this particular case perhaps the best solution
is to avoid routing optimization (the extra travel of packets, if any,
will be on a very fast backbone) and to rely on ROHC in order to remove
the cost of encapsulation from the HA to the MN. So the signaling will
occur on with HAs (something we can't delay or avoid).

   >  - document a way to use IPsec
   
   That can be done separately

=> Hersham explained (far better than I can) why this should not be done
separately.

   I'm speaking as someone who was (it seemed to me) the lone defender
   of using IPsec AH, during the discussions at the end of last year.

=> I had the same impression, to be in the IPsec AH camp was an ordeal...

   I was told that doing this could take a long time, which I thought was
   strange since we have already had IPsec AH working in our prototype
   for a long time.

=> your implementation was known to work only because there was a second
one (:-).

=> hum, the issue is the argument shall be the same from IPsec folk
(i.e. what we shall have to change in Mobile IPv6 in order to fit
with IPsec)... IPsec folk are ready to help us, don't say "wait, we
finish this, after you'll say what we should have done".

Thanks

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2001 10:45:57 -0700

> => you have to prove this when MTU discovery and ROHC compression

strongly disagree!! neither would be broken.

> => Hersham explained (far better than I can) why this should not be done

i prefer a separate draft which explains how AH can be used with 
MIPv6. and the requirements like (new next header, disable piggybacking)
for AH to work can be present in that draft. and it can advance at its 
own pace.

vijay

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Sep 2001 20:14:49 +0200 (CEST)

>    not need to perform the full return routability test

While I don't have a problem with this per-see I wonder how many flavours
will end up with. Potentially will have:
 - just return routability for each BU being sent - no crypto
 - return routability for first BU plus establish some keys so that
   subsequent BUs don't need the 3-way handshake required for
   return routability
 - IKE in the case when there is a PKI
 - Perhaps SUCV if not now but at a future date

From a total complexity perspective it would be good to figure out
how many flavours we need.

   Erik

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Sep 2001 11:37:43 -0700 (PDT)

>  - Perhaps SUCV if not now but at a future date

IMO, there should be two pieces in the MIPv6 draft:

1) A mechanism to use IPsec to protect BU's. Francis
   layed out the necessary changes required to make
   that possible. There is no need to mention IKE at
   all here because keying is orthogonal to IPsec,
   and its implications are well known to anybody
   who has any experience VPN's.

2) A basic return routability test for use between
   CN and MN. This can be extremely simple requiring
   no more than several paragraphs to explain, and
   a couple of new ICMP messages.

Any other optimizations should be deferred.
Indeed, it would probably be a good idea to get
some implementation/deployment experience to find
out whether further optmizations are even
warrented.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Sep 2001 13:06:59 -0700 (PDT)

> for AH to work can be present in that draft. and it can advance at its 

  The problem is that that does not provide adequate
  security for the HA/MN security association. We
  need a strong authentication mode for this SA.

	 Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2001 13:38:22 -0700

>   need a strong authentication mode for this SA.

I consider authentication data suboption with keys provided by 
BAKE/IKE/AAA/whatever as strong authentication too.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Sep 2001 13:40:38 -0700 (PDT)

> can't be tricked into using a less secure method when the more secure

   If you have access to the outbound IPsec processing,
   this should be fairly straightforward, I'd think:
   you check to see if BU packet would cause an ESP
   or AH header to be added, and if not then you use
   the weaker variety. I believe that this also addresses
   the authorization issue since you could set up different
   security policy database entries which reflect the
   different policies you might want to apply to BU's
   vs. other data (if any).

	     Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2001 15:01:37 -0700

> BAKE/IKE/AAA/whatever as strong authentication too.

sorry. BAKE wasnt supposed to be there. everything else

vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Sep 2001 15:21:27 -0700 (PDT)

> BAKE/IKE/AAA/whatever as strong authentication too.

   You can delete IKE from this list too since IKE
   does not have the ability to key the proposed 
   authentication suboption. Considering the brutal
   feedback from the AD's on the AAA keying draft, 
   including it is if nothing else premature.
   
		Mike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Sep 2001 10:58:51 +0200

=> and any (partial) replacements for IKE (KINK, AAA, ...) when
   it is available

   
=> at least two for IPsec based and not IPsec based (this is why
I'd like to get IPsec support hooks in the Mobile IPv6 document,
with those and the authentication sub-option the complexity should
be movable outside the Mobile IPv6 document).

Regards

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Sep 2001 13:01:21 +0300

>  - Perhaps SUCV if not now but at a future date

One observation I'd like to make here is that we
have basically entered a very new area, in terms
of existing research etc there isn't much old work.
The whole problem of "weak" authentication wasn't 
even known some time ago, and the the smart ways
of handling the problem (like SUCV etc) have surfaced
quite recently.

Therefore, it would seem prudent to prepare for
the possibility that research will come up with
more results in the area, given some time. 

Engineering-wise, this means that we should try
to decouple the weak key management protocols
from the rest of the system, allowing us to
add new ones later. This decoupling might mean
that any protocols designed for e.g. the
return routability should be extensible to
allow for SUCV etc at a future date, or that
we simply have different protocols that all
can key the same BU protection mechanism.

It may also mean that we should on purpose
try to *not* include everything we can in
the initial spec, fearing the danger that
we go too close to the leading edge and make
a mistake...

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Sep 2001 15:49:45 +0200 (CEST)

> - reduces number of bytes sent.

Since there exists implementations of MIPv6 I wonder 1) how many of them
have implementing piggybacking and 2) of those have any looked at
the effect of turning piggy-backing on and off.

Is there any data?

> a change in the mobile node's point of attachment, is going to have

It clearly doesn't work to always delay the BU until data needs to be sent
to the CN. The BU needs to be sent before the CN tries to send data
to the MN - if the CN sends to the old CoA the packet might be dropped
(depending whether the MN was successful in updating a previous default router
and to what extent you want to have a residual dependency on the availability
of the previous visited link).

Predicting when a CN is going to next try to send to the MN is hard and
requires being able to predict the behavior of the transport protocol
as well as the applications running.

I wonder what working strategies folks have tried in implementations.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Sep 2001 15:58:55 +0200 (CEST)

> not penalize the other applications that do not have the same

I think it is fair to say that as the piggybacking is currently defined
MIPv6 doesn't fit well with the IPsec architecture.

At least some folks see a need to be able use ESP and/or AH with
MIPv6, so isn't it time to face reality?

A few weeks back I had suggested a different way to doing piggybacking -
a generic IPv6 feature to allow to IP payloads in one packet.
The semantics of this should be defined as the same as two separate packets
i.e. a receiver could process this by cloning the IPv6 header and
creating the two different packets, which it can process independently
(including processing as it relates to IPsec).

If the WG has consensus to be able to use AH/ESP as well as consensus
to support piggybacking above the link layer, then it would make sense
to seriously explore things in the direction I expected.

My 2 cents,
   Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Sep 2001 16:11:36 +0200

Since there exists implementations of MIPv6 I wonder

=> I can answer for my (old) implementation

   1) how many of them have implementing piggybacking

=> only the receiving (mandatory) side

   2) of those have any looked at the effect of turning piggy-backing
   on and off.
   
=> no answer: the knob to put it on was never there.

   Is there any data?
   
=> at least one crash in a conformance test (unused code written
with regret :-). I've already explained in previous mails what
I think about piggybacking (BTW there is a warning against it in
the entrance of your previous building at Palo-Alto :-).

   ...
   
=> as noted before delaying BUs can be done with or without piggybacking.
I can't see a reason to forbid or enforce delaying: the current MAY
is fine. (PS: I didn't implement it)

Thanks

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Sep 2001 12:01:54 -0700 (PDT)

> of handling the problem (like SUCV etc) have surfaced

   Oh, I wouldn't say that it's _that_ new. I know
   that a certain rilly big router company who
   shall go unnamed has had to make patches to its
   TCP code to make certain that the ISS is random
   to provide protection against guessing barge in
   attacks...

   At it's base, that is what all of these
   proposals are providing when you strip all the
   rest of the bells and whistles... Which is why
   I think it would be prudent to do exactly that
   in the MIPv6 draft itself.

 > more results in the area, given some time. 

   Right. That's pretty much the point of the
   mail I sent out with this subject: strip what
   needs to be done with weak authentication down
   to it essentials for the mipv6 draft, and add 
   any enhancements later in another draft. 
   Generating a shared secret is not one of those
   essentials.

		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Sep 2001 14:42:07 +0200 (CEST)

>    different policies you might want to apply to BU's

That approach solves the problem when there already is
an IPsec SA established, which is an important case (it handles
MN-HA communication secured by IPsec).

But what about the general case?
MN has a certificate from the (private) foo CA, and a given CN also
has a certificate from the same CA. In this case they could use
IKE to establish an IPsec CA and use that for the BU (as well as potentially
other packets).

I think I've already seen your answer to the above question - that it
is controlled by the IPsec policy.
This would mean that for machines that are in the same (private) key
infrastructure they would need to have policy entries, e.g. based on
IP address prefixes, to indicate when they would kick IKE to create
a SA.
I was hoping that there be a less management intensive manner to make
this happen.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Sep 2001 10:31:19 -0700 (PDT)

> is controlled by the IPsec policy.

   Correct.

 > I was hoping that there be a less management intensive manner to make

   This is a general IPsec issue. If you have some better
   ideas about how to automagically install IPsec 
   policy, I'm sure lots of folks would be interested :-)

	   Mike