Subject: RE: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 18 Nov 2004 20:08:14 -0500

I'm trying to follow this discussion to understand what 
the threats are. Apart from a DoS attack on the mobile, is 
there anything we need to worry about here? I really don't
see a reason for securing DHAAD. The same type of active
attacks can be applied on authentic messages to DoS the MN..

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > Alexandru Petrescu
 > Sent: Thursday, November 18, 2004 3:42 PM
 > To: James Kempf
 > Cc: [email-masked]; Henrik Petander; [email-masked]
 > Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home
 > AgentAddressDiscovery
 > 
 > 
 > 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
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mip6
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

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

Soliman, Hesham wrote:
> I'm trying to follow this discussion to understand what the threats 
> are. Apart from a DoS attack on the mobile, is there anything we need
>  to worry about here?

The "DoS attack on the mobile" that you mention has been dissected into:
  denying HA service to the MN, building fake HA lists in the home link
by a legitimate-attacker MN, denying processing power capabilities on
the HA (if Requests were protected, HA would not process fake Requests),
denying HA service to LFN-behind-MR (but not to MR itself).

The attacks do depend a lot on the capabilities of the attacker.

Also, a packet that is dropped by a machine because it fails
authentication takes much less processing power on that machine than if
it were processed by the upper layer of the stack eventually followed by
generating new packets and sent on the wire.  So, authentication still
helps a lot to protect against DoS.  Except DoS should be better defined
when we talk about it :-)  There is DoS that nobody and nothing can
protect against when one unplugs a level 9 cable.

> I really don't see a reason for securing DHAAD.

The reason would be to enable a simple Home Address autoconfiguration
mechanism, whose components are already defined in RFC 3775 (DHAAD+MPD).

> The same type of active attacks can be applied on authentic messages 
> to DoS the MN..

A certain attack on the home link by legitimate-attacker MN (the one
that contributes building fake HA lists, "legitimate" because holds
IPsec keys with HA but simultaneously "attacker" because sends fake RAs
on the home link) can not be applied on authentic messages.  If the
messages were authentic (HA verifies the authenticity) then the
legitimate MN (the remote one) would not be denied HA service.

Alex

---

From: [email-masked]
Date: Sat, 20 Nov 2004 15:00:37 +1100 (EST)

Alex wrote:
> on the home link) can not be applied on authentic messages.

Should we make the following assumption?
Once the MN holds IPsec keys, it is a legimate node and would not send
malicious message (i.e. fake RAs) to HA. If the legimate nodes DO send
malicious message, it's easy to trace the origin.

So we don't need to worry about a legimate MN attack HA. Am I right?

Thanks.
Qian Sun

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 20 Nov 2004 12:15:56 +0100

> So we don't need to worry about a legimate MN attack HA. Am I right?

Yes, this is right.

I guess what I was trying to say was that even if MNs and HA hold 
current rfc3776 keys, an insecure current DHAAD allows MNs to attack 
each other and the HA.  The target of the attack is both HA and MN.  HA 
is a victim  overloading the network unknowingly while the remote MN is 
a victim attacked apparently by HA, but in reality by another MN at home.

These attacks are indeed traceable, but because there are three parties 
(MN, HA, victim MN) then the traceability is a bit more difficult.

Alex