Subject: [mobile-ip] Last Call Comments on http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-scrty-reqts-01.txt

From: James Kempf <[email-masked]>
Date: Thu, 18 Oct 2001 10:00:19 -0700 (PDT)

Hi folks,

I have not been following this discussion very closely
but several people here at DoCoMo Labs have and they
have requested I post comments on the document.
Apologies if this note duplicates comments from
others.

In general, the document seems very heavily weighed
towards MN/CN security threats and very lightly
weighted towards MN/AR threats. Some of the MN/CN
threats are redundant. There are 18 threats
identified for the MN/CN and only two for the MN/AR.
This is perhaps understandable, given the attention
the IETF security folks have been focussing on the BU
security problem, but the MN/AR relationship is, in
some sense, equally if not more important (it is, for
example, a MUST and not a SHOULD).

The particular threats that we feel need to be added
are the following:

1) A malicious AR could hijack traffic from a trusting
MN. This was partially identified in the document.

2) A theaving MN could gain network access without
authorization by soliciting a Router Advert, then
setting up a CoA.

3) Similar to 2), a theaving MN could gain network
access without authorization through responding to an
unsolicited Router Advert, then setting up a CoA.

There are a variety of places within the process of
network access where these threats could be addressed,
but I assume since this document is concerned with
threat analysis, the solutions will be in another
document.

                 jak

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Oct 2001 20:36:57 +0300 (EEST)

> example, a MUST and not a SHOULD).

I'm not sure if 'AR' means 'Access Router', but assuming so..

Hmm?

Am I mistaken but from the draft:
--8<--
   The goal is to determine which of those threats are of concern and
   should be defended against.  While the basic goal is "no worse than
   IPv4," the prevalence of wireless and the likely deployment of MIPv6
   in that space means the basic goal should aim at being "no worse than
   IPv4 with switched Ethernets", although the intent is not to try to
   solve the security problems of shared/broadcast wireless mediums.
   The threat model is used to generate a list of requirements to make
   the MIPv6 protocol secure against likely threats. These requirements,
   interspersed with the threats and also listed at the end of this
   document are aimed at providing guidelines in developing a solution
   for MIPv6 security.
--8<--

> MN. This was partially identified in the document.

This is no different from any secure IPv4/6 environment.  If you don't use
AH/ESP or equivalent, any upstream router can do that.  This is not in the
scope of MIPv6, I think.

> unsolicited Router Advert, then setting up a CoA.

This is no different from IPv6; it doesn't provide access controls on who 
can or can not autoconfigure an address and use it.

One should assume that if you can phycially get into a LAN, WLAN, a cell, 
... or whatever, you're authorized to use the network.

So these may also be outside of the scope.

One _could_ list a few "known" issues in the draft, of course.  (About 
one-two lines per non-issue).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Oct 2001 10:49:11 +0200 (CEST)

> example, a MUST and not a SHOULD).

I think Charlie argued that the generic IPv6 threats (which is
what I think you call MN/AR threats) should be removed instead.

The reason the few are present was intended to be examples
where e.g. Neighbor Discovery makes certain attacks possible
and point out that MIPv6 is not expected to solve those.
But if we can get closer to completeness on for those types of
threats I personally think it would make sense to add more of
them. Then we can send the document to the IPNGWG and point
out that e.g. ND needs to be secured better for public access networks.

> authorization by soliciting a Router Advert, then

I don't quite understand. Is the MN sending a Router Solicitation or
a Router Advertisement?

> unsolicited Router Advert, then setting up a CoA.

Also, 

4) a MN could launch a DoS attack against other MNs on the link
by responding to all duplicate address detection probes.

5) any MN could redirect traffic from other MNs by sending one Router
Advertisement announcing itself and sending periodic Router Advertisements
with AR as the source address and a lifetime of zero. This will make
all MNs on the link use the attacker as the default router.

> threat analysis, the solutions will be in another

Yes, and it makes sense pointing of which threats are possible due to
the mechanisms in ND vs. MIPv6 vs. ???

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 Oct 2001 07:05:22 -0700

> what I think you call MN/AR threats) should be removed instead.

I didn't go quite that far.  I agree with you that there is
value in providing information related to mobility somewhere
in the document.

I thought that the generic IPv6 threats should be clearly
labeled as such, and in the case of Neighbor Discovery I
would gather them into either an introductory section,
or else put a more detailed description into an appendix.
Maybe it's best to do both, with the introductory section
pointing to the appendix for details.

