Subject: RE: [Mip6] Re: rr weaknesses?

From: Soliman Hesham <[email-masked]>
Date: Mon, 16 Feb 2004 06:23:02 -0500

>     > To be short do you agree that
 >     > HIP is safer than current Mobile IPv6 RR?
 >    
 >    => We don't even need to go that far, CGAs were safer!!
 >    I wonder why we don't extend RR with CGAs and save ourselves
 >    all this trouble...
 >    
 > => the answer is very simple: IPR.

=> Ok, but please consider the following:
- It was good enough for SEND. There is no reason (at least 
  in theory) that we can't try to get the same statements
  as SEND.
- We don't know that other proposals (including ones being
  discussed now) are IPR-free.

Hesham

 > 
 > [email-masked]
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Soliman Hesham <[email-masked]>
Date: Mon, 16 Feb 2004 20:29:35 -0500

> >
 > > => Wow :)  I've seen a few papers, I'll try to find them and
 > > send them to you offline. In many cases each paper only
 > > addresses one part of the delay, unfortunately. But let me
 > > clarify what I was saying. I think that RR is not efficient for
 > > frequently moving MNs. This immediately excludes
 > >
 > 
 > It would be good to consolidate the current understanding on
 > this topic. Could you post a pointer the references ? It would be
 > useful for Mobopts as well.

=> ok, I'll go through what I have.

 > 
 > One could also look at the effect of RR, alongside its frequency,
 > on applications. I hope someone will simulate various scenarios!
 > 
 > 
 > > the 802.11 family from this discussion because, lets face it,
 > > how often are you going to handover with 802.11? I'm thinking
 > >
 > 
 > In some cases (e.g., campus WLAN networks), it could be as
 > often as when someone leaves a building for another!

=> Yes but I'm not counting the number of handovers for 
all devices. I'm counting the frequency of handovers for one
device.

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 17 Feb 2004 07:18:02 -0500

> Then we have a couple of interesting cases regarding the
 > use of e2e security. When that is in place, be it RR/CGA/HIP,
 > attackers can at most cause denial of service, not more.

 > With IPsec e2e, presumably the RR signaling would be protected
 > as well => no attack. 

=> Not sure about this statement, when you say e2e you mean
MN - CN, right? In this case the RR signalling _may_ be protected
if all traffic is protected. But if the protection does not 
cover all traffic then of course the CN - HA path will still
be vulnerable even if the connections between the MN and CN 
are covered with IPsec. Of course RR + CGA is not vulnerable
to that.

   With TLS e2e, RR would still be vulnerable,

=> Yes. 

 > but as mentioned above the effect would be at most denial-of-service.
 > TLS, however, is denial-of-service vulnerable in any case.

=> Yes it's a DoS attack on IPsec/TLS protected traffic. 
But it's still another (new) DoS attack.

 > In conclusion, I'd still like you or someone to write that
 > paper that describes the issues and compares them to the
 > issues with existing issues that mitms on the path can
 > cause. I mean its easy for us to make short comments on
 > the mailing list, but I think this matter is so important
 > that it needs to be described well. And be reviewed!

=> I remember the DT wrote a long analysis on residual
threat of RR. That might be a good start. I still have 
the text file you got rid of it ;)

 > Don't get me wrong. I want to create new route optimization
 > security mechanisms that are better than RR. But I just think
 > there is a big difference in "nice to have" vs. "must have
 > because of serious problems". Clearly we have seen and will
 > see folks who claim the latter to market their method; it
 > would be extremely useful to understand where we are in
 > reality, however.

=> I don't have a strong opinion on needing a new 
mechanism. I just think that it's cautious to have 
a more secure option in case we missed something 
or some attacks became worse than we expected. If that
happens in future we might not have the time to standardise
one immediately (IETF is not getting any faster!). 
But I know this is a very paranoid argument that might 
not find much support.

Hesham

---

From: [email-masked]
Date: Tue, 17 Feb 2004 06:29:16 -0600

> But I know this is a very paranoid argument that might 

I think this thread is based on paranoia. I think the MIPv6
design team ignored the threats and security issues with RR
when this was work was done over a year ago. We seem to be
revisiting the same issues. The security issues that are being
discussed now are not new. These have been considered.

More secure means of accomplishing RO should be considered in
the WG for MIP6. But I would argue against dismissing RR as
being insufficient at this time. 

> Hesham

-Raj