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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 30 Oct 2006 18:12:16 +0100

Hi Hesham:

I agree:

1) with relaxing the requirement in RFC 3775 to include an Alt CoA
option all the time.

2) that the MN should omit it, as opposed to the HA filtering it out.
The Alt CoA is the real address at which the MN is reachable, that is
what HAs implement today, that is what all people in the art understand.
I want to stay simple and keep it that way.  I'd hate to have rules like
"this is A but then if there is also that then this is B which is the
opposite of A", etc... we are not lawyers! 

3) that we have to find an alternate way to endure that the MN is
reachable at the CoA, defined as the source of the packet when the HA
gets it.

I'd also agree that:

4) UDP is used all the time in IPv4 roaming situation, regardless on
whether NAT is detected or not. That's not really in the mail but since
you fixed the message format in the thread to add UDP, I take advantage
of the exchange to raise that point again.

I disagree:

5) to jump too quickly on the conclusion that the checksum is the way to
go. I understand that it has value in certain scenarios that you
mention. But it fails to guarantee that the MN is reachable at the CoA
in another common case that is NAT; and it does not protect against a
rogue DHCP server assigning you an IPv4 DoS'ed address, which could
easily happen in the IPv4 world. 

So when you call for consensus, please leave open the solution to 3) so
we can see if there's a preferable alternative. I, for one, would favor
an approach like 2 BU flows in row, which would emulate a 3 way
handshake and guarantee the reachability of the MN in all cases. 

Pascal

>-----Original Message-----
>From: Soliman, Hesham [mailto:[email-masked]]
>Sent: Thursday, October 19, 2006 6:19 PM
>To: [email-masked]
>Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used when
traversingIPv4 NAT
>
>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
>
>_______________________________________________
>Mip6 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mip6

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