Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used when traversing IPv4 NAT

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 12 Oct 2006 23:51:59 -0700

hi Hesham,

question is, if the NAT is modifying the outer address
IPv4 anyway, and the HA is going to use the outer IPv4
address as the CoA, what is the point in protecting the
source address on the inner IPv6 header using the new
checksum option?

why don't we instead in the security considerations say
that with RFC 3775 we had integrity protection for the
CoA, but with DS-MIPv6, since a NAT could modify the 
outer source address, and the outer source address is 
what is considered as the CoA, we don't get integrity
protection for the CoA.

Vijay

> -----Original Message-----
> From: Soliman, Hesham [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 11:43 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used 
> when traversing IPv4 NAT
> 
>  
>  > sorry for the late reply.
>  > 
>  > I agree with relaxing the requirement in RFC 3775 to
>  > include an Alt CoA option all the time.
>  > 
>  > but I don't understand how the checksum option helps.
>  > 
>  > lets take the following packet
>  > 
>  > IPv4 hdr (src=ipv4-CoA, dst=ipv4-HA)
>  > IPv6 hdr (src=ipv4-mapped-ipv6-CoA, dst=ipv6-HA)
>  > ESP hdr
>  > Mobility Hdr
>  >      Binding Update
>  >      Checksum option
>  > 
>  > the checksum option protects the source in the IPv6
>  > hdr. but if there is a NAT on the path, the HA needs
>  > to take the IPv4 CoA in the source address of the
>  > outer IPv4 header as the correct CoA. 
> 
> => No, it only takes that outer address as the dst address of 
> its outer
> header, the CoA is still the inner address. In other words, the packet
> received at the HA (through the NAT) would look like this: 
> 
>   IPv4 hdr (src=ipv4-natted, dst=ipv4-HA)
>   IPv6 hdr (src=ipv4-CoA-mapped, dst=ipv6-HA)
>   ESP hdr
>   Mobility Hdr
>        Binding Update
>        Checksum option
> 
> Where ipv4-natted is the modified IPv4 CoA after the packet 
> went through
> the NAT.
> 
> the packets sent from the HA to the MN, after a NAT is detected would
> look like this:
> 
>   IPv4 hdr (src=ipv4-HA, dst=ipv4-natted)
>   IPv6 hdr (src= ipv6-HA, dst= ipv4-CoA-mapped)
>   .....etc
> 
> Am I missing something ?
> 
>    the NAT would
>  > modify the IPv4 CoA anyway. how does the checksum
>  > option protect the IPv4 Co?
> 
> => It only protects the inner address. Remember that the inner address
> (the one in the v4-mapped address) is still required as the CoA in the
> IPv6 packet. The problem with modifying the outer IPv4 address is of
> course valid, but that's the problem with NATs and there is 
> not much we
> can do about that.
> 
> Hesham
> 

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 13 Oct 2006 00:48:07 -0700

> source address on the inner IPv6 header using the new

=> Well, we're type to keep the integrity of the BU equivalent to 3775.
I know what you mean, evidently, the NAT will be the weakest link and it
will push the entire security level down. I agree. 

 > what is considered as the CoA, we don't get integrity

=> That's possible of course, but at lease with the checksum option we
know that one address is correct for sure (i.e. CoA in the v6 header). I
don't know if that reduces the number of potential attacks overall, my
aim was to keep it equivalent to 3775 so we don't have to worry about
re-analysing the threats. But may be it's a good exercise to do that.
Can you think of any attacks that would be reduced if the attacker could
not successfully modify the CoA in the v6 packet? This is a question for
anyone BTW. I'll think about it a bit more to see if it makes a
difference. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 19 Oct 2006 09:18:38 -0700

Folks, 

This issue was revived mainly due to Vijay points on the need for the
checksum option when the alt-CoA is not used. Let me summarise the
issues first then propose a way forward. 

Summary:
--------

The initial resolution for the issue suggested that we add a checksum
option that includes a checksum on the src and dst addresses in the IPv6
header. This was suggested to be used when the alt-coa is not present to
maintain the integrity of the src address when ESP is used. I want to
emphasise that this is only needed when ESP is used, not with AH. 

Now the point that Vijay raised is also quite valid: With NAT traversal,
the outer IPv4 header is vulnerable, yet it is needed because the HA
responds to that address and sets up the UDP tunnel to the outer
(natted) IPv4 src address in the packet containing the BU. There is no
way we can secure that address, yet, it essentially acts as another
binding, which if modified maliciously, would redirect the MN's packets
to another IPv4 address. To be clear, here is the packet format:
BU packet received by HA after passing through NAT:
  IPv4 HDR (src=natted-v4, dst=HA-addr)
       UDP
         IPv6 HDR (src=v4-mapped-v6, dst=HA-addr)
          ESP
          DST-OPT
          MH (BU)

The HA responds with a similar packet including the BA and forwards all
future packets in the UDP tunnel, with the dst address in the IPv4
header being the "natted-v4" address above. 
So essentially protecting the BU does not protect the MN from
redirection attacks in this case because the IPv4 header is vulnerable.
This is an inherent problem with NAT traversal. There is practically
nothing we can do about it. 

So the remaining question is: Is it worth worrying about the integrity
of the BU in this case? IMHO I think the answer is yes. Why? Two main
reasons:

1. There can be cases where the BU is sent to a local HA and the
operator can guarantee that no NATs are in the path. In this case we
would lose integrity for no reason, i.e. the BU becomes the weakest
link. This is not unusual really because an operator may decide that it
will only provide the HA function within its domain, which happens to
not include NATs between the MN and the HA. 

2. We have precedence with MIPv4 and NAT traversal where the RREQ is
still secure despite the UNSAF NAT traversal. 
 
Note that the answer to 1) above may be "Use AH", but I prefer to not
force that on implementations that do not do it today (although I would
personally prefer AH in general for the BU).

