1. Controlling Service Function Access to NSH
IETF 97 – Seoul
SFC WG
Vu Anh Vu –
Younghan Kim -
IETF 97 Seoul

2. Problem Statement Should SFs be trusted ??
Operator deploy and operate SFs => Ok, let’s trust them but ... how much ???
SFs can be malnipulated by malwares
SFs can be malfunctioned
Third-party SFs
Service provider outsource their services
Enterprise rent external SFs from SPs
Transportation network security threats (man-in-the middle, SF spoof, etc.)
IETF 97 Seoul

3. Problem Statement What if a SF can malnipulate:
SPI: wrong service path redirect
SI: forwarding loop or skip SFs
Metadata: Information leaking (sub)
NSH information must be protected
Header encryption: costly
The document propose an inexpensive mechanism to protect the sensitive information in NSH
IETF 97 Seoul

4. Terminologies
Access-Controlled Segment (ACS): an area/field within NSH that carries a piece of sensitive SFC information needed to be protected
SF Access Control List (SF ACL): a list describes the access permission of an SF to each ACS in the packet
NSH-state: a set of value/information stored in the NSH of a packet at a particular moment
IETF 97 Seoul

5. Access Control Policies
An Access Control List of an SF contains access permissions of the SF to each ACS
Three levels of permission to access an ACS
Hidden: the SF cannot view the information in this ACS
Read-only: the SF can view, but cannot modify the information in this ACS
Write: the SF can view and modify the information in this ACS
IETF 97 Seoul

6. Mechanism Only give SFs what information they need to access
SFFs cannot control SFs not to modify SFC information, but they can choose to discard the modification
Advantages:
Obscure sensitive information
Detect abnormal SF behavior
SFs are unaware of being controlled
IETF 97 Seoul

7. Flow tracking
Track the packet between ingress and egress Sub-CFs in order to recover the appropriate NSH state:
Reclassification: i.e. Using 5-tuple
Using Metadata
IETF 97 Seoul

8. Implementation Demo in IETF 97Hackathon
Using OpenDaylight as control plane and OVS as dataplane
SFF and CF are combine into a OVS
Using flow-rule to save NSH-state
IETF 97 Seoul

9. Consideration
Define MD mask for SF: Only give SFs what information they need to access
Dynamic MD for concealing information :
MCH value changes constantly between SFs to conceal the real value
Subsequent CF handle value mapping
IETF 97 Seoul

10. Discussion Should Service Path Header be access controlled or only MD?
Addition requirements for access control for MD type 2
NSH-State sync between ingress and egress Sub-CFs
IETF 97 Seoul

11. Thank you !!!
IETF 97 Seoul