Subject: RE: [mobile-ip] RE: Is RR only enough ?

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 10 Jan 2002 15:15:00 +0100

So this is an attempt to summarise where we are 
in the discussion. 

I have made 2 claims as to why this attack is different 
from today's MITM attacks and to show that RR only 
would not be enough. These two claims are:

1. The attacker does not have to be a router/switch
but can be an end host snooping the link layer. 
You mentioned that the difference here is subtle because
an attacker can overwrite the ARP cache of a router 
today, and receive all the packets addressed to a legitimate
router. 
I agree that the difference here is very subtle, and unless
someone can show that this is significantly different I
am inclined to think that this can go in the same container
as 'today's MITM attacks' and therefore would add no new harm.

2. The attack can be done despite the presence of e2e security.
E2E security (encryption)can be used today to stop these 
attacks. (I'm excluding DoS-based attacks).

Now I think this point is still valid for RR only mechanisms,
and I'll try to explain why below in my comments.

  > > => Sure, but it was suggested that TLS or other upper
  > > layer security mechanisms can be used to avoid 
  > > these types of attacks today. I don't think they 
  > > would help avoid this attack using the BU. 
  > 
  > By "these attacks" do you mean the DoS impact of the attacks or the
  > an attack that can modify the content of the communication?

=> I meant the latter (modifying the content).

  > The DoS attack by a MiTM can never be prevented.

=> Agreed.

  > The modification of content can be prevented with TLS, IPsec, etc.

=> Agreed. But the connection hijacking which is what I 
was concerned about, will not be prevented by TLS..etc
if RR only is used for the BU. More below.

  > > Also, I agree with what you say about security
  > > "Done right", implying the identity exchange between
  > > the two parties, but perhaps we should document
  > > somewhere (in the ultimate solution) that this will
  > > override any other security mechanism for BUs. 
  > > I.e. if there is "proper" SAs already established, 
  > > they should be sufficient for the MN to send 
  > > a BU without the need to run any other mechanism. 
  > 
  > You're skipping a few steps.
  > 
  > If you want to use an existing SA (IPsec, SSL, whatever) to 
  > protect BUs
  > the identities associated with the SA needs to be quite different
  > than what you'd get for other use of security.
  > E.g. when using SSL to a website you'd like to know that 
  > the identity
  > is www.example.com; when sending secure email to me you'd like the
  > identity to be [email-masked], but for a BU the 
  > identity you'd need
  > is the home IP address.

=> Fully agree. I know this contradicts my earlier (inaccurately
generalising statement).

  > 
  > Using security associated with one type of identity for 
  > something else
  > isn't likely to get the security you'd expect.

=> Makes sense.

  > 
  > Thus my personal opinion is that we should make the BU 
  > security be independent
  > of other (content-oriented) security. Thus if folks want to 
  > use IPsec or SSL
  > you'd still use the same BU security mechanism.

=> We're in agreement here. But my point is that, should
this BU security mechanism be RR only, MITM can 
hijack a connection and receive the content that was
intended for the legitimate MN. The will happen, despite
the presence of e2e security (SSL, TLS, IPsec ...etc) which
äwas setup based on the relevant identity. 
Now this is the major difference from today's networks. 
We agree (I think) that e2e security would stop 
connection hijacking (by MITM) today, but it will
not stop it if we rely on RR only for BU authentication /
authorisation. 

  > > => So the difference is that the BU attacker
  > > will not have to modify anything, which makes 
  > > him more dangerous if:
  > > 
  > > 1. upper layer security is used (not IPsec)
  > > 2. If IPsec is used but the CN still accepts
  > >    RR for BU. (strange situation that we should 
  > >    not allow of course).
  > > 
  > > I agree with the ARP case, However, ND has the potential
  > > of being secure, but even if it was secured (somehow
  > > keys are distributed), this problem would still exist. 
  > 
  > ND has the potential to be secure because of the IPsec pixie dust
  > in the security considerations section??? (Yes, I've 
  > learned some things
  > since that document became a draft standard without anybody 
  > having implemented
  > ND secured by IPsec.)

=> I guess it's a key distribution problem (not exactly
a small problem :)) but I always assume that between
routers (or in a small network) shared secrets maybe 
sufficient. But that is not a generic, scalable solution
of course. 

Cheers,
Hesham

---

From: Durga Prasad Pandey <[email-masked]>
Date: Thu, 10 Jan 2002 06:27:26 -0800 (PST)

Hesham
from the discussions of this WG, it seems that the
main discussions on M IP nowadays is regarding
security issues.
I am considering an UG research project in mobile IP.
Might this(security issues in mobile IP) be a good
area in your opinion.

Regards
Durga

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/