Subject: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery

From: [email-masked]
Date: Tue, 16 Nov 2004 12:52:21 +1100 (EST)

Hello, ALL.

Here is a new I-D, Security Issues in Dynamic Home Agent Address Discovery.

Abstract:
   This document describes potential security issues relevant to the
   Dynamic Home Agent Address Discovery (DHAAD) procedure in Mobile
   IPv6. In particular, we illustrate a Denial of Service (DoS) attack
   scenario and propose three possible solutions to improve the security
   of DHAAD in MIPv6.

URL to I-D:
http://www.ietf.org/internet-drafts/draft-sun-mipv6-dhaadsecurity-00.txt

Comments are welcome.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Nov 2004 15:08:33 +0100

> Here is a new I-D, Security Issues in Dynamic Home Agent Address 

Thanks for this draft.  It describes in detail a DoS attack on the MN,
where the attacker denies the MN access to a HA, via fake DHAAD Replies;
it mentions shortly the risk of disclosure of HA addresses to any remote
party.  It also proposes security solutions to this problem but I
haven't read those parts.

In addition to the HA-DoS threat, I think (let me know if I'm wrong)
there are two others: (1) faking the HA List by attacker MN on home link
and (2) attacks on the R-bit of a NEMO DHAAD Reply.

For (1), DHAAD relies on building of a HA list by HAs on the home link,
via the H-bit in their RAs.  An attacker MN (one that is at home on the
home link where the legitimate HAs are) can send fake HAs to pretend to
be a HA, I think.  Based on this fake RA, the legitimate HAs will build
attacking HA lists, that contain the attacker MN as the highest priority
HA (or pretending to support MRs while it doesn't).  The end result of
this attack is that MN uses the attacker HA as a HA.

It is true that this attack is not exploiting the weaknesses of
unprotected DHAAD Req/Rep, but building the HA list is an integral part
of DHAAD operation, I think.

For (2), NEMO Basic Support uses an R-bit in the DHAAD Req and Rep.  The
R-bit in the Req means MR is looking for an HA supporting MRs and an
R-bit in the Rep means this HA does support MRs.  An HA supporting MRs
does support MHs too, so the only possible attack is a DoS on the
"support MRs" part.  In plain words, the risk is that MR requests an HA
supporting MRs, gets fake reply back that has the R-bit 0, and thus all
LFNs behind MR are denied HA service (but MR is not denied HA service).

A similar threat analysis can be exercised on all fields in the DHAAD
Req/Rep and on the HA Information Option within an RA (preference,
lifetime).  Whether this analysis is necessary or not - I don't know -
but it usually gives exhaustive hints on what the solution would look like.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Nov 2004 08:43:45 -0800

The following seems problematic to me (Section 4.2):

   However, use of IPSec with IKE may introduce significant overhead on
   network transmission and host computation. To protect one message
   (i.e. DHAAD Reply), the home agent has to setup an IPSec Security
   Association (SA) with the mobile node. When using IPSec with Internet
   Key Exchange (IKE), IKE session involves at least six messages (three
   round trips) exchange to setup a SA between two nodes. It may also
   need a large number of computations. For small handheld devices, the
   use of IPSec may be too taxing on battery and processor performance
   [3]. Such overhead becomes particularly significant if this SA is
   used only once to protect DHAAD Reply message from the responding
   home agent and may not be used later for Binding Updates.

   A more serious problem of this mechanism is that it could introduce
   another kind of DoS attack. Home agent becomes vulnerable to DoS
   attacks, if it initiates IKE to protect DHAAD Reply with IPSec. An
   attacker could easily launch a DoS attack against all home agents on
   the home link by sending a large number of DHAAD Requests using
   different source addresses. Home agent(s) would create a new IKE
   session for each DHAAD Request, eventually running out of resources
   to serve valid mobile nodes. Note that there is no efficient
   mechanism to trace the attacker back to its real origin due to the
   DHAAD Requests are not authenticated.

because:

1) I believe IKEv2 requires four messages, unless EAP is used, in which case
it does require 6.
2) Both versions of IKE contain protection against DoS by requiring
responder cookies and that the cookies be properly formulated. Naturally,
this won't protect a flat out, no holds barred packet bombardment, but it
does prevent a more subtle, state depletion attack.

