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

From: [email-masked]
Date: Tue, 5 Feb 2002 16:18:45 +0200

Jari,

> > Could you clarify this?  By the 'bit method', are you essentially
> > taking about Section 8 in: 
> > 
> http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ?
> 
> Yes. First bullet item in section 8.
> 
> > Does (1) boil down to Mandatory RR and Optional CGA?
> 
> Not exactly. (1) suggests mandatory RR plus optional/later
> method X, for which we already should design the selection
> mechanism. But for (1), we don't need to decide that X=CGA.

Then I fully support (1).
 
> > CGA may not
> > protect well for IPv4 mapped address, etc.  Additionally,
> > I think Erik suggested that CGA may not be well known enough
> > and that perhaps a CGA BOF be held, so we can sort out all
> > of the details.  I would tend to agree. 
> 
> My personal opinion on this is that we should keep
> work specific to a problem in the WG handling
> that problem. I don't believe we have full understanding
> of what CGA could do for IPv6 control signaling,
> for instance, nor do we fully understand other possible
> solutions. Therefore, I'd rather recommend a IPv6
> control signaling BOF than a CGA BOF.

I think that would be quite valuable, actually.

> I'm in full agreement that we don't have last call -quality
> text. [However, that unfortunately applies in part also to
> RR techniques, see e.g. draft-roe-mobileip-updateauth-01.txt.]

Agreed, so perhaps we should get busy ;)
 
> In conclusion I'm in agreement with you that some
> further work is needed. Maybe even more work for CGA
> than for RR. In any case, we are suggesting separate
> RFCs for base MIPv6 + RR and for CGA. Would this address
> your concern on the additional work needed? The work
> for RR would have to be done to the last details very
> soon, while CGA RFC would not necessarily need to be
> last called at the same time.

I think this is a good way to procede.

> > > 3. Regarding issue (i), the design team recommends that the RR
> > 
> > Can live with this.
> 
> Ok. Hmm... when you say "can live with this", can you
> give some indication of why its only "live with" and
> not "agree"?

My brain has used its quota for the day (my daughter woke up at 4 AM)
I'll send more detailed follow-ups tomorrow.

John

---

From: [email-masked]
Date: Wed, 6 Feb 2002 10:17:40 +0200

Hi Erik,

> Agreeing with what Jari Arkko said but adding an example of 
> how this could play out in detail. We get a bit reserved in the 
> low-order 64 bits of an IPv6 address. A reasonable bit might be 
> the 'group/individual' bit. This probably means that RFC 3041 
> and perhaps other specs need to be tweaked to make it clear
> that the 'reserved' bit must not be used when forming IPv6 
> addresses per those specifications.
> 
> The MIPv6 specification says that if theabove  reserved bit is set in 
> a home address then route optimization using RR MUST NOT be used
> (and also says something about CGA being further studied to 
> be possibly used to route optimize for home addresses that has this bit set).

I think that this is a reasonable approach.

John

---

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

[Resending because of garbled line breaks]

Some comments on the recommendations:

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

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.

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

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. 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: "Tuomas Aura" <[email-masked]>
Date: Wed, 6 Feb 2002 09:07:33 -0800

Ok, I agree. 
Reverse tunnelling is fairly simple if it is provided as 
a general-purpose mechanism, which MN may use for any 
purpose. In that case, HA does not need to look into the 
packet contents or understand what is going on in the
(particular version) of BU authentication.

I have assumed that since general-purpose reverse 
tunnelling was not included in MIPv6 design from the 
beginning, it would not be reasonable to introduce it for 
the purposes of security. Maybe it was a wrong assumption.

(Jari, BTW, the security of reverse tunnelling with the 
unauthenticated home agents needs more thought.) 

> => This might be a stupid question, but where
> are the 'major additions' to the HA functionality?
> 
> You can setup a bidirectional tunnel between
> the MN and HA immediately after receiving the
> BU from the MN. From there on reverse
> tunnelling is pretty straight forward.

---

From: [email-masked]
Date: Wed, 06 Feb 2002 12:59:00 -0500

> the purposes of security. Maybe it was a wrong assumption.

The MIPv6 draft does cover reverse tunneled packets:

9.5. Handling Reverse Tunneled Packets from a Mobile Node

   A home agent MUST support decapsulating reverse tunneled packets
   sent to it from a mobile node's home address.  Such reverse tunneled
   packets MAY be discarded unless accompanied by a valid AH or ESP
   header.  This support for reverse tunneling allows mobile nodes to
   defeat certain kinds of traffic analysis.  Requiring IPsec headers
   on reverse tunneled packets allows the home agent to protect the
   home network against unwarranted intrusions by malicious nodes
   masquerading as a mobile node with a home address on the network
   served by the home agent.

Of course I'm curious now why it says "from a mobile node's home address",
I would have assumed the packet would be from the care-of address for
ingress-filtering reasons.  Maybe I'll have to start another thread
to ask about that...

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Feb 2002 10:34:34 -0800

[repost] for some reason, this mail did not make it to the list.
Erik has already responded to this mail.

Vijay

-------- Original Message --------
Subject: Re: [mobile-ip] BU Authorization method: design team
recommendation
Date: Thu, 07 Feb 2002 16:29:30 -0800
From: Vijay Devarapalli <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: Jari Arkko <[email-masked]>,[email-masked],
[email-masked]
References: <[email-masked]>

