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

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

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 describes proxy mode

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

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?

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?

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.