[sfc] Draft minutes for the SFC Meeting in Yokohama

[Thomas Narten <[e-mail]>]

Below are the draft minutes for the Yokohama SFC meeting. Please send
minor corrections to me directly, larger corrections should go to the
list.

Thanks!

Minutes for SFC Meeting in Yokohoma (IETF 94)

Minute takers:
    "Elzur, Uri" <[e-mail]>
    Dave Dolson <[e-mail]>
Merged by: Thomas Narten <[e-mail]>    

> 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