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 09:55:02 -0800

Hi Pascal,  

The options you list below are mixing two different problems together. 

There were two issues discussed:

A. Integrity of the CoA in the IPv6 packet

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 10:35:39 -0800

> From: Soliman, Hesham 
> Sent: Monday, November 06, 2006 9:55 AM
> To: Pascal Thubert (pthubert); Narayanan, Vidya; RYUJI WAKIKAWA
> Cc: Vijay Devarapalli; [email-masked]

What is this buying you, when the HA must be using the outer one anyway?

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. 
>  >
>  > 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.
>  >
>  > 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]]  > 
> >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]
>  > >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 
> 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
>  > >
>  > >
> > >> Sent: Thursday, November 02, 2006 6:07 AM  > >> To: 
> Narayanan, Vidya  > >> Cc: Vijay Devarapalli; [email-masked]; 
> Pascal Thubert  > >> (pthubert); Soliman, Hesham  > >> 
> > >> 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  > >> 
>  > 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  > >> > 
>  > >> > 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  > 
> > >> 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
>  > >> >