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

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 31 Oct 2006 16:54:17 -0800

Hi Ryuji, 

Sounds good. I can assure you that we can protect the CoA, I want the
same thing. I just wanted to put aside the question for the moment. But
I definitely want to protect it.

Hesham 

 > -----Original Message-----
 > From: RYUJI WAKIKAWA [mailto:[email-masked]] 
 > Sent: Wednesday, November 01, 2006 2:25 AM
 > To: Soliman, Hesham
 > Cc: Pascal Thubert (pthubert); [email-masked]
 > Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not 
 > be used when traversingIPv4 NAT
 > 
 > Hello Hesham
 > 
 > Yes and No.
 > Sorry, but it's hard to tell without concerning checksum and  
 > integrity issue..
 > 
 > It depends on how we provide integrity check to IPv4 CoA.
 > If there is a way to solve this, i don't mind to omit ACoA.
 > 
 > Otherwise, no.
 > We should protect IPv4 CoA by ACoA, even if it is valid only
 > when MN roams in global IPv4 access network.
 > If the src address and the IPv4 CoA in an ACoA option are 
 > different,  
 > HA assumes
 > that MN is at NATed network and ignores the address in the 
 > ACoA option.
 > We leave redirection attack and warns this possibility in the spec.
 > 
 > > 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
 > 
 > I am interested in how you fix this:-)
 > 
 > regards,
 > ryuji
 > 
 > On 2006/10/31, at 22:10, Soliman, Hesham wrote:
 > 
 > > 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