NAT/Firewall NSLP
IETF 63th – August 2005
draft-ietf-nsis-nslp-natfw-07.txt
Martin Stiemerling, Hannes Tschofenig, Cedric Aoun
0
Solved Issues
• NATFW NSLP issue tracker
 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
1
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
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
NSLP
Session
CREATE
NI
NF
NF
X
NOTIFY
NF
NR
3
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.
4
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)
5
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.
6
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)
7
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 (realtime notification of out of bound peak packet rate for specific flow type)
8
Semantics of UCREATE
• Proxy Mode for Data Receiver behind Firewall
• Used to block particular incoming data flows
• Can be used as “firewall REA”
9
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
10
Thank you.
Questions?
11