1. 0 NAT/Firewall NSLP IETF 63th – August 2005 draft-ietf-nsis-nslp-natfw-07.txt Martin Stiemerling, Hannes Tschofenig, Cedric Aoun

2. 1 Solved Issues NATFW NSLP issue trac ker  https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/ Solved Issues  I2: Installation of packet filters (in addition to pinholes)  I3: Wildcarding of policy rules  I10: Twice NAT handling  I12: Specific IANA port number for REA message  I17: Enable NSLP to carry TCP sequence numbers?  I19: Add new reference for RSVP/Firewall traversal  I31: NATFW NSLP Path Change Handling  I37: Proxy mode selection for DR behind NAT or Firewall

3. 2 Route-Change Handling Node detecting route change generates NOTIFY NOTIFY propagates to NI NI takes action depending on session  Sending CREATE/REA/UCREATE message Requires NI to act but keeps NFs simple

4. 3 Route-Change Handling Node detecting route change generates NOTIFY NOTIFY propagates to NI NI takes action depending on session  Sending CREATE/REA/UCREATE message Requires NI to act but keeps NFs simple NSLP Session X NOTIFY NR NI NF CREATE

5. 4 Proxy mode selection for DR behind NAT or Firewall Draft -06 discussed only possible solutions New text in draft -07:  It is RECOMMENDED that a DR behind NATs uses the proxy mode of operation by default, unless the DR knows that the DS is NSIS aware.

6. 5 Open Issues In total 17 open issues Some open issues  Port range parameter field (I29)  Keep port parity field/semantics (I28)  Session ownership (I7)  Exact semantics of UCREATE (I38)

7. 6 Issues 29/28: L4-Ports Issue 29: Port range parameter field  Some applications, such as RTP, require to run on two subsequent port numbers  Suggestion: Applications should use RFC 3605 and close issue Issue 28: Keep port parity field/semantics  As issue 29, some applications need not only 2 subsequent port numbers but keeping port parity too.  Suggestion: close issue.

8. 7 Session Ownership Current draft uses a public/private key mechanism to sign each message  Session ID and signature are used to prove ownership  Purpose-built keys (PBK)  Section 3.8 “Session Ownership” Puts heavy computational burden on NSLP nodes Recent changes discussed on Tuesday  No public/private key since too heavy  Relying on random session ID  Gives protection against off-path attackers  On-path attackers are hard to handle if present at session setup (without validating their claimed role in the network by using a security infrastructure)

9. 8 NR behind Firewall Protection In the case of a NR behind a firewall the current draft says:  Firewall NATFW NSLP must allow incoming NSIS signaling traffic towards an NR. Effectively this is a nice chance to attack any NSIS enabled hosts in an otherwise protected network Suggestion to change:  remove above requirement.  DR/NR must tell firewall its willingness to receive NSIS signaling  NR behind firewall must run a “firewall REA”  “firewall REA” = upstream message finding firewall & telling NSIS willingness  “firewall REA” could be an extended UCREATE The right firewall could be potentially known by out of band methods (real- time notification of out of bound peak packet rate for specific flow type)

10. 9 Semantics of UCREATE Proxy Mode for Data Receiver behind Firewall Used to block particular incoming data flows Can be used as “firewall REA”

11. 10 Conclusions Draft is stable in most parts Currently changing parts  Security  UCREATE semantics  REA objects and semantics  Mapping of policy rules to middlebox resources  Error code details and classification  Diagnosis procedures Diff between -06 and -07: http://www.stiemerling.org/ietf/nsis/draft-ietf-nsis-nslp-natfw-07-diff-to-06.html

12. 11 Thank you. Questions?