Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT)

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 2 Nov 2006 06:22:04 -0800

> RR check can be one solution, but as other people pointed out, this  
 > causes additional round trip.
 > In addition, if there is no NAT, we can simply protect CoA by ACoA  
 > option.

=> This is not the issue being raised, the issue is the insecurity of
the IPv4 header when a NAT exists. The outer header is obviously
unprotected and vulnerable to redirection attacks (an attacker acting as
a NAT bascially). I don't think we need to solve that problem as I
indicated in a previous email.

Hesham

 > If HA detects that the CoA is different between IPv4 header 
 > and ACoA,  
 > it can operate your RR check.
 > Otherwise, it should be skipped.
 > A new message BA-ack may be sufficient. i.e. An 
 > acknowledgment of BA  
 > sent back from  MN.
 > 
 > ryuji
 > 
 > On 2006/11/02, at 4:08, Narayanan, Vidya wrote:
 > 
 > >
 > > All,
 > > This is something I should've raised yesterday when I read all the
 > > emails, but after sleeping over it and some other 
 > discussions, I'm  
 > > still
 > > confused - so, figured I should raise it now :)
 > >
 > > First, I don't believe that an AltCoA option (v4 or v6) 
 > buys anything.
 > > Let's look at this.
 > >
 > > In IPv4, the outer IP address is always up for 
 > modifications and there
 > > is no way to distinguish an adversary modifying it from a NAT  
 > > modifying
 > > it. And, if the outer IPv4 source address is different from the  
 > > inner IP
 > > address, there is no way for the HA to figure out whether the
 > > modification is due to a NAT or an adversary. Such is the 
 > truth with
 > > NATs and there is nothing that can be done about it. Even 
 > if the outer
 > > and inner IP addresses are the same, there is no way to 
 > figure out  
 > > that
 > > they are the same because there is no NAT or because a NAT-ed IP  
 > > address
 > > in the outer header has been modified back to equal the inner IP  
 > > address
 > > by an adversary. This is quite feasible, especially when the inner
 > > packet is not encrypted and totally depends on the intention of the
 > > attacker.
 > >
 > > The presence of the Alt-CoA option buys nothing exactly 
 > for the same
 > > reasons. The fact that the Alt-CoA option is integrity 
 > protected means
 > > nothing, since the HA still must use the outer IP address 
 > as the CoA -
 > > and there is no guarantee about that being intact.
 > >
 > > We cannot pick and choose what attacks we like and what we don't.  
 > > Either
 > > we protect against redirection attacks or we don't. At 
 > this point, I'm
 > > saying that integrity protection of the actual CoA alone proves  
 > > nothing.
 > > Reachability checks have more value than integrity 
 > protection of a  
 > > field
 > > that is allowed to be modified. Reachability checks too, in the  
 > > absence
 > > of confidentiality on the inner packet, does not guarantee that an
 > > attacker is not on the path - but, it at least proves that 
 > the MN is
 > > reachable at that address.
 > >
 > > So, my vote would be to perform an optional reachability check and
 > > document the vulnerability that may still exist.
 > >
 > > Vidya
 > >
 > > _______________________________________________
 > > Mip6 mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/mip6
 > 
 > 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 02 Nov 2006 15:58:15 +0100

Soliman, Hesham wrote:
>>  causes additional round trip. In addition, if there is no NAT, we 
>> can simply protect CoA by ACoA option.
> 
> unprotected and vulnerable to redirection attacks (an attacker acting
>  as a NAT bascially).

IKE has features for NAT traversal.  Can that disturb DS-MIPv6'
and MIP4 NAT Traversal?

> I don't think we need to solve that problem as I indicated in a
> previous email.

Keeping the spec simpler - I'm in favor.

Alex

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 3 Nov 2006 00:09:09 +0900

Hi Hesham

Yes, I agree.
I don't want to have RR for MIP6TRANS, but
if somebody wants, please do not make this mandatory.
That's my intention:-)

regards
ryuji