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

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 1 Nov 2006 22:43:14 -0800

Hi all,

On the question I posted below, we got the following answer: 

Yes: 5
No: 1

Other (Yes and No): 1. This was Ryuji's comment where he said he would
go for "Yes" if integrity is ensured.

We have concensus on removing the Alt-CoA and I will post a separate
issue on the security aspect of this. Hopefully we can resolve the
security issue during IETF week. 

This issue is now closed. Thanks for your feedback.

Hesham

 > -----Original Message-----
 > From: Soliman, Hesham [mailto:[email-masked]] 
 > Sent: Wednesday, November 01, 2006 12:11 AM
 > To: Pascal Thubert (pthubert); [email-masked]
 > Subject: [Mip6] concensus: issue 76: Alt CoA should not be 
 > used whentraversingIPv4 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
 > 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 01 Nov 2006 23:09:46 -0800

thats funny. we had a 40 hour consensus call on
the "YES" and "NO" options. :)

anyway, I think this is a wrong decision. we
would need to re-visit this if the new solution
to provide integrity protection for the IPv4 CoA
is too complicated or not worth the tradeoff.

Vijay