Regards,
Charlie P.

---

From: James Kempf <[email-masked]>
Date: Fri, 19 Oct 2001 09:39:09 -0700 (PDT)

Hi Erik,

> out that e.g. ND needs to be secured better for

Agreed. Charlie's proposal to put them in an appendix 
seems like the best route.

> I don't quite understand. Is the MN sending a Router

It is sending a Solicitation. If the access router
is not required to authenticate the Solicitation, then
an unauthorized MN could gain access.

> > unsolicited Router Advert, then setting up a CoA.

In this case, the MN is responding to an unsolicited
Router Advert by performing address autoconfiguration.
With stateful address configuration, I would assume
that DHCP security could be used to determine
whether the MN is authorized for an address. So
the issue here is that there needs to be some way to
perform authentication on address autoconfiguration
messaging.

> the mechanisms in ND vs. MIPv6 vs. ???

I think the threats you've outlined above are clearly
not MIPv6 related, but, as I mentioned in an earlier
response, they are made worse by mobility because you
cannot secure a physical network access point.

There are some threats that require authentication on
the MN/AR exchange (1 and 2 in my original message,
also something similar to 1 is dicusssed in the
draft).
There are others, which you outline above, that
involve ND and address autoconfig. In addition, there
is a need to more thoroughly think through security if
stateful address config is needed.

A short summary of the threats in an appendix would be
useful. In addition to IPNG, I think URP will need to
be involved (presuming it gets chartered). Prior to
the authentication of any ND or address autoconfig
messaging, there needs to be some kind of AAA exchange
in order for the proper initial conditions to be set
up.

                 jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Oct 2001 09:54:41 -0700 (PDT)

> an unauthorized MN could gain access.

Um, not necessarily. You _could_ overlay admission
control onto RA/RS, but it isn't the only way to
produce a choke point. I don't know where URP
landed after last IETF, but it's not inconceivable
that the RA could just advertise the authentication 
mechanism/realm and that another protocol could do
the actual authentication work. The router just
needs to enforce a fairly restricted ACL in the
mean time. 

The nice thing about doing this is that you can
use normal mechanisms to enroll people for casual
use (eg, allow traffic to your enrollment web
site), and other things by granting limited IP
connectivity.

 > whether the MN is authorized for an address.

There is no "DHCP security" that I'm aware of.
Maybe that's changed recently, but it's certainly
not common. Also: you've factored out L2
authentication mechanisms. 802.1x(f?) and DOCSIS
are two examples of admission control that take
place at L2 on ethernet-like MAC's. That's another
approach, though truth be told, I'd be happier
with a common IP solution so all those folks can
do something else with their time (cf WEP).

	     Mike

---

From: James Kempf <[email-masked]>
Date: Fri, 19 Oct 2001 10:10:02 -0700 (PDT)

Hi Michael,

> site), and other things by granting limited IP

Good point. 

> do something else with their time (cf WEP).

I believe the DHCP group has been working on something
involving security, at least, I recall seeing a draft
go by awhile ago. I don't know where it is at.

I also think that having a common IP solution is
preferable to having a collection of L2 mechanisms,
though I think there are cases where L2 mechanisms may
also be desirable, for performance or other reasons
(fast handoff for example). Certainly, for admission
to network access an URP-like solution is more
desirable than having each L2 specify their own. 

                     jak

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Oct 2001 10:54:34 +0200 (CEST)

> an unauthorized MN could gain access.

What do you mean by "access"?
The MN will receive a Router Advertisement packet, but that in itself
doesn't imply access to anything.
The RA just carries parameters to the host.

> perform authentication on address autoconfiguration

Are you concerned that the ability to assign an address implicitly
allows the node to consume network resources?
Or are you concerned about the node being able to prevent others
from using their (perhaps more legimate) addresses?

> cannot secure a physical network access point.

The threats are made worse by computers moving around (i.e. the most
fundamental notion of "mobility") but also by the desire
to provide public access network infrastructure, whether in the form
of Ethernet wires in a hotel or some wireless technology.
Such public access networks could be used e.g. for residential
network access i.e. in cases where mobility isn't the key descriminant.

In order to reduce the likely confusion between "mobility" and "mobile IP"
I prefer to attach these types of threats to the "public access network"
term or something similar, since I think that captures the essential
element. 

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 22 Oct 2001 11:33:20 +0200

Michael Thomas:
> > not common.

