Subject: RE: [mobile-ip] MIPv6 IPSEc and s=0

From: [email-masked]
Date: Fri, 10 Jan 2003 10:42:24 -0600

Hi Gabriel,

I think that Jari has essentially done the work on clarifying
the "S" bit issue. I see no reason to drop it at this point.

I agree that the complexity of the "S" bit has caused more than
enough discussion, but I think we have a good proposal and one
that the key folks would agree to. So if Greg and Ed are okay 
with the recommendation from Jari, I would suggest that we keep
the "S" bit in the base spec. 
Of course if implementations discover that there are issues and
problems at a later date, we can always revisit. And nothing stops
the WG from developing a new I-D specifying the use of the "S" bit
that obsoletes the "S" bit spec in the base MIPv6.

-Basavaraj

> 
> Jari Arkko wrote:
> > What do others think? Greg? Here's suggested text for the
> > 5.1:  "When the Single Address Only (S) bit is zero, the home
> > agent MUST check that the same security association would
> > have been used if the Binding Update had been sent using
> > any of the implied home addresses."
> > 
> > I hate noticing serious issues like this at the last
> > minute. But what do folks think, would the above and
> > making S=0 optional for MNs solve this?
> 
> It seems like it, even though the SCTP ID_LIST is probably not
> in any current IPsec implementation (also, they seem to only
> allow IPv4 addresses, how come?). So how much work would it
> be to include all the above?
> 
> Would it be riskier at this stage than  leaving the
> S bit for another spec? I know you've concluded that
> since there is strong support for it, by default it
> should stay in. I don't agree. It is an optimisation
> which is not essential to the base protocol, and it's
> creating way too many complications (and huge volumes of
> email discussing issues like 202 and 184). I'd argue that
> by default (like all non-essential items) it should be out
> of the base spec. Folks could work on defining it later on.
> 
> This late in the game, though, let's do the simplest, I'm just
> wondering if after your recommendations above, Jari, inclusion of
> the S bit is still the simplest.
> 
> -gabriel
> 
>

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 10 Jan 2003 12:48:07 -0700

Jari's recommendation adds a little complexity (if I understand this
correctly), because now we are relying on having a list of HoA addresses as
a selector for the SPD entry.

Also, perhaps the wording is a little imprecise:
"the home agent MUST check that the same security association would have
been used..."

A SA is associated with a specific HoA, as I understand it, not with a list
of HoAs. I'd think that this text should instead say "security policy"
instead of "security association". Anyways, I'm not an IPsec expert so I'm
probably not understanding this correctly.

I would have preferred if the IPsec configuration was identical between the
single S=0 and the multiple S=1 cases (for the same set of MN HoAs). I think
Jari's recommendation is requiring that the IPsec configuration be different
between these two cases (but, perhaps it is a simplification worth
having...).

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, January 10, 2003 9:42 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [mobile-ip] MIPv6 IPSEc and s=0
>
>
> Hi Gabriel,
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Jan 2003 23:13:49 +0200

There was an argument whether there's a real threat involved in
this or not. Well, I'm not quite sure what this exactly means
in terms of a practical threat but I thought I'd share with you
a scenario that we came up with:

Alice has an agreement with an operator (or a company server)
for mobile IPv6 home agent service, with the home address
aaaa::1111. The security association SA_alice is used for
sending Binding Updates.

