Subject: [Mip6] RE: Mip6 Digest, Vol 7, Issue 21

From: 박은영 <[email-masked]>
Date: Fri, 19 Nov 2004 09:18:19 +0900

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 19, 2004 2:23 AM
To: [email-masked]
Subject: Mip6 Digest, Vol 7, Issue 21

Send Mip6 mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/mip6
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Mip6 digest..."

Today's Topics:

   1. Re: New I-D: Security Issues in Dynamic Home Agent Address
      Discovery (Henrik Petander)
   2. Re: New I-D: Security Issues in Dynamic Home Agent Address
      Discovery (Alexandru Petrescu)
   3. Re: New I-D: Security Issues in Dynamic Home Agent
      AddressDiscovery ([email-masked])

----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Nov 2004 19:04:25 +1100
From: Henrik Petander <[email-masked]>
Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent
	Address	Discovery
To: Alexandru Petrescu <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Alex,

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

Alexandru Petrescu wrote:
> [email-masked] wrote:
> 
>> Here is a new I-D, Security Issues in Dynamic Home Agent Address 
>> Discovery.
> 
> 
> 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.

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

------------------------------

Message: 2
Date: Thu, 18 Nov 2004 15:50:03 +0100
From: Alexandru Petrescu <[email-masked]>
Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent
	Address	Discovery
To: Henrik Petander <[email-masked]>
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

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.
> 
> 
> 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?

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
>  authenticated as coming from authorized routers.

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.

> 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.

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

------------------------------

Message: 3
Date: Fri, 19 Nov 2004 02:58:52 +1100 (EST)
From: [email-masked]
Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent
	AddressDiscovery
To: "Henrik Petander" <[email-masked]>
Cc: [email-masked], [email-masked],	Alexandru Petrescu
	<[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;charset=iso-8859-1

> Hi Alex,
>
> Thanks for reading the security analysis of DHAAD part of the draft and
> commenting it.
>
> Alexandru Petrescu wrote:
>> [email-masked] wrote:
>>
>>> Here is a new I-D, Security Issues in Dynamic Home Agent Address
>>> Discovery.
>>
>>
>> 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.
>>
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.

>> 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.
>
> 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
>
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
>

------------------------------

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

End of Mip6 Digest, Vol 7, Issue 21
***********************************

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