As a general point, with the exception of the MiTM DHAAD interception, how
is a DoS attack on a known home agent address any different from an attack
on any other server on the Internet, like, for example, cnn.com?

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Nov 2004 19:18:00 +0100

James Kempf wrote:
> As a general point, with the exception of the MiTM DHAAD 
> interception, how is a DoS attack on a known home agent address any 
> different from an attack on any other server on the Internet, like, 
> for example, cnn.com?

Attacks are different in that attacking cnn.com is attacking a unique
endpoint of many e2e edges, while attacking a Home Agent address is
attacking the crux of many e2e edges.

Enlarging the number of victims when attacking cnn.com can be achieved
by getting closer to cnn.com, enlarging the number of victims when
attacking MN can not by achieved by getting closer to HA (attacker does
not need to, it already denies all victim CNs).

Another comparison could be made with DHCP Discover (in my knowledge
also insecure).  Attacker DHCP Discovery may be avoided by simply moving
to the other nearby DHCP "domain" once the attack is detected, while
attacker DHAAD can not be avoided by moving to the next AR.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Nov 2004 21:48:24 +0200

>    attacks, if it initiates IKE to protect DHAAD Reply with IPSec. An

I agree with James' observations about this paragraph. While
I'm not a big fan of doing IKE everytime you send a packet
somewhere, it seems that any cryptographic mechanism that
protects DHAAD is bound to have some of the same DoS issues,
and probably also some of the same solutions, such as cookie
exchanges or rate limiting the processing of requests if you
get too many of them.

A meta-level issue with improvements to the DHAAD procedure
is that there seems to be an interest in different kinds of
provisioning schemes (including HA addresses) in the community,
and I wonder how much effort we should put into improving
DHAAD until we know what kind of provisioning is really
going to be "the winner".

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Nov 2004 22:04:10 +0100

Excuse my interfering...

Jari Arkko wrote:
> somewhere, it seems that any cryptographic mechanism that protects 
> DHAAD is bound to have some of the same DoS issues,

YEs, I agree, _some_.

A secure DHAAD _will_ protect against the threat where MR is forced into
being an MH (and thus denying service to LFNs behind it).  If DHAAD were
secure (even if not fully avoiding the HA DoS), this kind of MR DoS
wouldn't happen.

Also, if HAs on the same link send protected RAs then a certain
number of attacks on DHAAD are eliminated (note: I don't know SEND).

I think motivation for secure DHAAD should come from correctly
formulating the threats of non-secure DHAAD and knowing what to expect
from secure DHAAD.

> exchanges or rate limiting the processing of requests if you get too
>  many of them.

It is true that if a threat is formulated such as to say that because
DHAAD is insecure then there is a HA DoS risk possible, then by this
formulation it should mean that a secure DHAAD would eliminate entirely
all the HA DoS risks.  And this is barely feasible, as you mention.

> A meta-level issue with improvements to the DHAAD procedure is that 
> there seems to be an interest in different kinds of provisioning 
> schemes (including HA addresses) in the community, and I wonder how 
> much effort we should put into improving DHAAD until we know what 
> kind of provisioning is really going to be "the winner".

I am not aware of this proposal.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Nov 2004 14:21:26 -0800

> I am not aware of this proposal.

Check:

 draft-giaretta-mip6-authorization-eap-02.txt
draft-giaretta-mip6-aaa-ha-goals-00.txt
draft-yegin-mip6-aaa-fwk-00.txt
draft-jee-mip6-bootstrap-pana-00.txt
draft-tschofenig-mip6-bootstrapping-pana-00.txt
draft-ohba-mip6-boot-arch-dhcp-00
draft-deng-mip6-bootstrap-bcf-00.txt

as well as:

draft-ietf-mip6-bootstrap-ps-01.txt

which explains the problem.

In short, there are quite a few proposals for replacing DHAAD as part of the
bootstrapping work.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Nov 2004 23:45:41 +0100

> In short, there are quite a few proposals for replacing DHAAD as part of the

Sorry to sound ignorant...

The bootstrapping seemed to be an easy task, at least from an 
implementation perspective: discover your HA - DHAAD, get your prefix - 
MPD, configure a HoA, send a BU; that could have been all there was to 
it.  The keys?  Preconfigured.

Ok, I'll have to get up to speed with the proposals, thanks.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Nov 2004 08:18:35 +0200

> The bootstrapping seemed to be an easy task, at least from an 

:-)