> go by awhile ago. I don't know where it is at.

Maybe the DHCP Threats draft?
draft-prigent-dhcpv6-threats-00.txt

Alex

---

From: James Kempf <[email-masked]>
Date: Mon, 22 Oct 2001 09:14:14 -0700 (PDT)

Hi Erik,

> The RA just carries parameters to the host.

I means "access" in the sense of
draft-ietf-mobileip-ipv6-14.txt. I suppose to be more
generic, one could say last hop router. Default router
is another possibility, but the assumption is that at
this point, the host has not yet chosen a router,
there could be multiple RAs for a particular subnet if
there are multiple last hop routers, so the host
really has
no default yet.

> from using their (perhaps more legimate) addresses?

Primarily 1. With 1), the host could mount a DOS
attack or steal service once it has a legitimate
address, presuming the last hop router is willing to
co-operate and continue sending traffic. I have some
difficulty seeing that 2) could be a problem. Unless
addresses are in short supply (which should not be a
problem with IPv6), I can't see how one address could
be more legitmate or more valuable than another. Did
you have a particular case in mind?

There is an additional case involving mobility which
may be a problem, I don't know if it has been
discussed. Suppose a MN with a legitimate CoA moves
from one subnet to another and leaves behind a
still-legitimate CoA. An attacker or simply someone
wanting to steal service could start using that
address.
 
> network access i.e. in cases where mobility isn't

Yes, that's true. Many of these threats  with basic
access are fundamental to any public access network.

> term or something similar, since I think that

I think that's an excellent idea. 

                 jak

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Oct 2001 21:31:47 +0200 (CEST)

> co-operate and continue sending traffic.

It depends the model for how access control is implemented in the access 
network. One model is that access control is tied only to link-layer
authentication and authorization. Another is that it is done using
something akin to URP. In the latter case it will presumably be possible
to start off with a filter in the access router (or in some L2 device between
the AR and the host) that just allows the host to communicate with the URP 
agent. 
This is just an example to point out that the receipt of a RA doesn't imply
that the host has much of access.

> I have some

If a device uses RFC 2461 Duplicate Address Detection there is nothing
to prevent another device on the same multi-access link from responding
to each DAD probe. Hence the first device would not be able to allocate
any IPv6 link-local address. Without this it can't do anything. For instance,
it can't even talk to a DHCP server.

> wanting to steal service could start using that

Sure.
And depending on the link layer the attacker might be able steal service
using that CoA even before the MN moves away from the link.
For multi-access links without per host link layer encryption this can be
done by just sending an unsolicited Neighbor Advertisement.

I think the "steal service" i.e. unauthorized use of network
resources fall under the scope of what URP has been talking about.
And other forms of attacks are related to RFC 2461.

Makes me wonder if we could start with a threat analysis for URP
as opposed to trying to do one at the end ...

   Erik

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 26 Oct 2001 08:15:23 +0300

> it can't even talk to a DHCP server.

FYI:  Last spring when I considered the address ownership problem,
I also had some ideas how one maybe could fix this with a relatively
cheap S/Key like reveal-hashes-in-reverse order kind of construct.

See Sections 3.1.2 and 3.1.3 of
http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt

--Pekka Nikander

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 Oct 2001 16:53:55 -0700

Hello,

I know I'm late for the last call. But nevertheless I'd like to identify a
new security issue
with Mobile IPv6. Please take a look at this and comment....

Home address option of Mobile IPv6 gives the flexibility to use any IP
address as the source
address of a packet and send it to a receipent (a correspondent node). And
the correspondent
node should be able to process home address option to figure out the true
end point of this
communication. By using this option, a node can use any arbitrary IP address
as the source
address of outgoing packets, and be able to maintain end2end connection with
a peer.

This can be exploited by malicious nodes to impersonate other nodes, as far
as the routers
along the path are concerned.

Any mechanism that relies on the source IP address of a packet can be fooled
by using an
acceptable source IP address (like one borrowed from a legitimate node) and
carrying the
real source address in the home address option.

For example, a flow is (or proposed to be?) identified by the source address
and the flow
info of an IPv6 packet. If the malicious node can learn these two fields of
a legitimate packet, it can
start using them in its own packets. Therefore stealing QoS established for
another device (along
the common path).

So, why do we think there's something new here. Afterall, even with IPv4, a
device can steal
some other device's IP address and use it. But.... if it does so, the
correspondent node would
think that this packet is coming from the legitimate device, therefore any
correspondence will
be directed at the legitimate device. And hence, malicious node cannot enjoy
a end2end
communication.

