Subject: [Mipshop] NS-NA Exchange in draft-vidya-mipshop-handover-keys-aaa-01

From: Christian Vogt <[email-masked]>
Date: Tue, 13 Dec 2005 10:26:14 +0100

Hi Vidya and co-authors,

I read draft-vidya-mipshop-handover-keys-aaa-01.txt (henceforth called
"the draft") and caught up with the meeting minutes from Vancouver.

There was a brief discussion in Vancouver on the way CoA uniqueness is
verified in the draft.  The suggestion is to have the acess router (AR)
send an NS and wait for responding NAs, where the mobile node claiming
the CoA does *not* send an NA.

This is sort of a DAD-like approach.  Greg proposed that you better use
OptiDAD instead.

I do not fully agree.  The draft uses the NS-NA exchange in order to
mitigate the threat of connection hijacking by malicious (or
inadvertent) redirection, whereas OptiDAD tackles inadvertent address
collisions only.

It's ok for OptiDAD to expose nodes to a short "phase of uncertainty"
during which two nodes may use the same address because (a) the
probability for such an event is vanishingly small anyway, and (b) other
nodes' communications won't be affected due to the way OptiDAD handles
use of Optimistic Addresses.

But in draft-vidya-mipshop-handover-keys-aaa-01.txt, we talk about (a)
malicious connection hijacking, which won't happen by an unlikely
coincidence, and (b) packet redirection, which OptiDAD's rules for
Optimistic Addresses cannot do much about.

Running the NS-NA exchange in an OptiDAD style would have to be
supplemented with a variant of Credit-Based Authorization, which in turn
would require existing credit to be transferred from AR to AR.

But note that the NS-NA exchange is concurrent anyway because it happens
prior to handoff.

Having said that, I guess that the suggested NS-NA exchange is fine from
the perspective of performance...

...however, I have concerns with respect to the security it provides:

Assume an attacker, spoofing a neighbor's CoA, jams the link when the AR
sends the NS and/or when the victim sends its NA.  The AR won't receive
an NA from the victim then, and it will falsely assume that the attacker
uses a correct CoA.

F-MIPv6 solves this issue thus:

[From RFC 4068, section 8]
>   If an access router can ensure that the source IP address in an
>   arriving packet could only have originated from the node whose
>   Link-Layer Address is in the router's neighbor cache, then a bogus
>   node cannot use a victim's IP address for malicious redirection of
>   traffic.  Such an operation is recommended at least on neighbor
>   discovery messages including the RtSolPr message.

This approach does not help if the attacker spoofs its L2 address,
unfortunately.  Seems that SEND is the only way to solve the issue.

Without SEND, you could still force the attacker to stay on the old link
if the old AR re-sends NSs until the tunnel is torn down, each
successive transmissions spaced by a random amount of time.  The
attacker would have to jam the old link every so often, thus exposing
itself as someone malicous.

Besides, the new AR would never see the attacker arrive.  You might be
able to communicate this information back to the old AR, which could
then tear down the tunnel.  But this doesn't help much if the attack's
purpose is DoS rather than connection hijacking...

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Vidya Narayanan <[email-masked]>
Date: Fri, 16 Dec 2005 23:31:49 +0530

Hi Christian,
Thanks for providing comments on this issue. Actually, optimistic DAD
will not work in this case as you said. Also, the threats of ND can't
really be solved without SEND.

We have been having an offline discussion on whether or not the CoA
validation is even in the scope of the draft. The thought is that this
is typically not a AAA issue - so, perhaps we can mention it in the
security considerations section and leave it at that. Short of CGAs, a
clean solution for this is not available.

We are waiting for Jari and Mohan to review and give us comments. If
you have any comments on the scope of this, please let us know.

Thanks,
Vidya

---

From: Christian Vogt <[email-masked]>
Date: Sat, 17 Dec 2005 23:44:30 +0100

Vidya -

Yes, I cannot think of a solution to the CoA uniqueness problem other
than SeND either.  Keeping AAA and ND security separate seems like a
good idea.

