NAT/Firewall NSLP

1
NAT/Firewall NSLP

• IETF 63th August 2005
• draft-ietf-nsis-nslp-natfw-07.txt
• Martin Stiemerling, Hannes Tschofenig, Cedric Aoun

2
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

3
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

4
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

NF
NF
X
NR
NI
NF
5
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.

6
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)

7
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.

8
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)

9
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 (real-time notification of
  out of bound peak packet rate for specific flow
  type)

10
Semantics of UCREATE

• Proxy Mode for Data Receiver behind Firewall
• Used to block particular incoming data flows
• Can be used as firewall REA

11
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-ns
  is-nslp-natfw-07-diff-to-06.html

12
Thank you. Questions?