With IPv6 and home address option, the packets from the malicious node look
like they are from
a legitimate node to all the routers along the path (same as in IPv4)  and
when arrived at the
correspondent node they reveal their true sender (this is new!).

A correspondent node receiving such packets won't know what's going on. And
nothing special
on correspondent node is expected for this to work (except a correct
implementation of home
address option processing :)

First solution that comes to mind would be to expect protocols to check for
home address
option in addition to source address, but that is not desirable as it is
costly.

What do people think about this issue?

(I might not be able to follow rest of the discussion for a week. I'll be
out of town. But I'm sending
this now, so that the discussion is not delayed).

alper
NTT DoCoMo USA Labs

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 26 Oct 2001 21:51:41 -0700

Hello Alper,

Alper Yegin wrote:

> as the routers along the path are concerned.

The point of the option is to apply a topologically correct source
address.  Routers aren't checking to see _who_ is sending the
packet.  They're checking to see if the address matches a reasonable
prefix.  I don't think it makes sense to worry about a malicious node
impersonating a node, when the entity it is fooling doesn't care anyway.

>
>
>
> Aaddress in the home address option.
>

It is an interesting problem about whether a flow label needs to be
interpreted according to the destination IP address or the home
address.  It seems wrong to try to make the intermediate
routers parse the home address option.  I reckon that there
should be a QoS feature transfer, which includes something
about new and old flow labels, to handle the flow over a tunnel
between access routers while the new care-of address gets to
be associated with the flow.  We've been puzzling over this a
little bit already in our group, but it depends on a lot of things that
are currently unknown.

It's not a security problem, though...

> correspondent node they reveal their true sender (this is new!).

It would be exactly like the packets came from the home network.... right?
And so that's exactly what we are trying to accomplish!

> option in addition to source address, but that is not desirable as it is

Why do you want to do this?  Which protocols should check?  Surely not
the protocols running on the routers...?

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Oct 2001 13:35:25 -0800 (PST)

> impersonating a node, when the entity it is fooling doesn't care anyway.

   Would this were true. There is one pretty
   intersting question about the RSVP/MIPv6
   interaction, and that is whether the RSVP
   router should filter off of the CoA, or off
   of the home address. As far as I can tell,
   there isn't an answer for this. There's 
   some amount of win were it to filter off
   of the home address because of session 
   persistence (changing CoA's pretty much
   means that you have to start a new reservation
   otherwise). Here, the attack Alper points out
   could in fact lead to hijacking of QoS
   resources, I'd think were it to filter off
   of home address. That would certainly be
   notable since it would move the attack from
   a DoS attack to a hijacking attack.

   Of course, the reality is that routers do
   make decisions off of L3/L4 headers all the
   time. It's not clear that they wouldn't want
   to filter off of home address option as well
   since that denotes "home". Since the home 
   address option was motivated primarily by the
   fact that routers do ingress filtering, I don't
   think this is quite as clear as you make it out to be.

	    Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Oct 2001 13:42:31 -0800 (PST)

> And so that's exactly what we are trying to accomplish!

   There's nothing that currently prevents me from
   having a legitimate CoA and putting any home address
   I feel like in the home address option. Routers
   currently can prevent source spoofing by doing
   reverse path forwarding checks (RPF), but a RPF
   check on a spoofed HA option would be useless 
   since the access router does not have any clue
   about mobility with MIPv6, and thus cannot verify
   the legitimacy of the source spoofed HA option.

   Thus you get a new source spoofing attack which
   isn't easily defeated at the edges. Not Good.

		Mike

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 Oct 2001 00:06:38 +0200 (EET)

>    isn't easily defeated at the edges. Not Good.

One common counter-argument here is that the real source address will be 
stored in the header anyway, so it wouldn't be a real, "complete" spoof.

As my rh-ha-security draft points out, this causes problems with at least 
following scenarios:

 1) the spoofer does not actually care all that much whether the real 
address is detected or not (example: sending udp exploits off a stolen 
brazilian dial-up account), but spoofing could still yield better results.

 2) there is no ingress filtering at all (all too common); this can be 
used to get around _destination site's_ ingress filtering checks!

 3) ingress filtering is not done at the first hop router, but e.g.  
site/ISP border, and then spoofing for the src address could be done so
that the real destination/source differ enough so that the real sender is
not traceable.