Subject: Re: [Mipshop] NS-NA Exchange indraft-vidya-mipshop-handover-keys-aaa-01

From: Christian Vogt <[email-masked]>
Date: Wed, 04 Jan 2006 10:39:53 +0100

James,

a Happy New Year to you and all Mipshop folks!

It is true that the hijacker could stay on the victim's link if the 
hijacker's intent is to simply harass the victim.  A periodic NS-NA 
exchange cannot solve this problem.

But from that position (i.e., from the victim's link), the hijacker 
could just as well harass the victim by flooding the link.  At least, 
this would be possible on some link technologies, such as 802.11.

So, the modified, periodic NS-NA exchange that I was proposing at least 
does not allow the attacker to leave the link.  This narrows down the 
attack space to attacks where the hijacker is on the same link as the 
victim.  And in such a setting, the hijacker is likely able to harm the 
victim anyway.

(The periodic NS-NA exchange is in some sense similar to the MIPv6 
return-routability procedure:  It limits attacks to scenarios where the 
attacker is a certain position---in a position from which the attacker 
could do harm anyway.)

- Christian

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

James Kempf wrote:
> 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

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Jan 2006 09:40:26 -0800

Hi Christian,

Actually, my point was not that the attacker could stay on the link, but 
that it could pop up on the old link, establish a shared key for the 
victim's address, send an FBU, then disappear to a completely different link 
which may or may not be the same link to which it redirected the traffic. If 
nobody responds to the NS on the new link, then the NAR could cut the tunnel 
off immediately. This would require some signaling back to the PAR. If that 
signaling is not there, the NAR drops the traffic but doesn't terminate the 
tunnel immediately, meaning that the victim loses more than just a couple of 
packets.

But what is the PAR to then do with the traffic? The MN might still be on 
the link, in which case, the PAR will find it with a new NS and can return 
to delivering the traffic, but there will still be a disruption. If the MN 
has moved, however, the traffic will be dropped.

            jak

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; "Mipshop" <[email-masked]>; 
<[email-masked]>; "Vidya Narayanan" <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 04, 2006 1:39 AM
Subject: Re: [Mipshop] NS-NAExchange 
indraft-vidya-mipshop-handover-keys-aaa-01

> But from that position (i.e., from the victim's link), the hijacker could 
> just as well harass the victim by flooding the link.  At least, this would 
> be possible on some link technologies, such as 802.11.
>
>> 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
>
>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 20 Jan 2006 16:25:09 +0100

Hi James,

I think that trying to find a non-SeND solution to the address-ownership
problem is pretty much hopeless in this scenario:  Neither do we have a
cryptographic binding between the AAA key and the IP address, nor can
the MN verify ownership of its address through a property (such as the
routing property that the return-routability procedure checks).

The problem may be solvable with stateful address configuration where
addresses are bound to the AAA context and assigned during the initial
AAA authentication procedure.  Access routers could then verify an
arriving MN's CoA before they assign a handoff key.  This approach would
render address management more complicated, though.

- Christian

James Kempf wrote:
> victim's address, send an FBU, then disappear to a completely different
> link which may or may not be the same link to which it redirected the
> traffic. If nobody responds to the NS on the new link, then the NAR
> could cut the tunnel off immediately. This would require some signaling
> back to the PAR. If that signaling is not there, the NAR drops the
> traffic but doesn't terminate the tunnel immediately, meaning that the
> victim loses more than just a couple of packets.
> 
> But what is the PAR to then do with the traffic? The MN might still be
> on the link, in which case, the PAR will find it with a new NS and can
> return to delivering the traffic, but there will still be a disruption.
> If the MN has moved, however, the traffic will be dropped.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jan 2006 08:45:59 -0800

> render address management more complicated, though.

I think the address assignment could also be done through DHCP, if there is 
some co-ordination between the DHCP server and the NAS, for example, that 
the NAS acts as a DHCP relay. But I don't see any other way to ensure that 
the handover key is only given to a node that is allowed to route the 
address.

            jak

---

From: Christian Vogt <[email-masked]>
Date: Sat, 21 Jan 2006 10:34:00 +0100

> I think the address assignment could also be done through DHCP, if
> there is some co-ordination between the DHCP server and the NAS, for
> example, that the NAS acts as a DHCP relay. 

Correct.

 >                                              But I don't see any other
> way to ensure that the handover key is only given to a node that is
> allowed to route the address.

Yes, seems we agree in this point.

- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

James Kempf wrote:
>> The problem may be solvable with stateful address configuration
>> where addresses are bound to the AAA context and assigned during
>> the initial AAA authentication procedure.  Access routers could
>> then verify an arriving MN's CoA before they assign a handoff key.
>> This approach would render address management more complicated,
>> though.
>> 
> 
> I think the address assignment could also be done through DHCP, if
> there is some co-ordination between the DHCP server and the NAS, for
> example, that the NAS acts as a DHCP relay. But I don't see any other
> way to ensure that the handover key is only given to a node that is
> allowed to route the address.
> 
> jak
> 
> 
> Christian Vogt wrote:
>> Hi James,
>>