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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 31 Oct 2006 16:19:32 +0100

1) Yes ...

>-----Original Message-----
>From: Soliman, Hesham [mailto:[email-masked]]
>Sent: Tuesday, October 31, 2006 2:11 PM
>To: Pascal Thubert (pthubert); [email-masked]
>Subject: concensus: issue 76: Alt CoA should not be used when
traversingIPv4 NAT
>
>Pascal, all,
>
>There's been a lot of emails on this issue so I think WG members are
>fully informed now about what this issue involves. I will ask a simple
>question and I'd like people to choose one of the options below. To
>avoid any confusion I'm keeping the question simple and clear.
>
>Leaving the checksum option and integrity issue aside (because I know
we
>can fix it and I'm writing a separate issue for it) please let give me
>an answer to the following question:
>
>Do you agree that the MN does not include the Alt-CoA option in the BU
>when it is located in an IPv4-only network?
>
>1. Yes
>2. No
>
>Please include a brief reason for you answer, Pascal already did so I
>don't expect another one :). As I said, ignore the checksum issue, this
>will be handled separately.
>
>FWIW, I choose 1) above because it's the only way to make sure that the
>HA can detect the presence of a NAT by comparing the outer v4 addresses
>with the IPv6 header.
>
>Hesham
>
>
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> > Sent: Tuesday, October 31, 2006 4:12 AM
> > To: Soliman, Hesham; [email-masked]
> > Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used
> > when traversingIPv4 NAT
> >
> > 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

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 31 Oct 2006 18:37:06 -0800 (PST)

I support this. I agree with Pascal's explanation on
this.

1. Yes