Subject: Re: [Fwd: [mobile-ip] Mobile IPv6 clarifications]

From: Mattias Pettersson <[email-masked]>
Date: Tue, 03 Jul 2001 09:18:10 +0200

[This is a resend - wrong mailing list address in previous mail]

"Charles E. Perkins" wrote:

> > Our suggestion is that we instead define a new BA status code (139?) of
> > "sequence number too small". If the HA recieves a BU where T <= S, it
> > must instead send a BA back to MN with status = 139 and the sequence
> > number field set to S. The MN will retransmit the BU and now use T = S +
> > D (D=1 comes to mind as best choice).
> >
> > Does anyone see a security problem here? The HA only exposes what has
> > already been transmitted over the wire. The HA doesn't need to keep
> > state for this.
> 
> I have followed your suggestion, and added the following text:
> 
>     If the mobile node sends a sequence number which is not greater than
>     the sequence number from the last successful Binding Update, then
>     the home agent MUST send back a Binding Acknowledgement with
>     status code 141, and the last accepted sequence number in the
>     Sequence Number field of the Binding Acknowledgement.
> 

Sorry, I need to bother you again. I've discussed this with a security
expert (thanks Andras!), and we could revise this slightly.

There is a different approach to the sync problem, if I only had read
section 13.1 better or studied IPSec more. We don't need to beware of
replay attacks regarding the sequence number in the BU, as long as we
stick to IPSec protection, since IPSec has its own sequence number.

The mobile node may, upon it's first registration, use sequence number
0. If it gets no reply from the home agent, it may increase the sequence
number with 32768. That will assure that, as long as packets are
transmitted properly, either sequence number 0 or 32768 will be greater
that the previous sequence number the home agent possibly has stored.
This will assure that a registration will be accepted within one or two
BUs sent if the mobile node has lost sync with the home agent.

> > 2. There should be a statement about sequence numbers. According to the
> > sequence number comparison method, the number 0 is smaller than 1 up to
> > 32767, but greater than 32768 up to 65535. If MN sends a BU with
> > sequence number 0 at some point, it can use all sequence numbers up to
> > 32767. After that, it must renegotiate SA with the peer (HA/CN), or it
> > will be exposed to a potential replay attack.
> 
> I added the following text to the Security Considerations:
> 
>    After the Sequence Number space of the Binding Update and
>    Binding Acknowledgement options has been exhausted, the
>    mobile node and the home agent SHOULD renegotiate their
>    security association in order to prevent any possibility
>    of replay attacks.

This part will not be needed if we stick to IPSec protection. However,
I'm not sure what protection will be used for the MN-CN relation.

/Mattias

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 03 Jul 2001 16:33:47 -0700

Hello Mattias,

I thought the very clear message was given to the mobile-ip working
group that we couldn't use AH as originally specified for authenticating
Binding Updates.  I can recount the reasons if need be.

The working group has to decide ASAP how to resolve this issue about
using IPsec for authentication.  I'm not a security expert (although I've
learned a lot) and it seems to me that either way can be made into a
reasonable specification; the non-AH way has some epsilon better
properties from my standpoint, but nothing huge.  I'll happily re-revise
the specification so that the authentication data fields are removed and
use of AH is once again specified -- after the decision is made.  The
recently released draft specification assumes AH is NOT being used for
the purpose, and I believe the disruption to existing implementations is
substantial but not devastating, since the same subroutines can be
called but just from different places.

Your document drone,
Charlie P.

---

From: Jean-Michel COMBES <[email-masked]>
Date: Wed, 04 Jul 2001 18:36:57 +0200

Hi ,

> Binding Updates.  I can recount the reasons if need be.

JMC : I think it would be a good idea to summarize these reasons and why not to
launch a concrete debate.

> properties from my standpoint, but nothing huge.

JMC : ... and IPsec is native in IPv6. Are the reasons (of not using IPsec with
MIPv6) so strong to make things more complex ?

>  I'll happily re-revise

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Alexis Olivereau <[email-masked]>
Date: Thu, 05 Jul 2001 17:01:26 +0200

Hello Charlie,

Frankly, I would be quite reluctant to discard IPsec that way, not only
from a 'existing implementations' point of view but also taking into
consideration the future enhancements that are likely to be added to MIP
in the next few years.  I am quite convinced that more powerful
terminals, general AAA framework, will re-enable the use of IPsec (let's
say ESP/NULL) to secure BUs and BAcks. Shouldn't we consider these
future prospects before such a decision?

