NSIS NATFW NSLP: A Network Firewall Control Protocol draft-ietf-nsis-nslp-natfw-08.txt

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

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

IPTelephone

IPTelephone

SIP Server

SIP signalling RTP/UDP voice transmission

AccessNW

Client/Server Signaling

Client/Server Firewall SignalingExample: VoIP Network

Client/Server Firewall SignalingExample: VoIP Network

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

IPTelephone

IPTelephone

SIP Server


AccessNW

NSIS NATFW Firewall SignalingExample: VoIP Network

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

IPTelephone

IPTelephone

SIP Server


AccessNW

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

IP forwarding

SignallingAppl. Protocol

Resourcespecific layer

CommonSignalling

?

?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

S e cu rityP ro to co ls

(T L S , IP se c )

S igna llingA pp lica tion - m idcom

S igna llingA pp lica tion -Q oSN

SLP

level

NTLP level

IP

S igna llingA pp lica tion - A N O

G IS TG IS T M e ssa g e E n ca p su la tio n G IS T S ta te M a in te n a n ce

U D P T C PD C C P S C T P

IP

...w h ich inc ludes m anagem en t o f a ll o f th is

F ocus o f spec ifica tionis th is

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

NSISHost A

NSISHost B

NSIS router

NetworkView

RouterwithoutNSIS

RouterwithoutNSIS

NSIS router

NTLPView

NTLPStack

NTLPStack

NTLPStack

NTLPStack

NSLPView

NTLPStack

NTLPStack

NTLPStack

NTLPStack

UDPtransport

Are you mynext node?(discovery)

Need FirewallConfiguration!

Here it is! Here it is!

Here it is!

Abstraction



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

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

CoreNW

Firewall

Firewall

Firewall

Data Sender

Data Receiver

Data flow

AccessNW


NSLP CREATE message

NSLP RESPONSE message

• Firewall is blocking by default• Signaling with allow action

Data Receiver behind Firewall

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data Sender

Data flow

AccessNW



NSLP REA message(running against flow direction)


RememberState forIncoming

NSLP request Firewall

Firewall

Data Receiver behind Firewall

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data Sender

Data flow

AccessNW


RememberState forIncoming

NSLP request

NSLP CREATE message

!



Data Receiver behind Firewall:Terminal Proxy Mode

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data Sender

Data flow

AccessNW


• Firewall is blocking by default• Signaling with allow action• Data sender NSIS unaware



ProcessingStops at

Edge-Firewall

Data Sender behind Firewall:Terminal Proxy Mode

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Sender

Data Receiver

Data flow

AccessNW


• Firewall is blocking by default• Signaling with allow action• Data Receiver NSIS unaware

ProcessingStops at

Edge-Firewall

NSLP CREATE message


Data Receiver behind Firewall:Terminal Proxy Mode and Attack Response

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data SenderAttacker

Data flow

AccessNW


• Firewall is open by default• Data Sender is an attacker• Signaling with deny action• Using sameREA message



Data Receiver behind Firewall:Terminal Proxy Mode and Attack Response

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data SenderAttacker

Data flow

AccessNW


• Firewall is open by default• Data Sender is an attacker• Signaling with deny action• Using sameREA message



X

Data Receiver behind Firewall:Network Proxy Mode and Attack Response

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data SenderAttacker

Data flow

AccessNW


• Firewall is open by default• Data Receiver NSIS unaware• Data Sender is an attacker• Signaling with deny action• Using same REA message


Data Receiver behind Firewall:Network Proxy Mode and Attack Response

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Receiver

Data SenderAttacker

Data flow

AccessNW


• Firewall is open by default• Data Receiver NSIS unaware• Data Sender is an attacker• Signaling with deny action• Using same REA message



X

Path Maintenance

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Sender

Data Receiver

Data flow

AccessNW


• Path is automatically maintained• NSIS reacts to route changes• Planned removal of firewalls• Firewall failures

XNSLP NOTIFY message

Path Maintenance

Internet

Provider 1

Provider 2

CoreNW

Firewall

Firewall

Firewall

Data Sender

Data Receiver

Data flow

AccessNW


• Path is automatically maintained• NSIS reacts to route changes• Planned removal of firewalls• Firewall failures

XNSLP NOTIFY message

NSLP RESPONSE messageNSLP 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 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


• 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


• 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


• 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 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 [email protected]

• NATFW NSLP authors Martin Stiemerling [email protected]

Hannes Tschofenig [email protected]

Cedric Aoun [email protected]

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?

NSIS NATFW NSLP: A Network Firewall Control Protocol draft-ietf-nsis-nslp-natfw-08.txt

Documents

Transcript of NSIS NATFW NSLP: A Network Firewall Control Protocol draft-ietf-nsis-nslp-natfw-08.txt