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: Mon, 6 Nov 2006 10:59:36 -0800

> > There were two issues discussed:
 > > 
 > > A. Integrity of the CoA in the IPv6 packet
 > 
 > What is this buying you, when the HA must be using the outer 
 > one anyway? 

=> Well, DSMIP is not limited to be used when NATs are available. It can
be used in public IPv4 networks where no NATs exist, or where no NAT
exist between the MN and an HA in the same domain. So, what this buys is
the same security as MIPv6 when no NATs exist. 

Hesham

 > 
 > Vidya
 > 
 > 
 > > 
 > > B. Integrity of the IPv4 header. 
 > > 
 > > Option 2) below is intended for A) above and option 3) was 
 > > discussed to address B. I hope it's clear that the options 
 > > you list below are not alternatives as they address different 
 > > problems.
 > > 
 > > Hesham
 > > 
 > > 
 > >  > I'm with you on that. 
 > >  >
 > >  > The options we have are so far:
 > >  >
 > >  > 1) do nothing. If the MN roams in IPv4, the source is not 
 > > protected.
 > >  > There is a potential of an attack, but that is a difficult 
 > > one, in an  > IPv4 world where so many other attacks are 
 > > possible anyway.
 > >  >
 > >  > 2) provide the source IPv4 address one way or another. 
 > > This approach  > includes Hesham's checksum. This seems to 
 > > provide an IPv6 equivalent  > security in the absence of NAT. 
 > > I'd argue that it does not really,  > because it is still the 
 > > IPv4 world, and with IPv4 it much  > easier to fool  > a 
 > > visiting MN into using, as CoA, an address that belongs to  > 
 > > an attacked  > server. 
 > >  >
 > >  > 3) propose an optional RR test. The test verifies that the 
 > > MN is  > reachable at the CoA, so it protects even against 
 > > NAT and  > rogue router  > in the visited network. 
 > >  >
 > >  > I think we have to consider the whole picture, thus I 
 > > favor  > 3. I could  > do with 1, and then we'd propose the 
 > > optional RR test as a separate  > draft, which would be valid 
 > > for all declinations of MIP6,  > should the WG  > decide that 
 > > the RR test is not specific to this draft.
 > >  >
 > >  > I have trouble with 2. People who do not really understand 
 > >  > what it does  > might get a false sense of security, which 
 > > can be even more  > dangerous.
 > >  > Once this option is in, it will be hard to take it out, 
 > > even  > when the RR  > test is available and actually 
 > > provides a better security.
 > >  >
 > >  > Pascal
 > >  >
 > >  >
 > >  >
 > >  >
 > >  > >-----Original Message-----
 > >  > >From: Narayanan, Vidya [mailto:[email-masked]]  > 
 > > >Sent: Friday, November 03, 2006 5:00 PM  > >To: RYUJI 
 > > WAKIKAWA  > >Cc: Vijay Devarapalli; [email-masked]; Pascal 
 > > Thubert (pthubert);  > Soliman, Hesham  > >Subject: RE: What 
 > > are we protecting over IPv4 in DS-MIP6? 
 > >  > (RE: [Mip6]
 > >  > concensus: issue 76: Alt CoA
 > >  > >should not be usedwhen traversingIPv4 NAT)  > >  > >Hi 
 > > Ryuji,  > >I think this is missing the threat model. Let's 
 > > look at two possible  > >scenarios.
 > >  > >
 > >  > >1. MN --- (Attacker) --- HA
 > >  > >
 > >  > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA  > > 
 > >  > >( ) indicates that an attacker may be present.
 > >  > >
 > >  > >If the HA received a BU with the inner and outer 
 > > addresses  > the same, it  > >has no way of telling it was 
 > > due to case 1 with no attacker  > or case 2  > >with Attacker 
 > > 2 who changed a NAT'ed outer address back to equal the  > 
 > > >inner address.
 > >  > >
 > >  > >So, there is no use in saying that the check is done when 
 > > the HA  > detects  > >a NAT.
 > >  > >
 > >  > >But, we can document this issue and say that we don't  > 
 > > protect against  > >on-path attackers in IPv4, because it is 
 > > complicated and  > not worth it.
 > >  > I
 > >  > >guess that's what Vijay and Hesham are saying - I could 
 > > be  > convinced of  > >that, although, I don't see why we 
 > > can't make the RR  > optional and leave  > >it at that.
 > >  > >
 > >  > >Vidya
 > >  > >
 > >  > >
 > >  > >> -----Original Message-----
 > >  > >> From: RYUJI WAKIKAWA [mailto:[email-masked]]  
 > > > >> Sent: Thursday, November 02, 2006 6:07 AM  > >> To: 
 > > Narayanan, Vidya  > >> Cc: Vijay Devarapalli; [email-masked]; 
 > > Pascal Thubert  > >> (pthubert); Soliman, Hesham  > >> 
 > > Subject: Re: What are we protecting over IPv4 in DS-MIP6?
 > >  > >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be  
 > > > >> usedwhen traversingIPv4 NAT)  > >>  > >> Hi Vidya  > >>  
 > > > >> 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.
 > >  > >> 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: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 6 Nov 2006 11:31:26 -0800

