draft-ietf-behave-nat-udp-00 NAT Behavioral Requirements for Unicast UDP draft-ietf-behave-nat-upd-00 François Audet - Cullen Jennings -

draft-ietf-behave-nat-udp-00 Status 2 nd release of Working Group Document Posted January 10 th 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 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 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 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 Source Port Range Well-known (0-1023), Registered ( ), Dynamic/Private ( ) 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 , it is RECOMMENDED the NAT's source port also be in the same range. If the host's source port was in the range , it is RECOMMENDED that the NAT's source port also be in that range.

draft-ietf-behave-nat-udp-00 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 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 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 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 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 Open issues Port preservation –REQ-3: It is RECOMMENDED that a NAT have a "Port assignment" behavior of "No port preservation". a)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?