Re: [nvo3] Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00

[Dan Wing <[e-mail]>]

On Sep 20, 2017, at 2:57 PM, Linda Dunbar <[e-mail]> wrote:
> Dan and Sami, 
> 
> Since the draft is only about the consideration, does it need to dive into the detailed solution? 
> 
> I feel the actions at the initiating VTEP and returning VTEP are part of solution. The bottom line, the consideration needs to point out issues traversing the existing NAT. 

Yes, I agree some text discussing NAPT and firewall port forwarding is necessary.  I have provided text.

I object to the proposal that VTEPs implementations send traffic to a port other than the IANA-assigned destination port, because the proposal forces both VTEPs to maintain per-flow state and the proposal introduces new brittleness.  The proposal still requires the remote VTEP to have NAPT port forwarding, so it can't achieve its goal of eliminating port forwarding, anyway.

-d


> Linda
> 
> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]] 
> Sent: Wednesday, September 20, 2017 4:18 PM
> To: Linda Dunbar <[e-mail]>
> Cc: Sami Boutros <[e-mail]>; [e-mail]; NVO3 <[e-mail]>
> Subject: Re: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
> 
> 
>> On Sep 20, 2017, at 2:09 PM, Linda Dunbar <[e-mail]> wrote:
>> 
>> Sami,
>> 
>> Answers inserted below:
>> 
>> From: Sami Boutros [mailto:[e-mail]] 
>> Sent: Tuesday, September 19, 2017 5:23 PM
>> To: Linda Dunbar <[e-mail]>; Dan Wing <[e-mail]>; [e-mail]
>> Cc: NVO3 <[e-mail]>
>> Subject: Re: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
>> 
>> Hi Linda,
>> 
>> There are some more clarifications needed before adding the text.
>> 	• The VTEP initiating the traffic, does it need to maintain a state for each source port it is putting on the packet? I.e. The inner payload flow info that maps to this source port? So when it receives return traffic it knows this is a return traffic for the Geneve tunnel from the other VTEP?
>> [Linda] I don’t think the VTEP initiating the traffic need to make any changes to its current implementation.
> 
> 
> It would need to change, because it would need to listen for incoming packets on a different port than 4789.  How long does it listen?  How many ports does it listen to?  What happens if the NAPT loses mapping state (reboots)?  Does it need to send UDP keepalive traffic?  
> 
>> 	• The VTEP sending only the return traffic, does it need to maintain a state between the NAT translated source port (by the NAT GW) and the inner payload too? Which source should it use for returned traffic? 
>> [Linda] the VTEP sending the return traffic may need some changes, especially if VxLAN is used, because the Destination Port can no longer to be 4789. 
> 
> It would need to remember which destination port it needs to reply on, which is effectively a NAPT table for the entire network of the inner IP addresses.  That's a very significant amount of state, on par with large-scale NAT.  If we want high availability, that state would need to be synchronized with an adjacent VTEP, just like with a large-scale NAT.
> 
> 
> Instead, let's just do what's easy:  send packets to the IANA-assigned UDP port, which keeps the VTEP implementation simple.
> 
> -d
> 
> 
>> 
>> Thanks,
>> 
>> Sami
>> From: Linda Dunbar <[e-mail]>
>> Date: Friday, September 15, 2017 at 12:42 PM
>> To: Sami Boutros <[e-mail]>, Dan Wing <[e-mail]>, "[e-mail]" <[e-mail]>
>> Cc: NVO3 <[e-mail]>
>> Subject: RE: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
>> 
>> Sami,
>> Your wording only describes the scenario of one VTEP initiating the traffic, but doesn’t describe the issues within the NAT device when receiving the return encapsulated traffic from the remote VTEP.  
>> 
>> Specifically,  if the Overlay Tunnel uses VxLAN encapsulation [RFC7348], IANA assigned Port 4789 is used in the outer frames’ destination port field and hashed value of inner packet is used in the outer frames’ source port field [RFC 7348].  This approach can cause trouble when traversing NAT.
>> 
>> In addition, your wording of “The Other VTEP … should use the translated UDP source port as the destination port for the reverse traffic” is basically eliminating the VxLAN RFC7348 encapsulation as a valid tunnel method (is it a problem?)
>> 
>> IMHO, this document should only describes the issue, but not the solutions.
>> 
>> 
>> Therefore, I suggest some minor changes to your wording:
>> -------------------------------------------------------------------------
>> NAT traversing consideration:
>> 
>> For scenarios where traffic over an NVO3 tunnel can be initiated from only one VTEP side, and in the event that the NVO3 tunnel encapsulation traverse a NAT GW.
>> The NAT GW will change both the VTEP src ip and udp port of the tunnel IP/UDP header for the traffic initiated from one VTEP and expects the return traffic to have certain destination udp port (instead of the RFC7348 specified 4789 as the destination udp port).   
>> 
>> The other VTEP end of the tunnel, which MUST not be initiating any traffic but only sending the return traffic, should use the translated UDP source port as the destination port for the reverse traffic sent over the tunnel to the translated NAT VTEP src address.
>> 
>> 
>> Thanks, Linda
>> 
>> From: Sami Boutros [mailto:[e-mail]] 
>> Sent: Thursday, September 14, 2017 4:37 PM
>> To: Linda Dunbar <[e-mail]>; Dan Wing <[e-mail]>; [e-mail]
>> Cc: NVO3 <[e-mail]>
>> Subject: Re: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
>> 
>> Hi Linda,
>> 
>> Thanks for the response. 
>> 
>> I will add a section as follow, please let me know if this is OK.
>> 
>> NAT traversing consideration:
>> 
>> For scenarios where traffic over an NVO3 tunnel can be initiated from only one VTEP side, and in the event that the NVO3 tunnel encapsulation traverse a NAT GW.
>> The NAT GW will change both the VTEP src ip and udp port of the tunnel IP/UDP header.
>> 
>> The other VTEP end of the tunnel, which MUST not be initiating any traffic but only sending the return traffic, should use the translated UDP source port as the destination port for the reverse traffic sent over the tunnel to the translated NAT VTEP src address.
>> 
>> Thanks,
>> 
>> Sami
>> From: Linda Dunbar <[e-mail]>
>> Date: Thursday, September 14, 2017 at 12:33 PM
>> To: Sami Boutros <[e-mail]>, Dan Wing <[e-mail]>, "[e-mail]" <[e-mail]>
>> Cc: NVO3 <[e-mail]>
>> Subject: RE: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
>> 
>> Sami,
>> 
>> Sorry for the delayed response.
>> 
>> Answers are inserted below:
>> 
>> From: Sami Boutros [mailto:[e-mail]] 
>> Sent: Monday, September 11, 2017 12:24 PM
>> To: Linda Dunbar <[e-mail]>; Dan Wing <[e-mail]>; [e-mail]
>> Cc: NVO3 <[e-mail]>
>> Subject: Re: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
>> 
>> Hi Linda,
>> 
>> I have few clarifications and one question?
>> 
>> When an overlay tunnel traverses an SNAT GW, the source address of the VTEP will change to be the NAT source address. So, if we have an overlay tunnel between 2 endpoints and we are doing SNAT in one direction. The other endpoint will only see the translated NAT address.  
>> 
>> [Linda] Correct. China Telecom needs this type of deployment.
>> 
>> 
>> An overlay tunnel is bidirectional and doesn’t make an assumption that the overlay traffic carried over the tunnel will only be initiated from one side. 
>> 
>> [Linda] The tunnel is bidirectional, but the traffic is initiated from the CPE side for this scenario.
>> 
>> 
>> And it seems that what you are asking is to add directionality to the overlay tunnel, in which one endpoint can not send any overlay traffic unless it receives traffic from the other endpoint of the overlay tunnel, as well this endpoint should use the UDP source port received from the other initiating endpoint as the destination UDP port for the tunnel to accommodate for SNAT traversal.
>> 
>> [Linda] The so called “Overlay tunnel” is simply the encapsulation done by both end points. In the scenario depicted, the traffic is initiated from the CPE to the Gateway, and can be returned by the Gateway. Therefore, the tunnel is bi-directionally.  I don’t see any extra work needed to add “directionality to the overlay tunnel”
>> 
>> Linda 
>> 
>> Is my understanding correct?
>> 
>> Thanks,
>> 
>> Sami
>> 
>> From: Linda Dunbar <[e-mail]>
>> Date: Friday, September 8, 2017 at 2:31 PM
>> To: Dan Wing <[e-mail]>, "[e-mail]" <[e-mail]>, Sami Boutros <[e-mail]>
>> Cc: NVO3 <[e-mail]>
>> Subject: Suggested wording for the "NAT Traversing Consideration" to be added to the Section 6 of draft-ietf-nvo3-encap-00
>> 
>> Sami, et al:
>> 
>> Follow up the discussion during IETF 99, I took the stab putting together the wording to describe why it is an issue for VxLAN encapsulated data frames traversing NAT. I think this sub-section should be included in the Section 6 of the draft-ietf-nvo3-encap.
>> 
>> Linda Dunbar
>> 
>> ----------------------------------------------------------------------
>> 
>> 6.10 NAT Traversal consideration
>> Here is an example of encapsulated traffic traversing NAT (Network Address Translation) or, to be precise, NAPT (Network Address and Port Translation):
>> <image001.jpg>
>> Figure x – Scenario of Overlay Tunnel traversing NAT
>> 
>> If the Overlay Tunnel uses VxLAN encapsulation [RFC7348], IANA assigned Port 4789 is used in the outer frames’ destination port field and hashed value of inner packet is used in the outer frames’ source port field [RFC 7348].  Using different source port numbers is for achieving better traffic distribution among multiple paths.  This approach is fine within one data center, but can cause trouble when traversing NAT.
>> Many NAT devices use Source Address and Port number of the data frames coming from private addresses to derive the source port number for the frames sent to the public network, as shown below (assuming VxLAN is used for encapsulation between the CPEs and the Gateway).  The NAT Public Source Port H1/H2/H3/H4 can’t be the same, otherwise the NAT device can’t tell if the return data frames should be sent to CPE1 or CPE2.
>> 
>> Private Source Address
>> Private Source Port
>> Private Destination Port 
>> NAT Public Source Addr
>> NAT public Source Port
>> NAT public Destination Port
>> CPE1
>> A1
>> 4789
>> Public A
>> H1
>> 4789
>> CPE1
>> A2
>> 4789
>> Public A
>> H2
>> 4789
>> CPE2
>> A3
>> 4789
>> Public A
>> H3
>> 4789
>> CPE2
>> A4
>> 4789
>> Public A
>> H4
>> 4789
>> 
>> Per RFC 7348, the destination port number of the data frames returned from the Gateway should be 4789. When the NAT device receive the data frames (with the destination port = 4789) from the Public Network (i.e. from the Gateway in the figure above), the NAT device has to drop the data frames as the Destination Port 4789 is not one of H1/H2/H3/H4.
>> Of course, we can always modify the NAT devices to accommodate the VxLAN encapsulated data frames. The problem is traversing the existing NAT devices already deployed.
>> --------------------------------------  
>> 
>> Sincerely hope the editors to draft-ietf-nvo3-encap can add those suggested text to the draft.
>> 
>> Linda Dunbar
>> 
>> _____________________________________________
>> From: Linda Dunbar 
>> Sent: Thursday, July 13, 2017 2:31 PM
>> To: 'Dan Wing' <[e-mail]>
>> Cc: NVO3 <[e-mail]>; [e-mail]
>> Subject: RE: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
>> 
>> 
>> Dan,
>> 
>> Thanks for pointing out the Geneve's processing for traversing VxLAN.
>> 
>> First of all I wasn't proposing using reduced set of source ports. I think that the general document needs to add the consideration for traversing NAT because it is an issue for IPv4. Joe Touch suggested adding the entropy in the IPv6 flow ID as a solution for IPv6.
>> 
>> As for your suggested approach in Geneve:
>> The reverse traffic is sent to the Geneve destination port (6081), and a firewall or NAT or NAPT mapping is necessary for UDP/6081 traffic -- on both datacenters, which both probably have their own underlay NAPTs.  Those firewalls (or NATs or NAPTs) need to have appropriate pinholes for UDP/6081.
>> 
>> Does it mean all reverse traffic only use UDP port 6081?
>> Or all the NAT device convert the NVE’s UDP port 6081 to multiple port numbers?
>> 
>> Thanks,
>> Linda
>> 
>> -----Original Message-----
>> From: Dan Wing [mailto:[e-mail]] 
>> Sent: Wednesday, July 12, 2017 6:09 PM
>> To: Linda Dunbar <[e-mail]>
>> Cc: NVO3 <[e-mail]>; [e-mail]
>> Subject: Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT
>> 
>> 
>>> On Jul 12, 2017, at 12:37 PM, Linda Dunbar <[e-mail]> wrote:
>>> 
>>> Sami, et al,
>>> 
>>> 
>>> 
>>> The draft-ietf-nvo3-encap-00 is written very clear.
>>> 
>>> 
>>> 
>>> However, the Section 6 (Common Encapsulation Considerations) should add a sub-section on the consideration of traversing NAPT.  Encapsulated traffic could go to different data centers or WAN, which could go through Network Address Port Translation devices
>>> 
>>> 
>>> 
>>> Using VxLAN as an example: VxLAN specification [RFC 7348] uses a set of Port numbers to achieve better traffic distribution among multiple paths, which is fine within one data center, but causing trouble when traversing NAPT.
>> 
>> You're describing a problem with Geneve, which mimics VXLAN in that both of them suggest using a wide range of UDP ports to help underlay ECMP and to help receiver CPU load balancing, specifically this text of https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnvo3-2Dgeneve-3A&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=JVfdVYy3BrUDhZx4ZdLfwKHw_6NfcycUjhx4GlepvXE&s=hqGiAon1Fo8tWEivuKr2TEh2yRYzg9IIbpQHO1C1-yg&e= 
>> 
>>   Source port:  A source port selected by the originating tunnel
>>      endpoint.  This source port SHOULD be the same for all packets
>>      belonging to a single encapsulated flow to prevent reordering due
>>      to the use of different paths.  To encourage an even distribution
>>      of flows across multiple links, the source port SHOULD be
>>      calculated using a hash of the encapsulated packet headers using,
>>      for example, a traditional 5-tuple.  Since the port represents a
>>      flow identifier rather than a true UDP connection, the entire
>>      16-bit range MAY be used to maximize entropy.
>> 
>> If a reduced set of source ports is used instead, as you propose, the ECMP and CPU load balancing benefits are lost.  That seems problematic.
>> 
>>> NAPT use Port number to map back the source address. With a set of port numbers, NAPT can’t easily figure out the reverse direction traffic’s final IP addresses.
>> 
>> The reverse traffic doesn't use the inverted 5-tuple.  The reverse traffic is sent to the Geneve destination port (6081), and a firewall or NAT or NAPT mapping is necessary for UDP/6081 traffic -- on both datacenters, which both probably have their own underlay NAPTs.  Those firewalls (or NATs or NAPTs) need to have appropriate pinholes for UDP/6081.
>> 
>>> In addition, since the IP of packets change through NAPT device, it can mess up the learning of the peer NVE used in encapsulation.
>> 
>> The underlay did the NAPT, so I don't see a problem with the NVE overlay getting confused.  Could you explain in more detail?
>> 
>>> STUN can be used to get changed IP and port from NAPT device, but it requires NAPT device support STUN.
>> 
>> NAPT devices are not expected to implement STUN.  STUN is expected to be implemented in the hosts behind the NAT and on a server on the other side of the NAT (usually on a server on the Internet).  See Figure 1 on page 6 of https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5389-23page-2D6&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=JVfdVYy3BrUDhZx4ZdLfwKHw_6NfcycUjhx4GlepvXE&s=1nrxWvsqi-o7i2t6n0fS6cS070-aqwJKHFT5sCF4cPg&e= .
>> 
>>> That’s not available in some scenarios. Furthermore, it can’t solve the aforementioned five-tuple issue.
>>> 
>>> 
>>> 
>>> VXLAN over IPSec may be used to deal with the above problems,
>> 
>> Both Geneve and VXLAN run over UDP, and both use a fixed destination port (rather than inverted 5-tuple) for return traffic.  Not sure how VXLAN succeeds at dealing with the above problems, but I would love to learn.
>> 
>>> but IPSec brings up to 88 bytes of overhead plus the key distribution management, which can lower the efficiency.
>> 
>> Should be able to use IPsec transport mode, which is more around 40 bytes overhead.
>> 
>> -d
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> Suggestion: Add Section 6.10 Traversing NAPT consideration.
>>> 
>>> I can help to provide the text if you all think the suggestion is acceptable.
>>> 
>>> 
>>> 
>>> We can discuss more in Prague.
>>> 
>>> 
>>> 
>>> Thanks, Linda Dunbar
>>> 
>>> 
>>> 
>>> Huawei USA IP Technology Lab
>>> 
>>> 5340 Legacy Drive,
>>> 
>>> Plano, TX 75024
>>> 
>>> Tel: [phone] - 5840
>>> 
>>> Fax: [phone] - 5900
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> nvo3 mailing list
>>> [e-mail]
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=60T3yKN2I7oCxe8OH9mfZix-2ykSSjL-P-RoXCkZGdg&s=q7A_LzZuDp-yZnlA7Xw_N7yuLk4HO7K07jgl3Z78Ixg&e=