NSIS NATFW NSLP: A Network Firewall Control Protocol draft-ietf-nsis-nslp-natfw-08.txt IETF NSIS Working Group January 2006 M. Stiemerling, H. Tschofenig, C. Aoun, and J. Loughney

NSIS Scope Next Steps in Signaling (NSIS) working group Responsible for standardizing a path-coupled IP signaling protocol  QoS signaling  For Firewall and NAT signaling  Extensible for others as well Follows a two-layer signaling paradigm A more general signaling model than RSVP

Internet Provider 1 Provider 2 Core NW Firewall IP Telephone IP Telephone SIP Server SIP signallingRTP/UDP voice transmission Access NW Client/Server Signaling Client/Server Firewall Signaling Example: VoIP Network

Internet Provider 1 Provider 2 Core NW Firewall IP Telephone IP Telephone SIP Server SIP signallingRTP/UDP voice transmission Access NW

NSIS NATFW Firewall Signaling Example: VoIP Network Internet Provider 1 Provider 2 Core NW Firewall IP Telephone IP Telephone SIP Server SIP signallingRTP/UDP voice transmission Access NW NSIS NATFW signalling

NSIS NATFW Firewall Signaling Example: VoIP Network Internet Provider 1 Provider 2 Core NW Firewall IP Telephone IP Telephone SIP Server SIP signallingRTP/UDP voice transmission Access NW NSIS NATFW signalling

Protocol Examples Path-decoupled (Client/Server)  COPS  MEGACO  DIAMETER  MIDCOM Path-coupled  Resource Reservation Protocol (RSVP, RFC 2205)  IETF NSIS (Next Steps in Signaling)

RSVP vs. NSIS RSVP  Made for resource reservation per data flows  Resource = QoS reservation  Implementation difficulties  Many timers used per flow  Multicast support  Limited extensibility (objects and semantics)  Not adapted to today’s needs NSIS  Intended to fix difficulties of RSVP  Less timers  Easy to extend  No multicast support  Adapted to today’s networking needs  No multicast support  Mobility support  Signal for any resource possible (not only QoS)  Flexibility in protocol extension in any degree

NSIS Framework Flexible/extendable message transport  Reliability/order protection  Keepalive and multiplexing  Some security services  Common transport functions Flexible/extendable multiple signalling application  Per flow QoS (IntServ)  Flow aggregate QoS (DiffServ)  Firewall and Network Address Translator (NAT)  Traffic meter configuration  And others A two-layer split  Transport layer (NTLP or GIST)  Signalling layer (NSLP) NSIS framework defined in RFC 3726

