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

From: Soliman Hesham <[email-masked]>
Date: Mon, 16 Feb 2004 05:36:12 -0500

>  In your previous mail you wrote:
 > 
 >    In reading Francis' draft on bombing I came across the following
 >    statement:
 >    
 >        As the return
 >        routability is not considered by many people as very safe or
 >        efficient, some new ways to
 >    
 >    I agree about the efficiency part*.
 >    
 >    But I'm wondering if you have any specific worries about the
 >    safety part. I mean beyond issues that already exist in plain
 >    IPv4 and IPv6, such as MitMs being able to do bad things.
 >    
 > => the RR of Mobile IPv6 has all packets in clear somewhere 
 > in the Internet.
 > IMHO the real issue is the RR assumptions are a bit weak, so 
 > it is not
 > a surprise that with stronger assumptions (strong 
 > authentication available
 > for instance) we can get safer mechanisms. 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...

Hesham

 > 
 > Regards
 > 
 > [email-masked]
 > 
 > PS: we can poll the WG to see whether many people consider 
 > that RR is not very
 > safe if you'd like (:-).
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/mip6
 > 

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Feb 2004 12:11:24 +0100

In your previous mail you wrote:

    > To be short do you agree that

=> the answer is very simple: IPR.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 22:43:12 +0200

Thanks for the responses! Let me explain a little bit why
initiated this thread.

I was not asking for the known limits of RR. We all remember them
pretty well. The most typical case is being on the path between
the home agent and the correspondent node; if you are there, you
don't even need to eavesdrop any of the messages as you can just
initiate the procedure by yourself.

The discussion on specific stronger methods is interesting --
and we should continue that discussion. We know for a fact that
there are stronger methods. At least HIP and CGA can do better;
it will be interesting to figure out if there are more. There is
also probably methods that are equally secure but better in some
other respect, such as efficiency. And methods methods that are
less secure but even better again in some other way so that the
end result makes sense. And then there are methods that are just
no good at all ;-)

Now we are getting nearer to what originally intended to ask.
A year... two ago we held a BoF on alternate RO security mechanisms.
If I remember correctly, most people said that their primary goal
was not to increase the security of RR, but to improve its effiency.
Does this still hold, or do people feel that they also need to
address the security aspects? Tentative answer: it seems that
optimization is still the main issue, but there is also interest
for improved security?

I also wanted to ask whether there was some specific new vulnerability
that I had not heard. Apparently, this is not the case, if I
understood the replies correctly?

Finally a suggestion for the folks who responded that there are some
security issues that they care about. Would you consider writing
them in a draft or paper somewhere, preferrably comparing the issues
with existing issues that mitms on the path can cause? We do have
the old design papers, but they basically concluded that the issues
are nearly identical. If people feel/know differently now, this would
be good to get documented someplace. Any takers?

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Feb 2004 09:27:31 -0800

> I wonder why we don't extend RR with CGAs and save ourselves

Same issue as originally: IPR. 

Unfortunately, the release for SEND only applies to ND.

            jak