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 11:50:23 -0800

> > => 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. 

=> Yes I read all emails about the draft. The point is, we're making the
v6 packet as secure as MIPv6. Now, the receiver (HA/MAP) can use the
fact that the v6 packet is secure for their advantage. For instance, if
the receiver *knows* that no NATs exist, then it can trust the v6
information. If it doesn't then it won't be able to do that.
So I see no harm in keeping the v6 packet secure, it can only be a
benefit/requirement.   Why should we not secure the v6 packet?

Hesham

 > 
 > Vidya
 > 
 > 
 > > 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 14:26:21 -0800

> From: Soliman, Hesham 
> Sent: Monday, November 06, 2006 11:50 AM
> To: Narayanan, Vidya; 'Pascal Thubert (pthubert)'; 'RYUJI WAKIKAWA'
> Cc: 'Vijay Devarapalli'; [email-masked]'
> Subject: RE: What are we protecting over IPv4 in DS-MIP6? 
> (RE: [Mip6] concensus: issue 76: Alt CoA should not be 
> usedwhen traversingIPv4 NAT)
> 
> 
> > > 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. 
> 
> => Yes I read all emails about the draft. The point is, we're 
> making the v6 packet as secure as MIPv6. 

In fact, no. In MIP6, it is truly secure, because when the Alt-CoA
option is present, that is always used as the CoA by the HA. In this
case, the HA has no choice but to use the outer IP address as the CoA -
if it is different from the inner CoA, it thinks there is a NAT; if it
is not different, it doesn't make a difference. But, the HA can never be
able to tell exactly what the case was. So, it is the outer IP address
the HA uses, period. 

So, protection of the inner IP address buys nothing, as far as I can
see. 

> Now, the receiver 
> (HA/MAP) can use the fact that the v6 packet is secure for 
> their advantage. For instance, if the receiver *knows* that 
> no NATs exist, then it can trust the v6 information. 

What do you mean that the receiver *knows* that no NATs exist? You mean,
administratively (via configuration or what not) knows that? If so,
first, I'd ask how practical is that? Second, the HA behavior would then
be different based on whether or not the HA knows this via
configuration? 

> If it 
> doesn't then it won't be able to do that.
> So I see no harm in keeping the v6 packet secure, it can only 
> be a benefit/requirement.   Why should we not secure the v6 packet?
> 

Let's answer the above questions and then talk about this. I want to
understand what scenario you have in mind first. 

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.
>  > > 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. 
>  > > 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.
>  > >  > >  >
> > > 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  >  > > 
>  > >  > >  > concensus: issue 76: Alt CoA  > >  > >  > 
> >should not be usedwhen traversingIPv4 NAT)  > >  >  > > >Hi  
> > > Ryuji,  > >I think this is missing the threat model. 
>  > >  > >  > >1. MN --- (Attacker) --- HA  > >  > >  > >  > > 
>  > >  > >  > >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.
>  > >  > >  > >
>  > > 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;  > > 
>  > > 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  >  > > >>  > > acknowledgment of BA sent back from  MN.
>  > >  > >  > >>
>  > >  > >  > >> ryuji
>  > >  > >  > >>
>  > >  > >  > >> > 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
>  > >  > > 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
>  > >  > >  > >> >