It turns out that the same home agent happens to have more prefixes
than just "aaaa" (but Alice doesn't consider them her home prefixes
for some reason, or hasn't yet considered). One of the other prefixes
is "bbbb".

The bad guy Mallory enters the picture. Mallory's IID is "2222", but
he has seen Alice's IID "1111" on the local WLAN. He now requests
Mobile IPv6 service from the same operator using the home address
"bbbb::1111". This "request" could be in the form of making an
agreement with the operator for the service for some money, or
walking to the company network manager's office and asking him
to configure Mallory's home address to the home agent. In any
case, at the time of asking for this service Mallory can use the
address bbbb::1111 in the home network without any DAD problems;
Alice doesn't defend this address*. Also, there are no SAs or
policy entries colliding with the addition of bbbb::1111 for
Mallory, so the network administrator is not alarmed. *If* the
administrator explicitly goes and checks for IID collision
Mallory will be "caught". However, if the administrator forgets
to do this and there are no software checks, Mallory gets his
SA_mallory and he's set up for the actual attack.

The attack is then that Mallory sends a S=0 registration
using SA_mallory. He will then register both bbbb::1111 and
aaaa::1111, Alice's address.

At this point Mallory has hijacked Alice's home address,
and she can't get service**.

Where does this leave us? Apparently, Mallory was able to
do some bad things. This was no random attack from the
Internet, however. This was an attack from another
customer, possibly identified or alternatively at least
he had to pay some amount of money for the service. Or
if this was a company network then the network managers
did identify Mallory in some manner before configuring the
SAs.

So, we have an attack which isn't catastrophic: like
in all failures of authorization you still need to be
able to authenticate yourself. This narrows down the
suspects to the subscribers of one operator, or the
employees of the company, maybe even identify the attacker
directly. Still, it is an attack that is bad and can't be
prevented beforehand unless someone checks the BUs,
SPD consistency, or IID collisions. Bad enough to require
a mandatory check in the MIPv6 spec? I don't know. But we
did require a mandatory authz check. This seems to be
in the same category, and the bad guys can set their own
IID to get into the collision situation so we can't really
argue that this is improbable.

Jari
----

*) Note that Mallory needs to avoid configuring fe80::1111 to
achieve this, but since he is in control of his own host he
can do it.

**) There are some further details, depending on the semantics
of re-regs and de-regs with differing S values, and whether
Alice is around to defend her IID with DAD or not. The spec
says S bit will be ignored for re-regs and de-regs. But what
does that mean if there's multiple addresses and some of them
were registered using S=0 and others with S=1? Also, DAD may
save Alice in some cases, such as if she was home at the
time of the attack. But Mallory might launch a packet storm
at that time to hide a DAD response, so there's no gurantee
about this. The bottom line is that executing the attack is
not easy, but there appears to be some cases where it succeeds.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 10 Jan 2003 18:26:17 -0800

> aaaa::1111, Alice's address.

at this point, if Alice had a binding cache entry at the home 
agent for aaaa::1111, this BU fails. Mallory gets a binding 
ack with 'DAD failed' status.

its possible Alice doesnt have a binding cache entry. then you
can have a problem. but, here is another scenario.

Alice's mobile node is shut off. the HA is not defending it. a 
node on the home link starts using Alice's IID. this node on 
the home link has same intentions as Mallory. Alice's MN comes
up and sends a BU. the BU fails. what does Alice do? 

now what does Alice do? isnt Alice in the same situation? why 
blame the S bit?

infact Mallory has be to be crazy. if he is caught doing this
intentionally he either loses his job (if HA is in corporate
intranet) or loses service (if HA is in an operator's network) 
:-)

> were registered using S=0 and others with S=1? 

how? why? are these registrations with two different home agents 
on the home link? thats not possible. only one home agent? then 
why does the MN send two BUs, when it can just send one BU with 
S=0?

please let me know if I am missing something stupidly obvious.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 11 Jan 2003 16:36:30 +0200

> ack with 'DAD failed' status.

Good point, and I missed that. But let's see all the details
on what actually happens. Lets assume the HA is OK with the
authz part of Mallory's request, either through some magic
or simply by us ignoring the implied home addresses. As
specified in 10.3.1, the home agent proceeds to run DAD.
The text says: "Unless this home agent already has a binding
for the given and implied home addresses, the home agent MUST
perform Duplicate Address Detection[13] on the mobile node's
home link before returning the Binding Acknowledgement."
This seems a bit vague, but I take it that it means the
home agent will use DAD to test all addresses it is not
yet defending. That is, in this case it tests for bbbb::1111.
(This could be argued perhaps. But if you consider a perfectly
normal S=0 re-registration when the home network has recently
gotten a new prefix... you'll see that the home agent *must*
test only bbbb::1111 and not aaaa::1111 or fe80::1111... if
it tested those other addresses, it would itself respond to
DAD and fail, even without any attacks.)

Conclusion: DAD succeeds for Mallory, as the home agent
is already defending other addresses and therefore skips DAD
for them. Or did I miss something?

> now what does Alice do? isnt Alice in the same situation? why 

Roughly the same situation, yes. I guess one difference is
that with Mobile IPv6, neither entity has to be physically
present. But both must have some sort of an association with
the home network.

