Subject: RE: [mobile-ip] list of things for MIPv6

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 21 Dec 2001 16:45:46 +0100

Hi Vijay and all, 

Sorry, long email but there are lots of issues.

  > -----------------------------------
  > 
  > 1. Mobile IPv6 use of Routing Header
  >         It has been identified that reflector attacks are
  >         possible with MIPv6 use of routing header. There is
  >         also a solution for this. If the host processing
  >         the routing header performs a simple rule of 
  >         'check if the destination address and the next address
  >         to be swapped in both belong to the same interface 
  >         of the node', before processing the routing header,
  >         we eliminate this threat caused by MIPv6.

=> I think the best way to solve this is to make sure
a node, by default, doesn't forward to any addresses
outside any of the node's interfaces. And that it 
MUST be possible to override this behaviour by manual
configuration. Unfortunately though this 
is something that needs to be done in IPng to be generic
for all IPv6 hosts, so I don't know how to go about that. 

Different flavours of this rule are mentioned in Erik's
draft, Pekka's draft and the cellular host (manyfolks)
draft in IPng. 

  > 
  > 2. Mobile IPv6 use of Home Address Option
  >         The threat in this case is that some trivial source 
  >         spoofing attacks are possible. The answer to source 
  >         spoofing has always been smart ingress filtering. 
  >         its the same in this case too. Using a tunneling 
  >         approach does not it solve it either. So we have 
  >         two options
  >         a. Document this threat in Mobile IPv6 security 
  >            considerations and leave it.
  >         b. Solve it by mandating that home address option 
  >            is not processed unless there is a corresponding 
  >            binding cache entry (of course created securely). 
  >            use reverse tuneling through the home agent when 
  >            a binding cache entry does not exist.
  > 
  >         in my opinion, lets go with (a). (b) is a really bad 
  >         idea. (b) is too drastic. I can live (a) becase the 
  > 	threat is very insignificant. Source spoofing attacks 
  > 	are possible currently (in the current internet). if 
  > 	the bottom line is 'do no harm' lets go with (a).
  >         

=> I'm afraid I agree with Pekka here. The threat 
is definitely significant. We can't pretend it
won't happen, so I'd have to go with b) (unfortunately). 
But think on the positive side, it's good to have 
a symmetrical bidirectional path, for QoS reasons :)

  > 
  > 3. Protecting the BU. There are three options. pick one. 
  >         a. new extension header
  >         b. Authentication Sub-Option only.
  >         c. Jari Arkko's draft, option 4 which shows how 
  >            authentication suboption and AH can be used 
  >            together with minimal changes.
  > 
  >         if we decide to go with (a), lets not go with UDP. 
  >         instead we should use a new extension header. 
  >         I personally prefer option (c). Implementing the
  >         auth suboption is very easy. I can provide the code
  >         if people think it is complicated to implement.
  > 

=> Definitely a) or alternatively a UDP port number.

  > 
  > 4. Piggybacking
  >         Phil described various options in his presentation 
  > 	at Salt Lake City. lets pick one.
  >         a. lets leave it as it is. it is a 'MAY'.
  >         b. leave it as it is, but recommend when it is
  >            good to use and when it is bad to use. 

=> c). (which was discussed), say that it SHOULD NOT
be done. I agree with Francis on this one.

  > 
  > 
  > 5. Key Distribution protocol between MN and CN
  >         a. Return routability vs CGA (Cryptographically 
  >            Generated Addrs)
  >         b. Binding Security Association
  > 
  >         for (a), lets go with return routability unless 
  > 	somebody can prove that it is insecure. The added 
  > 	complexity of CGA or Diffie Helman operations is 
  > 	not worth it. no additional gain. so lets go with 
  > 	simple return routability.

=> I can't see how we can do RR only and still maintain
that our requirement is "Add no harm". Connection
hijacking can be considered "new harm" and RR will
not stop it. IMHO (and I'm not a security expert)
the combination of CGAs and RR is an excellent idea
and will give quite a strong security. 
If the processing power is a concern, some optimisations
were proposed to off-load some of the operations 
onto the HA. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 10:08:56 -0800

Hi Hesham,

> is definitely significant. We can't pretend it

Well. I disagree that the threat is significant. and we are
not pretending that it is not there. we document it and leave
it to the implementations. 

> => Definitely a) or alternatively a UDP port number.

never UDP. a lot of implementations dont have UDP in the
kernel. Mobile IPv6 almost always exists in the kernel.
IF we go with (a) lets use a new extension header.

But before that, I think people should read Jari Arkko's
draft again. draft-arkko-mipv6-bu-security-01.txt, section 6.4.
With that approach we dont need a new extension header for
the BU. and there will be minimal changes to the existing
implementations.

Before people say 'new extension header' please think about
what it means. it means changing a lot of implementations. 
a new extension header not understood by intermediate routers
and dropped. firewalls need to know about the new extension
header....

> hijacking can be considered "new harm" and RR will

