1 / 12

NAT Behavioral Requirements for Unicast UDP

NAT Behavioral Requirements for Unicast UDP. draft-ietf-behave-nat-upd-00 François Audet - audet@nortel.com Cullen Jennings - fluffy@cisco.com. Status. 2 nd release of Working Group Document Posted January 10 th Last version was draft-audet-nat-behave-00 presented at IETF 61

astra
Download Presentation

NAT Behavioral Requirements for Unicast UDP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NAT Behavioral Requirements for Unicast UDP draft-ietf-behave-nat-upd-00 François Audet - audet@nortel.com Cullen Jennings - fluffy@cisco.com draft-ietf-behave-nat-udp-00

  2. Status • 2nd release of Working Group Document • Posted January 10th • Last version was draft-audet-nat-behave-00 presented at IETF 61 • Integrates decisions made in IETF 61 and on mailing list since then • No major outstanding issue draft-ietf-behave-nat-udp-00

  3. Terminology • “address and port mapping” ≠ “binding” • translation between an external address and port and an internal address and port • Different from “binding” as per RFC 2663, MIDCOM, etc. draft-ietf-behave-nat-udp-00

  4. Applicability statement • New text for “big NAT/FW opt-out” • Because of other more important requirements, security, multihoming, etc., some large Enterprise NATs may decide to comply to only some of the requirements in this draft • Based on last meeting’s input • Any concerns? draft-ietf-behave-nat-udp-00

  5. Removal of redundant REQs • No more “It is RECOMMENDED that X but you MAY also Y”. Replaced with “It is RECOMMENDED that X” • No more “best effort nonsense” • Simpler and clearer • Removal of REQ-8 “The NAT UDP filter timeout behavior MUST be the same as the NAT UDP binding timeout”. (confusing) draft-ietf-behave-nat-udp-00

  6. Source Port Range • Well-known (0-1023), Registered (1024-49151), Dynamic/Private (49152-65535) • Old text: MUST NOT use Well-known (REQ-3c) • New text (agreed at last meeting): • If the host's source port was in the range 1-1023, it is RECOMMENDED the NAT's source port also be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port also be in that range. draft-ietf-behave-nat-udp-00

  7. ALGs • Old text: • A NAT MUST have the capability to turn off individually all ALGs it supports, except for DNS and IPsec (REQ-10) • Any NAT ALG for SIP MUST be turned off by default (REQ-10a) • New text (agreed at last meeting): • REQ-9 If a NAT includes ALGs, it is RECOMMENDED that all of those ALGs be disabled by default. (REQ-9) • If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. (REQ-9a) draft-ietf-behave-nat-udp-00

  8. Deterministic behavior • Clarification of requirement: • A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT mapping or the External External Filtering Behavior at any point in time or under any particular conditions. (REQ-10) draft-ietf-behave-nat-udp-00

  9. Port Parity • Finally and agreement • No change to requirement (RECOMMEND respecting port parity) • Changed wording on RFC 3550 • Explains that some implementation don’t support RFC 3605 and may substract one to an RTP port if it is odd causing lost media (even if the sender did everything correctly), thus the recommendation • Note: SDP-new-24 now explains that if you don’t respect the parity and/or contiguity rule (because of NAT for example), then you must use RFC 3605 draft-ietf-behave-nat-udp-00

  10. RTCP=RTP+1 • No requirement to attempt to preserve the Port contiguity rule • New text (agreed at last meeting): • Explaining that techniques currently used (sequential assignment, port reservation) have significant issues with glare and/or is wasteful for non-RTP UDP packets. • Separate negotiation must be done by application, e.g., RFC 3605 (out-of-scope of this document: for app document). draft-ietf-behave-nat-udp-00

  11. Relationship with Cone and Symmetric NAT Terminology • New explanatory section ------------------------------------------------ || External Filtering Behavior | -------------------++---------------------------------------------| | External NAT || Endpoint | Endpoint | Endpoint | | Mapping Behavior || Independent | Address | Address/Port | | || | Dependent | Dependent | |=================================================================| | Endpoint || Full | Restricted | Port Restricted | | Independent || Cone | Cone | Cone | |------------------++-------------+-------------+-----------------| | Endpoint Address || Symmetric~ | Symmetric~ | Symmetric~ | | Dependent || (a) | (a, 2) | (a, b) | |------------------++-------------+-------------+-----------------| | Endpoint Address || Symmetric~ | Symmetric | Symmetric~ | | /Port Dependent || (1) | (1, 2) | (1, b) | ------------------------------------------------------------------- draft-ietf-behave-nat-udp-00

  12. Open issues • Port preservation • REQ-3: It is RECOMMENDED that a NAT have a "Port assignment" behavior of "No port preservation". • NAT MAY use a "Port assignment" behavior of "Port preservation". • Not recommending “port preservation” is meaningless because “random” can mean preservation • Either we recommend port preservation or we don’t recommend anything at all • Proposal: Don’t recommend anything at all (i.e., ports may or may not be preserved: not important) • Others? Next step? draft-ietf-behave-nat-udp-00

More Related