Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 2 Nov 2006 17:57:14 +0100

Hi Ryuji:

I agree on your intention. This should be an option. We need to be able
to disable the feature completely, and maybe (TBD) we can work out a
solution that enables a HA or a MN to stay compatible even if one of the
2 does not support the feature.

If it can be lightweight and still provide the service of giving MIP6
equivalent security then I believe we should provide a reachability
test, because MIPTRANS inherit from MIP6 and thus come with a MIP6
equivalent level of expectation (in that I slightly disagree with
Hesham). 

It is very true, as you point out, that the 3 way handshake adds to the
latency. It is also true that is many case, roaming in IPv4 will be much
slower than in IPv6, so maybe the added latency is relatively small and
thus affordable.

There's also the issue of the added complexity to the protocol and the
deployment. We need to come up with a simple increment to the protocol,
and propose workable default behavior. I believe that the double BU
proposal achieves all this with a default configuration to do the 3 way
handshake automatically whenever the alt CoA is missing.
	
Is that already too much?

Pascal

>-----Original Message-----
>From: RYUJI WAKIKAWA [mailto:[email-masked]]
>Sent: Thursday, November 02, 2006 4:09 PM
>To: Soliman, Hesham
>Cc: [email-masked]; Pascal Thubert (pthubert)
>Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE:
[Mip6]concensus: issue 76: Alt CoA
>should not beusedwhen traversingIPv4 NAT)
>
>Hi Hesham
>
>Yes, I agree.
>I don't want to have RR for MIP6TRANS, but
>if somebody wants, please do not make this mandatory.
>That's my intention:-)
>
>regards
>ryuji
>
>
>On 2006/11/02, at 23:22, Soliman, Hesham wrote:
>
>>
>>> 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.
>>
>> => This is not the issue being raised, the issue is the insecurity of
>> the IPv4 header when a NAT exists. The outer header is obviously
>> unprotected and vulnerable to redirection attacks (an attacker
>> acting as
>> a NAT bascially). I don't think we need to solve that problem as I
>> indicated in a previous email.
>>
>> Hesham
>>
>>
>>
>>> 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

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 2 Nov 2006 17:57:14 +0100

Hi Ryuji:

	

Pascal

---

From: "Zhang, Qiang [NTK]" <[email-masked]>
Date: Fri, 3 Nov 2006 07:55:12 -0600

Hesham, 

I would agree the MITM attack will not compromise the security provided via Ipsec ESP but rather a DoS is possible if indeed the attacker got in the routing path/redirect. Just a hypothesis that the issue can only be resolved through hop-hop security, RR will not help on the DoS, no?

Qiang
-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]] 
Sent: Thursday, November 02, 2006 9:22 AM
To: RYUJI WAKIKAWA; Narayanan, Vidya
Cc: [email-masked]; Pascal Thubert (pthubert)
Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT)

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

=> This is not the issue being raised, the issue is the insecurity of the IPv4 header when a NAT exists. The outer header is obviously unprotected and vulnerable to redirection attacks (an attacker acting as a NAT bascially). I don't think we need to solve that problem as I indicated in a previous email.

Hesham

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 3 Nov 2006 06:20:17 -0800

> I would agree the MITM attack will not compromise the 
 > security provided via Ipsec ESP but rather a DoS is possible 
 > if indeed the attacker got in the routing path/redirect. 
 > Just a hypothesis that the issue can only be resolved 
 > through hop-hop security, RR will not help on the DoS, no?

=> RR would certainly not help with DoS, it doesn't help with DoS today.
But more importantly, DoS can be done today on other protocols doing NAT
traversal and even on any normal communication that doesn't involve MIP
or NAT traversal. So solving it for this draft doesn't add anything to
Internet security in general. 

Hesham

 > Subject: RE: What are we protecting over IPv4 in DS-MIP6? 
 > (RE: [Mip6]concensus: issue 76: Alt CoA should not 
 > beusedwhen traversingIPv4 NAT)
 > 
 > 
 >  > RR check can be one solution, but as other people pointed 
 > out, this  > causes additional round trip.
 > => This is not the issue being raised, the issue is the 
 > insecurity of the IPv4 header when a NAT exists. The outer 
 > header is obviously unprotected and vulnerable to 
 > redirection attacks (an attacker acting as a NAT bascially). 
 > I don't think we need to solve that problem as I indicated 
 > in a previous email.
 > 
 > Hesham
 > 
 > 
 > 
 >  > 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  
 > > 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.
 >  > >
 >  > 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 -  
 > > 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
 >  > >

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 6 Nov 2006 13:59:49 +0100

Hi Hesham:
 
This is getting confusing, maybe because of the RR term. As you very
well know:

- What we are really talking about here is enabling the HA to check that
the MN can be reached at the CoA, which causes an extra latency when
roaming but does not involve the complexity of the test by the MN.

- What it mitigates is the redirection attack which can be used to bomb
an attacked server. Such a DoS attack is difficult in IPv6 because in
most cases, the MN will autoconf its address. So the bombing can only be
done against (the access of) an attacked network, not a specific host. 	
 
- There can still be a MITM. But it needs to be able to forward the BA
to the MN, so it is on the way of its own attack. Combined with ESP,
this leaves little room for an attacker. In other words, we are trying
to have better locks than the neighbors :)
 
My point is this. We can make a simple and optional addition to the
protocol where the HA asks the MN to send a second BU. If this provides
an interesting improvement in the security level of the solution, why
not just do it?

  Pascal

>Sent: Friday, November 03, 2006 3:20 PM
>To: Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, Vidya
>Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE:

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 6 Nov 2006 10:02:05 -0800

> an interesting improvement in the security level of the solution, why

=> Because it adds nothing to Internet security in general. As I said in
an earlier email, these attacks are already doable today in an IPv4
Internet. So what gain to Internet security do we add by making this
protocol ultra secure? This is the equivalent of installing a steel door
in a glass house IMO. 

The key principle I'm trying to follow here is "do no harm". If there
are new vulnerabilities introduced that don't exist today then I agree
we need to solve them, however, if those vulnerabilities already exist,
then adding this would only confuse people and give a false sense of
security. 

My goal is to keep the MIPv6 packet as secure as it is today, but I
don't see the benefit in designing the only secure NAT traversal
mechanism (aqssuming the reachability check will actually make it
secure). 

Hesham