I guess you need to read BU3WAY again. It just uses return
routability. and BU3WAY cannot be called insecure in any
way. and your connection hijacking does not happen there.

> were proposed to off-load some of the operations

IMO, this is not a option. there is no protocol for that.
and if you try to do that, its plain stupid (of course IMHO).

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 10:20:03 -0800

> and if you try to do that, its plain stupid (of course IMHO).

here I was talking about off-loading the operations onto
the Home Agent.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Dec 2001 10:27:18 -0800 (PST)

> it to the implementations. 

One of the criteria that Jeff gave was "do no
harm".  There has *considerable* push to get RFC
2827 implemented widely. MIPv6 providing a new and
pervasive source of source spoofing without a way
to prevent that introduces considerable harm by
any reasonable definition. I cannot see how this
can be handwaved away.

       Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Dec 2001 11:02:43 -0800

Hello Hesham,

"Hesham Soliman (ERA)" wrote:

> not stop it.

Can you be specific about the hijacking danger that you see?

What I'm imagining is this:

- Suppose Correspondent Node and Mobile Node (MN) are
  communicating

- Bogus Mobile Node (BMN) sends a bu3way (e.g.) message
  to validate a Binding Update for a bogus care-of address.

- BMN eventually gets CN to send packets to BMN.

I agree that this could happen.  But only when BMN resides
in certain places (e.g., at Francis Dupont's default router).
Thus, I don't think this qualifies as an additional threat.

>                IMHO (and I'm not a security expert)

CGA helps to establish ownership of an address.  As has been
pointed out, it doesn't solve all the problems with bombing
arbitrary subnets.  So I think it should be an optional feature,
not mandated but recommended for situations where the extra
security is valuable.

Regards,
Charlie (not a security expert either) P.

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 21 Dec 2001 21:26:37 +0200

> and if you try to do that, its plain stupid (of course IMHO).

Well... I'm not going discuss the latter claim, but there *is*
a protocol. See

http://www.ietf.org/internet-drafts/draft-roe-mobileip-updateauth-01.txt

under 3.2 and Optimisations. (In any case, the feeling in SLC
seemed to be roughly the following: "Nice to know we can optimise
for small MNs/CNs, but thank's, we don't think it will be necessary at
the beginning. We could do it as an optional protocol later.")

Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 21:54:15 +0200 (EET)

> any reasonable definition. I cannot see how this

Completely agree.  I fear the issue cannot be settled properly.

Everyone who thinks the threat isn't real should read:

Date: Fri, 21 Dec 2001 13:16:57 +0200 (EET)
From: Pekka Savola <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: [mobile-ip] list of things for MIPv6 (2)

This clarifies one issue that may not have come up strongly enough before.

Practically destination site's filtering which you _can_ rely on these
days is nullfied.

-- 
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: Sat, 22 Dec 2001 17:41:44 +0100

=> Mobile IPv4 uses UDP and this doesn't seem to be a problem...
As an implementor (of a mobile IPv6 in the user space :-) I can
say the alternative is valid.

=> I already said why I don't believe in this approach.

=> note that "extension" is misleading, we are talking about
a new terminal header type (a protocol in IPv4 terms).

=> these implementations have to be changed in any case...

   and dropped.

=> NO, intermediate routers don't process terminal headers.

   firewalls need to know about the new extension header....

=> this is true for any new protocols like SCTP.

=> don't joke: BU3WAY security is very low (perhaps too low).

Regards

[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Sat, 22 Dec 2001 18:49:40 +0200 (EET)

> => this is true for any new protocols like SCTP.

SCTP is a valid analogy only if the considered extension header type is
"terminal".  So no TCP/UDP/whatever in that packet then .. that's what's
under the discussion, right?

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 18:18:23 +0100

=> it should be terminal because a new not-terminal header type has
no real advantage over the destination option header.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Dec 2001 00:33:16 +0100 (CET)

> and will give quite a strong security. 

Any node on the path between two communicating entities today can be
MiTM for TCP connections and UDP "flows". If IPsec/TLS/etc is not used those 
MiTM can modify the content of the communication; otherwise they can
just cause a DoS by dropping packets (or modifying them and having the
receipient drop then due to authentication failure).

Adding MIPv6 a BU protected by RR doesn't seem to make this any worse.
What am I missing?

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 24 Dec 2001 16:03:35 -0800 (PST)

> Adding MIPv6 a BU protected by RR doesn't seem to make this any worse.

   Right. It should be noted that the even the
   most widely deployed crypto/auth layer (TLS)
   is subject to trivial MITM wedging attacks
   (eg, insert a bogus-TLS good-TCP segment --
   barf, die). For better or worse, we depend
   on there not being many evil routers. Literally.

	    Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 29 Dec 2001 13:08:44 -0800 (PST)

> it to the implementations. 

   To do _what_ precisely? As in: what exactly can
   this implementation do to protect itself from
   source spoofing?

	  Mike