Subject: [mobile-ip] Re: New authentication scheme in Mobile IPv6 draft revision ...-14

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Jul 2001 15:47:04 -0400

> > 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.
> 
> Could you make a small description about how the attacks work?
> 
> I would have thought that IPsec should be applied depending on the
> kind of socket opened by the application, but maybe not.

It's more complicated than that.

A system may want to allow opportunistic use of IPsec.  In particular,
a server doing a passive tcp open may wish to accept either
unprotected or protected traffic, leaving the choice of whether to use
IPsec up to the client which does the active open.

However, once the connection is started, it would be a security hole
for the server to accept an unprotected packet; otherwise, an attacker
could inject a forged RST or FIN as a denial-of-service attack.

If AH or ESP is used to protect the binding update, then a server
doing the MIPv6 Correspondant-node protocol and allowing opportunistic use
of encryption does not know whether the protection applies to both the
BU and the rest of the packet.

> >> 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.
> > 
> > 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.
> 
> Doesn't this problem go away entirely in draft ...-14?

I have no idea.  It may, but there may be new problems introduced by
the new protocol in -14.  The document is 120 pages long and I simply
don't have time at the moment to review it.  

The underlying message you should have been getting all along from the
security experts is to simplify the protocol.  This change increases
its complexity.

I repeat my recommendation that MIPv6 discard the use of destination
options and just use straightforward IPv6-in-IPvN tunnels, which are
already understood and are well-handled by existing IPsec
implementations.

					- Bill

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Jul 2001 13:12:12 -0700

> don't have time at the moment to review it.

I can certainly understand that.  If you had time to review just a
dozen pages, I could suggest the Changes appendix and just the
Binding Update option.

> security experts is to simplify the protocol.  This change increases

I don't think so!  The change amounts to putting the authentication
data directly into the Binding Update option (an increase in complexity)
and removing dependence on IPsec.  The latter, as I think has been
conclusively demonstrated even by your notes of the last week, amounts
to a very large decrease in overall complexity.  For instance, there
wouldn't be the kind of denial of service attacks you mentioned.

> already understood and are well-handled by existing IPsec

It's something to consider.  However, I should also point out that

- People have been building implementations for a long time
- There have been numerous interoperability tests
- The protocol was already working pretty well, and then the
  request was made by security authorities to enlarge the problem
  space in order to make the protocol more immediately applicable
  to all IPv6 nodes.

This all amounts to a pretty big delay, but I continue to hope that
we could be done soon after some work on getting keys set up for
the Binding Update message.  Throwing away all the previous work
doesn't seem fair, nor even warranted because it doesn't get to the
root of the problem(s).  That's not fair, and a high price to pay
for catharsis.  Plus, it seems to me that the destination option
structure is exactly right for the purpose -- which is to notify the
destination about something related to the delivery of data back
to the source.

Regards,
Charlie P.

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Jul 2001 16:35:00 -0400

> It's something to consider.  

Good.  I hope it gets a fair consideration.

> However, I should also point out that
> 

In response, I'll point out that folks have been asking me how to
secure mobile IPv6 for about a year and a half, and I've been
providing the feedback quoted above for nearly that entire time.

						- Bill

---

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

> wouldn't be the kind of denial of service attacks you mentioned.

Bill's right: what IKE DOI currently describes how
to key that authentication data? How does that
authentication data prevent replays? &tc.

If we use standard IPsec mechanisms, we inherit
answers for those questions automatically along
with a well understood set of complaints about
them. Rolling our own in MIP gets to answer all of
those questions anew (and more, I'll bet) which
IMO is an increase in complexity, and certainly a
more complex security analysis would be needed.

 > Plus, it seems to me that the destination option

That's arguable. It's a routing change and could
easily be treated as such. The main advantage
seems like the ability to piggyback, but it
remains to be seem whether that optimization is
really worth the trouble it brings.

		Mike