> intranet) or loses service (if HA is in an operator's network) 

Yes.

Here's the difference of this attack vs. the basic authorization
attack where there is no authorization at all: In the basic
attack any mobile node could grab any number of other addresses
for himself, by sending BUs on behalf of those addresses using
his own SA. This has pretty devastating effects, even if here too
the guilty party can be caught at least if logs are kept.

In this new IID-collision attack the attacker has to first
trick the operator into giving him a colliding IID. This may
or may not be possible, depending on the operator's procedures.
Furthermore, the effects of this attack are less devastating
than in the basic case... there's just one victim per one
SA setup in the home agent.

So, our options are:

(a) Ignore the problem.
     + No document modifs needed
     - Seems a bit irresponsible at this stage

(b) Warn the administrators of this issue in the document,
     require an administrative procedure to prevent this.
     + Easy to do
     - Admins might be missing this check
     - Makes the configuration task a bit harder (and it already is
       hard)

(c) Require a protocol solution to prevent this, e.g. in
     the way I outlined with the 'list' selectors.
     + Prevents the attack in all cases.
     - Adds a dependency to a new document.
     - Increases complexity.
     - Might not be available yet in typical implementations.

(d) Start removing functionality until the problem goes away.
     + The document gets shorter
     - Multi-prefix home networks will be less efficient with MIPv6

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 11 Jan 2003 22:42:57 -0800

hi Jari,

Jari Arkko wrote:
>> at this point, if Alice had a binding cache entry at the home agent 
>> for aaaa::1111, this BU fails. Mallory gets a binding ack with 'DAD 
>> failed' status.
> 
> 
> yet defending. 

my assumption (and the way our implementations handles it), has
been that the HA does DAD for every address that it is about to
proxy for and defend. thats means the home address in the BU
and all the derived home addresses.

if it is vague, it needs to be clarified. IMO, it is kind of
dumb for the HA not to realise that it is defending an address
itself. it should send a bind ack with a failed status.

> That is, in this case it tests for bbbb::1111.

disagree. the HA knows that it is a new binding for bbbb::1111.
it should make sure all other derived addresses are not in its
binding cache already. it should reject the BU.

>     - Seems a bit irresponsible at this stage

:-) I am not yet convinced there is a problem. sorry for being
stubborn. but I hate removing features. we have already removed
a lot of features (IMHO), with the "its just too complicated"
argument.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Jan 2003 10:17:36 +0200

> binding cache already. it should reject the BU.

I agree that the home agent knows bbbb::1111 is a new binding.
It also knows its defending aaaa::1111 and fe80::1111. However,
I don't believe the rule "reject binding updates if I'm already
defending any of the addresses" is correct either. For instance,
this would clearly prevent _any_ re-registration even by the
same node and with S=1.

So, perhaps the rule is "reject binding updates if I'm already
defending any of the implied addresses"? If I registered
prefixes aaaa and bbbb earlier, I can no longer send in a S=0
registration before the binding expires, because there will
be an implied address that the home agent is defending.

The authorization question is at the heart of this issue.
Basically, the right rule is "reject binding updates if I'm
already defending any of the addresses *for some other mobile
node*".

We could either deal with this head-on with the alternatives
(a) to (d) in my previous e-mail. Alternatively, we could require
that a re-registration of an S=0 binding is always performed
using the same home address in the packet. This would prevent
the attack, as Mallory can't send in anything using Alice's
home address. I'm not sure, however, that there aren't any
remaining attacks. Also, using the same address might also
put some requirements on the MNs to have nv storage so that
they themselves remember which home address they used over
reboots.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 12 Jan 2003 16:52:52 +0200

