0 NAT/Firewall NSLP Activities IETF 60th - August 2nd 2004 Cedric Aoun, Martin Stiemerling, Hannes Tschofenig

1 NAT/Firewall NSLP updates WG document has significantly improved and integrated prior analysis done in the accompanying ephemeral drafts NAT / Firewall NSLP - v01 -> v03 Security Threats for NAT/FW NSLP v01 Migration Draft v01 -> v02 Intra-realm considerations v00 -> v01 NAT/Firewall NSLP Security Problems Documents introduced after IETF 59

2 NATFW NSLP WG document updates Editorial changes:  increased readability, shortened section 2 and moved security discussions into one section  New terminology for Reserve External Address messages destination address: Opportunistic Address  New section: Section 4: NTLP requirements

3 NATFW NSLP WG document updates New messages and message processing changes: CREATE - Creates, maintains and deletes a NATFW NSLP session and all its associated policy rule states Reserve External Address (REA) RESPONSE - integrates all semantics of the previous response messages with usage of various response object types NOTIFY - asynchronous event notification message TRIGGER - Message used by NR to update and refresh policy rule state installed by NR requested CREATE. Allows deployments with one end initiative NSIS messages but not the other  CREATE messages sent from the far-end (i.e., not triggered) take precedence on triggered CREATE and no loner require TRIGGER messages to be sent by NR QUERY - query message used for diagnosis and potential NI misbehavior detection

4 NATFW NSLP WG document updates Protocol can signal policy rules with ‘drop‘ action  Feedback requested from WG on this as it has limited applicability Different response types - hinted by the RESPONSE_TYPE object: RESPONSE (usual case) CREATE:  A) Sent only if the responding node is not the message destination I.e.no NR on the other end  B) Sent by node meeting the scope  Sent either on the existing pinned down reverse or a new separate one  CREATE could be sent with a specific source address (if provided in the message triggering the CREATE) or the responding node address No RESPONSE(no RESPONSE_TYPE object inserted) case of NOTIFY messages and session states deleting CREATE messages

5 NR behind a NAT - existing capability DS Public Internet NAT Private address NR No NI | space | | REA[CREATE, DISC] | | |< | | | RESPONSE[Error/Success] | | | > | | |CREATE | | | > | | | RESPONSE[Error/Success] | | | > | | | | NR acts autonomously without Any DS NSIS capability knowledge No restriction on authorized data senders address

6 NR Behind NAT - extensions Foo.com Public Internet Bar.com DS NAT Firewall NR No NI | | TRIGGER[DSinfo] TRIGGER[DSinfo]< | < | | |CREATE | | | >|CREATE | | | > | | | RESPONSE[SUCCESS] | | < | RESPONSE[SUCCESS] | |< | | Refresh period expiry | or updates to Data Sender information | | | | | TRIGGER[DSinfo] TRIGGER[DSinfo]< | < | | | |CREATE | | >|CREATE | | | >| | | RESPONSE[SUCCESS] | | < | RESPONSE[SUCCESS] | |< | | NR acts autonomously without Any DS NSIS capability knowledge Authorized data sender address is limited to known DS address and port (if available to the user application layer)

7 NATFW NSLP WG document updates Session refresh still handled end to end  Refreshes only generated by NI and not by intermediate NE  BUT when intermediate NE requests lifetime changes  They also provide the associated Message Refresh Rate Allows the support of different relations between state lifetime and message refresh rate CREATE(lt=60s) CREATE(lt=20s) | | >| NSLP | > | | | NI | | | | NR | | |< | forwarder |< | | RESPONSE RESPONSE (lt=15s MRR=3s) (lt=15s MRR=3s) lt = lifetime MRR = Message Refresh Rate

8 NATFW NSLP WG document updates NATFW NSLP’s NTLP requirements:  Ability to detect that the NSIS Responder does not support NATFW NSLP  Detection of NATs and their support of the NSIS NATFW NSLP.  Message origin authentication and message integrity protection Will depend on used security approach: hop by hop or end to end  Detection of routing changes  Protection against malicious announcement of fake path changes  Transport of user application correlation information. This requirement allows NSLP NATFW to check that the message was solicited by prior application message exchanges before an NTLP messaging association is established between an NR and the upstream NF.

9 Open issues Procedural:  Authors sent protocol operations changes to mailing list but no comments were received? No news = GOOD NEWS :-) ? Should a REA always trigger a CREATE message? Should triggered CREATE messages be always sent on a new reverse path (and not the pinned down one)? Should TRIGGER messages require a RESPONSE?  In case a CREATE is not received by the NR it would know if the TRIGGER was received by its target

10 Open issues Usage of TRIGGER and REA variant for NRs behind Firewalls  Currently not discussed in the document, relates to: Scenarios where one end-host supports the protocol Drop action handling  Would have more issues with route asymmetry as no path anchoring provided as is the case with NR behind NAT scenario  In case the host was the application initiator it would send the CREATE triggering a CREATE, but if it wasn’t the application initiator TRIGGER would certainly be useful Message and object format alignment to NTLP and Qos NSLP  Do we have agreement on the format?  Extensibility handling and its integration in the object format Twice NAT handling Security issues - discussed in security presentation