Subject: Re: [mobile-ip] RE: BU Authorization method: design team recommendation

From: "Jari Arkko" <[email-masked]>
Date: Wed, 6 Feb 2002 18:36:22 +0200

Thanks Tuomas for your input! Some further discussion
below:

> Yes, BSA is needed in order to implement Recommendation 6! Since HoA RR
> is 
> omitted for most BUs, you need some other way of authenticating these 
> BUs. Otherwise, the attacker could use its own address as the CoA, pass
> the 
> CoA RR test, and send false BU.

Yes. I believe we stated something about BSAs being needed for
CGA. Are you saying that you want the BSAs also for RR?

> When CREATING a BCE, both HoA RR and CoA RR are needed. 
> When UPDATING a BCE with a new CoA, only CoA RR is needed. 
> When REFRESHING a BCE without changing the CoA, I suggest testing both
> CoA RR and HoA RR every time. 
> Finally, if the mobile has a new CoA in every BU and never refreshes
> without changing the address, HoA RR must nevertheless be done periodically.

I think what you suggest is actually quite close to what we were thinking
in the recommendation, just that instead of considering these separate
cases we simply grouped the above different update actions into one
kind of an update, and considered a time limit on the lifetimes. But I
have nothing against e.g. doing the HoA test periodically instead of
limiting BCE lifetime. You mentioned improved latency as an advantage
of the above scheme. Are there other advantages and/or tradeoffs,
will there be additional complexity or does this simplify things?

> I have an issue with the introduction of reverse tunnelling. Message 1a 
> requires a major addition to the Home Agent functionality. For all other
> purposes, the Home Agent is acting as a simple router that forwards
> packets  into an IPIP tunnel.

With 'major addition', do you refer to reverse tunneling, i.e. forwarding
packets also out of an IPIP tunnel? Or did you have something else
in mind? The HA is not expected to do anything for the 

> I wonder if the reflection attack is really serious

This is indeed the question. You could say that the reflection
attack for the BU authorization protocol is dangerous, if
we decide that the HAO is dangerous in general. We haven't
gotten to that recommendation yet, though there's been
a lengthy discussion on the mailing list. What's your opinion?

> That way, the source address of the attacker is 
> not masked in the reflection and tracing attackers is easier. 

Yes, this would reveal the attacker's source address. I believe
the concern we had about this is what happens after you notice
that you are being attacked. With the address in the packet
coming towards the victim, we now have a chance to e.g.
block it at the ISP router in both methods. However, the
blocking is easier if the address is in the IP header directly
rather than hidden at an "application layer". There may be
some itrace/IPPT differences as well.

Jari

---

From: "Tuomas Aura" <[email-masked]>
Date: Wed, 6 Feb 2002 07:37:28 -0800

Some comments on the recommendations:

> (i)  Whether or not Binding Security Associations (BSAs) are
>       used

> (ii) What addresses need RR tests (HoA, CoA, or both), and
>       what is the correct time to perform the tests, always
>       at the time the binding is requested?

When CREATING a BCE, both HoA RR and CoA RR are needed. CGA
authentication 
is a plus. (At this time, a BSA can be established either with CGA+DH or
by 
sending the key in plain text in the HoA RR message.)

When UPDATING a BCE with a new CoA, only CoA RR is needed. HoA RR before

a location change adds unnecessary latency and should be avoided, but 
read further for an exception. (Without BSA, HoA RR would also be needed

to authenticate the BU.)

When REFRESHING a BCE without changing the CoA, I suggest testing both
CoA 
RR and HoA RR every time. CoA RR verifies that the mobile really has
stayed 
at CoA. Frequent HoA RR ensures that CN can delete the BCE at any time
and 
when it does, a HoA RR test has been done recently. This prevents
bombing 
attacks against HoA (to be documented in
draft-aura-mipv6-bu-attacks-02). 
Yes, both RR tests could be done only periodically, but the cost of
doing 
them every when refreshing a BCE time is low. No latency is added by the
RR 
tests because is the protocol can be executed well in advance in the 
background. 

Finally, if the mobile has a new CoA in every BU and never refreshes
without 
changing the address, HoA RR must nevertheless be done periodically.
Again, 
this prevents bombing attacks against HoA.

> 1a. MN(HoA)--->HA--->CN
> 1b. MN(CoA)--------->CN
> 2a. CN-------->HA--->MN(HoA)
> 2b. CN-------------->MN(CoA)
> 3.  MN(CoA)--------->CN

purposes, the Home Agent is acting as a simple router that forwards
packets 
into an IPIP tunnel. I wonder if the reflection attack is really serious

enough to warrant the complexity that is added to the Home Agent by 
Message 1a.

May I suggest an alternative protection:
Consider a modification of the above the protocol where Message 1a has
been 
removed. Yes, CN could be used for reflection (and amplification by a
factor 
of 2). In order to discourage the attack, copy the source address of 
Message 1b into Message 2a. That way, the source address of the attacker
is 
not masked in the reflection and tracing attackers is easier. 

Tuomas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Feb 2002 14:51:24 +0100 (CET)

> enough to warrant the complexity that is added to the Home Agent by 

Tuomas,

For 1a the HA is also just a router that forwards packets - in this case
from an IP-in-IP tunnel out on some other interface.

Is your point that we shouldn't mandate support for reverse tunneling in the HA
or is there another point that am I missing?

I think HAs need to support reverse tunneling in general - e.g. in order to
deal with multicast packets sourced from the HoA, in order to allow
MNs not to disclose their current CoA to some CNs, etc.

   Erik