>     - Makes the configuration task a bit harder (and it already is

Here's some potential text for this alternative. Comments
appreciated. Which alternative do folks want to pick? I'm
leaning on (b) myself at this hour, given that if interface
identifier collisions are allowed to develop, we have more
serious problems that just security: its hard for the colliding
mobile nodes to get any service due to link-local DAD checks.

The text is expected to be added after the second paragraph
in Section 5.2 [1]:

    "Note that when the Single Address Only (S) bit has been
     set to zero, bindings for several home addresses may be
     affected, all with the same interface identifier. Only one
     of these addresses appears in the packet, however, and the
     IPsec policy checks are based on that address. Such checks
     are therefore unable to verify that the correct security
     association was used, had the address been one of the other
     ones. For this reason (and in order to avoid Duplicate Address
     Detection conflicts), home agents SHOULD NOT be
     configured to serve different mobile nodes with the
     same interface identifier. Instead, it is recommended
     that the for each mobile node, security associations
     are configured to the same node for all combinations of
     available home subnet prefixes and the node's interface
     identifier(s). Home agent implementations MAY provide
     automated support for ensuring the consistency of
     the configuration setup."

Jari
----

[1] http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#securing-regs-with-home-agents

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 12 Jan 2003 11:09:47 -0800

I am fine with this, if it helps closing the issue immediately.

Vijay

Jari Arkko wrote:
> serious problems that just security: its hard for the co lliding
> [1] 
> http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#securing-regs-with-home-agents 
> 
>

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 12 Jan 2003 23:00:54 -0800

Hello Jari,

I think this is an excellent resolution to the problem.
In fact, I would change "SHOULD NOT" to
"MUST NOT" in the text you have devised.

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 13 Jan 2003 17:09:42 +0100

I like either option (b) "the warning" or option
(d) leave optimization for later.

Seems like (b) is gaining some traction. Let me do
a sanity check on it, and unless there's nothing
major here, I'll vote for it:

With option (b) it strikes me like
we're edging back into the DAD vs DIID discussion.
What it amounts to is that we're requiring the
equivalent of IID via some  ("automated support
for ensuring consistency"). Sounds like it'll
avoid collisions amongst mobiles, but...

Doesn't this assume that we *only* have mobile's on this
link? What if in addition to mobiles we have regular
devices, like web servers, etc. Presumably, they won't
be subject to their addresses being checked as per the
above rule? So we'll have a mixture of devices: some
for whom in effect we do IID (mobiles) and some that
don't have that mechanism (regular non-mobiles). I don't
think we can impose the rule below on non-mobiles.

So if collisions are a concern, sounds like we can't
avoid them.

-gabriel

-- 
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
180, Avenue de l'Europe          Email: [email-masked]
ZIRST de Montbonnot              Mobile: +33 673 99 56 62
38334 Saint Ismier CEDEX, France
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Jan 2003 10:24:37 -0800

> think we can impose the rule below on non-mobiles.

we cant do much about this. the only thing we can do in
addition to the above is run DAD on every address and 
detect if something is wrong. the HA currently runs DAD 
for every derived address, while making sure _it_ is not 
already defending the address. so we should be okay.

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Jan 2003 01:04:36 +0200

> So if collisions are a concern, sounds like we can't

It is true that collisions can still happen with other
hosts. Indeed Mallory could do an S=0 binding with aaaa::1111
to prevent the communications of a non-mobile node
at bbbb::1111 which happened to be off at the time.

But lets go back where this discussion started: an
imperfect authorization rule extends a registration
to an area that it shouldn't go to. With the config
check, we have this covered _within Mobile IPv6 home
agents_. Not across the whole network of nodes. But
the question is whether that's mobile IP's responsibility
or not. It seems to me that what we need to worry
about is ensuring that *our* nodes don't do what
hasn't been authorized for them. If a collision
happens after this, its a feature not a bug.

I agree that its funny that there are two different
kinds of nodes. But that is a direct consequence of
the S=0 bit; Mobile IPv6 is special because its the
only protocol that lets you cover a set of addresses
with the same IID in a single request. Good or Bad?
Hmm... I'm not particularly fond of it. But it
looks like the rule is enough to prevent the original
problem.

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 14 Jan 2003 00:33:46 +0100

> looks like the rule is enough to prevent the original

Sounds to me like it's closed on option b, then.

-gabriel

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 13 Jan 2003 16:33:31 -0800

Jari -

> they themselves remember which home address they used over

Good point. This will be easy to screw up, if the HA isn't robust enough to
recognize when different S=0 BUs specifying HoAs with the same IID actually
are for the same S=0 binding. I'm willing to pass that extra complexity on
to the user application (since in our implementation, the user must
explicitly choose to register with S=0, the default is S=1 registration),
although a friendlier HA won't require it IMHO.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com