IKE is heavy and PKI is not scalable, that is quite a consensus.  On the
other hand BAKE (for example :-) is scalable but the key it provides is
not as secure as the one IKE provides.  As an example of alternative, I
would like to make a very basic proposal that will neither modify
heavily MIP nor IPsec.  The idea is to let IPsec use the key that BAKE
(for example :-) gives. Now this can not be done without telling the
upper layer about the (poor) level of security this Security Association
would provide.  I suggest that we use a new protocol flag to mark the SA
as a MIP one. For example, along with MD5, SHA1, SHA2 algorithms that
ESP uses for its authentication part, we would add MIP-MD5 as if it was
a new authentication algorithm.  Concretely the MN-CN key could be
copied into IPsec part within a new SA after its distribution has taken
place.  SPI and SN would have to be synchronized, let's say during key
distribution.  And the algorithm would just be marked as 'MIP-MD5'...

Anyway, the point here is not to write new scenarios, but to emphasize
some other ways that I think we have not paid enough attention to:
splitting Mobility from Security would surely discredit the very reason
for IPv6...

No need to say that comments are welcomed!

Regards,
Alexis

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Jul 2001 08:36:35 -0700

Hello Alexis,

First, I need to doubly emphasize that I have no part in any decision
to discard IPsec.  However, statements have been made by the Security
Area Directors (and other very knowledgeable people within the IPsec
working group) that we couldn't use IPsec that way.  When I asked how
we might go about making changes that would enable the use of IPsec,
I was told it would take a very long time (possibly years) of IPsec
working group action.

If somebody in the Security area wants to tell a different story,
that will be just very fine with me.  I'll try in a later note to
describe my perhaps-inadequate understanding of the reasons why.
I wish they would carry out the conversation on the [mobile-ip]
mailing list instead of telling me in person or making statements
in the face-to-face Mobile IP meetings.  That way we could get it
in writing and bring into the conversation the Mobile IP experts
and IPsec experts from around the world.

Furthermore, in no way does the current document split Mobile IP
away from security.  The current Binding Update is quite secure,
as was the previous Binding Update which relied on AH.  The difference
is that the current Binding Update can have _EXACTLY_ the semantics
that need to be specified for Mobile IPv6.  Relying on AH, which in
my opinion SHOULD still be O.K. but that's just my opinion and not
going to matter when the IESG reviews the document, has the effect
of leaving the Mobile IPv6 vulnerable to outside forces who may claim
(and have claimed) that we have made inappropriate use of the protocol.

Please note that this discussion is quite independent of
any discussion about BAKE or PKI, at least to my understanding.
But since you mentioned it, I believe that BAKE is amenable to
further extension that would allow:
- Better security with Diffie-Hellman (as an optional feature)
- Identity authentication by way of PKI (as an optional feature),
and I expect to do something along those lines before London.
BAKE must be considered to be an individual submission, not a
working group document, and as such the Mobile IPv6 document has
zero reliance on BAKE.  Having said that, however, I absolutely
agree with your statements that BAKEd keys COULD be used with
IPsec if such a thing were classifiable as a good feature by the
appropriate security folks.

It's crucial to identify what is needed for implementation from
_every_ IPv6 node, vs. what can be implemented by IPv6 nodes that
need additional features.  I'm sympathetic to arguments about
what needs to go into IPv6 lightbulbs, as well as cellphones,
laptops, workstations, and mainframes.

Regards,
Charlie P.

---

From: Alexis Olivereau <[email-masked]>
Date: Fri, 06 Jul 2001 13:50:44 +0200

Hello Charlie,

Please find my comments inline!

> I was told it would take a very long time (possibly years) of IPsec
Actually I was expecting that some "security people" would react to that
thread, telling us all the very reasons why we should not make use of
IPsec.  This is a tough decision, I am a bit surprised to see that very
few people (even on this mailing list) appear to be affected; hey folks,
are you all on holidays ?! :-)

> and IPsec experts from around the world.
I plainly agree with you; I would even say that it seems essential to
obtain a real consensus.  We *do* need that reasons, plus the reasons
why IPsec could not be easily made able to cooperate with MIP.

> (and have claimed) that we have made inappropriate use of the protocol.
Of course! Actually, I did not mean that we had lost any security
service or that the security level afforded to BU was weaker.  What I
meant is that mandatory IPsec and MIPv6 within IPv6 are 2 essential
blocks, which are now said not to be able to work together! Personally I
do not find that very clean to go back to a specific security solution
for MIPv6 as it was the case with MIPv4...

