410 likes | 558 Views
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
E N D
NSIS NATFW NSLP:A Network Firewall Control Protocoldraft-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 apath-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
Client/Server Signaling IP Telephone IP Telephone Client/Server Firewall SignalingExample: VoIP Network SIP Server Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall SIP signalling RTP/UDP voice transmission
IP Telephone IP Telephone Client/Server Firewall SignalingExample: VoIP Network SIP Server Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall SIP signalling RTP/UDP voice transmission
IP Telephone IP Telephone NSIS NATFW Firewall SignalingExample: VoIP Network SIP Server Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall SIP signalling RTP/UDP voice transmission NSIS NATFW signalling
IP Telephone IP Telephone NSIS NATFW Firewall SignalingExample: VoIP Network SIP Server Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall SIP signalling RTP/UDP voice transmission 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 Signalling Layer (NSLP) NSIS Transport Layer (NTLP) • 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
NSIS router NSIS router Need Firewall Configuration! Need Firewall Configuration! Need Firewall Configuration! NTLP Stack NTLP Stack NTLP Stack NTLP Stack Here it is! Here it is! Here it is! Are you my next node? (discovery) Abstraction UDP transport NTLP Stack NTLP Stack NTLP Stack NTLP Stack NSIS Host B NSIS Host A Router without NSIS Router without NSIS View on NSIS’ Layers NSLP View TCP connection NTLP View Network View
NSIS Documents • Available online • NSIS Framework, RFC 3726 • NTLP (GIST), Internet Draft • NATFW NSLP, Internet Draft • More documents on • 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
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
NSLP CREATE message Data Receiver Data Sender NSLP RESPONSE message Data Sender behind Firewall • Firewall is blocking by default • Signaling with allow action Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP REA message (running against flow direction) Data Receiver Data Sender NSLP RESPONSE message Data Receiver behind Firewall • Firewall is blocking by default • Signaling with allow action Remember State for Incoming NSLP request Firewall Provider 1 Firewall Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
Data Receiver Data Sender NSLP CREATE message NSLP RESPONSE message Data Receiver behind Firewall • Firewall is blocking by default • Signaling with allow action Remember State for Incoming NSLP request ! Firewall Provider 1 Firewall Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP REA message (running against flow direction) Data Receiver Data Sender NSLP RESPONSE message Data Receiver behind Firewall:Terminal Proxy Mode • Firewall is blocking by default • Signaling with allow action • Data sender NSIS unaware Processing Stops at Edge-Firewall Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP CREATE message Data Receiver Data Sender NSLP RESPONSE message Data Sender behind Firewall:Terminal Proxy Mode Processing Stops at Edge-Firewall • Firewall is blocking by default • Signaling with allow action • Data Receiver NSIS unaware Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP REA message (running against flow direction) Data Receiver Data Sender Attacker NSLP RESPONSE message Data Receiver behind Firewall:Terminal Proxy Mode and Attack Response • Firewall is open by default • Data Sender is an attacker • Signaling with deny action • Using sameREA message Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP REA message (running against flow direction) Data Receiver Data Sender Attacker NSLP RESPONSE message Data Receiver behind Firewall:Terminal Proxy Mode and Attack Response • Firewall is open by default • Data Sender is an attacker • Signaling with deny action • Using sameREA message Firewall Provider 1 Internet Core NW Access NW X Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP REA message (running against flow direction) Data Receiver Data Sender Attacker Data Receiver behind Firewall:Network Proxy Mode and Attack Response • Firewall is open by default • Data Receiver NSIS unaware • Data Sender is an attacker • Signaling with deny action • Using same REA message Firewall Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP REA message (running against flow direction) Data Receiver Data Sender Attacker NSLP RESPONSE message Data Receiver behind Firewall:Network Proxy Mode and Attack Response • Firewall is open by default • Data Receiver NSIS unaware • Data Sender is an attacker • Signaling with deny action • Using same REA message Firewall Provider 1 Internet Core NW Access NW X Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP NOTIFY message Data Receiver Data Sender Path Maintenance • Path is automatically maintained • NSIS reacts to route changes • Planned removal of firewalls • Firewall failures Firewall X Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
NSLP NOTIFY message Data Receiver Data Sender NSLP CREATE message NSLP RESPONSE message Path Maintenance • Path is automatically maintained • NSIS reacts to route changes • Planned removal of firewalls • Firewall failures Firewall X Provider 1 Internet Core NW Access NW Firewall Provider 2 Firewall NSIS NATFW signalling Data flow
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 http://www.ietf.org/internet-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 http://www.stiemerling.org/ietf/nsis/snapshot
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?
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 compared to Client/Server
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 • http://www.ietf.org/html.charters/midcom-charter.html • 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 • http://www.ietf.org/html.charters/nsis-charter.html • NSIS WG chair • John Loughney john.loughney@nokia.com • NATFW NSLP authors • Martin Stiemerling stiemerling@netlab.nec.de • Hannes Tschofenig Hannes.Tschofenig@siemens.com • Cedric Aoun cedric@caoun.net
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?