NSIS 2 Layer Split NSIS Transport Layer (NTLP) NSIS Signalling Layer (NSLP) Two names for transport layer: NTLP (the basic concept) GIST (the protocol implementation Generic Internet Signalling Transport

NSIS Transport Layer (NTLP) NTLP/GIST responsible for  Transport signalling message through network  Finding necessary network elements Abstraction of transport to NSLPs  NSLP do not care about transport at all

NSIS Signaling Layer (NSLP) NSLP contains the signalling intelligence QoS signalling  Finds NSIS QoS devices  How to reserve resources (bandwidth, jitter, etc)  If per flow or per aggregate QoS Firewall/NAT signalling  Finds NSIS firewall/NAT devices  Opening pinholes in firewalls  Creating address bindings in NATs Or any other signalling application!  Example: traffic meter configuration

TCP connection View on NSIS’ Layers NSIS Host A NSIS Host B NSIS router Network View Router without NSIS Router without NSIS NSIS router NTLP View NTLP Stack NTLP Stack NTLP Stack NTLP Stack NSLP View NTLP Stack NTLP Stack NTLP Stack NTLP Stack UDP transport Are you my next node? (discovery) Need Firewall Configuration! Here it is! Abstraction Need Firewall Configuration! Need Firewall Configuration!

NSIS Documents Available online  NSIS Framework, RFC 3726RFC 3726  NTLP (GIST), Internet DraftInternet Draft  NATFW NSLP, Internet DraftInternet Draft More documents on  NSIS WG home page NSIS WG home page Working copy of the NATFW NSLP M. Martin, M. Brunner, M. Stiemerling, A. Fessi, “Path-coupled signaling for NAT/Firewall traversal”, HPSR 2005, Hong Kong

The NATFW NSLP

NATFW NSLP “Find all firewalls on my data path and configure them to my needs, independent of application signaling and data protocol to be used.” NATFW NSLP features  On-path firewall detection  Automatic firewall configuration  “Fire and forget” approach (no configuration)  Support for allow and deny configuration  End-to-end signaling  End-to-middle signaling  Middle-to-middle signaling  Soft-state mechanism

Filter Parameter NATFW NSLP filter parameter  IPv4 and IPv6  Source/destination IP addresses  Source/destination IP prefix length  IP protocol (e.g., TCP, UDP, IP, SCTP, etc)  Diffserv-codepoint (DSCP)  IPv6 flow label  IPsec SPI  Layer 4 ports (e.g., TCP and UDP) Ranges/wildcarding of these parameters Allocation of subsequent port numbers  Used by legacy VoIP applications for RTP+RTCP Extensible to other parameters needed!

NATFW Messages CREATE  Enabling data path to data receiver  Typically used for allowing data traffic REA  Locating upstream firewalls (towards data sender)  Used for allowing data traffic  Used for blocking data traffic  Used for enabling incoming NSIS signaling TRACE  Collecting information about involved firewalls RESPONSE  Positive and negative synchronous responses NOTIFY  Asynchronous notifications  Generated by firewalls

Data Sender behind Firewall Internet Provider 1 Provider 2 Core NW Firewall Data SenderData Receiver Data flow Access NW NSIS NATFW signalling NSLP CREATE message NSLP RESPONSE message Firewall is blocking by default Signaling with allow action

Data Receiver behind Firewall Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Data flow Access NW NSIS NATFW signalling Firewall is blocking by default Signaling with allow action NSLP REA message (running against flow direction) NSLP RESPONSE message Remember State for Incoming NSLP request Firewall

Data Receiver behind Firewall Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Data flow Access NW NSIS NATFW signalling Remember State for Incoming NSLP request NSLP CREATE message ! NSLP RESPONSE message Firewall is blocking by default Signaling with allow action

Data Receiver behind Firewall: Terminal Proxy Mode Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Data flow Access NW NSIS NATFW signalling Firewall is blocking by default Signaling with allow action Data sender NSIS unaware NSLP REA message (running against flow direction) NSLP RESPONSE message Processing Stops at Edge-Firewall

Data Sender behind Firewall: Terminal Proxy Mode Internet Provider 1 Provider 2 Core NW Firewall Data SenderData Receiver Data flow Access NW NSIS NATFW signalling Firewall is blocking by default Signaling with allow action Data Receiver NSIS unaware Processing Stops at Edge-Firewall NSLP CREATE message NSLP RESPONSE message

Data Receiver behind Firewall: Terminal Proxy Mode and Attack Response Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Attacker Data flow Access NW NSIS NATFW signalling Firewall is open by default Data Sender is an attacker Signaling with deny action Using same REA message NSLP REA message (running against flow direction) NSLP RESPONSE message

Data Receiver behind Firewall: Terminal Proxy Mode and Attack Response Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Attacker Data flow Access NW NSIS NATFW signalling Firewall is open by default Data Sender is an attacker Signaling with deny action Using same REA message NSLP REA message (running against flow direction) NSLP RESPONSE message X

Data Receiver behind Firewall: Network Proxy Mode and Attack Response Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Attacker Data flow Access NW NSIS NATFW signalling Firewall is open by default Data Receiver NSIS unaware Data Sender is an attacker Signaling with deny action Using same REA message NSLP REA message (running against flow direction)

Data Receiver behind Firewall: Network Proxy Mode and Attack Response Internet Provider 1 Provider 2 Core NW Firewall Data ReceiverData Sender Attacker Data flow Access NW NSIS NATFW signalling Firewall is open by default Data Receiver NSIS unaware Data Sender is an attacker Signaling with deny action Using same REA message NSLP REA message (running against flow direction) NSLP RESPONSE message X

Path Maintenance Internet Provider 1 Provider 2 Core NW Firewall Data SenderData Receiver Data flow Access NW NSIS NATFW signalling Path is automatically maintained NSIS reacts to route changes Planned removal of firewalls Firewall failures X NSLP NOTIFY message

Path Maintenance Internet Provider 1 Provider 2 Core NW Firewall Data SenderData Receiver Data flow Access NW NSIS NATFW signalling Path is automatically maintained NSIS reacts to route changes Planned removal of firewalls Firewall failures X NSLP NOTIFY message NSLP RESPONSE message NSLP CREATE message

NATFW NSLP Feature Summary Path-coupled signaling  No need for terminal configuration  Terminal ‘shoots’ towards sender/receiver  Appropriate firewall chosen automatically  No need for reconfiguration of signaling server  No need for topology knowledge  Firewall discovery relies on plain IP routing/packet forwarding  Reacts to route changes  Reacts to firewall failures or scheduled maintenance Proxy mode support  Proxying of messages by firewalls  Proxying of messages by non-terminal  Middle-to-middle signaling

NATFW NSLP Security Two-layer security  Interconnected! Transport layer (NTLP)  Securing signaling transport  Using TCP with TLS  Firewall identity management  Certificates Signaling layer (NATFW NSLP)  User management  Authentication and authorization  Policy decisions (User allowed to load filter rule?)

3GPP2 Requirements (1) Documented in drafts/draft-bajko-nsis-fw-reqs-04.txthttp:// drafts/draft-bajko-nsis-fw-reqs-04.txt NSIS NATFW NSLP fits major requirements NSIS WG open for further cooperation Upcoming draft adapted to 3GPP2 requirements  Support for multiple, subsequent port numbers  See

3GPP2 Requirements (2) Not yet fulfilled requirements  “A client MUST be able to specify pinholes that refer to encapsulated headers (tunnelled packets filtering).”  Supported by any firewall?  “A client MUST be able to specify pinholes that contain at least the routing options (Mobile IPv6). The protocol must be flexible enough to accomodate other IPv6 options and possibly for the ones which are not yet defined.”  This item is currently under discussion

3GPP2 Requirements (3) Single protocol instance requirements  “A client MUST be able to close any or all the pinholes it created with a single protocol instance.”  “A client MUST be able to refresh all associated pinhole timeouts with a single protocol instance.”  “The protocol MUST allow an end point to create, modify or delete several firewall states with one protocol instance.”  Not supported by NSIS due to signaling session paradigm  All resources are bound to a signaling session  Only resources within signaling session can be modified

3GPP2 Requirements (3) Further requirements  “The granularity of the rules MUST allow an end point to specify the TCP flags, and other transport protocol related information (e.g. the end point should have the ability to specify that it does not want to receive TCP SYN packets.”  Not supported, but can be extended!  What is the reasoning for this?  Usually TCP flags are required for stateful firewalls  “The protocol MUST allow the client to learn the features implemented in the FW and whether those are enabled or disabled”  Not supported and hard to implement  NATFW NSLP would return a whole chain for firewalls  What is the outcome of this?

NSIS compared to Client/Server No terminal configuration needed Automatic adaptation to network changes Network topology agnostic Proxy mode support Terminal configuration needed Topology knowledge need in server Static configuration

NSIS WG Status Documents done (RFC status)  Requirements of a Quality of Service (QoS)Solution for Mobile IP (RFC 3583)  Requirements for Signaling Protocols (RFC 3726)  Analysis of Existing Quality of Service Signaling Protocols (RFC 4094)  Next Steps in Signaling (NSIS): Framework (RFC 4080)  Security Threats for Next Steps in Signaling (NSIS) (RFC 4081)  RSVP Security Properties (RFC 4230) Document in Last Call  Transport Layer NTLP (draft-ietf-nsis-ntlp-08.txt) Documents to be completed soon  QoS NSLP (draft-ietf-nsis-qos-nslp-08.txt)  NATFW NSLP (draft-ietf-nsis-nslp-natfw-08.txt)

Related IETF Work MIDCOM working group  MIDCOM = MIDdlebox COMmunication   Defined a client/server firewall control protocol  MIDCOM MIB module (official protocol)  draft-ietf-midcom-mib-05.txt  SIMCO (unofficial protol, SImple Middlebox COntrol protocol)  Currently in RFC editor queue  draft-stiemerling-midcom-simco-08.txt  WG is going to finish all work soon.

Contact Addresses NSIS working group  NSIS WG chair  John Loughney NATFW NSLP authors  Martin Stiemerling  Hannes Tschofenig  Cedric Aoun

Conclusions Already several NTLP implementations  5 independent implementations  NEC/Siemens, 2 Universities, 1 SME  Interoperality event in July 2005 in Paris Two NATFW NSLP prototype implementations  NEC and Siemens NATFW NSLP fits well to 3GPP2’s requirements Powerful and flexible protocol and framework How can the NSIS WG help? For any comment, questions, and discussions contact us!

Thank you! Question?