Minutes for SFC Meeting in Yokohoma (IETF 94) Minute takers: "Elzur, Uri" Dave Dolson Merged by: Thomas Narten > 00:00 Introduction (WG-chairs) - [5 minutes] > Agenda bashing, note-well, (WG-chairs) - [5 minutes] Stand-in chairs: Joel Halpern and Carlos Pignataro. Carlos kicks off the meeting. Arch published as an RFC, this is the 2nd RFC the WG released > 00:05 SFC Security Requirements (Presenter + open-mic) - [25 minutes] > > - SFC Environment Security Requirements (Daniel Migault) - [15 minutes] > - http://www.ietf.org/id/draft-mglt-sfc-security-environment-req-00.txt > - SFC Security Requirements Q&A (open-mic) - [10 minutes] Basic architecture: Divided to two plane. Attack Scenarios: The CP benefits from strong access control, in the Tenant User plane this is not the case as the tenant can craft any packet and controls both ends of the communication. Tenant can also measure which packets will take more resources, create loop or leak information and use those to launch DDOS. Another scenario: can discern if the client is on WL, RAN or other access method, force the user to provide some additional info to discern info about the user identity, location etc. Attacker can also change metadata Requirements: 2 type of categories 1) Plane Separation 2) SFC service itself In the talk today, focus on SFC specific: REQ14, 15, 16, 17. Recommend use of fixed length metadata to allow for more predictable performance and less exposure of what loads the nodes. REQ19 - keep isolation. Ability to detect the user in the domain to prevent man in the middle (MitM) attack Question to the WG: 2 additional requirements 23 and 24 - are they in scope? Q&A: Ramki - NFVRG has a draft about misconfiguration. Did you consider addressing miss configuration? Needs to be added to the draft, it is a major source for security exposure. Daniel - agree. Detect misconfiguration with auditing. Ramki: mention explicitly? Daniel: OK, I will get back. Linda: Similar to I2RS security reqirements: Can relax security if firewall around everything. Requirements should be based on whether there is a firewalled network or not. Have different reqirement for each type. Another issue is that without specificity, a user may discredit other requirements if they notice some of them as irrelevant. Daniel: all REQ are preceded by a scenario so if the scenario doesn't apply, no need to follow it. This is the reason the draft uses SHOULD vs. MUST. Linda: REQx mentions use of a FW, need to be specific, otherwise it is meaningless. Protects against what threat? Joel: asks for action to start 2 threads on the list for these issues. Nicolas - Disputes prohibitation against use of metadata for steering. Daniel: it is just "SHOULD". Nicolas: Also, important to allow components to share SFs, for efficiency. Metadata size is performance oriented not security, Where is the boundary? One use of the metadata is to carry multi tenant information. It provides efficiency. The draft seems to discourage that Surendra: Meaning of "Volume must be limited"? Daniel: Be careful about size of metadata; Surendra: But says "MUST" Daniel: agree Surendra: Important to protect both path and index. Uri: Is this draft REQ normative or not? Or good advice? This is especially important when it comes to some of the MUST like REQ24, which may have wire protocol implications. Joel -if WG adopts document, depends on SHOULD or MUST, which would be normative. WG needs to decide what will be normative. If the WG adopts the draft (or parts of it) it affects all the other documents including NSH. Carlos: Work was tasked because WG declared security important; thanks to Alia for raising issues. If a MUST is adopted, then it is normative. Uri: in that case, I hope this WG will not be more zealous than other WGs. Especially on MUST Requirements, which needs to be carefully analyze and with a proper scenario like what Linda suggested. Joel: point is WG members need to review and comment, possibly provide caveats Alia - Some WGs have been more relaxed and then later in the IETF process find that more rigor is required and they get sent back to the beginning. So my advice is for the WG to think before submitting their drafts and include all the necessary security provisions. This is especially important as SFC has some potential privacy exposures Al Morten: wrt threads on slide; are people who want to measure performance threats? Need to distinguish legitimate testers vs. those doing "reconnaisance". Sometimes the man-in-the-middle is a tester. Suggest to use API control for testing vs. reconnaissance. Sometimes the man in the middle is legitimate. Daniel: the point is to only allow legitimate devices (a tester would be legitimate) > 00:30 SFC Use Cases (Presenters + open-mic) - [30 minutes] > > - SFC Use Cases for Network Security (Eric Wang) - [10 minutes] > - https://www.ietf.org/internet-drafts/draft-wang-sfc-ns-use-cases-00.txt Scenario awareness is important: SPI may be different if the traffic is a response or a request. Need to classify based on Network and Application criteria: for example a SSL proxy will not be identified before the handshake is established and it may result in moving to another SPI . Service Function (slide 4): Embedding: beneficial to avoid unnecessary roundtrip to the classifier. Note color code on the slide for new requirements that are not in the current WG docs. E.g., Bypass / offloading - may require TCP state clearing too. Need to be reviewed in the offload mechanism. Tap mode - is an input device w/o output, requires a copy of the traffic and maybe more. Discussion needed Packet handling (slide 5): Results to allow multiple devices to make a joint decision. Poll of the room: Very few read the use case draft. Q&A: Carlos: who has read this? Show of hands? [Joel: very few] Al Moron: "I volunteer to read because we need more of this for measurements." Carlos: "who are on the hook" Diego Lopez: impression is using SFC to provide security. Joel: yes, the opposite. Diego: then title is misleading. Joel: send suggestion for better title to the list. Diego: I will. > - SFC Use Cases in Broadband (Wei Meng) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/ Slide 3: SFC can be used to simplify the architecture of certain devices. If split out some SFC out of BNG, then the rest can be common such a switch today! Slide 4: Same for CPE which is complex, then it can be cheaper and simpler! Q&A: Kengo Naito: Is there NSH inside the CPE? Wei: Yes Slide 5: IPTV - special use case in BB scenario, as it is forked. The BNAS fwd and traffic is duplicated to STB. It is also not symmetric. Q to the WG: Is it one SFC and SFP or six different ones? Suggest to have ml discussion to follow. Slide 6 Issue-1: In legacy devices/architecture, the address pool is configured on the device itself. However using SFC - should it be distributed or centralized? Who provides input to BB network to steer the traffic? If asymmetric traffic inbound SFP and outbound SFP are separate. How do we ensure both have the same SF devices in the path? Slide 7 Issue-2 : In legacy devices/architecture, fwd-ing and control are integrated in one device. How to do it w SFC? NAT can send a session to SFF or to a physical witch. So now a 2nd or 3rd packet can be fwd by SFF feeing up NAT resources. For a high perf scenario, can use by-pass to avoid sending all the traffic to the NAT. Request WG adoption. Joel: we aren't going to progress the adoption question today. Chairs: Send a note to ml to ask for WG adoption of the document. Q&A: Kent Leung: many issues are wrt NAT: why is this just a broadband issue? Other issues are generic and overlapping too. Diego - the presentation is much to specific to particular architecture/solution. If we go this way, we will have 10M use cases. Should not go there. Joel - focus should be on use cases that drive new protocol needs / requirements. Carlos - Use case presented, should be Protocol or Security requirement driven. Wei: not to provide a solution Ericsson - How does this relate to broadband forum WT345 (?) Meng - will consider contributing there too > 01:00 SFC Architecture Discussion (Presenters + open-mic) - [50 Minutes] > > - UDP Overlay Transport For Network Service Header (Surendra Kumar) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-transport/ Transport is out of scope for the SFC WG. Today NSH editors have to go to each WG to get NSH supported . A draft in NVO3 WG for VxLAN-gpe, but it requires to operate a Virtual Network and is NOT native on top of UDP. It is out of scope for SFC, so Surendra presented this draft in the routing WG and received lots of feedback. Q&A: Carlos: does "signaling" mean signaling? Surendra: must be a way to indicate carrying NSH. Joel - commenting as an individual. Conflict between slide 2 (i.e. Transport out of scope) and slide 3 (i.e. ask SFC for UDP as transport for NSH) is confusing. Aiming for WG adoption for something outside of charter? Alia: it is outside the charter, but WG may discuss. UDP encap is not the hard part, but we need to understand security considerations. Knowledge to turn this from "NSH in UDP" to something that is reasonable to use; the knowledge to do that is within SFC. Joel: is it not the case that the same knowledge applies to all encap types. The same arguments would seem to apply to all of them. Agree that transports should not be work item. advice not to do it here? Alia: yes, same types of arguments apply, and if there is active interest in multiple transports, then maybe have a "general considerations" draft. Joel: I could understand a different general considerations draft. Alia: Discuss here because it is the first. Could consider general considerations. Lucy Yong - first, this is still a Transport draft. Second, we have a GRE draft and only need to register EtherType and get it done. Surendra - still, even with GRE still need to manage a virtual network? Daniel E/// - note discussion in DOTS. Are Service Providers ready to use UDP for such a purpose? Say on mailing list. Kengo Naito - I like this encap, but should not be WG recommendation. Dino - NSH runs over L4 transport, can use UDP like any other protocol like DNS. Made this comment to NSH authors few times. Dave Dolson- There is an EtherType in the NSH draft. Was it an omission not to relate to it? > - Map Assisted SFC Proxy using LISP (Albert Cabellos) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-cabellos-sfc-map-assisted-proxy/ Proxy may also need to re-classify as legacy may change the packet! RFC6830 offers a std interface to a way to store a key and retrieve it back later. This simplifies the Proxy Q&A: Kent Leung: How to deal with NFC-unaware device has rewritten 5-tuple? Is NAT ok changes the 5 tuple? Albert: this is an advantage: it can rewrite it Kent: who is doing rewrite when legacy SF creates a packet with brand new 5-tuple. How does mapper know it? Albert: SFC control function must be aware of that. Kent: now clear: proxy must be ready for new 5-tuples. Albert: control plane is aware of the mapping done by the NAT. Uri: this goes beyond the question of what to do in the case the SF changed the 5-tuple. It is the question of: is the SF trusted - for the sake of the 5 tuple, as well as the NSH header. There are opinions as if we need to allow for some SF that are and some that are not trusted. I assume all agree the SFF is part of the infrastructure and is trusted. We need to close on this for the NSH draft too. Albert: in my scenario, all elements are trusted. Lucy Yong: with these applications, is it a LISP network, or just between the proxy & SF Albert: maybe semantics, but does not understand this as a LISP network. Wei Meng: if the packet is received by the proxy, does the proxy need to put the payload in the cache? Albert: depends on mappings of 5-tuple to NSH. Can be defined by prefix. > - Packet Generation in Service Function Chains (Reinaldo Penno) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-penno-sfc-packet/ SF need to generate packets on their own, intrinsic need of these devices. SF needs 3 pieces of data to be able to send a packet back. Options: 1) SFF sends this to the SF 2) SF sends NSH OAM to the SFF 3) Classifier - but that consumes lots of metadata space 4) Algorithmic - draft authors have invested time on this option and have also implemented in ODL How to determine the metadata? Key focus right now. Two options: 1. Path-invariant - Min amount of metadata an push it to every SF 2. Flow invariant - metadata in every packet in specific positions Q&A: David Dolson: I think this is important; I would like to work on it. Kent Leung: this is important, and an oversight. This needs to be addressed. > - Hierarchical Service Function Chaining (Dave Dolson) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-dolson-sfc-hierarchical/ Problem space - for a large scale network/DC. Maybe Containers based. Large network and asymmetric traffic patterns (e.g. packets from WAN). And also for supporting multiple teams who need access to control / configure SFC elements: e.g., separate teams for Security, DDOS, network that are all involved. Many operators can't use a "Super controller" - a single controller to setup paths in the entire network - becoming a single point of failure and a performance bottleneck Slide 7 Mechanism - inbound into IBN is not too difficult, back is complex. Reviewed the CP drafts and found no issues yet. IBN is viewed as a SF and a Classifier to external higher hierarchy. Need to treat theses function independently. Q&A: x- Current SFC assumes single domain. This draft seems to require multi domain. What is the practical scenario? Dave - draft has examples. E.g. biz traffic vs residential services. The high level classifier sorts out what DC to use, and the low level classifier - controlled by a separate team, implements the paths and the features e.g. FW, NAT for a residential traffic and another team for the biz etc. Andy Beach NetCracker - looked into API for.. > 01:50 SFC Miscellaneous (Presenters + open-mic) - [35 minutes] > > - SFC Trace Issue Analysis & Solutions (Xinpeng Wei) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-yang-sfc-trace-issue-analysis/ There are issues that are not covered by current drafts the WG has. Slide 4: frame format suggests that OAM can extend the MD-Type1 packet??? Q&A: Uri: you were showing OAM type 1, which is fixed size. Did you mean OAM type 2 for TLV structure? Joel: we could redefine the fixed length format as not fixed. We should discuss it. Presenter - agree Joel - we have fixed size for MD Type = 1, but can redefine if the WG thinks it is of value Erik Nordmark - OAM work assumed the trace packets go along the same path as regular packets, here the trace report goes to the controller which is a novel idea. We should study this new approach that allows packets to cause events in the control plane. Including potential DDOS against the controller? Carlos: please clarify: operations or security Erik: it feels novel. We know how to do tracert because it flows in reverse direction, but this feels new because it crosses into a different security domain. Kengo Naito: how to deal (in terms of getting OAM supported) with NSH-unaware service functions? Xinpeng: proxy is not here right now Kengo: we should get some OAM Xinpeng: ok > - SFC: Subscriber & Host Identification Considerations (TBD) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-serviceheader/ Presented by Behcet Sarikaya Joel: on IMEI or subscriber ID, both arch and security draft indicate we should obscure that. Also it is a large thing to pass around. In security we said indirect IDs should be used. Also, we do have a draft for a list of useful TLVs, which has a subscriber ID. As a personal point of view, I'd rather see one draft of TLVs. WG also has a draft with proposed TLV for MD Type=2, pls join. Behcet: open to merging. Problem with merging drafts is loss of rationale and use case. > - SFC NSH Context Header Allocation -- Mobility (Praveen Muley) - [10 minutes] > - https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-mobility-allocation/ Q&A: Uri: bothered by whether the WG can merge the bit allocation schemes. In some areas there is duplication of the same entity. Another way to pose the question is to ask what happens when a packet from mobility domain enters DC domain. Who does the mapping? Why is different information being carried? Can we strive to blend them together? Praveen: I guess the information is different. Uri - While I fully recognize that in some fields the info carried for the mobile case and the DC case are different it still makes sense to attempt to merge what is possible between DC and mobility bit allocation drafts. Also is there a case where the traffic will traverse te boundary between the two and hence will be good to make it easier with similar format? Uri: Looked at both drafts, and there is common information. Praveen: please post to lists. Surendra: I raised this earlier; there are some commonalities, which we can try to align. But use cases are different and we should align common parts. Kent Leung: should align formatting, but there are some that don't match. There is a draft proposing a bit for which is used? Dave Dolson: control plane is a possible way of setting the metadata "schema" for each SPI/SI at each node. Kent: also feels need to address. Not sure we want to create registry Dave Dolson - put it in the CP to tell what format to use where. It is a schema and it is important to the WG to work on it