1. 0 NAT/Firewall NSLP IETF 61th November 2004 draft-ietf-nsis-nslp-natfw-04.txt Martin Stiemerling, Hannes Tschofenig, Cedric Aoun

2. 1 Changes in -04 Editorial changes Query  Removed user id Moved Section 3.4.x to 3.3.8 and 3.3.9  Sections are about proxy mode operation

3. 2 Proxy Mode 1/2 Removed section on “CREATE on previously pinned down path”  NR behind a NAT, NI not NSIS capable  NR uses REA to create ‘incoming’ data path  CREATE runs on reverse path created by REA  Excludes routing asymmetry Section 3.3.8 describes proxy mode

4. 3 Proxy Mode 2/2 DS Public Internet NAT Private address NR No NI | space | | REA[CREATE] | | |<------------------------------- | | | RESPONSE[Error/Su] | | | ----------------------------- > | | | CREATE | | | ------------------------------> | | | RESPONSE[Error/Su] | | | <------------------------------ | | | |

5. 4 Notify NOTIFY implements asynchronous messages NOTIFY carries codes indicating reason  Timeout  Local error in middlebox Notify address can be set  NOTIFY message is not sent up- or downstream  Message is sent to notify address What direction NOTIFY messages should be sent  Upstream or downstream  Upstream and downstream  Should there be switch for NI to decided which way?

6. 5 Close Pinholes Current NSLP: Default to Deny NATFW NSLP opens Firewall/NAT New: Closing Firewall pinholes Accepts open by default Do people feel that closing Firewall pinholes is a useful functionality? Does this apply to NATs as well?

7. 6 Open Issues Message extensibility Overview picture about NATFW elements Discussion about Firewall/NAT state transfer  Requested for mobile hosts  Host should be able to transfer state from one NATFW NSLP box to a new one Other open issues are in the NATFW NSLP issue tracker.