There are basically only two ways in which CoA uniqueness can be
ensured:  (1) A router verifies CoA uniqueness by just looking at the
address, or (2) the router explicitly asks around whether a given CoA is
already in use.  SeND enables the former.  The NS-NA exchange described
in draft-vidya-mipshop-handover-keys-aaa-01 accomplishes the latter.

But option (2) requires that there are no nodes which could interfer
with the NS-NA exchange.  This is, e.g., the case in DAD, where it is
assumed that all on-link neighbors behave well.  This is also the case
with reachability checks, where you assume that the attacker is not on
the path between its peer and the victim.

The pre-assumption does not hold in
draft-vidya-mipshop-handover-keys-aaa-01, however, because the whole
purpose of the protocol is to protect against an on-link attacker.

To make a long story short:  Yes, I think the CoA uniqueness problem is
better left to SeND.

- Christian

---

From: "James Kempf" <[email-masked]>
Date: Mon, 19 Dec 2005 10:54:00 -0800

Christian,

If the router does not somehow verify the ownership of a CoA in a request to 
establish a key for handover, then how can the router know that the key is 
not being sent by an attacker attempting to steal the legitimate owner's 
traffic?

                jak

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "Vidya Narayanan" <[email-masked]>
Cc: <[email-masked]>; "Mipshop" <[email-masked]>; 
<[email-masked]>; "Vidya Narayanan" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Saturday, December 17, 2005 2:44 PM
Subject: Re: [Mipshop] NS-NA Exchange 
indraft-vidya-mipshop-handover-keys-aaa-01

---

From: Christian Vogt <[email-masked]>
Date: Tue, 20 Dec 2005 09:03:24 +0100

James -

The problem that I see with the NS-NA echange is that a connection 
hijacker could circumvent the measure by jamming the link.

One mitigation that crossed my mind was to have the PAR retransmit the 
NS in intervals of random length until the handoff tunnel is torn down. 
  This would at least require a connection hijacker to stay on the old 
link---for the purpose of flooding the old link whenever the PAR sends 
an NS.

If the connection hijacker left the old link even though, in order to 
receive the victim's packets on another link, it would miss an NS.  The 
victim could then reply with an NA, and the PAR knew that it should 
probably tear down the handoff tunnel immediately.

The perpetrator could also be identified that way.

But yes, we still have the problem with DoS attackers redirecting other 
nodes' traffic into the void.  And we also have the problem with 
connection hijackers that can attach to both the old and the new link 
simultaneously.

Would you suggest to make SeND a requirement for the handoff-key protocol?

What's good about the handoff-key protocol, even in the absence of SeND, 
is that a connection hijacker must in any case operate from its victim's 
link, because it must retrieve the handoff key from the PAR.  This holds 
with or without the NS-NA exchange.

Regards,
- Christian

James Kempf wrote:
> Christian,
> 
> If the router does not somehow verify the ownership of a CoA in a 
> request to establish a key for handover, then how can the router know 
> that the key is not being sent by an attacker attempting to steal the 
> legitimate owner's traffic?
> 
>                jak
> 
> ----- Original Message ----- From: "Christian Vogt" <[email-masked]>
> <[email-masked]>; "Vidya Narayanan" 
> <[email-masked]>; <[email-masked]>; 
> <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Dec 2005 08:57:47 -0800

> hijacker could circumvent the measure by jamming the link.

I discussed this with the author group in private email.

> One mitigation that crossed my mind was to have the PAR retransmit the NS 
> in intervals of random length until the handoff tunnel is torn down. This 
> would at least require a connection hijacker to stay on the old link---for 
> the purpose of flooding the old link whenever the PAR sends an NS.
>

I don't think the validation of the CoA need take place around the handoff, 
and I don't think that is what draft-vidya is proposing. In fact, I don't 
see how this could be done, because ND signaling doesn't go off the local 
link. At the time packets are being tunneled to the terminal during 
handover, the terminal is on the new link. Or did you have something else in 
mind that I am missing? Section 5.1.2.1 in draft-vidya describes the NS-NA 
exchange as occuring after receiving the HKReq and prior to sending the 
HKResp.

