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

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 21 Dec 2001 11:35:51 -0600

> -----------------------------------
> 
> 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 guess all application or transport layers, even UDP, are responsible for
checking that the source address is valid to tunnel-in so to speak? I may be
wrong but we might be ignoring some other - less publicized threats.

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

My opinion is that the specs should be correct and devoid of holes. It is
implementation specific choice of vendors of equipment and software to be
compliant or not. I don't think we should trivialize the hole. We should
just fix it and move on. I also do not think that plugging the hole will
significantly increase the cost of devices. Ex. I don't see an IP-enabled
light switch or toaster being accessed by millions of mobile nodes at the
same time. 
         
> 
> 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.
> 

I thought the group had already settled on b. Last time I checked there were
even plans to upgrade various open-source implementations as well.

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

Both are fine with me. The points made above about implementation
conformance still apply, though.

> 
> 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.
> 
>         for (b), I am not sure.         
> 

While I am not apposed to the 3-way triangular handshake - bounce around the
world solutions being devised and standardized. At some point, it might be
fruitful to focus on finding solutions that don't require AAA, yet can
accomplish the association establishment in fewer messages. This might be
more appropriate for working with real-time media streams. It would also be
faster for non-realtime streams.  I don't really see that solution to this
fast establishment problem should be restricted to just mobile ip, however.
I would certainly understand if MIP-specific slower methods were
standardized and implemented first, though.

The main point here is that if the 3-way handshake is the implementation,
the applicability of its use with other WG technologies may be deminished;
therefore other SDOs can claim that because of this, they are not conformant
with MIPv6 route optimization.

Even if there were a MIP RO with AAA document that did show how it could be
done with fewer messages, I suspect that the endpoints might need to know
which way it is being done and this might affect the MIPv6 protocol, itself?
If a solution with no AAA could be found and agreed upon, this might avoid
all of this unpleasantness.

Regards,

Glenn

---

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

Hello Glenn,

> wrong but we might be ignoring some other - less publicized threats.

To my understanding, the routing header is not necessarily even
visible to higher-level protocols.  I don't think they should have
anything to do with processing routing headers.

On the other hand, I think that setting up intermediate nodes for
routing headers is an application-level function, just as with
routing protocols.

> compliant or not. I don't think we should trivialize the hole. We should just
> fix it and move on. I also do not think that plugging the hole will
> light switch or toaster being accessed by millions of mobile nodes at the same
> time.

I have to agree that the specification has to be correct!  However, we
always have to weigh the cost of the problem against the cost of the
solution.  If the problem is microscopic, and the solution so burdensome
as to likely inhibit implementation, then the solution is not a solution
after all, and we should just document the problem.  Thus I agree very
much with (a), because I think the threat is small.  Plus, I think that
ingress-filtering routers can be built to make the threat even smaller.
Furthermore, there are rules that can be built into correspondent nodes
to reduce the threat even more.

> accomplish the association establishment in fewer messages. This might be more
> appropriate for working with real-time media streams. It would also be faster
> for non-realtime streams.  I don't really see that solution to this fast
> establishment problem should be restricted to just mobile ip, however. I would
> certainly understand if MIP-specific slower methods were standardized and
> implemented first, though.

If we were to make the three-way handshake part of the data stream, then it
would boil down to no more messages, but of course a lot more data bytes in
those messages.  Even if we don't do that, I think that the return routability
stuff isn't so bad, given that it would typically occur when the application
starts up, so that it would not interfere with the actual data streaming.

The thing about Mobile IP that suggests a specialized solution is exactly
the possibility to rely on the return routability for additional protection
against wide-area attacks.  In fact, I reckon that this will make MIP-specific
methods faster, not slower, as long as we don't go overboard with mandating
a lot of heavy exponentiation as part of the solution.

> The main point here is that if the 3-way handshake is the implementation, the
> applicability of its use with other WG technologies may be deminished;

I don't think this is a likely result.  Furthermore, if another solution
is found that meets the performance and security needs of Mobile IPv6, then
it should be possible to use it.  This is another good reason to keep the
key establishment protocol separated from the Mobile IPv6 protocol.

> If a solution with no AAA could be found and agreed upon, this might avoid all
> of this unpleasantness.

What do you think about bu3way?  It's bound to be a lot faster than AAA, and
can be adorned with optional features for additional security for applications
that need it.

Regards,
Charlie P.

---

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

> to reduce the threat even more.

Charlie,

since I have no idea what rules could possibly be built into 
ingress-filtering routers and CNs that reduce the threat, could you please
enlighten me?

As far as I can tell, any scheme for verifying the relationship between
the source address (CoA) and the Home Address, whether done by an
ingress-filtering router or a CN, requires knowing the binding between
those two addresses.
Which ways to you see around this?

  Erik