> it.  The keys?  Preconfigured.

I think the "keys" part is the hard issue, people want to get away
from having to have those preconfigured. But as a result it may
also imply a different approach to discover the HA addresses, too.
Or maybe not, but we don't know yet.

--Jari

---

From: Henrik Petander <[email-masked]>
Date: Thu, 18 Nov 2004 18:46:06 +1100

Hi Jak,

Thanks for your comments on the draft. My replies are inline.

> 1) I believe IKEv2 requires four messages, unless EAP is used, in which case

Yes, you are correct about IKEv2. Still its use has a certain overhead, 
which may be considered large, if the IPSec SA is only used for 
protecting the DHAAD protocol at one CoA. Although this overhead may not 
happen very often, we thought that it was still relevant enough to be 
mentioned. IMO the second paragraph is a sufficient reason to not use 
IKE initiated by HA for creating IPSec SAs for protcting DHAAD reply.

> does prevent a more subtle, state depletion attack.

The cookies protect the responder in IKE, who does not create state 
without the correct cookies. I am not an expert on the inner workings of 
IKE, but the initiator surely creates state to handle resending, in case 
it does not get a reply from the responder, or am I mistaken?

> on any other server on the Internet, like, for example, cnn.com?

Normally AFAIK, if IPSec with IKE is used to protect a protocol, IKE is 
initiated by the initiator of the protocol to be protected. If IPSec was 
used to protect only the unicast DHAAD reply, HA would be the initiator 
of IKE and would create a new IKE session for each incoming DHAAD 
request. Then a malicious attacker could send masses of DHAAD requests 
with different source addresses, thus triggering new IKE sessions in HA 
until some limit would be reached after which HA could not serve valid 
MNs (at least with IKE). Does this clarify our point of the DoS attack 
against HA?

Thanks,

Henrik

---

From: Henrik Petander <[email-masked]>
Date: Thu, 18 Nov 2004 19:04:25 +1100

Hi Alex,

Thanks for reading the security analysis of DHAAD part of the draft and 
commenting it.

> this attack is that MN uses the attacker HA as a HA.

Yes, if home link is also an access network, then this is a very 
relevant vulnerability, since an attacker only needs to be able to send 
packets on the home link. We focused on the MN-HA part of the protocol, 
but this could be added to the draft, since building of HA list can also 
be seen to be a part of the DHAAD protocol. Alex, would you be 
interested in adding a subsection to the protocol vulnerabilities part 
about this?

If SEND is used on the home link then this vulnerability can be fixed, 
provided that the HAs only add HAs to their list RAs which are 
authenticated as coming from authorized routers.

I am not sure about the relevance of the R-bit attack, but it could 
possibly be used to attack MR more subtly han sending just an empty list 
or a list with fake addresses, which depending on the implementation 
might be more effective.

Thanks,

Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 15:50:03 +0100