> Would you suggest to make SeND a requirement for the handoff-key protocol?

Well, I am reluctant to recommend this, since the whole point of an 
AAA-based handover key derivation protocol is to provide something that 
works without SEND. Otherwise, why not simply use the SEND-based protocol, 
it is quite simple and if SEND is available, why not use it?

> with or without the NS-NA exchange.

The basic security issue is that there is no trust relationship between the 
terminal and the AR. The trust relationships are between the terminal and 
the AAA Home and between the AAA Home and the AR (via the AAA Local). So it 
seems to me that when the AR receives an HKReq message, it must verify the 
terminal's address authorization with AAA, if SEND is not to be used. I also 
feel that it is critical for address authorization to be checked prior to 
key exchange. Otherwise, the AR might end up giving a handover key to an 
attacker (even one that is duly authenticated but does not own the address) 
which wants to disrupt the terminal's traffic.

However, there is a problem with this in general. The typical way for AAA to 
occur is that network access authentication and authorization occurs prior 
to the terminal having a globally routable IP address. The terminal and the 
NAS communicate at the MAC layer, via something like 802.1x prior to the 
terminal obtaining an IP address. So there is really no opportunity for the 
terminal to communicate an authenticatable message to the AAA Home about its 
IP address, at least, not with existing standards.

The exception is, of course, PANA. Since PANA is conducted at the IP layer, 
the terminal could send a message to the PAA after network access 
authentication and address configuration that would somehow allow the PAA to 
determine the terminal's address authorization (perhaps there is an 
additional return routability check to avoid redirection attacks).

Also, it might be possible to propose an extension to 802.1x allowing such a 
message over EAP. 802.11r has some stuff in it for pre-authentication, this 
might be extended to allow an IP address on the new subnet to be included so 
that the AR can authorize the address prior to the terminal moving. The AR 
can, for example, check if someone else owns the address (via NS) and even 
proxy defend it until the terminal moves.

            jak

---

From: Vidya Narayanan <[email-masked]>
Date: Thu, 22 Dec 2005 10:28:15 +0530

Sorry, I'm on vacation and have not been regular in catching up with emails..

> exchange as occuring after receiving the HKReq and prior to sending the

James is right.

> it is quite simple and if SEND is available, why not use it?

The point raised by Rajeev was that AAA-based protocols don't normally
do address validation - we are talking about authenticated nodes that
are authorized for FMIP service stealing IP addresses. Depending on
the deployment, this may not be an issue. The suggestion was to
recommend the use of SEND (not make it a requirement) if a deployment
required such protection in addition to the AAA process. The AAA-based
approach still has its advantages in terms of coupling the service
authorization with the key derivation - this makes it applicable to
all handoff scenarios, irrespective of whether the link layer is using
802.11i, PANA, 802.11r, 802.11s or anything else. In the SEND-based
protocol, the assumption is that authentication and service
authorization happens during network access - this makes certain
assumptions about what the link layer authentication mechanism is -
this is okay for some deployments, but not all. That is why it seems
to still make sense to have a AAA-based approach.

> which wants to disrupt the terminal's traffic.

The node is authenticated and authorized specifically for FMIP service
in this case - while this is a valid case, I'm not sure that this is a
concern in most AAA-based deployment environments. If this is a major
concern, then, I would imagine regular NDP threats would be a major
concern too.

> proxy defend it until the terminal moves.

All such extensions will be specific to the link layer authentication
- it is really not possible to specify such extensions for every
possible case. Also, these approaches a still a little vague to me.
For e.g., if the AR uses NS as you say above, all the threats of NDP
still exist - which seems to be the problem with the approach in
5.1.2.1 of the draft - so, I'm confused as to how this will solve the
problem.

Vidya

---

From: Christian Vogt <[email-masked]>
Date: Thu, 22 Dec 2005 14:37:26 +0100