Hi Erik, Jari,

Erik Nordmark wrote:

> > 3. Assume, I have more than 2 mechanisms for BU authorization
> > (RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here?
> > For this, (IMO) the obvious thing would be a set of bits
> > in the Binding Update. You dont have to specify this now. We
> > can do this later using the reserved bits in the BU.
> 
> RR+DH seems to incur close to the same processing overhead as RR+CGA
> while not providing much more security that just RR. MiTM is still possible.
> Perhaps there is a subtle difference (I don't know for sure) that such a DH
> MiTM requires seeing packets in both directions (i.e. that unicast routing
> is somewhat symmetric between the CN and HA) whereas a RR MiTM does not
require
> this.

I would say RR+DH is a better BU Authorization mechanism over RR,
but not as good as RR+CGA. So it is still an option over RR and 
an MN should be able to select this mechanism.

> Infrastructure-based mechanisms might make sense in some cases.
> I have doubts whether a PKI would ever carry accurate information about
> what Home Addresses a given certificate has authority to create binding for.
> So personally I think that a PKI can be used in addition to whatever BU
> authorization mechanism there is (e.g. RR) to be able to provide corse
> level distinction between "known friends" and "others".

If a MN's home address ever changes, then it gets a new certificate.
Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a 
few domains (eg a corporate network). And this should be the most
preferred BU Authorization mechanism whereever it is available.

> I don't personally understand AAA-based authorization of binding updates would
> entail and whether it would fit into the architecture of AAA that the AAAwg
> is assuming to comment on that.

Trust me. It will work. We will soon see AAA-based BU authorization 
mechanisms. (again wherever possible, this should be more preferred 
than RR, RR+DH, RR+CGA mechanism). 

> But up-leveling - the property that "the low-order 64 bits of the address
> is allocated according to EUI-64" is currently encoded in the IPv6 address -
> it is a property of the address.
> The fact that "the low-order 64 bits is a <hmac/hash/prf> of a public key"
> is also a property of the address, thus it would make sense to encode this
> in the address as well.
> The fact that a MN or CN uses AAA (or some other infrastructure) for
> pair-wise authentication and authorization is not a property of an IPv6
> address.

Basically the above reinforces, what I had thought. The "1 bit method" 
is very specific to RR+CGA mechanism. It does not help in any way
to select the other strong BU Authorization methods. 

I want to emphasize one point again. CGA is good for IPv6 and ND. I am
not against it. And the "1 bit mechanism" is good for distinguishing a 
CGA address from another address. But that does not make it the best 
mechanism to select from a bunch of BU Authorization mechanisms.

regards
Vijay

---

From: [email-masked]
Date: Mon, 11 Feb 2002 14:58:31 -0600

Hello Jari,

Thank you for the clarification: Seen the previous comments, I was thinking that the knowledge of the value of the keys was the issue.

As for your other comment, I agree with your concerns. But I just wanted to say that there could be other mechanisms than RR, and CGA. We need to have solutions that do not require any infrastructure (such as RR and CGA) but if the network has a AAA infrastructure deployed, it could also take advantage of it to perform authenticated key distribution. 

Franck

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 11 February, 2002 2:27 PM
> To: Le Franck (NRC/Dallas); [email-masked];
> [email-masked]
> Cc: Patil Basavaraj (NET/Dallas)
> > > (*) RR + CGA is more secure since the AAA servers
> > > will not know the keys. 
> >
> > If you use the AAA servers just to authenticate the Diffie 
> Hellman values, the AAA servers will not have
> > knowledge of the keys neither; so I don't think RR+CGA is 
> more secure.
> >
> > In addition, using AAA servers for key distribution avoids 
> the use of signatures.
> 
> I think the original point about 'more secure' wasn't quite correctly
> formulated. The point about CGA is that it is more secure because
> it proves address and key relationship, and does so without 
> any sort of
> configuration or trust that could go wrong. 
> 
> The point about using AAA for key distribution is a correct one:
> this probably does avoid the use of signatures. However, we can't
> use AAA in isolation, it always needs to be complemented with
> the Authentication part --- and that may involve different kinds of
> cryptographic operations. True, those don't necessarily have to
> be based on signatures. But there has to be something. And it
> has to be done to the *CN* also, and this might not have been
> necessary otherwise.
> 
> I'm very much in favor of the AAA schemes for building infrastructure
> to allow access or authenticate a particular service. However, I'm
> concerned that its application for MIPv6 Route Optimization would
> create a situation where an extremely large global 
> infrastructure would
> have to be built. Much larger than would be necessary to e.g. just
> authenticate everyone on a cellular terminal - and even that is big
> enough. More seriously, everyone outside this global infrastructure
> would not get the same kind of service as the ones inside. 
> For instance,
> my home web server might not be able to offer Route Optimization
> while the operator owned commercial service could. I think this would
> be bad for MIPv6, and bad for Internet in general if we could have
> avoided it. Finally, as Erik pointed out all of the 
> infrastructure-based
> methods have serious trouble with dynamically changing things such
> as RFC 3041.
> 
> Jari
> 
> 
> 
>