>  > > A. Integrity of the CoA in the IPv6 packet  >  > What is 
> this buying you, when the HA must be using the outer  > one anyway? 
> 
> => Well, DSMIP is not limited to be used when NATs are 
> available. It can be used in public IPv4 networks where no 
> NATs exist, or where no NAT exist between the MN and an HA in 
> the same domain. So, what this buys is the same security as 
> MIPv6 when no NATs exist. 
> 

No, it doesn't, since there is no way to figure out whether there were
NATs + an attacker or just NATs or no NATs. Please see my response to
Ryuji where I explained this with an illustration. 

Vidya

>  > > Option 2) below is intended for A) above and option 3) 
> was  > > discussed to address B. I hope it's clear that the 
> options  > > you list below are not alternatives as they 
> address different  > > problems.
>  > >
>  > > Hesham
>  > >
>  > >
>  > >  > I'm with you on that. 
>  > >  >
>  > >  > 1) do nothing. If the MN roams in IPv4, the source is 
> not  > > protected.
>  > >  > There is a potential of an attack, but that is a 
> difficult  > > one, in an  > IPv4 world where so many other 
> attacks are  > > possible anyway.
>  > >  >
>  > > This approach  > includes Hesham's checksum. This seems 
> to  > > provide an IPv6 equivalent  > security in the absence of NAT. 
>  > > I'd argue that it does not really,  > because it is 
> still the  > > IPv4 world, and with IPv4 it much  > easier to 
> fool  > a  > > visiting MN into using, as CoA, an address 
> that belongs to  >  > > an attacked  > server. 
>  > >  >
>  > >  > 3) propose an optional RR test. The test verifies 
> that the  > > MN is  > reachable at the CoA, so it protects 
> even against  > > NAT and  > rogue router  > in the visited network. 
>  > >  >
>  > > favor  > 3. I could  > do with 1, and then we'd propose 
> the  > > optional RR test as a separate  > draft, which would 
> be valid  > > for all declinations of MIP6,  > should the WG  
> > decide that  > > the RR test is not specific to this draft.
>  > >  >
>  > >  > I have trouble with 2. People who do not really 
> understand  > >  > what it does  > might get a false sense of 
> security, which  > > can be even more  > dangerous.
>  > >  > Once this option is in, it will be hard to take it 
> out,  > > even  > when the RR  > test is available and 
> actually  > > provides a better security.
>  > >  >
>  > >  > Pascal
>  > >  >
>  > >  >
>  > >  >
>  > >  >
>  > >  > >From: Narayanan, Vidya [mailto:[email-masked]]  
>  > > WAKIKAWA  > >Cc: Vijay Devarapalli; [email-masked]; 
> Pascal  > > Thubert (pthubert);  > Soliman, Hesham  > 
> >Subject: RE: What  > > are we protecting over IPv4 in DS-MIP6? 
>  > >  > (RE: [Mip6]
>  > >  > >should not be usedwhen traversingIPv4 NAT)  > >  > 
> >Hi  > > Ryuji,  > >I think this is missing the threat model. 
> Let's  > > look at two possible  > >scenarios.
>  > >  > >
>  > >  > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA 
>  > >  > >If the HA received a BU with the inner and outer  > 
> > > due to case 1 with no attacker  > or case 2  > >with 
> Attacker  > > 2 who changed a NAT'ed outer address back to 
> equal the  >  > > >inner address.
>  > >  > >
>  > >  > >So, there is no use in saying that the check is done 
> when  > > the HA  > detects  > >a NAT.
>  > >  > >
>  > >  > >But, we can document this issue and say that we 
> don't  >  > > protect against  > >on-path attackers in IPv4, 
> because it is  > > complicated and  > not worth it.
>  > >  > I
>  > >  > >guess that's what Vijay and Hesham are saying - I 
> could  > > be  > convinced of  > >that, although, I don't see 
> why we  > > can't make the RR  > optional and leave  > >it at that.
>  > >  > >
>  > >  > >Vidya
>  > >  > >
>  > >  > >
>  > >  > >> From: RYUJI WAKIKAWA 
> [mailto:[email-masked]]  > > > >> Sent: Thursday, 
> November 02, 2006 6:07 AM  > >> To: 
>  > > Narayanan, Vidya  > >> Cc: Vijay Devarapalli; 
> [email-masked];  > > Pascal Thubert  > >> (pthubert); Soliman, 
> Hesham  > >>  > > Subject: Re: What are we protecting over 
> IPv4 in DS-MIP6?
>  > >  > >> (RE: [Mip6] concensus: issue 76: Alt CoA should 
> not be  > > > >> usedwhen traversingIPv4 NAT)  > >>  > >> Hi 
> Vidya  > >>  > > > >> 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.
>  > >  > >> If HA detects that the CoA is different between 
> IPv4  > > header  > >> and ACoA, it can operate your RR check.
>  > >  > >> A new message BA-ack may be sufficient. i.e. An  > 
>  > >  > >> > 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.
>  > >  > >> >
> > > 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
>  > >  > >> > Reachability checks have more value than 
> integrity  >  > > protection of a  > >> > field that is 
> allowed to be modified. 
>  > > 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.
>  > >  > >> >