> appropriate security folks.
Once again, I wish I were able to get some feedback from IPsec people on
this point!

> laptops, workstations, and mainframes.
I try to keep in mind future needs too, and IMHO the future will be
based on IPsec.  We may certainly use both MIP-only security mechanism
and IPsec but in my (protocol-oriented) point of view, it is not only a
waste of bandwidth: it is something that would definitely go against
IPv6 spirit.  Now the question is "do we have any other solution?..."

Regards,
Alexis

---

From: Michael Thomas <[email-masked]>
Date: Sat, 21 Jul 2001 08:40:53 -0700 (PDT)

[I know this is old, but probably worth restarting this before London]

 > (and have claimed) that we have made inappropriate use of the protocol.

As I recall, there were two objections to the way that -13
was using IPsec.

1) There is no way to express a SPD rule (or ingress/egress filter)
   for an IP packet which has multiple IP extensions. There is the
   ability to filter on the normal five tuple (or subset thereof)
   and that is it. -13's ability to piggyback a BU (which is an
   IP extension header) with a normal, say, TCP header would not
   be processed correctly by IPsec.

   If, however, a node were willing to _not_ piggyback BU as 
   well as instantiate an SA either solely for the purpose of matching the BU header
   (where it was there alone), or with the properly formated 
   wildcarded IPsec ID -- typically, all traffic from a particular
   IP address in transport mode only -- I believe that IPsec's
   current selector mechanism works fine. Indeed, I don't see any
   problem with using IPsec between the HA and MN, and with the
   proper restrictions, I think that can be extended for use between
   the MN and CN. See draft-thomas-mobileip-esp-bu-00.txt for a 
   discussion of the problem, as well as a proposal to use ESP for BU's.

2) There was a great deal of concern about the authorization problem.
   Namely, that even if a random CN were able to determine the
   identity of a node requesting a BU (a dubious proposition in
   itself), that doesn't give it in and of itself the _authority_
   to change the binding for a particular IP address. In order to
   prevent otherwise authenticated but potentially unauthorized
   entities from abuse, there must be some form of correlation
   that the CN can use to determine whether a particular identity
   is authorized. This is nothing new, really, and happens all of
   the time with PKI's, Kerberos, etc, backed by authorization
   correlation, say, in an LDAP database. However, the scale of
   of the *random* CN/MN interaction posits the *worldwide* 
   availability of that authentication/authorization correlation
   which is secure, scalable, free from reptilian corruption,
   etc, etc. In other words, it's untenable, and unclear that
   it would be desirable even if.

   Now, that said, I do not think that rules out use of IPsec
   (with the restrictions from #1) in situations where the
   authentication/authorization correlation can be kept a local
   matter (eg, doesn't require IANA, or or the address registries
   to become a PKI root). It would be perfectly reasonable for
   an enterprise to run their own authentication/authorization
   service for their own employees, and they could use IPsec
   to protect the BU's after, say, IKE or KINK made a policy
   decision based on the security policy database rules it
   was provisioned with. Indeed, within some security domains,
   authentication is in many cases sufficient to grant 
   authorization, and I think we should still preserve that
   flexibility so long as we do *not* try to extend it to the
   general case, which was what -13 was hoping to do.

In conclusion, I do think it's worthwhile to
preserve a strong crypto possibility using IPsec
for both MN/HA interaction as well as MN/CN
interaction within the scope that it was meant to
operate (ie, without global implications). The
weak authentication/authorization that is being
proposed in BAKE and my Cookies draft should be
more narrowly focused on the random MN/CN
interaction where it is not pragmatic to have a
strong crypto solution.

	      Mike

---

From: Jean-Michel COMBES <[email-masked]>
Date: Tue, 24 Jul 2001 18:30:05 +0200

Hi,

>    be processed correctly by IPsec.

JMC : May you explain me why can't you piggyback BU with a TCP header ?

In my point of view, the problem of IPsec granularity is on the fact that BU and BAck
have no "special" next header number. Thus, any Destination Option (not only BU/BAck)
will be processed by IPsec.

>    discussion of the problem, as well as a proposal to use ESP for BU's.

JMC : BTW, where is placed the DO-H@ in your proposal ?

>    general case, which was what -13 was hoping to do.

JMC : Totally agree.

--

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 24 Jul 2001 13:27:47 -0400

Not quite; we could fix IPsec implementations to recognize BU's and
treat them separately if there was no piggybacking going on.  

The deeper problem here is that AH/ESP protect the entire packet, and
mobile IPv6 currently only wants to protect the binding update.  

This leads to ambiguity on the receiver in terms of knowing what
policy to apply to a new connection.

If I receive an AH-protected packet containing a binding update and a
TCP SYN, a receiver cannot know for sure whether the sender intended
the AH protection to apply just to the binding update, or also to
subsequent packets that are part of the TCP connection.

While I thought this option had been beaten to death, if folks still
want to use IPsec to protect MN/CN traffic, here are two possible ways
to deal:

 1) disallow piggybacking, and always send binding updates separately