> I don't think the validation of the CoA need take place around the 
> handoff, and I don't think that is what draft-vidya is proposing. In 
> fact, I don't see how this could be done, because ND signaling
> doesn't go off the local link. At the time packets are being tunneled
> to the terminal during handover, the terminal is on the new link. Or
> did you have something else in mind that I am missing? [...]

Actually, yes.  What I was having in mind was that the PAR should at
least force a connection hijacker to remain on the same link where the
victim is---assuming that, in the typical connection-hijacking attack,
the attacker would attempt to move to the link to which it has redicted
its victim's packets.

So, if the PAR sends NSs periodically while the handoff tunnel is up,
the hijacker could not move to the link to which it has redirected the
victim's packets.  Instead, the hijacker would have to jam the old link
whenever the PAR sends an NS.  (Otherwise, the victim would hear the NS
and send an NA.)

This would at least be better than the current NS-NA exchange, which the
hijacker can be easily circumvent by flooding the link after the HKreq
is sent.

But I was not saying that periodically repeating the NS-NA exchange is a
bullet-proof mechanism.  In fact, I agree with you and Vidya that, in
the absence of SeND, there is little one can do to protect against
Neighbor Discovery spoofing.

- Christian

James Kempf wrote:
>> One mitigation that crossed my mind was to have the PAR retransmit
>> the NS in intervals of random length until the handoff tunnel is
>> torn down. This would at least require a connection hijacker to
>> stay on the old link---for the purpose of flooding the old link
>> whenever the PAR sends an NS.
>> 
> 
> I don't think the validation of the CoA need take place around the 
> handoff, and I don't think that is what draft-vidya is proposing. In
>  fact, I don't see how this could be done, because ND signaling
> doesn't go off the local link. At the time packets are being tunneled
> to the terminal during handover, the terminal is on the new link. Or
> did you have something else in mind that I am missing? Section
> 5.1.2.1 in draft-vidya describes the NS-NA exchange as occuring after
> receiving the HKReq and prior to sending the HKResp.
> 
>> If the connection hijacker left the old link even though, in order
>> to receive the victim's packets on another link, it would miss an
>> NS. The victim could then reply with an NA, and the PAR knew that
>> it should probably tear down the handoff tunnel immediately.
>> 
>> But yes, we still have the problem with DoS attackers redirecting 
>> other nodes' traffic into the void.  And we also have the problem
>> with connection hijackers that can attach to both the old and the
>> new link simultaneously.
>> 
> AAA-based handover key derivation protocol is to provide something
> that works without SEND. Otherwise, why not simply use the SEND-based
>  protocol, it is quite simple and if SEND is available, why not use
> it?
> 
>> What's good about the handoff-key protocol, even in the absence of
>>  SeND, is that a connection hijacker must in any case operate from
>> its victim's link, because it must retrieve the handoff key from
>> the PAR. This holds with or without the NS-NA exchange.
>> 
> 
> The basic security issue is that there is no trust relationship
> between the terminal and the AR. The trust relationships are between
> the terminal and the AAA Home and between the AAA Home and the AR
> (via the AAA Local). So it seems to me that when the AR receives an
> HKReq message, it must verify the terminal's address authorization
> with AAA, if SEND is not to be used. I also feel that it is critical
> for address authorization to be checked prior to key exchange.
> Otherwise, the AR might end up giving a handover key to an attacker
> (even one that is duly authenticated but does not own the address)
> However, there is a problem with this in general. The typical way for
>  AAA to occur is that network access authentication and authorization
>  occurs prior to the terminal having a globally routable IP address.
> The terminal and the NAS communicate at the MAC layer, via something
> like 802.1x prior to the terminal obtaining an IP address. So there
> is really no opportunity for the terminal to communicate an
> authenticatable message to the AAA Home about its IP address, at
> least, not with existing standards.
> 
> The exception is, of course, PANA. Since PANA is conducted at the IP
>  layer, the terminal could send a message to the PAA after network
> access authentication and address configuration that would somehow
> allow the PAA to determine the terminal's address authorization
> (perhaps there is an additional return routability check to avoid
> redirection attacks).
> 
> Also, it might be possible to propose an extension to 802.1x allowing
>  such a message over EAP. 802.11r has some stuff in it for 
> pre-authentication, this might be extended to allow an IP address on
> the new subnet to be included so that the AR can authorize the
> address prior to the terminal moving. The AR can, for example, check
> if someone else owns the address (via NS) and even proxy defend it
> until the terminal moves.
> 
> jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 22 Dec 2005 09:27:05 -0800

