Controlling Service Function Access to NSH IETF 97 – Seoul SFC WG Vu Anh Vu – vuva@dcn.ssu.ac.kr Younghan Kim - younghak@ssu.ac.kr IETF 97 Seoul

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

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

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

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

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

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

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

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

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

Thank you !!! IETF 97 Seoul