Henrik Petander wrote:
>> For (1), DHAAD relies on building of a HA list by HAs on the home
>> link, via the H-bit in their RAs.  An attacker MN (one that is at
>> home on the home link where the legitimate HAs are) can send fake
>> HAs to pretend to be a HA, I think.  Based on this fake RA, the
>> legitimate HAs will build attacking HA lists, that contain the
>> attacker MN as the highest priority HA (or pretending to support
>> MRs while it doesn't).  The end result of this attack is that MN
>> uses the attacker HA as a HA.
> 
> 
> relevant vulnerability, since an attacker only needs to be able to
> send packets on the home link. We focused on the MN-HA part of the
> protocol, but this could be added to the draft, since building of HA
> list can also be seen to be a part of the DHAAD protocol. Alex, would
> you be interested in adding a subsection to the protocol
> vulnerabilities part about this?

Sure, you need a paragraph, a two-three paragraphs?  How would you title it?

> If SEND is used on the home link then this vulnerability can be
> fixed, provided that the HAs only add HAs to their list RAs which are

I went back to read SEND.  It somehow relies on routers (those who send
RAs) be leading to "Trust Anchors" i.e. use Certificates; this implies
to me that if we want to prevent MN from sending fake RAs on the home
link then MN should use certs, or at least HAs use certs before building
the HA lists.

Also, I think that using SEND to protect DHAAD's RAs also involves using
CGAs as options, but it is not clear to me whether RAs are an exception
to this.

Finally, outside SEND, the MN and the HA do share a key, and it would be
risky for HA to rely on that key when receiving RAs from MN at home.

> possibly be used to attack MR more subtly han sending just an empty
> list or a list with fake addresses, which depending on the
> implementation might be more effective.

The attack on R-bit looks to me like an exemplification of more than
just denying HA service to a MH.  An attacker could just zero the bit
once and thus deny all service to LFNs but not to MR itself, there is no
need to fake other addresses in the DHAAD Reply or to block all packets
from HA to MR.  And yes, depends on the implementation a lot.

Alex

---

From: [email-masked]
Date: Fri, 19 Nov 2004 02:58:52 +1100 (EST)

>> and (2) attacks on the R-bit of a NEMO DHAAD Reply.
Yes, R-bit attack is another DoS attack scenario. Since this draft only
focus on security issues in MIPv6, we don't mention R-bit attack scenarion
in this draft. Actually, I think, in order to prevent R-bit attack, we
should protect both DHAAD Request and DHAAD Reply. Solution 2 in the draft
can be easily extended to protect R-bit attack.

In my understanding, R-bit attack can be performed in two means: (let me
know if I am not correct.thanks)
(1) Attacker spoofing DHAAD Reply
When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1),
it replies a DHAAD Reply with R-bit set 0. The mobile router would
register with home agent as a mobile node, so that it cannot serve all
mobile nodes attach to it.

(2) Attacker spoofing DHAAD Request
When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1),
it replicate the message, change R-bit to 0 and send it to home agent.
Then home agent would reply mobile node with two DHAAD Reply(one R-bit set
0, and the other R-bit set 1). If the Reply with R-bit 1 arrives the
mobile node first, then everything is ok. But if the DHAAD Reply with
R-bit 0 arrives first, then the mobile router has two choice: (a) Discard
it. The problem is: when the only home agent that supports mobile router
crashes, the mobile router cannot register with other home agent as a
mobile node, or it takes long time to do this(the mobile router retry
DHAAD unitl it achieves maximum attempts, then register as a mobile node.)
(b)Register as a mobile node. It cannot serve the mobile nodes attach to
it.

Based on above analysis, I think we should protect both DHAAD Request and
Reply to prevent R-bit attack. Thanks for your comments.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Nov 2004 09:09:01 -0800

Henrik,

> it does not get a reply from the responder, or am I mistaken?

It is not clear to me why the HA needs necessarily to be the initiator. The
HA can discard the DHAAD Request unless the MN initiates the IKE SA.

Anyway, I think we are mostly arguing about how many angels can dance on the
head of a pin, since DHAAD does not seem to be a likely candidate for
deployment at this point. The current bootstrapping work in mip6  is
intended to replace DHAAD and HoAD with something that the WG deems is more
deployable.

> MNs (at least with IKE). Does this clarify our point of the DoS attack

