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

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 21 Dec 2001 13:25:39 -0600

Charlie,

I think I may not have made myself clear on some of the points. I'll try to
rephrase them either via contributions or in a later posting.  

Happy Holidays to all,

Glenn

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Friday, December 21, 2001 12:11 PM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] list of things for MIPv6
> 
> 
> Hello Glenn,
> 
> Glenn Morrow wrote:
> 
> > 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.
> 
> 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.
> 
> >> 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.
> 
> 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.
> 
> 
> >> 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.
> 
> 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;
> > therefore other SDOs can claim that because of this, they 
> are not conformant
> > with MIPv6 route optimization.
> 
> 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.
> 
> > 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.
> 
> 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.
>