1 / 11

NAT/Firewall Behavioral Requirements

NAT/Firewall Behavioral Requirements. draft-ietf-behave-nat-00 François Audet - audet@nortelnetworks.com Cullen Jennings - fluffy@cisco.com. Status. Working Group Document Last version was draft-audet-nat-behave-00 presented at IETF 60

sarah-mason
Download Presentation

NAT/Firewall Behavioral Requirements

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/Firewall Behavioral Requirements draft-ietf-behave-nat-00 François Audet - audet@nortelnetworks.com Cullen Jennings - fluffy@cisco.com draft-ietf-behave-nat-00

  2. Status • Working Group Document • Last version was draft-audet-nat-behave-00 presented at IETF 60 • Integrates decisions made in IETF 60 on mailing list since then • Presentation also describes new mailing list discussion concensus reached after current text was submitted • No major outstanding issue draft-ietf-behave-nat-00

  3. Changes to Scope • Covers only NAT • Firewall out-of-scope: only “inherent filtering aspects of NAT” is in-scope • Covers only UDP Unicast • UDP Multicast in separate document • TCP Behavior to be in a separate document • “Application” aspects still out-of-scope (but very important!) draft-ietf-behave-nat-00

  4. IP address assignment • Multiple IP addresses on external side of NAT • IP address pooling: • “Arbitrary”: MUST NOT (REQ-2a) • “Paired, strict”: MAY (REQ-2b) • “Paired, best-effort”: RECOMMENDED (REQ-2) • Required for gaming and other protocols that don’t negotiate IP address for RTP/RTCP separately • Minimize port exhaustion draft-ietf-behave-nat-00

  5. RTCP=RTP+1 • No requirement to attempt to preserve the Port contiguity rule • Mailing list consensus for new text for next release: • Explaining that techniques currently used (sequential assignment, port reservation) have significant issues with glare and/or is wasteful for non-RTP UDP packets. • OK with Magnus Westerlund (AVT): RTSP impact • Separate negotiation must be done by application (out-of-scope of this document, but very important for application document). draft-ietf-behave-nat-00

  6. Source Port Range • Well-known (0-1023), Registered (1024-49151), Dynamic/Private (49152-65535) • Current text: MUST NOT use Well-known (REQ-3c) • Mailing list discussion: • Some applications will break with this (RFC 2623) • Mailing list agreement for next version: • If the host's source port was in the range 0-1023, the NAT's source port MUST also be in the same range. If the host's source port was in the range 1024-65535, the NAT's source port MUST also be in that range. (REQ-3c) • Everybody OK with this? draft-ietf-behave-nat-00

  7. Port Parity Preservation • Port Parity Preservation Behavior • “Yes, best effort”: RECOMMENDED (REQ 4) • “Yes, strict”: MAY (REQ-4a) • “No”: MUST NOT (REQ-4b) • Respect RTP/RTCP parity convention when possible, without running out of ports unnecessarily • Some RFC 3550 has some wording that may cause applications to unilaterally subtract 1 to an odd RTP port • Reasonable and Simple to implement draft-ietf-behave-nat-00

  8. Binding refresh direction • Outbound Refresh = True: MUST (REQ-6) • No change • Inband Refresh = True: MAY (REQ-6a) • To allow for multicast, described in new document (i.e., no conflict between 2 document) draft-ietf-behave-nat-00

  9. Fragmentation • New text provided by Dan Wing • Much clearer than old text • MUST support fragmentation of packets larger than link MTU (REQ-13) • MUST support receiving in order fragments, so MUST be RF=O or RF=OO (REQ-14) • MAY support receiving out of order fragments and be RF=OO (REQ-14a) draft-ietf-behave-nat-00

  10. ALGs • Current 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) • Mailing list discussion consensus text for next version: • If a NAT includes ALGs, all of those ALGs MUST be disabled by default. (REQ-10) • If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the user to enable or disable each ALG separately. (REQ-10a) • IPsec is not relevant to UDP • Stronger stance against ALGs being “off” by default draft-ietf-behave-nat-00

  11. Open issues • Do we need an explicit REQ for the “don’t attempt to fix RTCP=RTP+1 rule because you’ll break more things!”? • Or is explanatory text enough? • Others? draft-ietf-behave-nat-00

More Related