Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 31 Oct 2006 22:36:06 -0800

I don't understand something here. Why would ESP tunnel mode not provide
the needed protection? Given that we already have two IP headers in this
case, it isn't even adding any overhead. I can't see why we need
anything else. 

I can understand not wanting to impose AH, but I don't see ESP tunnel
mode as a restriction at all. 

So, the headers would simply be:

  IPv4 HDR (src=natted-v4, dst=HA-addr)
       UDP
          ESP
	      IPv6 HDR (src=v4-mapped-v6, dst=HA-addr)
              DST-OPT
              MH (BU)

What's the problem with that? 

Vidya

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 8:00 PM
> To: Soliman, Hesham
> Cc: Narayanan, Vidya; [email-masked]; Pascal Thubert (pthubert)
> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not 
> be usedwhen traversingIPv4 NAT
> 
> Soliman, Hesham wrote:
> >  > well, if there is a NAT on the path the source  > address on the 
> > outer IPv4 header is modified.
> >  > anytime a packet goes through a NAT, we have  > this 
> problem. this 
> > is a common problem. so I  > don't think we should design a 
> DS-MIPv6  
> > > specific mechanism to protect  an address that  > is 
> modified by the 
> > NAT. its not worth it.
> > 
> > => You keep repeating that and I keep answering as follows: 
> If there 
> > is an alt-coa in the packet then the HA has no way of 
> knowing if there 
> > was a NAT or not without checking it first, it can't simply compare 
> > the outer headers...
> 
> I actually agree with this. :)
> 
> Again, this has nothing to do with the presence of the
> > NAT and everything to do with the presence of the alt-CoA...
> > 
> > So it makes zero sense to say that the "HA should ignore 
> the alt-coa 
> > if a NAT were detected" because the HA can't possibly know 
> that a NAT 
> > was en route without inspecting the alt-coa....
> 
> hmmm... there is a misunderstanding. I didn't say ignore the 
> alt-CoA option. I said the HA should not use the contents of 
> the altCoA option as the CoA when it detects a NAT.
> 
> it does not matter if the HA compares the source address on 
> the outer IPv4 header with the source address of the inner 
> header or the contents of the altCoA option to detect the 
> presence of a NAT. its the same for me.
> 
> Vijay
> 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 07:30:51 -0800

when you create an IPsec SA in tunnel mode, the
source address on the inner header becomes a
traffic selector (goes in the TSi as the address).
it shouldn't be the v4-mapped-v6 address. it has
to be the v6 home address.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Nov 2006 10:14:49 -0800

Let's discuss this more separate from this issue, as Hesham says. I
don't think there is a problem. We can talk in SD to make sure there
isn't an issue here. 

Vidya 

> Sent: Wednesday, November 01, 2006 7:31 AM
> To: Narayanan, Vidya
> Cc: Soliman, Hesham; [email-masked]; Pascal Thubert (pthubert)
> when you create an IPsec SA in tunnel mode, the source 
> address on the inner header becomes a traffic selector (goes 
> in the TSi as the address).
> it shouldn't be the v4-mapped-v6 address. it has to be the v6 
> home address.
> 
> Vijay
> 
> Narayanan, Vidya wrote:
> > I don't understand something here. Why would ESP tunnel mode not 
> > provide the needed protection? Given that we already have two IP 
> > headers in this case, it isn't even adding any overhead. I 
> can't see 
> > why we need anything else.
> > 
> >> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be 
> >> usedwhen traversingIPv4 NAT
> >>
> >> Soliman, Hesham wrote:
> >> hmmm... there is a misunderstanding. I didn't say ignore 
> the alt-CoA 
> >> option. I said the HA should not use the contents of the altCoA 
> >> option as the CoA when it detects a NAT.
> >>
> >> it does not matter if the HA compares the source address 
> on the outer 
> >> IPv4 header with the source address of the inner header or the 
> >> contents of the altCoA option to detect the presence of a NAT. its 
> >> the same for me.
> >>
> >> Vijay
> >>
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 10:36:56 -0800

> don't think there is a problem. We can talk in SD to make sure there

I don't like this step-by-step process of splitting
an issue into multiple small issues. it is easy to
miss the context and just say yes or no to a
particular small issue.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 10:52:47 -0800

Narayanan, Vidya wrote:
> I

I missed replying to the above part. :)

you can't change the source address in the inner
header when a tunnel mode IPsec SA is used without
invalidating the IPsec SA. so you always need the
home address to appear as the source address on
the inner header.

