1

NAT/Firewall NSLPNAT/Firewall NSLP

IETF 61th November 2004draft-ietf-nsis-nslp-natfw-04.txt

Martin Stiemerling, Hannes Tschofenig, Cedric Aoun

2

Changes in -04Changes 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

Proxy Mode 1/2Proxy 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

Proxy Mode 2/2Proxy Mode 2/2

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

5

NotifyNotify

• 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

Close PinholesClose 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

Open IssuesOpen 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.