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: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 2 Nov 2006 13:35:24 +0100

Hi Vidya

Even with MIP6, as long as SeND is not deployed throughout, a visitor
can always be fooled by a rogue visited network into forming an address
from a victim network's prefix, thus the MN would unknowingly register
an address that is not there and causing DoS against the victim's access
network. Thus the discussions about an RR test for the HA.

IPv4 makes it somewhat worse since the rogue can be a mobile DHCP server
assigning the MN a victim's address over a public wlan, thus enabling
DoS against that specific address; and there's no SeND; and of course,
there's the NAT issue for which we drop the alt CoA shield.

So the issue exists at different degrees in all protocols. Thus I'm with
you on the conclusion to propose an optional reachability check. Whether
to add that proposal in MIPTRANS or as a separate draft can be debated. 

Please have a look at the proposal I made at the end of the consensus
thread.
	
Pascal

>-----Original Message-----
>From: Narayanan, Vidya [mailto:[email-masked]]
>Sent: Wednesday, November 01, 2006 8:09 PM
>To: Vijay Devarapalli
>Cc: Soliman, Hesham; [email-masked]; Pascal Thubert (pthubert)
>Subject: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]
concensus: issue 76: Alt CoA should
>not be usedwhen traversingIPv4 NAT)
>
>
>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

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 8 Nov 2006 11:52:54 +0100

Hi Hesham:

To be honest I do not mind which integrity 2) tests because to my best
knowledge, it is only useful when the source IPv4 address matches the
mapped one in the Ipv6 CoA. If that's so and you could test either
address, you're done, aren't you?

But that's not the issue because integrity is not the final goal. The
final goal is to prove that the MN is reachable at the CoA, because at
the end of the day, the protocol is about binding an identity (the HoA)
with the location where it can be reached (the CoA).

The integrity check of the CoA verifies that the (TRUSTED) MN (BELIEVES
THAT IT) owns that address, so it is an only indirect proof of
reachability, based on other assumptions which are difficult to assert
for sure (trust and belief).

I agree that the Internet in between will not change in a day, and that
we can not prevent a MITM attack from destroying some or all packets
between MN and HA, just the way one can not prevent a good willing
public access to provide too little bandwidth for instance. 

Yet IPSec coupled with RR test verifies the integrity of the data and
actually proves the validity of the end points, making the Internet a
safer place to roam.

Pascal

>From: Soliman, Hesham [mailto:[email-masked]]
>Sent: Monday, November 06, 2006 6:55 PM
>To: Pascal Thubert (pthubert); Narayanan, Vidya; 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)
>
>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
> >
> >
> >
> >
> > >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
> > >
> > >
> > >> 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,
> > >> > still confused - so, figured I should raise it now :)
> > >> >
> > >> > 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.
> > >> >
> > >> > 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.
> > >> >