For these reasons, and there may be more, I prefer to not take this big
decision to lose the integrity for the BU. 

Way forward:
------------

This issue is now closed, we all agree on it, but there may be
disagreement on the checksum part. So I suggest that I generate a new
issue for this discussion. Until the new issue is resolved, I won't add
the checksum option to the draft. 

Feel free to send comments. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 19 Oct 2006 12:10:10 -0700

> nothing we can do about it. 

right.

> not include NATs between the MN and the HA. 

if there is no NAT on the path, the use of alt-CoA
gives automatic integrity protection for the CoA.
so its best to use the alt-CoA option all the time
(which is what RFC 3775 says anyway).

the original suggestion was to relax the "MUST"
in RFC 3775 which says the HA should always use the
CoA in the alt-CoA option. not to relax the
MN requirement to include the alt-CoA option when
ESP is used.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 19 Oct 2006 13:43:59 -0700

> MN requirement to include the alt-CoA option when

I should have said "... when ESP in transport mode is used". :)

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 19 Oct 2006 22:05:11 -0700

> gives automatic integrity protection for the CoA.

=> The point here is that you don't know that at the time the BU is
sent. As I said in an earlier email we can't say that "the mobile node
should do X if there is no NAT". The MN doesn't know if there is a NAT
or not. 

 > MN requirement to include the alt-CoA option when

=> Of course, but the only way to fix it for DSMIP is to say "when in an
IPv4 network don't use the alt-coa". We can't rely on the knowledge of
the presence of a NAT before the BU is sent. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 19 Oct 2006 22:45:35 -0700

> the presence of a NAT before the BU is sent. 

no. simple solution is for the MN to include the
alt-CoA all the time in the BU when using ESP in
transport mode.

the HA does the NAT detection. if it does not
detect a NAT, it uses the CoA in the alt-CoA
option. the CoA is integrity protected in this
case. if the HA detects a NAT, it uses the
source address in the outer IPv4 header. no
integrity protection for the CoA in this case.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 19 Oct 2006 23:49:41 -0700

Vijay, 

