Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access

From: Pekka Nikander <[email-masked]>
Date: Thu, 03 Jan 2002 12:55:59 +0200

Markku Savela wrote:

> I may have missed some discussion due to high volume on this topic,
> but I like to inject one scenario of Home Address option use...
> 
>   If MN and CN have IPSEC session between them, then I
>   suppose HAO within such session is safe. (I leave it open for now,
>   whether the session should be between care of addresses or home
>   addresses of MN and CN, but either should work?).

Well, that depends on _how_ exactly you have created the IPSEC session,
and, as a consequence, how much you trust the MN.  If you use something
like opportunistic IPSEC (see
http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic-04-change.txt)
you certainly CANNOT trust the HAO any more than without IPSEC.
On the other hand, if you have a closed user group with strong
internal trust relationships, you may decide to trust the HAO
without any explicit authorization.  However, in the general
case, when you create the IPSEC SA, you have to check that the
MN is _authorized_ to use the Home Address.  Only that makes
it secure to trust on the HAO.

As a side note, the CGA and RR methods are means to check an
MN's authority to use a Home Address.  Basically, RR relies
on the assumption that if a host can answer to messages sent
to an address, it is authorized to use that address.  CGA,
on the other hand, relies on that if a host possesses a private
key that corresponds to the host ID part of an IPv6 address,
it is assumed to be authorized to use that address.  Neither
is perfectly secure, but both are much better than nothing.

(Well, what do I mean with "much better".  In the RR case,
much better means that the number of hosts able to foil the
RR check is much smaller than the number of hosts in the
Internet.  In the CGA case, creating a private key that
corresponds to a given IPv6 interface ID requires so large
amounts of computational capasity that few attackers are
likely willing to spend that much of resources.)

--Pekka Nikander

---

From: Francis Dupont <[email-masked]>
Date: Fri, 04 Jan 2002 17:12:36 +0100

About section 2 on Correspondent Nodes; could you elaborate in the 
   document why exactly solution is too drastic?

=> because this gives no choice between bidirectional tunnel and
route optimization, so in some cases mobile IPv6 becomes far less
attractive. The real impact depends on how mobile IPv6 is used,
in fact one can argue that bidirectional tunnels are enough, but
I don't believe that mobile-ip list members will agree...

   Note that BCE check is not 
   the only way to ensure legitimity of HAO: if it's secured by AH, it's ok;  
   if some SUCV/.. weak authentication method is used, it's probably also ok; 
   the same might even apply to return routability.  It's too early to crush 
   CN solutions.
   
=> these CN solutions have the same cost than full routing optimization,
so I consider them as BCE check variants.

   (I think the solution for HAO should most likely consist of two separate, 
   "strong-enough" layers, one mandated at CN, one possible at firewalls, but 
   that's not the topic of this draft).
   
=> one mandated at CN == no third choice.

   Note: it seems every site, even if it had only a few MN's, will have to
   have AAA infrastructure, so that it could interact, certify etc. home
   address use for remote AAA systems when MN goes roaming and there's a need
   to punch a hole in ingress filtering of remote sites.
   
=> I don't know if the "remote sites" are home sites (sites with home agents)
or correspondent sites (sites with correspondent nodes).
 In the last case the only issue is the iDDoS because both care-of
and home addresses are external. In the first case one can rely on
home registrations (which have to be strongly secured) in order to
understand what happens (and what HAO are valid), in fact this is just
remote network access control (in AAA terms this can be done directly
(IKE with certificate for instance) or (better because simpler) using
the local/visited AAA system as a mediator, note the issue is for
first home registrations because they have to create security contexts).

   (If this is the approach for security, it should be required in the main
   MIPv6 draft).
   
=> I disagree, the iDDoS security threat is not a major one because
ingress filtering is not really mandatory. The purpose of my draft is
not to fill the hole, it is to get back the previous (i.e. before HAO)
situation.

   Or have I missed something?  This seems unnecessary in many environments,
   e.g. university campus area WLAN or company's internal network.
   
=> this depends on where are the visited, home and correspondent domains.
 For an university campus area WLAN home agents are in campus area too
so a bidirectional tunnel with a good local security seems enough
(i.e. visited domain = home domain with home agents in the path
between MNs and CNs).
 In a company internal network all three domains are the same so there is
no security problems as soon as basic security (i.e. no physical intruders)
is enforced.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 04 Jan 2002 17:22:20 +0100

If MN and CN have IPSEC session between them, then I
     suppose HAO within such session is safe.

=> this depends on what is an IPsec session (AH makes HAO safe,
more details are needed for other cases).

     (I leave it open for now,
     whether the session should be between care of addresses or home
     addresses of MN and CN, but either should work?).
   
=> if the IPsec SA is with a care-of address it has to be rebuilt
after each movement. But the ISAKMP SA can be with the care-of
or the home address (i.e. IKE session can use the care-of or the
home address) at the exception of the IKE session for a first home
registration (i.e. before the home agent - mobile node tunnel is
established, mobile IPv6 drafts have a MUST because of this case).

Regards

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Jan 2002 18:29:09 +0200 (EET)

> I don't believe that mobile-ip list members will agree...

Nothing prevents from applying some kind of RR tests to HAO (without BU) 
use too.  The HAO implementation would just be a .. little .. more 
complicated.. but then again it hasn't been defined in the spec anyway.

> so I consider them as BCE check variants.

See above.

> => one mandated at CN == no third choice.

One must be available for CN, because CN cannot trust the source if it 
isn't authenticated or in some form authorized.

[snip rest]

I won't get into this more here, because I must say I agree almost 100%
with comments from Pekka Nikander, Jari Arkko et al. (You should be very,
very afraid if you ever venture in Finland, Francis ;-).

One point I've made before: perhaps the check is trivial, but IMO _the
most important thing_ is that *every* site could easily check from
incoming packets with HAO, whether the HAO is is spoofed to belong to
*destination site in question* or some other site the destination site
trust at some level.

This form of spoofing can be protected against now.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Francis Dupont <[email-masked]>
Date: Mon, 07 Jan 2002 18:23:30 +0100

=> I believe the ".. little .. more complicated.." is a joke, isn't it?

   > (I think the solution for HAO should most likely consist of two
   > separate, "strong-enough" layers, one mandated at CN, one possible
   > at firewalls, but that's not the topic of this draft).
   >    

=> again, if you rely on routing optimization (RO) or something equivalent 
then you close the door to the third choice (aka triangular routing).
IMHO HAO has nothing to do with RO: if for sanity HAOs can be checked
against the BCE (i.e. if they don't match something is wrong), the only
way to reply to the iDDoS threat by this way is to mandate the check
and to forbid HAOs without RO.

   [snip rest]

=> so you agree to kill triangular routing?

=> so the easiest solution for someone which doesn't want to implement
or enable RO is just to drop HAOs. In France we have an expression for
that: "la politique du pire".

Regards

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Jan 2002 22:27:34 +0200 (EET)

> => I believe the ".. little .. more complicated.." is a joke, isn't it?

Of course. :-)

[snip]

> => so you agree to kill triangular routing?

What's the point of it, really?

If you don't want routing optiomization, nothing prevents you from
establishing tunnels to your home agent: no need for HAO etc. either then.  
This is probably better for TCP and the like which like symmetric
propagation properties.

> that: "la politique du pire".

Sure, if that only means the connections will break if the MN moves.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 08 Jan 2002 11:31:53 +0100

=> no, that only means the only solution is to use a bidirectional
tunnel with the home agent (i.e. we are back to the current mobile
IPv4 situation).

Regards