I think your point is an argument against this particular design, I don't
think it addresses my general point.

Alex's point, which ran towards "the difference is that the HA is more like
a router rather than a server" was more what I was looking for. I don't see
this point as necessarily being decisively differentating, however, since it
addresses the quality of the impact for the attack rather than the
mechanisms attackers use and therefore the possible effective
countermeasures, which is what I was looking for. Based on impact, one could
argue that an attack on a medical server used by people daily with some
chronic disease that denied them access necessary for their health would
have even more impact, though the mechanism might be the same as used on
cnn.com or an HA.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Nov 2004 09:33:17 -0800

Alex,

> link then MN should use certs, or at least HAs use certs before building

The MN doesn't need a cert, only the routers on the home link, including the
HA if it sends RAs, do. The MN uses the CPS/CPA to obtain the cert chain
from the router, and the public key from the router's cert to validate the
signature on the RA.

> CGAs as options, but it is not clear to me whether RAs are an exception

I don't know that SEND could be used to protect DHAAD since the CPS/CPA is
sent over ICMP and therefore subject to problems with fragmentation if send
over more than one link, since certs can be large. CGAs don't help here
because the security issue is not authorization to do something with an
address (which is what CGAs provide) but rather whether the router is
authenticatable as certified by a trusted root (and, additionally if
deployed, whether the router is authorized to route the subnet prefixes it
is advertising).

SEND might be used to protect RAs sent from the HA over the MN-HA tunnel
when the HA has the MN's CoA binding, but, again, provided the MN already
had the cert paths for the routers on the home link, due to the issue with
CPS/CPA fragmentation.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 21:42:13 +0100

