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: Mon, 6 Nov 2006 12:14:12 +0100

Hi Vidya

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:08 -0800

I agree on all the points. I'm not sure if we need to do RR in a
separate draft essentially though... But, if we decide to live with 1,
that is a moot point. 

Vidya 

> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 3:14 AM
> To: Narayanan, Vidya; RYUJI WAKIKAWA
> Cc: Vijay Devarapalli; [email-masked]; Soliman, Hesham
> Subject: RE: What are we protecting over IPv4 in DS-MIP6? 
> 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 
> 
> 
> 
> 
> >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen 
> >> traversingIPv4 NAT)
> >>
> >> Hi Vidya
> >>
> >> 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.