from draft-ietf-mip6-ikev2-ipsec-07.txt

>    o  The mobile node and the home agent MUST create security
>       associations based on the home address, so that the security
>       associations survive change in care-of address.  When using IKEv2
>       as the key exchange protocol, the home address should be carried
>       as the initiator IP address in the TSi payload during the
>       CREATE_CHILD_SA exchange [4].

for a tunnel mode SA, this means the source address
on the inner IP header must be the home address.

from RFC 3776

>       mobile node SPD-S:
>          - IF source = home_address_1 & destination = any &
>               proto = MH & local_mh_type = HoTi &
>               remote_mh_type = HoT
>            Then use SA ESP tunnel mode
>                        IDi = user_1, IDr = home_agent_1,
>                        TSi = home_address_1, MH, HoTi
>                        TSr = any, MH, HoT
>                        outer src addr = care_of_address_1,
>                        outer dst addr = home_agent_1,
>                        inner src addr = home_address_1

note the "home_address_1 in the TSi when creating
a tunnel SA.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Nov 2006 11:08:39 -0800

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Nov 2006 11:10:29 -0800

I was not assuming that the SPD entries and selectors for this would be
the same as those for regular MIP6 - but, let's first discuss what we
are protecting (see the email I just sent out with a subject change). 

Vidya

> Sent: Wednesday, November 01, 2006 10:53 AM
> To: Narayanan, Vidya
> you can't change the source address in the inner header when 
> a tunnel mode IPsec SA is used without invalidating the IPsec 
> SA. so you always need the home address to appear as the 
> source address on the inner header.
> 
> for a tunnel mode SA, this means the source address on the 
> inner IP header must be the home address.
> 
> from RFC 3776
> 
> >       mobile node SPD-S:
> note the "home_address_1 in the TSi when creating a tunnel SA.
> 
> Vijay
> 
> > 
> > Vidya
> > 
> address on the 
> >> inner header becomes a traffic selector (goes in the TSi as the 
> >> address).
> >> it shouldn't be the v4-mapped-v6 address. it has to be the v6 home 
> >> address.
> >>
> >> Vijay
> >>
> >> Narayanan, Vidya wrote:

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 11:21:15 -0800

Narayanan, Vidya wrote:
> the same as those for regular MIP6 

the restriction comes from RFC 4301. we are not
planning to remove that in DS-MIPv6.

Vijay

- but, let's first discuss what we

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 11:29:57 -0800

> document the vulnerability that may still exist. 

so your solution is to perform a return routability
check on the IPv4 CoA. this is certainly a good
solution. it has been suggested many times in the
past to add a return routability check for the CoA
for MIPv6 in general to prevent re-direction
attacks, i.e., a legitimate mobile node uses someone
else's CoA.

but there was no consensus to add that.

two points to note here

1. we add a round trip between the BU and BAck. the
WG as to decide if that is worth adding to the
DS-MIPv6 spec.
2. the exchange of BU/BAck is preceded by an IKEv2
exchange between the MN and the HA. since IKEv2
involves multiple round trips and the fact that the
IKE SA is based on the IPv4 CoA, we get some
protection already.

please consider these two points.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Nov 2006 12:15:28 -0800

> so your solution is to perform a return routability check on 
> the IPv4 CoA. this is certainly a good solution. it has been 
> suggested many times in the past to add a return routability 
> check for the CoA for MIPv6 in general to prevent 
> re-direction attacks, i.e., a legitimate mobile node uses 
> someone else's CoA.
> 

This is completely different from the case at hand. When an MN that
legitimately owns the claimed HoA (let's differentiate this from a
*legitimate* MN that would behave properly) uses someone else's IP
address (it doesn't have to be CoA) as it's CoA, the result is a *DDoS
attack* on the owner of that address. Clearly, here, the MN is acting as
an attacker. And, given that there are other ways to launch DDoS attacks
on a victim and that such an attack is traceable to the MN via checks at
the HA, based on administrative channels, this is not worth protecting
against. 

The case at hand is one that results in a *redirection attack* on a
legitimate MN. It is equivalent to an attacker claiming the MN'S HoA at
the HA. The MN is the victim here, as opposed to the attacker in the
previous case. This is a very different case and is a cause for conern,
especially because, this is not detectable at the HA even by
administrative channels and the MN is being denied service. This is
because, the attacker is on-path and using a valid integrity protected
packet from the MN and making an allowable modification to the packet to
realize this attack. 

Hence, the case at hand is worth protecting against. Note that this is
unique to the IPv4 tunneled case alone. Such an attack is not feasible
with regular MIP6 (oh, assuming that v6 deployments won't use NATs, but
then, NATs are a religion and one never knows what an admin may be
thinking :)). 