from user traffic.

 2) since you've already paid the cost of setting up the IPsec
security associations, you might as well just keep using them -- once
a binding is established, *all* traffic between the MN and the CN
should be protected the same way.

Note that even with this issue resolved, you still have to deal with
the PKI/authentication/etc. issues involved with SA setup; if
anything, this is a much harder problem..

					- Bill

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 24 Jul 2001 10:55:38 -0700 (PDT)

> mobile IPv6 currently only wants to protect the binding update.  
When piggybacked, the intention was to protect the whole packet and
not just the Binding Update. The issue was then how to piggyback
the binding update on a clear TCP connection. Because IPsec policy
would not allow this. I think you really meant to say the entire flow
above i guess.

>  1) disallow piggybacking, and always send binding updates separately
This is the easiest.
 
> anything, this is a much harder problem..
It depends on how secure a solution you want. The requirements state
that :

    It SHOULD be extremely difficult for an attacker "off-axis" i.e.
    an attacker that cannot snoop packets on either of the three legs
    of the paths, to divert traffic. This difficulty should be on the
    order of correctly guessing a very large random number.

    Any approach MUST consider the scalability issues and
    computational capabilities of the entities in a mobile environment
    (MN, HA, CN). The expense associated with generating keys or
    public key operations or Diffie Hellman computations SHOULD be
    accounted for

-mohan

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Jul 2001 14:56:57 -0700

hello,

i thought the real problem with the use of IPSec was with 
distinguishing a destination options header containing a 
BU and a destination options header containing some other 
option. this is not possible with current IPsec selectors.

at least this is what Jeff Schiller said in his presentation 
at the minneapolis IETF.

if piggybacking a BU was the problem, we could have solved
it long back. just disallow piggybacking. anyway its a 'MAY'
in the current draft. you dont lose much by not piggybacking
the BU.

of course, the other problem is the lack of a global PKI.

> subsequent packets that are part of the TCP connection.

dont sent those two together, then. you dont HAVE to piggyback.

vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Jul 2001 15:28:06 -0700 (PDT)

> option. this is not possible with current IPsec selectors.

Ah, that's very different, and I agree it would be
a problem with IPsec selectors. I guess I have to
ask that _if_ that was the intention of the -13
draft, why. I didn't read it that way, but it's
quite possible I didn't notice that subtlety. If
the intention was not wanting other DO's to have
to be protected, I guess I have to wonder why. I'm
starting to think that Bill's suggestion of just
setting a up coarser ID selector (ie, don't select
based off of IP protocol) may be the right tweak
here.

Frankly, I think that IPsec/IKE needs a face lift
here, because this is all screwed up; MIP has the
dubious distinction of being first to be blown up
by this land mine left over from the v4 centric
world.

		Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Jul 2001 14:56:57 -0700

hello,

vijay

---

From: Jean-Michel COMBES <[email-masked]>
Date: Wed, 25 Jul 2001 14:18:37 +0200

Hi Vijay,

> option. this is not possible with current IPsec selectors.

JMC : why not attribute a different "Next Header" value (ie. not equal to
60) to BU/BAck ? With this solution and "no piggybacking", IPsec will work
fine.

JMC.

--

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 25 Jul 2001 11:56:29 -0400

> option. this is not possible with current IPsec selectors.

Vijay,

This is a *consequence* of the issue I pointed out yesterday: namely,
that if you allow for traffic on a connection/flow to contain a mix of
encrypted and unencrypted packets, you open yourself up to various
nasty denial of service attacks, and IPsec cannot provide useful
guarantees to upper layers.

> in the current draft. you dont lose much by not piggybacking