Chrisitan,

I'm still not sure I understand. I don't see any reason why a connection 
hijacker would always want to move to the new link. If the attacker's intent 
is to harass, it might simply redirect the traffic to a NAR where neither 
the victim nor the attacker are, causing a disruption. So the attacker could 
pop up on the victim's link, send the HReq, get a handover key, send an FBU 
for a new address on some other link, then disappear. The victim's traffic 
ends up in /dev/null on the other link.

            jak

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Vidya Narayanan" <[email-masked]>; 
<[email-masked]>; "Mipshop" <[email-masked]>; 
<[email-masked]>; "Vidya Narayanan" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Thursday, December 22, 2005 5:37 AM
Subject: Re: [Mipshop] NS-NA Exchange 
indraft-vidya-mipshop-handover-keys-aaa-01

---

From: "James Kempf" <[email-masked]>
Date: Thu, 22 Dec 2005 09:58:36 -0800

The point raised by Rajeev was that AAA-based protocols don't normally
do address validation - we are talking about authenticated nodes that
are authorized for FMIP service stealing IP addresses. Depending on
the deployment, this may not be an issue.

jak>> I think this is missing the point.  My cannonical example of why a 
fully auth/authzed node would want to steal an address is a couple that is 
undergoing a contentious divorce and one party decides to harass the other 
by staging traffic redirection attacks on wireless service. It is possible 
for a fully authenticated and authorized node to attempt to steal an 
address. If we can't achieve concensus on this point in MIPSHOP, we should 
take it to the Security Directorate and ask them if they think it is 
important.

jak>> Rajeev, maybe you could comment? What exactly did you have in mind?

The suggestion was to
recommend the use of SEND (not make it a requirement) if a deployment
required such protection in addition to the AAA process.

jak>> Again, AAA provides no protection against address stealing. It 
provides protection against theft of service from an unauthorized terminal, 
but not against an authorized terminal stealing the address of another 
authorized terminal.

The AAA-based

jak>> I see a different motivation for the AAA-based approach. I see it as a 
way of providing some selective service authorization. With an AAA-based 
approach, the Mobility Service Authorizer has the option of authorizing 
handover optimization service or not when the terminal requests a handover 
key. SEND makes no assumptions about when or if auth/authz is occuring, in 
fact, it need not occur at all. So the SEND key approach has no provision 
for selective authorization of handover optimization service. Whether such a 
level of fine grained service authorization actually becomes popular and is 
widely deployed is another story.

jak>> I'm not sure I follow your reasoning. Why is it unnecessary to check 
that a message requesting a handover key for a particular CoA comes from a 
node which is authorized to claim that address? What is to prevent another 
node, which is completely authorized for FMIP service, from requesting a key 
on a victim's address and then disrupting the victim's traffic by using that 
key?

> layer,

jak>> Of course it's AAA-technology specific. AAA is technology specific. 
There is no single, general way to do AAA that is used by every link layer. 
PANA is an option for a link-layer independent way, but it is just an 
option.

jak>> But I think I understand your point about NS. The NAR must proxy the 
new CoA if the terminal attempts to claim the new CoA when the terminal is 
not on the link. If the NAR must proxy the address, then it will use NS/NA 
and therefore address authorization security is required (though at present 
there is no proxy SEND).  And PANA can't do a return routability test if the 
terminal claims the address from the old link. Perhaps it is not possible to 
avoid using SEND in some way.

            jak