James Kempf wrote:
[angels on a pin's top...]
> Anyway, I think we are mostly arguing about how many angels can dance
>  on the head of a pin, since DHAAD does not seem to be a likely 
> candidate for deployment at this point.

Do you know why is DHAAD not a candidate for deployment at this point?
Is it because it is insecure?  Should we secure it such as to be a
candidate for deployment?  Is it impossible to secure because of the 
difficulties IPsec/anycast?  Maybe it is not needed to use IPsec/anycast 
in order to have it a little more secure, a little more deployable.  Or 
has DHAAD been simply overlooked by people in need of urgent deployment?

> The current bootstrapping work in mip6  is intended to replace DHAAD
> and HoAD with something that the WG deems is more deployable.

I don't think there is anything simpler and thus more deployable than: 
discover HA - get MPD - configure HoA.  The keys?  Pre-shared.  I still 
have to figure out why people don't like them pre-shared here.

I bet that other methods to do HA Discovery and HoA configuration will 
render not only DHAAD useless but also MPD.  And, being new methods, 
they'll surely have their own new security risks.

That said, it still makes sense to me to recognize in a written document
that a certain procedure (DHAAD) in a Standards Track RFC is insecure.
Somehow for completeness.  Somehow as advice "don't do so".  Whether it
is worth the effort to secure it or not - is another question.  A
question which could be raised to the WG.

> Alex's point, which ran towards "the difference is that the HA is 
> more like a router rather than a server" was more what I was looking 
> for. I don't see this point as necessarily being decisively 
> differentating, however, since it addresses the quality of the impact
>  for the attack rather than the mechanisms attackers use and
> therefore the possible effective countermeasures, which is what I was
> looking for. Based on impact, one could argue that an attack on a
> medical server used by people daily with some chronic disease that
> denied them access necessary for their health would have even more
> impact, though the mechanism might be the same as used on cnn.com or
> an HA.

This sounds logic, all layer-3 mechanisms used for attack being equal 
the impact on layer-7 is also equal (be it health data or video
entertainment).  I could only argue that impact is also a sort of
assessment of the size of the risk, and impact of a risky local DHCP is
obviously lower than impact of a risky Internet-wide Mobile IPv6.  I am
not arguing the impact of a risky HL7, a protocol for the kind of health
data you mention (IIRC).

Note I still have to read the drafts you mentioned.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Nov 2004 13:23:22 -0800

Alex,

Many ISPs block ICMP except on the local link, since it can be used for ping
attacks and also tends to cause increased traffic from backscatter during
worm scanning. Also, as the draft points out, there are security problems
with DHAAD, in addition to the issues with anycast that you point out below.
The basic architectural thinking that went into DHAAD seems to have been
that home agent discovery on the Internet is analgous to router discovery on
the local link. I believe this thinking is not accurate, as services are
discovered in the Internet in ways that are much different than locally in
enterprise networks.

Personally, I think the WG will come up with a couple (but probably not just
one) techniques that are a better fit with the way wireless ISPs currently
operate, and therefore are more deployable. We've got a some good drafts in
this area, and the technical discussion seems to be progressing along well.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Henrik Petander" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, November 18, 2004 12:42 PM
Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent
AddressDiscovery

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 22:50:23 +0100

James Kempf wrote:
> Many ISPs block ICMP

James, as far as I can remember, one cellular ISP doesn't block ICMPv4
although NAT is in place and there is at least one other cellular ISP
that does not do NAT.  I will not dare however to make definitive
statements about ISPs, cellular or otherwise.

> below. The basic architectural thinking that went into DHAAD seems to
>  have been that home agent discovery on the Internet is analgous to 
> router discovery on the local link. I believe this thinking is not 
> accurate, as services are discovered in the Internet in ways that are
>  much different than locally in enterprise networks.

If this thinking is not accurate, then MPD qualifies to same thinking:
MPD is devised after router discovery on the local link too.

> Personally, I think the WG will come up with a couple (but probably 
> not just one)

It's good when there is choice.

> techniques that are a better fit with the way wireless ISPs currently
>  operate, and therefore are more deployable. We've got a some good 
> drafts in this area, and the technical discussion seems to be 
> progressing along well.

Again, I'll have to look at these.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 23:02:05 +0100

Does this somehow mean that probably the DHAAD part of the NEMO BAsic 
Support suddenly becomes superfluous?  This should be known...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 23:06:01 +0100

qsun the 300th.  Thanks for your reply.  Could you please reveal your
name so I can address you, thanks.

Chairs, if I'm dancing on a pinus :-) please let me know if this effort
is out of focus here, thanks.

[email-masked] wrote:
> Yes, R-bit attack is another DoS attack scenario. Since this draft 
> only focus on security issues in MIPv6, we don't mention R-bit attack
>  scenarion in this draft. Actually, I think, in order to prevent 
> R-bit attack, we should protect both DHAAD Request and DHAAD Reply.

Yes, that's what I thought too, it's not enough to protect only the Reply.

> In my understanding, R-bit attack can be performed in two means: (let
>  me know if I am not correct.thanks) (1) Attacker spoofing DHAAD 
> Reply When attacker sniffs a mobile router sending a DHAAD 
> Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The 
> mobile router would register with home agent as a mobile node, so 
> that it cannot serve all mobile nodes attach to it.

YEs, but it may be not necessary for attacker to create a Reply faking
the HA Reply, it is sufficient to forward a fake Request to HA and drop
the valid Request.

> (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile 
> router sending a DHAAD Request(R-bit set 1), it replicate the 
> message, change R-bit to 0 and send it to home agent. Then home agent
>  would reply mobile node with two DHAAD Reply(one R-bit set 0, and 
> the other R-bit set 1).

Actually, I was seeing a more powerful attacker that would create a
brand new fake request (R-bit 0) and discard the valid Request (R-bit
1), so only the fake Request hits the HA, so only the fake Reply hits
the MR.

> If the Reply with R-bit 1 arrives the mobile node first, then 
> everything is ok. But if the DHAAD Reply with R-bit 0 arrives first,
>  then the mobile router has two choice: (a) Discard it.

Yep, that's what the MR could do to realize there's error possible attack.

> The problem is: when the only home agent that supports mobile router 

That is a possibliity, I didn't think that far.

> (b)Register as a mobile node. It cannot serve the mobile nodes attach
>  to it.
> 
> Based on above analysis, I think we should protect both DHAAD Request
>  and Reply to prevent R-bit attack.

Yes, I guess both should be protected somehow to protect against these
attacks.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Nov 2004 23:46:37 +0100

James Kempf wrote:
> The MN doesn't need a cert, only the routers on the home link, 
> including the HA if it sends RAs, do. The MN uses the CPS/CPA to 
> obtain the cert chain from the router, and the public key from the 
> router's cert to validate the signature on the RA.

The attack was something like where the MN at home sends the fake RA to
HAs, so the receiving HAs on the home link needed to make sure the
content of that RA is valid such as _not_ to build fake HA lists.  So if
SEND were to help with this, would MN need a cert?

So this is like true simple SEND on a simple unique link, not across
tunnels.

>> Also, I think that using SEND to protect DHAAD's RAs also involves
>>  using CGAs as options, but it is not clear to me whether RAs are
>> an exception to this.
>> 
> 
> 
> I don't know that SEND could be used to protect DHAAD since the 
> CPS/CPA is sent over ICMP and therefore subject to problems with 
> fragmentation if send over more than one link, since certs can be 
> large.

Fragmentation is done by end nodes so more than one intermediary links
is not an issue.  The first link may be an issue, because the links
following usually have larger MTUs (unless successive HAs get in the
way, a la nested NEMO).  But there's also reassembly, hopefully.

> CGAs don't help here because the security issue is not authorization
>  to do something with an address (which is what CGAs provide) but 
> rather whether the router is authenticatable as certified by a 
> trusted root (and, additionally if deployed, whether the router is 
> authorized to route the subnet prefixes it is advertising).

Ok, I understand that.

What I was wondering was whether a MH on the home link can be recognized
as sending fake RAs with the tool SEND that may use certs or CGA, and if
yes, are both certs and CGAs needed?  Would this involve that HoA must
be a CGA.  I hope not.

> SEND might be used to protect RAs sent from the HA over the MN-HA 
> tunnel when the HA has the MN's CoA binding, but, again, provided the
>  MN already had the cert paths for the routers on the home link, due
>  to the issue with CPS/CPA fragmentation.

I don't think fragmentation on such long paths is an issue because
reassembly.

I didn't think to send DHAAD messages (Req/Rep) through the tunnel.  I
wondered whether SEND can protect when a legitimate-and-attacker MN is
at home. (legitimate: because it shares keys with HA but attacker
because it attacks another MN, attack by forcing HA to send fake DHAAD
Replies to MN).

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 18 Nov 2004 15:05:40 -0800

> SEND were to help with this, would MN need a cert?

If the MN doesn't have a certified asymmetric key pair, it can't generate a
signature on the RA, thus the HAs would not accept the RA.

> yes, are both certs and CGAs needed?  Would this involve that HoA must

No, only certified asymmetric key pairs are needed and only on the HA. The
HAs can recognize the fake RA, as can any other node on the home link.

> because it attacks another MN, attack by forcing HA to send fake DHAAD

I suppose one could put a SEND signature on the DHAAD message using the key
pair certified by the router certificate.

            jak

---

From: [email-masked]
Date: Fri, 19 Nov 2004 11:20:31 +1100 (EST)

Thanks for your comments.

You mentioned "drop the valid Request", however I think it requires the
attacker sit in the middle of mobile router and home agent. I think it
would be difficult to do this. On the other hand, if the attacker sits in
the middle between the mobile router and home agent, it can definitly
perform DoS attack no matter what kind protection is adopted(even you use
IPSec, the attacker can drop IKE messages, SA cannot setup). So the attack
scenarios I mentioned assumes the attacker is in the same foreign link
with mobile router. That would be very easy. And the attack is still quite
significant.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Nov 2004 12:09:24 +0100

> with mobile router. That would be very easy. And the attack is still quite

I agree.

Alex