Subject: RE: [Mip6] use of IPsec

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 5 May 2004 09:06:32 -0400

Francis, please use an appropriate subject.

Comment inline.

 > Description of issue : Strong disagreement vs 3.5 introduction
 > Submitter name: Francis Dupont
 > Submitter email address: [email-masked]
 > Date first submitted: 2004/05/05
 > Reference: 
 > Document: draft-ietf-mip6-ro-sec-00.txt
 > Comment type: T
 > Priority: S
 > Section: 3.5
 > Rationale/Explanation of issue: 
 >  I strongly disagree with the first paragraph of 3.5.
 > Length description of problem :
 >  The current text is:
 >    Early in the MIPv6 design process it was assumed that plain IPsec
 >    could be used for securing Binding Updates. However, this 
 > turned out
 >    to be impossible for two reasons. The first reason can be inferred
 >    from the attack descriptions above: IPsec is not designed 
 > to protect
 >    against the kinds of DoS attacks that would be possible 
 > with MIPv6.
 >    Protecting against the flooding attacks would be very difficult or
 >    even impossible with plain vanilla IPsec. The second reason is
 >    scalability.
 > 
 >  I have three points:
 >   - I agree with the last statement (scalability) only.
 >   - the word "could" in the first statement should be 
 > improved because
 >     it may be interpreted as IPsec can't be used to protect BUs when
 >     in fact the idea is that IPsec can't be the 
 > default/required mechanism.
 >   - the first reason is completely wrong IMHO. One can argue 
 > that IPsec
 >     has its own DoS issues but this is not what I can read 
 > here. Do authors
 >     really believe that the strong mutual authentication 
 > required/used by
 >     IPsec is weaker than return routability check?
 > 
 > Requested change: 
 >  Reword the first statement and remove the "first reason" (the second
 >  should be enough, and was).

=> I completely agree with Francis here. The only real
reason is scalability/reliability on global PKI. If global PKI 
existed of course IPsec would have been a possible way
to go for the default mechanism...

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

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

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 7 May 2004 00:42:15 -0400

> >Obviously I don't have any data to support the attack. OTOH,
 > >other types of attacks (e.g. MITM) can also be a bit fictitiuos
 > >IMO if the MITM is not on the MN or CN links. So while we don't
 > >have data that attacks like this already happen, it's hard to
 > >dismiss the requirement.
 > >  
 > >
 > But if I compare this with, say, the other trivial attacks 
 > in the news
 > recently, it does look pretty esoteric.

=> Agreed. When  it comes to what we're experiencing
today, the biggest problems seem to be viruses communicated
over poor email clients, and worms.

 > 
 > Furthermore, I am not at all claiming that we should just 
 > forget about
 > such attacks.  I am claiming that these attacks do not and did not
 > provide sufficient justification for the subject of 
 > discussion, which was
 > why IPsec was originally proclaimed insufficient to secure 
 > the original
 > format of the Binding Update.  To me it looked like piling on for who
 > knows what purpose.

=> I also don't claim that this is the reason for dropping
IPsec, this type of attack is a reason for the requirement
of authorisation for both CoA and HoA. The strongest
reason for not using IPsec as a default mechanism, IMO,
is scalability.

 > I thought we were talking about the case where a mobile node 
 > maliciously
 > claims ownership of a care-of address belonging to another node (the 
 > victim),
 > ==> the home address belongs to the mobile node, the care-of address 
 > does not.
 > What is the attack where the home address belongs to the victim?

=> Ok, in this case, it is traceable but it's probably
not realistic for any random server on the Internet
to be expected to trace it. However, I was thinking of
the reverse case where a node steals another MN's home 
address. and use it to bomb the MN that owns this address. 
Unfortunately this is still doable with RR if the attacker
is on the CN-HA path. 

Hesham

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 7 May 2004 00:44:27 -0400

hi Charlie,

 > to be expected to trace it. 

=> Please ignore everything below this, not enough coffee
for me obviously!

Hesham

However, I was thinking of