> 1. we add a round trip between the BU and BAck. the WG as to 
> decide if that is worth adding to the
> DS-MIPv6 spec.

Hence, it should be a SHOULD and not a MUST. Implementations that don't
do this stand to be more vulnerable and if they are certain about not
having on-path attackers in their networks, that's their choice. 

> 2. the exchange of BU/BAck is preceded by an IKEv2 exchange 
> between the MN and the HA. since IKEv2 involves multiple 
> round trips and the fact that the IKE SA is based on the IPv4 
> CoA, we get some protection already.
> 

Not really. Especially given that the IKE SA can be pointed to the new
CoA as the CoA changes, this doesn't buy anything AFAICT. 

So, I still maintain my vote on optional reachability checks :) 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 15:44:35 -0800

ok. stepping back a bit, I will let the WG decide
whether we want to add a return routability check
for the IPv4 CoA. it will work of course.

my preference would be not to add this since it
adds a round trip, making it two round trips
every time you send a BU.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Nov 2006 21:39:11 -0800

> 
> ok. stepping back a bit, I will let the WG decide whether we 
> want to add a return routability check for the IPv4 CoA. it 
> will work of course.
> 
> my preference would be not to add this since it adds a round 
> trip, making it two round trips every time you send a BU.
> 

That is not the question. The question is whether it is important to
protect against redirection attacks while traversing IPv4 networks. I
believe it is. If not, it is somewhat akin to saying that we don't care
about a malicious MN claiming an incorrect HoA and then, we might as
well say that no address authorization is needed. Well, ok, that is a
bit of exaggeration :) The latter can be realized by off-path attacks,
while the IPv4 case is about on-path attacks. 

I think that the vulnerability is not insignificant and needs
protection. Once we agree on that, we can see how best to do the
reachability checks and if there is a way to do it without always
impacting handoff latency. 

Vidya

> >> so your solution is to perform a return routability check 
> on the IPv4 
> >> CoA. this is certainly a good solution. it has been suggested many 
> >> times in the past to add a return routability check for 
> the CoA for 
> >> MIPv6 in general to prevent re-direction attacks, i.e., a 
> legitimate 
> >> mobile node uses someone else's CoA.
> >>
> > 
> > attack* on the owner of that address. Clearly, here, the MN 
> is acting 
> > as an attacker. And, given that there are other ways to launch DDoS 
> > attacks on a victim and that such an attack is traceable to 
> the MN via 
> > checks at the HA, based on administrative channels, this is 
> not worth 
> > protecting against.
> > 
> > legitimate MN. It is equivalent to an attacker claiming the 
> MN'S HoA 
> > at the HA. The MN is the victim here, as opposed to the attacker in 
> > the previous case. This is a very different case and is a cause for 
> > conern, especially because, this is not detectable at the 
> HA even by 
> > packet from the MN and making an allowable modification to 
> the packet 
> > to realize this attack.
> > 
> > with regular MIP6 (oh, assuming that v6 deployments won't use NATs, 
> > but then, NATs are a religion and one never knows what an 
> admin may be 
> > thinking :)).
> > 
> >> 1. we add a round trip between the BU and BAck. the WG as 
> to decide 
> >> if that is worth adding to the
> >> DS-MIPv6 spec.
> > 
> > Hence, it should be a SHOULD and not a MUST. Implementations that 
> > don't do this stand to be more vulnerable and if they are certain 
> > about not having on-path attackers in their networks, 
> that's their choice.
> > 
> exchange between 
> >> the MN and the HA. since IKEv2 involves multiple round 
> trips and the 
> >> fact that the IKE SA is based on the IPv4 CoA, we get some 
> protection 
> >> already.
> >>
> >

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 2 Nov 2006 23:07:18 +0900

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 3 Nov 2006 07:59:52 -0800

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.
> A new message BA-ack may be sufficient. i.e. An 
> acknowledgment of BA sent back from  MN.
> 
> ryuji
> 
> > emails, but after sleeping over it and some other discussions, I'm 
> > 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.
> >
> > 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.
> >