I disagree.  If it's a "MAY", then folks will build implementations
which always piggyback, which will cause interoperabilty problems with
IPsec implementations (such as Solaris's) which do per-connection
policy checks.

> dont sent those two together, then. you dont HAVE to piggyback.

It's not that simple.  It's an interoperability issue.  If
piggybacking remains optional, the sender chooses whether to
piggyback, while the *receiver* either does or does not do the
connection-oriented policy checks which would cause subsequent
unencrypted packets to the connection to be dropped..

This causes a perverse result that high quality IPsec implementations
which do the policy checks will fail to interoperate, while low
quality IPsec implementations will appear to work (while not providing
appropriate levels of protection to the traffic).

					- Bill
				(Solaris IPsec implementor)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 25 Jul 2001 09:12:35 -0700 (PDT)

> guarantees to upper layers.

Bill,

I think you two are actually in violent agreement,
as I read Vijay's comment as meaning that killing
piggybacking in the spec if that were necessary
wouldn't be any huge loss.

However, your comment about mixed traffic bothers
me quite a bit. A very ordinary mix of traffic for
mobile nodes will probably be SRTP (secure RTP)
media probably over ROHC header compression, but
using IPsec for most other signaling. This is an
extremely appealing combination since the high
bandwidth media is heavily optimized, but the
relatively low bandwidth signaling is fully
protected.

If you think this is a bogus use of IPsec, I'd
appreciate if you'd elaborate on it more.

	      Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jul 2001 10:31:39 -0700

Bill,

i meant 'if piggybacking the BU is a problem, we can put an
explicit statement in the mobile ip draft which says BU
MUST not be piggybacked with any packet'.

this wont lead to any interoperability problems.

the actual problem is every packet from the MN to the CN
would have a home address option in a destination options
header. i cant have an IPsec SA in which i can say 'protect
only the packet which has protocol 60 AND a BU destination
option'. i can only say 'protect protocol 60'.

of course this can be solved by a simple hack in the 
implementation (i have done this), but everybody would 
have to implement this hack. and i dont see the IPSec 
specs being changed anytime.

Vijay
( Nokia's MIPv6 AH implementor :-) )

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jul 2001 10:42:55 -0700

> 60) to BU/BAck ? With this solution and "no piggybacking", IPsec will work

Francis Dupont tried it at the San Diego IETF. but people in the IPng
working group werent too happy.

the draft was draft-dupont-destoptupd-00.txt

and check out http://www.ietf.org/proceedings/00dec/toc.htm#P137_4468
for comments from folks in the IPng WG.

vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Jul 2001 10:49:36 -0700

> based off of IP protocol) may be the right tweak

i have already done this as an hack in my implementation.
but specifying this would be nice.

vijay

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 25 Jul 2001 15:36:06 -0400

> I think you two are actually in violent agreement, as I read Vijay's
> comment as meaning that killing piggybacking in the spec if that
> were necessary wouldn't be any huge loss.

I didn't read his comment that way.

Oh, by the way...

Once you've thrown out piggybacking, why not also throw out the whole
binding-update, home-address, etc., etc, option scheme and just go to
a much simpler ipvN-in-ipvN tunneling scheme in conjunction with a
tunnel setup/update protocol?  Yes, the packets get slightly bigger,
but header compression can deal with that over low bit-rate links.

> However, your comment about mixed traffic bothers me quite a bit. 

Good, it was supposed to ;-)

> A very ordinary mix of traffic for mobile nodes will probably be
> SRTP (secure RTP) media probably over ROHC header compression, but
> using IPsec for most other signaling. This is an extremely appealing
> combination since the high bandwidth media is heavily optimized, but
> the relatively low bandwidth signaling is fully protected.

As always, you need someone to do a security analysis of the
proposed combination before you can say with any confidence that a
particular combination looks secure.

You have to look for weaknesses not only in the protocols themselves,
but also in exactly how they're stapled together.  As a good example
of a flaw of this form, early versions of the GSSAPI authentication
scheme for IKE (draft-ietf-ipsec-isakmp-gss-auth-07.txt) allowed the
GSSAPI tokens to be cut & pasted between IKE sessions, allowing for a
man-in-the-middle attack.

Note that I'm not volunteering to do the analysis for this protocol..

					- Bill

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Jul 2001 08:24:49 -0700 (PDT)

> but specifying this would be nice.
   
   Er, I think what Bill (and I) suggested didn't require
   a hack to IPsec at all. Ie, just set up an ID selector
   which doesn't filter off of the IP protocol (ie, is
   wildcarded.) This means that you wouldn't be able to
   put TCP traffic on one SPI, UDP on another, etc, but
   it would work without hacks.

   Maybe revisting Francois' UDP proposal isn't such a
   bad idea...

	Mike