You've just done a complete 180 degree turn and are essentially asking
to always use it instead of the agreed decision to not use the alt-coa. 

 > integrity protection for the CoA in this case.

=> You're misrepresenting the issue here. It's not an either or
situation...you use **both**
addresses, the one in the outer IPv4 header and the one in the IPv6
packets in *both* cases...

I prefer to avoid a circular discussion about this issue. Since we all
agreed to relax the requirement, let's focus the discussion on whether
we need the checksum or not. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 20 Oct 2006 06:25:21 -0700

> to always use it instead of the agreed decision to not use the alt-coa. 

??

from what I remember we wanted to relax the MUST
requirement at the HA to always the CoA in the
alt-CoA option when there is a NAT present.

I remember someone suggesting not using the option
at all in DS-MIPv6, but I don't remember concluding
on that. anyway, lets figure out what we want to do
now.

> packets in *both* cases...

The HA uses both for NAT detection. but considers
only one as the CoA.

> we need the checksum or not. 

:) I don't think we need it.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 20 Oct 2006 08:39:12 -0700

> alt-CoA option when there is a NAT present.

=> Right, but please s/when a NAT is present/when in an IPv4 network.
As I said a couple of times now, the MN doesn't know if a NAT is present
when it sends the BU.

 > The HA uses both for NAT detection. but considers

=> Not quite. The outer v4 address is still used in the UDP tunnel
interface, the IPv4 address in the IPv6 packet is the "CoA" as far as
MIPv6 is concerned. Of course the two can be the same (no NAT) or
different (NAT or MITM).

 > :) I don't think we need it.

=> That's fine, so you just express that opinion for this new issue. All
I said was that the checksum (the need for it) will be a separate issue
since we agreed on the other part (relaxing of 3775). 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 20 Oct 2006 08:52:18 -0700

> => Right, but please s/when a NAT is present/when in an IPv4 network.

nope. the HA needs to relax the requirement only
when it detects a NAT, not because the MN is on
an IPv4 access network.

> As I said a couple of times now, the MN doesn't know if a NAT is present

who disagreed?

> since we agreed on the other part (relaxing of 3775). 

lets be clear on what we agreed to relax. only the
MUST requirement on the HA to use the CoA in the
alt-CoA option all the time.

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 23 Oct 2006 01:19:02 -0700

For the benefit of the list I'm repeating what I already told Vijay in
a private mail.

 > when it detects a NAT, not because the MN is on

=> This can't work because the HA has no way of knowing whether the src
address in the v6 header is different because of NAT or due to a
legitimate use of the alt-coa option. So the HA can't decide whether a
NAT is detected or not by comparing the v4 and v6 headers if the alt-coa
may be found later. The only way to detect a NAT beased on the v4/v6
headers comparison is to remove the alt-coa option.

 > alt-CoA option all the time.

=> I don't think you could have agreed with that because it was never
suggested. Neither the issue text nor my analysis/recommendation ever
suggested this approach. Both clearly suggested ommitting the alt-coa
option. 

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Oct 2006 10:17:35 -0700

Soliman, Hesham wrote:
> legitimate use of the alt-coa option. 

thats an inherent problem with NAT traversal.
any recipient of a packet that goes through
a NAT does not know if the source address on
the packet was modified by a NAT or by some
attacker on the path.

> So the HA can't decide whether a

does not follow.

> suggested this approach. Both clearly suggested ommitting the alt-coa

my bad. I was under the impression that we are
relaxing the MUST requirement in RFC 3775. not
the altCoA option. anyway, I don't believe we
have consensus on removing the alt-CoA option.
did we have consensus on the mailing list?

Vijay

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 23 Oct 2006 21:18:29 -0700

> the packet was modified by a NAT or by some

=> No I'm not talking about that. If the alt-coa is present, the HA
can't tell that a NAT was in the path just by comparing the v4 and v6
headers. This has nothing to do with NAT and everything to do with the
alt-coa option. That is the issue.

 > > headers comparison is to remove the alt-coa option.

=> What doesn't follow??

Hesham