1 / 11

NATFW NSLP Status draft-ietf-nsis-nslp-natfw-12.txt

This document provides the latest status and updates on the NATFW.NSLP protocol, including discussion points, issues, and proposed changes. The document also covers topics such as NAT-PT support, DTINFO issues, and TRACE semantics.

mannm
Download Presentation

NATFW NSLP Status draft-ietf-nsis-nslp-natfw-12.txt

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. NATFW NSLP Statusdraft-ietf-nsis-nslp-natfw-12.txt M. Stiemerling, H. Tschofenig, C. Aoun, and E. Davies stiemerling@netlab.nec.de NSIS Working Group, 66th IETF meeting

  2. 3GPP2 and NSIS • Network Firewall Configuration & Control Protocol (NFCCP) • "Requirements for Firewall Configuration Protocol”(draft-bajko-nsis-FW-reqs-04.txt) • Presentation of the NATFW NSLP at the Jan 17th meeting by John • TSG-X, PSN, WG 3.1 • Slides are here http://www.stiemerling.org/ietf/nsis/3gpp2/3gpp2_nsis_natfw_overview_final.ppt • 3GPP2 WG is in favour of the path-coupled NSIS approach • NSIS NATFW NSLP is the NFCCP! • Discussion between NATFW NSLP authors and 3GPP2 group are on-going

  3. Status • draft-ietf-nsis-nslp-natfw-11 • After IETF-65 version for WGLC • Received comments editorial & technical • draft-ietf-nsis-nslp-natfw-12 • First changes after WGLC comments • Mainly editorial changes due to WGLC • Diff is here • http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-12-diff-to-11.html • NATFW issue trackerhttps://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/

  4. Some Issues • Who is defining the NSLP object space? • It is not in GIST! • Signaling Destination Address (SDA) selection appendix • Quite old • Needs to be reworked • Input is welcome! • Terminology issues • NSLP signaling vs. Application signaling • Different “modes” • Signaling exchanges • Etc.

  5. REA Naming Contest • REA = Reserve External Address (REA) • Past: Used to get external address/port at NAT • Name was 100% fit • But semantics changed over time • Now: • Used to get external address/port at NAT • Used to install firewall rules for inbound traffic • Used in proxy mode usage • Name seems to inappropriate! • Need new name but no idea... • REA naming contest (reanco) • Starts today July 12th • Runs until August 3rd 8am EST • Send suggestions to NSIS WG mailing list • Prize: Six-pack of local beer at next IETF in San Diego • All legal things apply here: participants must be older than 18 or 21 years (depending on location of IETF and the local laws), no guarantees, not entitled for anything, must be at the next IETF meeting, etc...

  6. NAT-PT Support • Draft -12 unspecified about NAT-PT usage(RFC 2766). • Past revisions had text specifying NAT-PT • NAT-PT support has been removed • One of the reasons ishttp://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-03.txt • Where to go with NAT-PT support? • Overall tendency (list opinion): Do not support NAT-PT • Not really recommended... • There is no known deployment to us. • Keep “Remove NAT-PT”.

  7. DTINFO Issues • Carries additional information for REA • Port numbers • Transport protocol • Basically all things not in the LE-MRM • DTINFO_IPv4 ambiguity issues • Usage not fully specified • Editorial changes needed • DTINFO_IPv4 MAY be included • But required in many cases (above 50%) • Change to MUST and wildcard fields (if needed)

  8. DTINFO_IPv6 • DTINFO_IPv6 was removed • Same as DTINFO_IPv4 • Removed due to removal of NAT-PT support • Caused confusion • DTINFO_IPv6 could be used for back-to-back NAT-PT: • Proposal: Keep removed.

  9. TRACE Semantics • TRACE: a request message to trace all involved NATFW NSLP nodes in a particular signaling session. • Defined simple semantics • Defined object • Overall semantics still shaky.

  10. TRACE Issues • Which type of information should be conveyed? • Currently: IPv4 or IPv6 addresses • Support for any “identifier”* included • NATs: which IP to report? • Why are you only allowed to TRACE from the session owner? • Many more... • Asked for well-defined semantics on May 11 • Still no proposal for semantics • Give YOUR input and discussions NOW • Without input TRACE needs to be removed!

  11. Thank you! Question?

More Related