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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 19 Nov 2004 11:41:36 -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?
 > 
 > 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.  

=> We're talking about communication between the MN and HA.
What upper layers are involved here? If something modifies
the BU on the way it will not affect upper layers.

   So, 
 > authentication still
 > helps a lot to protect against DoS.  

=> Not the kind of DoS (actively modifying a packet) being
discussed here.

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

=> Please separate DHAAD from MPD. MPD can be protected today.
DHAAD is not and need not IMO.

Hesham

===========================================================
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 19:05:49 +0100

Soliman, Hesham wrote:
>> 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.
>> 
>> 
>> 
> => We're talking about communication between the MN and HA. What 
> upper layers are involved here? If something modifies the BU on the 
> way it will not affect upper layers.

I meant "upper" not "uppermost".  An IPv6 stack does some IPsec checks
when receiving a packet.  It drops them if checks fail, thus
upper-above-ipsec layers (not necessarily L7, but still above) are not
submitted, thus less processing.

An attacker sending fake DHAAD Requests to HA provokes that HA to
process the Request a bit upper than IPsec, but still below L7, and even
generate replies back and overload o wire.

If the DHAAD Req were protected somehow then no fake Rep generated, less 
load on the network.

Some people call these aspects "bombing" or "reflection" or DDoS or similar.

> So,
>> authentication still helps a lot to protect against DoS.
> 
> => Not the kind of DoS (actively modifying a packet) being discussed
>  here.

I think that here we discuss both actively in-path intercepting,
modifying and dropping packets, and also an attacker that can send any
packet and not be subject to ingress filtering rules.

It is true that DHAAD is subject to a range of DoS attacks to which no 
security mechanism can provide total protection (active on-path), but it 
is also true that DHAAD opens up new risks ("HA reflection" if you wish) 
to which protection _is_ possible, with known methods.  And it is also 
true that _without_ DHAAD the network is more secure, as it is true that 
a network without _any_ protocol is more secure.

>> The reason would be to enable a simple Home Address 
>> autoconfiguration mechanism, whose components are already defined 
>> in RFC 3775 (DHAAD+MPD).
> 
> => Please separate DHAAD from MPD. MPD can be protected today. DHAAD
>  is not and need not IMO.

Yes, I agree to keep them separated.  DHAAD serves mostly to discover
the HA, maybe when MN powers up while MPD serves mostly to get its
address remade up when the prefixes on the home link change, every three
months or so.  They're separated now, ok?  (they're still both ICMP :-)

MPD can be protected today and should be; actually the spec it says it is.

DHAAD can also be protected.  If you think it needs not to be protected,
then fine, I'm ok to know.

If both DHAAD and MPD are protected and if MN uses the prefix in the MPD
to initially configure its Home Address then we can say that DHAAD+MPD
is a method to remotely and securely autoconfigure a HA address and a
Home Address.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Sat, 20 Nov 2004 21:29:32 +0200

> If the DHAAD Req were protected somehow then no fake Rep generated, less 

It is true that additional security mechanisms on DHAAD would
be able to prevent some vulnerabilities. I guess my question
and Hesham's question are about what the most urgent things
are the IETF should deal with in this space. In terms of MIP6,
my personal top three list is:

   - deployment/bootstrapping improvements
   - making it possible to use operator AAA for home authentication
   - some improvements to movement latencies

There's a bunch of other medium priority things following
this (maybe privacy, home agent redundancy, etc). And then
some low-priority items which we should forget for now.
The question is, where is the DHAAD security improvement
in this classification? Are there requirements from PP2
or someone else who intends to deploy that this particular
issue is a problem?

> Some people call these aspects "bombing" or "reflection" or DDoS or 

In the design of various protocols, we have looked into the
economic aspects of vulnerabilities, similar vulnerabilities
that exists elsewhere in the Internet already, and the cost
of defenses. While its true that you can use DHAAD for bombing,
its important to see that its still just 1:1 cost-benefit
factor for the attacker; one packet causes another packet to
be sent. Generally speaking, the Internet is full of attacks
of similar severity. This does not seem like a major reason
to start up some work. (Of course, there may be other issues,
such the ability of operators to hide their infrastructure
from each other.)

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 21 Nov 2004 00:15:12 +0100

Jari, thanks for the message.

Jari Arkko wrote:
> It is true that additional security mechanisms on DHAAD would be able
>  to prevent some vulnerabilities. I guess my question and Hesham's 
> question are about what the most urgent things are the IETF should 
> deal with in this space. In terms of MIP6, my personal top three list
>  is:
> 

It looks to me that these three items have a strong deployment push,
which is very important for the protocol itself, if it needs to live.

I do not currently have such an ordered list of priorities for MIP6.

> There's a bunch of other medium priority things following this (maybe
>  privacy, home agent redundancy, etc). And then some low-priority 
> items which we should forget for now. The question is, where is the 
> DHAAD security improvement in this classification?

I may link "securing DHAAD" to "easy HoA configuration", and thus
finally to "deployment/bootstrapping improvements" (your first item) but
it seems that's a too contortious link, supposedly because secure
DHAAD+MPD does not involve AAA (your second item).

Thus, do you have a rough idea whether secure DHAAD would somehow fall
within the "low-priority items" that we may forget for now?

> Are there requirements from PP2 or someone else who intends to deploy
>  that this particular issue is a problem?

Not as far as I know.  I am not aware of 3GPP2 needing DHAAD secured,
nor of 3GPP2 not needing DHAAD at all.  I am just aware of a deployer
mentiong something like "I don't deploy DHAAD because insecure".  Which
does not necessarily mean that particular deployer needs secure DHAAD,
and I didn't ask.  Absence of a protocol is more secure than that same
protocol secured, I agree.

> its true that you can use DHAAD for bombing, its important to see 
> that its still just 1:1 cost-benefit factor for the attacker;

That's true and well said.  Attackers may be indeed more tempted by
"explosion"-like attacks like 1:n.  I could build an "explosion"-like
attack 1:n involving one attacker MN, one HA and several attacked MNs,
triggered by only one fake RA on the home link, but I am not sure
that me describing such an attack is of any use if there is no
deployment push.  I mean if nobody deploys DHAAD then there is no need
to talk about it and its risks at all.

> packet causes another packet to be sent. Generally speaking, the 
> Internet is full of attacks of similar severity. This does not seem 
> like a major reason to start up some work. (Of course, there may be 
> other issues, such the ability of operators to hide their 
> infrastructure from each other.)

I agree.

It is good to know this.  I do not know whether this particular draft's
authors also see secure DHAAD+MPD as a HoA bootstrapping mechanism, or
whether secure DHAAD only is the only motivation.

Thanks,

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Nov 2004 09:49:26 -0800

> or someone else who intends to deploy that this particular

I have to second Jari's note. As I mentioned in my original response, I
don't see DHAAD being deployed. I believe that the mip6 group needs to stay
closely focussed on those issues that have arisen as a result of
implelmentation and deployment considerations. The issue of security for
DHAAD falls way below the line, in my opinion.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 22 Nov 2004 23:20:19 +0100

James Kempf wrote:
> I don't see DHAAD being deployed. [...] focussed on those issues 
> [...] implementation and deployment considerations.

Ok, I got the idea; I'm not insisting on this.

Thanks,

Alex