Service Function Chaining Problem Statement
draft-ietf-sfc-problem-statement-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7498.
|
|
|---|---|---|---|
| Authors | Paul Quinn , Thomas Nadeau | ||
| Last updated | 2014-04-16 | ||
| Replaces | draft-quinn-sfc-problem-statement | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7498 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sfc-problem-statement-04
CoRE Working Group M. Tiloca
Internet-Draft R. Hoeglund
Updates: 7252, 7390, 7641 (if approved) RISE AB
Intended status: Standards Track C. Amsuess
Expires: January 7, 2020
F. Palombini
Ericsson AB
July 06, 2019
Observe Notifications as CoAP Multicast Responses
draft-tiloca-core-observe-multicast-notifications-00
Abstract
The Constrained Application Protocol (CoAP) allows clients to
"observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases,
such as based on publish-subscribe, it would be convenient for the
server to send a single notification to all the clients observing a
same target resource. This document defines how a CoAP server sends
observe notifications as response messages over multicast, by
synchronizing all the observers of a same resource on a same shared
Token value. Besides, this document defines how Group OSCORE can be
used to protect multicast notifications end-to-end from the CoAP
server to the multiple CoAP clients registered as observers.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2020.
Tiloca, et al. Expires January 7, 2020 [Page 1]
Internet-Draft Observe Multicast Notifications July 2019
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Override-Token Option . . . . . . . . . . . . . . . . . . 4
3. The Override-AAD Option . . . . . . . . . . . . . . . . . . . 5
4. Resource Observation . . . . . . . . . . . . . . . . . . . . 6
4.1. Client Registration . . . . . . . . . . . . . . . . . . . 6
4.2. Multicast Notifications . . . . . . . . . . . . . . . . . 7
4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Token Values for Multicast Notifications . . . . . . . . . . 9
6. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 11
7. Protection of Multicast Notifications with Group OSCORE . . . 11
7.1. Secure Binding of Multicast Notifications . . . . . . . . 12
7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] has been
extended with a number of mechanisms, including resource Observation
[RFC7641]. This enables CoAP clients to register at a CoAP server as
"observers" of a resource, and hence being automatically notified
with an unsolicited response upon changes of the resource state.
Tiloca, et al. Expires January 7, 2020 [Page 2]
Internet-Draft Observe Multicast Notifications July 2019
CoAP supports group communication over IP multicast [RFC7390], and
[I-D.dijk-core-groupcomm-bis] has been enabling Observe registration
requests over multicast, in order for clients to efficiently register
as observers of a resource hosted at multiple servers.
However, in a number of use cases, the opposite usage of multicast
messages would be also desirable. That is, it would be useful that a
server sends observe notifications for a same target resource to
multiple observer clients, as responses over IP multicast.
For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub],
multiple clients can subscribe to a topic, by observing the related
resource hosted at the responsible broker. When a new value is
published on that topic, it would be convenient for the broker to
send a single multicast notification at once, to all the subscriber
clients observing that topic.
A different use case concerns clients observing a registration
resource at the CoRE Resource Directory
[I-D.ietf-core-resource-directory]. For example, multiple clients
can benefit of observation for discovering (to-be-created) OSCORE
groups [I-D.ietf-core-oscore-groupcomm] and retrieving updated
information to join them through their respective Group Manager
[I-D.tiloca-core-oscore-discovery].
More in general, multicast notifications would be beneficial whenever
several CoAP clients observe a same target resource at a CoAP server,
and can be all notified at once by means of a single response
message. However, CoAP does not currently define response messages
over IP multicast. This specification fills this gap and provides
the following twofold contribution.
First, it defines a method to deliver Observe notifications as CoAP
responses over IP multicast. The proposed method relies on the
server managing the Token space for multicast notifications, by
providing all the observers of a target resource with the same Token
value to bind to their own observation. That Token value is used in
every multicast notification for that target resource. This is
achieved by introducing a new CoAP option used in the notification
response to the original registration request from each client.
Second, this specification defines how to use Group OSCORE
[I-D.ietf-core-oscore-groupcomm] to protect multicast notifications
end-to-end between the server and the observer clients. This is
achieved by introducing a second new CoAP option used in the
notification response to the original registration request from each
client. The option specifies parameter values that the server uses
to secure every multicast notification for the target resource by
Tiloca, et al. Expires January 7, 2020 [Page 3]
Internet-Draft Observe Multicast Notifications July 2019
using Group OSCORE. This provides a secure binding between each of
such notifications and the observation of each of the clients.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are expected to be familiar with terms and concepts described
in CoAP [RFC7252], group communication for CoAP
[RFC7390][I-D.dijk-core-groupcomm-bis], Observe [RFC7641], CBOR
[RFC7049], OSCORE [I-D.ietf-core-object-security], and Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
2. The Override-Token Option
The Override-Token option defined in this section has the properties
summarized in Figure 1, which extends Table 4 of [RFC7252].
Since the option is not Safe-to-Forward, the column "N" is filled
with a dash. The Override-Token option contains a Token value.
+------+---+---+---+---+----------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+----------------+--------+--------+---------+
| TBD1 | X | x | - | | Override-Token | opaque | 1-8 | (none) |
+------+---+---+---+---+----------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 1: The Override-Token Option.
This document specifically defines how this option is used to support
Observe notifications over IP multicast (see Section 4).
If a server provides multicast notifications for a target resource,
the server includes the Override-Token option in the unicast
notification response sent as the first reply to a registration
request from each client to that resource, i.e. a GET request with
the Observe option set to 0. The server indicates a same immutable
Token value T in the Override-Token option of each of these first
replies. In any other circumstance, this option is not included.
The server will use that same Token value T when sending multicast
notifications to registered clients observing that resource. This
Tiloca, et al. Expires January 7, 2020 [Page 4]
Internet-Draft Observe Multicast Notifications July 2019
ensures that every multicast notification for that resource is
expected on the same Token value T by each observing client.
The Override-Token option is of class U for OSCORE
[I-D.ietf-core-object-security][I-D.ietf-core-oscore-groupcomm],
since intermediaries may be present, and may replace it with a new
instance (see Section 6).
3. The Override-AAD Option
The Override-AAD option defined in this section has the properties
summarized in Figure 2, which extends Table 4 of [RFC7252].
+------+---+---+---+---+--------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+--------------+--------+--------+---------+
| TBD2 | X | | | | Override-AAD | (*) | 3-255 | (none) |
+------+---+---+---+---+--------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
(*) See below.
Figure 2: The Override-AAD Option
If a server that provides multicast notifications for a target
resource protects them with Group OSCORE
[I-D.ietf-core-oscore-groupcomm], the server includes the Override-
AAD option in the unicast notification response sent as the first
reply to a registration request from each client to that resource,
i.e. a GET request with the Observe option set to 0. In any other
circumstance, this option is not included.
The Override-AAD option contains a CBOR array [RFC7049] composed of
the two following elements.
o The first element is a CBOR byte string, which encodes the Sender
ID of the server in the OSCORE group.
o The second element is a CBOR integer, which encodes a particular
value SN of the Sender Sequence Number of the server in the OSCORE
group.
The server uses this same immutable pair to build the two OSCORE
'external_aad' (see Section 5.4 of [I-D.ietf-core-object-security]
and Sections 3.1 and 3.2 of [I-D.ietf-core-oscore-groupcomm]), when
encrypting and countersigning every multicast notification for the
observed resource using Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
Tiloca, et al. Expires January 7, 2020 [Page 5]
Internet-Draft Observe Multicast Notifications July 2019
This ensures that every multicast notification for a same observed
resource is securely bound to the first unicast notification sent to
each client observing that resource.
The Override-AAD option is of class E for OSCORE
[I-D.ietf-core-object-security][I-D.ietf-core-oscore-groupcomm].
4. Resource Observation
Clients interested in receiving multicast notifications from a server
have to first register their interest, as described in Section 4.1.
This registration is performed over unicast, i.e. comprising both the
observation request and the first notification response.
Upon a change of the state of the target resource, the server sends a
multicast notification, i.e. a single CoAP response over Multicast IP
intended to all the clients in the list of observers of that
resource, as described in Section 4.2. Multicast notifications MUST
be non-confirmable.
Interested clients need to know the IP multicast address and UDP port
number where the server sends multicast notifications for the target
resource(s). To this end, a possible approach may rely on the CoRE
Resource Directory (RD) and the RD-Groups usage pattern (see
Appendix A of [I-D.ietf-core-resource-directory]). In particular,
application groups may be registered to the RD, as composed of the
resource(s) for which a server provides multicast notifications, and
specifying the used IP multicast address and UDP port number.
Further details on how clients retrieve this information are out of
the scope of this specification.
The server MUST NOT send multicast notifications to unmanaged IP
multicast addresses, such as All CoAP Nodes (see Section 12.8 of
[RFC7252]).
4.1. Client Registration
The registration process occurs according to the following steps.
1. A client sends an observation request to the server as described
in [RFC7641], i.e. a GET request with an Observe option set to 0
(register).
2. If the list of observers for the target resource has just changed
from empty to including one observer, the server selects a
currently available value T from its Token space and exclusively
assigns it as Token value to the list of observers of the target
resource (see also related considerations in Section 5). That
Tiloca, et al. Expires January 7, 2020 [Page 6]
Internet-Draft Observe Multicast Notifications July 2019
is, from then on, the server MUST use T as its own local Token
value associated to that observation, with respect to the (next
hop towards the) client.
3. The server adds the client to the list of observers of the target
resource.
4. The server sends a unicast response notification to the client as
described in [RFC7641], i.e. a 2.05 (Content) or 2.03 (Valid)
response with an Observe option including a sequence number.
Additionally, the server includes an Override-Token option
defined in Section 2, which MUST contain the value T. Note that
every client further added to the same non-empty list of
observers of that target resource receives a notification
response to its registration request with the same value T
included in the Override-Token option.
5. Upon receiving the unicast notification response to the
observation request, the client retrieves the Override-Token
option and the conveyed value T. The client interprets this
response as if the server: i) has successfully added an entry
with the client endpoint and Token value T to the list of
observers of the target resource; and ii) will notify changes to
the state of the target resource, by means of multicast
notifications with Token value T. The client MAY adopt a policy
for re-registering its interest for observation, if the Override-
Token option includes a Token value already in use with that
server. Clients MUST treat as non valid and silently discard
responses that include an Override-Token option but do not
include also an Observe option.
6. From then on, the client MUST be able to receive, accept and
process multicast notifications about the state of the target
resource from the server. To this end, the client is required to
know in advance the IP multicast address and port number where
the server will send multicast notifications to. Also, from then
on, the client MUST use T as its own local Token value associated
to that observation, with respect to the (next hop towards the)
server. The particular way to achieve this is implementation
specific.
4.2. Multicast Notifications
Upon a change of the status of the target resource, the server sends
a multicast notification intended to all the clients in the list of
observers of that resource. In particular, a multicast notification
MUST include an Observe option, as specified in [RFC7641].
Tiloca, et al. Expires January 7, 2020 [Page 7]
Internet-Draft Observe Multicast Notifications July 2019
Compared to notifications as described in [RFC7641], the following
two differences apply for a multicast notification.
o It is sent as a single CoAP response over Multicast IP.
o It has Token value T, as indicated to every interested client in
the Override-Token option of the notification response to its
observation request to the target resource (see Section 4.1).
That is, every multicast notification for a target resource is not
bound to the different original observation requests, but rather to
the whole set of clients currently in the list of observers of that
resource.
4.3. Example
The following example refers to two clients C_1 and C_2 that register
to observe a resource /r at a Server S.
Before the following exchanges occur, no clients are observing the
resource /r , which has value "1234".
Tiloca, et al. Expires January 7, 2020 [Page 8]
Quinn & Nadeau Expires October 17, 2014 [Page 3]
Internet-Draft SFC Problem Statement April 2014
server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
injection [RFC6967], HTTP Header Enrichment functions, TCP
optimizer, etc.
The generic term "L4-L7 services" is often used to describe many
service functions.
Service Function Chain (SFC): A service Function chain defines an
ordered set of service functions that must be applied to packets
and/or layer-2 frames selected as a result of classification. The
implied order may not be a linear progression as nodes may copy to
more than one branch. The term service chain is often used as
shorthand for service function chain.
Service Function Path (SFP): The instantiation of a service function
chain in the network. Packets follow a service function path from
a classifier through the required instances of service functions
in the network.
Service Node (SN): Physical or virtual element that hosts one or
more service functions.
Service Overlay: An overlay network created for the purpose of
forwarding data along a service function path.
Service Topology: The service overlay connectivity forms a service
topology.
Quinn & Nadeau Expires October 17, 2014 [Page 4]
Internet-Draft SFC Problem Statement April 2014
2. Problem Space
The following points describe aspects of existing service deployments
that are problematic, and that the Service Function Chaining (SFC)
working group aims to address.
2.1. Topological Dependencies
Network service deployments are often coupled to network topology,
whether it be real or virtualized, or a hybrid of the two. Such
dependency imposes constraints on the service delivery, potentially
inhibiting the network operator from optimally utilizing service
resources, and reduces the flexibility. This limits scale, capacity,
and redundancy across network resources.
These topologies serve only to "insert" the service function (i.e.,
ensure that traffic traverses a service function); they are not
required from a native packet delivery perspective. For example,
firewalls often require an "in" and "out" layer-2 segment and adding
a new firewall requires changing the topology (i.e., adding new
layer-2 segments).
As more service functions are required - often with strict ordering -
topology changes are needed before and after each service function
resulting in complex network changes and device configuration. In
such topologies, all traffic, whether a service function needs to be
applied or not, often passes through the same strict order.
The topological coupling limits placement and selection of service
functions: service functions are "fixed" in place by topology and
therefore placement and service function selection taking into
account network topology information is not viable. Furthermore,
altering the services traversed, or their order, based on flow
direction is not possible.
A common example is web servers using a server load balancer as the
default gateway. When the web service responds to non-load balanced
traffic (e.g., administrative or backup operations) all traffic from
the server must traverse the load balancer forcing network
administrators to create complex routing schemes or create additional
interfaces to provide an alternate topology.
2.2. Configuration complexity
A direct consequence of topological dependencies is the complexity of
the entire configuration, specifically in deploying service function
chains. Simple actions such as changing the order of the service
functions in a service function chain require changes to the
Quinn & Nadeau Expires October 17, 2014 [Page 5]
Internet-Draft SFC Problem Statement April 2014
topology. Changes to the topology are avoided by the network
operator once installed, configured and deployed in production
environments fearing misconfiguration and downtime. All of this
leads to very static service delivery deployments. Furthermore, the
speed at which these topological changes can be made is not rapid or
dynamic enough as it often requires manual intervention, or use of
slow provisioning systems.
2.3. Constrained High Availability
An effect of topological dependency is constrained service function
high availability. Worse, when modified, inadvertent non-high
availability or downtime can result.
Since traffic reaches many service functions based on network
topology, alternate, or redundant service functions must be placed in
the same topology as the primary service.
2.4. Consistent Ordering of Service Functions
Service functions are typically independent; service function_1
(SF1)...service function_n (SFn) are unrelated and there is no notion
at the service layer that SF1 occurs before SF2. However, to an
administrator many service functions have a strict ordering that must
be in place, yet the administrator has no consistent way to impose
and verify the ordering of the service functions that are used to
deliver a given service.
Service function chains today are most typically built through manual
configuration processes. These are slow and error prone. With the
advent of newer service deployment models the control and policy
planes provide not only connectivity state, but will also be
increasingly utilized for the creation of network services. Such a
control/management planes could be centralized, or be distributed.
2.5. Application of Service Policy
Service functions rely on topology information such as VLANs or
packet (re) classification to determine service policy selection,
i.e. the service function specific action taken. Topology
information is increasingly less viable due to scaling, tenancy and
complexity reasons. The topological information is often stale,
providing the operator with inaccurate placement that can result in
suboptimal resource utilization. Furthermore topology-centric
information often does not convey adequate information to the service
functions, forcing functions to individually perform more granular
classification.
Quinn & Nadeau Expires October 17, 2014 [Page 6]
Internet-Draft SFC Problem Statement April 2014
2.6. Transport Dependence
Service functions can and will be deployed in networks with a range
of transports, including under and overlays. The coupling of service
functions to topology requires service functions to support many
transport encapsulations or for a transport gateway function to be
present.
2.7. Elastic Service Delivery
Given that the current state of the art for adding/removing service
functions largely centers around VLANs and routing changes, rapid
changes to the service deployment can be hard to realize due to the
risk and complexity of such changes.
2.8. Traffic Selection Criteria
Traffic selection is coarse, that is, all traffic on a particular
segment traverse service functions whether the traffic requires
service enforcement or not. This lack of traffic selection is
largely due to the topological nature of service deployment since the
forwarding topology dictates how (and what) data traverses service
function(s). In some deployments, more granular traffic selection is
achieved using policy routing or access control filtering. This
results in operationally complex configurations and is still
relatively inflexible.
2.9. Limited End-to-End Service Visibility
Troubleshooting service related issues is a complex process that
involve both network-specific and service-specific expertise. This
is especially the case when service function chains span multiple
DCs, or across administrative boundaries. Furthermore, the physical
and virtual environments (network and service), can be highly
divergent in terms of topology and that topological variance adds to
these challenges.
2.10. Per-Service (re)Classification
Classification occurs at each service function independent from
previously applied service functions. More importantly, the
classification functionality often differs per service function and
service functions may not leverage the results from other service
functions.
Quinn & Nadeau Expires October 17, 2014 [Page 7]
Internet-Draft SFC Problem Statement April 2014
2.11. Symmetric Traffic Flows
Service function chains may be unidirectional or bidirectional
depending on the state requirements of the service functions. In a
unidirectional chain traffic is passed through a set of service
functions in one forwarding direction only. Bidirectional chains
require traffic to be passed through a set of service functions in
both forwarding directions. Many common service functions such as
DPI and firewall often require bidirectional chaining in order to
ensure flow state is consistent.
Existing service deployment models provide a static approach to
realizing forward and reverse service function chain association most
often requiring complex configuration of each network device
throughout the SFC.
2.12. Multi-vendor Service Functions
Deploying service functions from multiple vendors often require per-
vendor expertise: insertion models differ, there are limited common
attributes and inter- vendor service functions do not share
information.
Quinn & Nadeau Expires October 17, 2014 [Page 8]
Internet-Draft SFC Problem Statement April 2014
3. Service Function Chaining
Service Function Chaining aims to address the aforementioned problems
associated with service deployment. Concretely, the SFC working
group will investigate solutions that address the following elements:
3.1. Service Overlay
Service function chaining utilizes a service specific overlay that
creates the service topology. The service overlay provides service
function connectivity and is built "on top" of the existing network
topology and allows operators to use whatever overlay or underlay
they prefer to create a path between service functions, and to locate
service functions in the network as needed.
Within the service topology, service functions can be viewed as
resources for consumption and an arbitrary topology constructed to
connect those resources in a required order. Adding new service
functions to the topology is easily accomplished, and no underlying
network changes are required.
Lastly, the service overlay can provide service specific information
needed for troubleshooting service-related issues.
3.2. Control Plane
Service aware control plane(s) provide information about the
available service functions on a network. The information provided
by the control plane includes service network location (for topology
creation), service type (e.g. firewall, load balancer, etc.) and,
optionally, administrative information about the service functions
such as load, capacity and operating status. The service aware
control plane allows for the formulation of service function chains
and exchanges requisite information needed to instantiate the service
function chains in the network.
Furthermore, the service aware control plane may interact with the
topology aware control plane (if separate) to ensure optimal
selection (and possibly placement) of service function within a
service function path.
3.3. Service Classification
Classification is used to select which traffic enters a service
overlay. The granularity of the classification varies based on
device capabilities, customer requirements, and service offered.
Initial classification determines the service function chain required
to process the traffic. Subsequent classification can be used within
Quinn & Nadeau Expires October 17, 2014 [Page 9]
Internet-Draft SFC Problem Statement April 2014
Internet-Draft Observe Multicast Notifications July 2019
C_1 ------------------ [ Unicast ] --------------------> S /r
| GET |
| Token: 0x4a |
| Observe: 0 (Register) |
| |
| (S adds C_1 to the list of observers of /r .) |
| |
| (S allocates the available Token value 0xff .) |
| |
| |
C_1 <--------------------- [ Unicast ] ----------------- S
| 2.05 |
| Token: 0x4a |
| Observe: 10 |
| Override-Token: 0xff |
| Payload: "1234" |
| |
C_2 ------------------ [ Unicast ] --------------------> S /r
| GET |
| Token: 0x01 |
| Observe: 0 (Register) |
| |
| (S adds C_2 to the list of observers of /r .) |
| |
C_2 <--------------------- [ Unicast ] ----------------- S
| 2.05 |
| Token: 0x01 |
| Observe: 10 |
| Override-Token: 0xff |
| Payload: "1234" |
| |
| (The value of the resource /r changes to "5678".) |
| |
C_1 |
+ <-------------------- [ Multicast ] ---------------- S
C_2 |
| 2.05 |
| Token: 0xff |
| Observe: 11 |
| Payload: "5678" |
| |
5. Token Values for Multicast Notifications
The Token space for multicast notifications is shared by all the
clients that have registered to observe resources at a server. As
described in Section 4, the server aligns all the clients observing a
Tiloca, et al. Expires January 7, 2020 [Page 9]
Internet-Draft Observe Multicast Notifications July 2019
same resource to consider a same Token value, which is then used in
every multicast notification sent for that resource.
This specification updates [RFC7252] by defining the Token values in
Figure 3 as intended for multicast notifications.
A server supporting the Override-Token option and Observe multicast
notifications MUST use the Token values in Figure 3 for its multicast
notifications and as content of the Override-Token option. A server
MUST NOT use the same Token value in multicast notifications for
multiple resources currently under observation.
A client supporting the Override-Token option and Observe multicast
notifications MUST NOT use the Token values in Figure 3 for its
outgoing messages, except when explicitly cancelling the observation,
i.e. a GET request to the server with an Observe option set to 1 (see
Section 3.6 of [RFC7641]). That GET request has the same Token value
used by the server in the multicast notifications for that
observation.
This ensures clients to correctly distinguish a multicast
notification from a regular (notification) response, as well as to
correctly bind the former with the corresponding observation, while
the latter with the corresponding original request.
+------------+-------------------------------------------+-------+
| Token size | Token value range | Range |
| (Bytes) | | size |
+------------+-------------------------------------------+-------+
| 1 | [0xf0 , 0xff] | 16 |
+------------+-------------------------------------------+-------+
| 2 | [0xffc0 , 0xffff] | 64 |
+------------+-------------------------------------------+-------+
| 3 | [0xffff00 , 0xffffff] | 256 |
+------------+-------------------------------------------+-------+
| 4 | [0xfffffbff , 0xffffffff] | 1024 |
+------------+-------------------------------------------+-------+
| 5 | [0xfffffff7ff , 0xffffffffff] | 2048 |
+------------+-------------------------------------------+-------+
| 6 | [0xffffffffefff , 0xffffffffffff] | 4096 |
+------------+-------------------------------------------+-------+
| 7 | [0xffffffffffdfff , 0xffffffffffffff] | 8192 |
+------------+-------------------------------------------+-------+
| 8 | [0xffffffffffffbfff , 0xffffffffffffffff] | 16384 |
+------------+-------------------------------------------+-------+
Figure 3: Range of Token values for multicast notifications.
Tiloca, et al. Expires January 7, 2020 [Page 10]
Internet-Draft Observe Multicast Notifications July 2019
6. Intermediaries
In case intermediaries such as CoAP proxies are involved, the same
approach described in Section 4 is used independently on both the
client- and server-side of each proxy. Care must be taken to only
use IP multicast addresses that have all the same meaning on all
interfaces of the involved hops.
Upon receiving the unicast response to an original observation
request, a proxy on the path between the server and a client performs
the following actions.
o The proxy retrieves the Token value T from the Override-Token
option. From then on, the proxy MUST use T as its own local Token
value associated to that observation, with respect to the next hop
towards the server.
o The proxy MAY remove the original Override-Token option. In such
a case, the proxy MUST include a new Override-Token option. The
newly included Override-Token option specifies a Token value T'
(which may be equal to T), consistently with the rules defined in
Section 5. From then on, the proxy uses T' as its own local Token
value associated to that observation, with respect to the next hop
towards the clients. Otherwise, if the proxy does not remove the
Override-Token option, the proxy uses T as its own local Token
value associated to that observation, with respect to the next hop
towards the clients.
The process described above starts at the server and continues until
the clients are eventually reached. Even in the presence of
intermediaries, this ensures general conflict-free synchronization of
Token values at each hop on the path from the server to the clients.
7. Protection of Multicast Notifications with Group OSCORE
A server can protect multicast notifications by using Group OSCORE
[I-D.ietf-core-oscore-groupcomm]. In such a case, both the server
and the clients interested in receiving multicast notifications from
that server have to be members of the same OSCORE group.
Building on the approach suggested in Section 4.1 to discover IP
multicast addresses and UDP port numbers, clients may discover the
OSCORE group to refer to by using the method in
[I-D.tiloca-core-oscore-discovery], also based on the CoRE Resource
Directory (RD) [I-D.ietf-core-resource-directory].
Furthermore, both the clients and server may join the OSCORE group by
using the approach described in [I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, et al. Expires January 7, 2020 [Page 11]
Internet-Draft Observe Multicast Notifications July 2019
and based on the ACE framework for Authentication and Authorization
in constrained environments [I-D.ietf-ace-oauth-authz].
Further details on how to discover the OSCORE group and join it are
out of the scope of this specification.
Alternative security protocols than Group OSCORE, such as OSCORE
[I-D.ietf-core-object-security] and/or DTLS [RFC6347], can be used to
protect other unicast exchanges between the server and each client,
including the original client registration described in Section 4.1.
7.1. Secure Binding of Multicast Notifications
When using Group OSCORE to protect multicast notifications, the
registration process occurs as described in Section 4.1, with the
following additions.
o If the list of observers for the target resource has just changed
from empty to including one observer, the server consumes the
current value of its own Sender Sequence Number SN in the OSCORE
group, and hence updates it to SN* = (SN + 1).
Note for implementation: a possible way to achieve this is for the
server to produce a dummy request addressed to the OSCORE group,
and protect it using its own Sender Context of the Group OSCORE
Security Context. This dummy request is not actually transmitted,
i.e. it does not hit the wire.
o Upon sending the unicast first notification response to a just
registered client, the server includes in that response an
Override-AAD option defined in Section 3. The option MUST contain
the pair ('kid' ; 'piv') encoded as defined in Section 3, where
'kid' is the Sender ID of the server in the OSCORE group, while
'piv' is the previously consumed Sender Sequence Number value SN
of the server in the OSCORE group, i.e. (SN* - 1). Note that
every client further added to the same non-empty list of observers
of that target resource receives a notification response to its
registration request including the exact same pair ('kid' ; 'piv')
in the Override-AAD option.
o Upon receiving the unicast notification response to the
observation request, the client retrieves the Override-AAD option
and the conveyed pair ('kid' ; 'piv'). From then on, when
verifying multicast notifications as described in Section 6.4 of
[I-D.ietf-core-oscore-groupcomm], the client MUST use 'kid' as
'request_kid' and 'piv' as 'request_piv' in the two 'external_aad'
for decrypting and verifying every multicast notification from the
server for the target resource (see Sections 3.1 and 3.2 of
Tiloca, et al. Expires January 7, 2020 [Page 12]
Internet-Draft Observe Multicast Notifications July 2019
[I-D.ietf-core-oscore-groupcomm]). The particular way to achieve
this is implementation specific. Clients MUST treat as non valid
and silently discard responses that include an Override-AAD option
but that do not include also both an Override-Token option and an
Observe option. A client has to be a current member of the OSCORE
group comprising also the server and associated to the target
resource, and MUST otherwise silently discard responses that
include an Override-AAD option.
Upon sending every multicast notification for the target resource as
described in Section 4.2, the server protects it with Group OSCORE.
In particular, the process described in Section 6.3 of
[I-D.ietf-core-oscore-groupcomm] applies, with the following
differences when building the two OSCORE 'external_aad' to encrypt
and countersign the multicast notification (see Sections 3.1 and 3.2
of [I-D.ietf-core-oscore-groupcomm]).
o The 'request_kid' contains the 'kid' value that the server
specifies to clients as first element in the Override-AAD option,
when replying to the their registration request.
o The 'request_piv' contains the 'piv' value that the server
specifies to clients as second element in the Override-AAD option,
when replying to their registration request.
7.2. Example
The following example refers to two clients C_1 and C_2 that register
to observe a resource /r at a Server S. Pairwise communication over
unicast are protected with OSCORE, while S protects multicast
notifications with Group OSCORE.
Before the following exchanges occur, no clients are observing the
resource /r , which has value "1234". In addition:
o C_1 and S have a pairwise OSCORE Security Context. In particular,
C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sequence Number.
Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Sequence
Number.
o C_2 and S have a pairwise OSCORE Security Context. In particular,
C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sequence Number.
Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Sequence
Number.
o C_1, C_2 and S are members of an OSCORE group with 'kid_context' =
"feedca57ab2e" as Group ID. In the OSCORE group, S has 'kid' = 5
as Sender ID, and SN_5 = 501 as Sequence Number.
Tiloca, et al. Expires January 7, 2020 [Page 13]
Internet-Draft Observe Multicast Notifications July 2019
C_1 ------------ [ Unicast w/ OSCORE ] -----------------> S /r
| GET |
| Token: 0x4a |
| Observe: 0 (Register) |
| OSCORE: {kid: 1 ; piv: 101 ; ...} |
| |
| (S adds C_1 to the list of observers of /r .) |
| |
| (S allocates the available Token value 0xff .) |
| |
| (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) |
| |
C_1 <--------------- [ Unicast w/ OSCORE ] --------------- S
| 2.05 |
| Token: 0x4a |
| Observe: 10 |
| OSCORE: {piv: 301; ...} |
| Override-Token: 0xff |
| Override-AAD: {5 ; 501} |
| Payload: "1234" |
| |
C_2 ------------ [ Unicast w/ OSCORE ] -----------------> S /r
| GET |
| Token: 0x01 |
| Observe: 0 (Register) |
| OSCORE: {kid: 2 ; piv: 201 ; ...} |
| |
| (S adds C_2 to the list of observers of /r .) |
| |
C_2 <--------------- [ Unicast w/ OSCORE ] --------------- S
| 2.05 |
| Token: 0x01 |
| Observe: 10 |
| OSCORE: {piv: 401 ; ...} |
| Override-Token: 0xff |
| Override-AAD: {5 ; 501} |
| Payload: "1234" |
| |
| (The value of the resource /r changes to "5678".) |
| |
C_1 |
+ <------------ [ Multicast w/ Group OSCORE ] ---------- S
C_2 |
| 2.05 |
| Token: 0xff |
| Observe: 11 |
| OSCORE: {kid: 5 ; piv: 502 ; ...} |
| Payload: "5678" |
Tiloca, et al. Expires January 7, 2020 [Page 14]
Internet-Draft Observe Multicast Notifications July 2019
The two external_aad used to encrypt and countersign the multicast
notification above have 'req_kid' = 5 and 'req_iv' = 501, as
indicated in the Override-AAD option to the two clients. Thus, the
two clients can build the two same external_aad for decrypting and
verifying this multicast notification and the following ones.
8. Security Considerations
The same security considerations from [RFC7252][RFC7390][RFC7641][I-D
.dijk-core-groupcomm-bis][I-D.ietf-core-object-security][I-D.ietf-cor
e-oscore-groupcomm] hold for this document.
The Override-Token option is of class U for OSCORE, hence
intermediaries and on-path active adversaries are able to modify its
value. This yields the same effects of altering the Token value of
CoAP messages.
If multicast notifications are protected using Group OSCORE, the
original registration requests and related unicast notification
responses MUST also be secured. This prevents on-path active
adversaries from altering the Override-AAD option, and thus ensures
secure binding between every multicast notification for a same
observed resource and the first notification response sent to each
client observing that resource.
To this end, clients and servers MUST use OSCORE or Group OSCORE, for
which the Override-AAD option is of class E and would thus be hidden
also from intermediaries such as CoAP proxies. This ensures that the
secure binding above is enforced end-to-end between the server and
each observing client.
9. IANA Considerations
This document has the following actions for IANA.
9.1. CoAP Option Numbers Registry
IANA is asked to enter the following option numbers to the "CoAP
Option Numbers" registry defined in [RFC7252] within the "CoRE
Parameters" registry.
+--------+------------------+-------------------+
| Number | Name | Reference |
+--------+------------------+-------------------+
| TBD1 | Override-Token | [[this document]] |
+--------+------------------+-------------------+
| TBD2 | Override-AAD | [[this document]] |
+--------+------------------+-------------------+
Tiloca, et al. Expires January 7, 2020 [Page 15]
Internet-Draft Observe Multicast Notifications July 2019
10. References
10.1. Normative References
[I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-00 (work in progress), March 2019.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP",
draft-ietf-core-oscore-groupcomm-05 (work in progress),
July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Tiloca, et al. Expires January 7, 2020 [Page 16]
Internet-Draft Observe Multicast Notifications July 2019
10.2. Informative References
[I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
oscore-02 (work in progress), July 2019.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019.
[I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-08 (work in
progress), March 2019.
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-22 (work in progress), July 2019.
[I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
Groups with the CoRE Resource Directory", draft-tiloca-
core-oscore-discovery-03 (work in progress), July 2019.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2a given service function chain to alter the sequence of service
functions applied. Symmetric classification ensures that forward and
reverse chains are in place. Similarly, asymmetric -- relative to
required service function -- chains can be achieved via service
classification.
3.4. Dataplane Metadata
Data plane metadata provides the ability to exchange information
between logical classification points and service functions (and vice
versa) and between service functions. As such metadata is not used
as forwarding information to deliver packets along the service
overlay.
Metadata can include the result of antecedent classification and/or
information from external sources. Service functions utilize
metadata, as required, for localized policy decisions.
In addition to sharing of information, the use of metadata addresses
several of the issues raised in section 2, most notably the de-
coupling of policy from the topology, and the need for per-service
classification (and re-classification).
A common approach to service metadata creates a common foundation for
interoperability between service functions, regardless of vendor.
Quinn & Nadeau Expires October 17, 2014 [Page 10]
Internet-Draft SFC Problem Statement April 2014
4. Related IETF Work
The following subsections discuss related IETF work and are provided
for reference. This section is not exhaustive, rather it provides an
overview of the various initiatives and how they relate to network
service chaining.
1. [L3VPN]: The L3VPN working group is responsible for defining,
specifying and extending BGP/MPLS IP VPNs solutions. Although
BGP/MPLS IP VPNs can be used as transport for service chaining
deployments, the SFC WG focuses on the service specific
protocols, not the general case of VPNs. Furthermore, BGP/MPLS
IP VPNs do not address the requirements for service chaining.
2. [LISP]: LISP provides locator and ID separation. LISP can be
used as an L3 overlay to transport service chaining data but does
not address the specific service chaining problems highlighted in
this document.
3. [NVO3]: The NVO3 working group is chartered with creation of
problem statement and requirements documents for multi-tenant
network overlays. NVO3 WG does not address service chaining
protocols.
4. [ALTO]: The Application Layer Traffic Optimization Working Group
is chartered to provide topological information at a higher
abstraction layer, which can be based upon network policy, and
with application-relevant service functions located in it. The
mechanism for ALTO obtaining the topology can vary and policy can
apply to what is provided or abstracted. This work could be
leveraged and extended to address the need for services
discovery.
5. [I2RS]: The Interface to the Routing System Working Group is
chartered to investigate the rapid programming of a device's
routing system, as well as the service of a generalized, multi-
layered network topology. This work could be leveraged and
extended to address some of the needs for service chaining in the
topology and device programming areas.
6. [ForCES]: The ForCES working group has created a framework,
requirements, a solution protocol, a logical function block
library, and other associated documents in support of Forwarding
and Control Element Separation. The work done by ForCES may
provide a basis for both the separation of SFC elements, as well
as provide protocol and design guidance for those elements.
Quinn & Nadeau Expires October 17, 2014 [Page 11]
Internet-Draft SFC Problem Statement April 2014
5. Summary
This document highlights problems associated with network service
deployment today and identifies several key areas that will be
addressed by the SFC working group. Furthermore, this document
identifies four components that are the basis for service function
chaining. These components will form the areas of focus for the
working group.
Quinn & Nadeau Expires October 17, 2014 [Page 12]
Internet-Draft SFC Problem Statement April 2014
6. Security Considerations
Security considerations are not addressed in this problem statement
only document. Given the scope of service chaining, and the
implications on data and control planes, security considerations are
clearly important and will be addressed in the specific protocol and
deployment documents created by the SFC WG group.
Quinn & Nadeau Expires October 17, 2014 [Page 13]
Internet-Draft SFC Problem Statement April 2014
7. Contributors
The following people are active contributors to this document and
have provided review, content and concepts (listed alphabetically by
surname):
Puneet Agarwal
Broadcom
Email: pagarwal@broadcom.com
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange.com
Abhishek Chauhan
Citrix
Email: Abhishek.Chauhan@citrix.com
Uri Elzur
Intel
Email: uri.elzur@intel.com
Kevin Glavin
Riverbed
Email: Kevin.Glavin@riverbed.com
Ken Gray
Cisco Systems
Email: kegray@cisco.com
Jim Guichard
Cisco Systems
Email:jguichar@cisco.com
Christian Jacquenet
France Telecom
Email: christian.jacquenet@orange.com
Surendra Kumar
Cisco Systems
Email: smkumar@cisco.com
Nic Leymann
Deutsche Telekom
Email: n.leymann@telekom.de
Darrel Lewis
Cisco Systems
Quinn & Nadeau Expires October 17, 2014 [Page 14]
Internet-Draft SFC Problem Statement April 2014
Email: darlewis@cisco.com
Rajeev Manur
Broadcom
Email:rmanur@broadcom.com
Brad McConnell
Rackspace
Email: bmcconne@rackspace.com
Carlos Pignataro
Cisco Systems
Email: cpignata@cisco.com
Michael Smith
Cisco Systems
Email: michsmit@cisco.com
Navindra Yadav
Cisco Systems
Email: nyadav@cisco.com
Quinn & Nadeau Expires October 17, 2014 [Page 15]
Internet-Draft SFC Problem Statement April 2014
8. Acknowledgments
The authors would like to thank David Ward, Rex Fernando, David
Mcdysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel
Halpern and Jim French for their reviews and comments.
Quinn & Nadeau Expires October 17, 2014 [Page 16]
Internet-Draft SFC Problem Statement April 2014
9. Informative References
[ALTO] "Application-Layer Traffic Optimization (alto)",
<http://datatracker.ietf.org/wg/alto/>.
[ForCES] "Forwarding and Control Element Separation (forces)",
<http://datatracker.ietf.org/wg/forces/>.
[I2RS] "Interface to the Routing System (i2rs)",
<http://datatracker.ietf.org/wg/i2rs/>.
[L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
<http://datatracker.ietf.org/wg/l3vpn/>.
[LISP] "Locator/ID Separation Protocol (lisp)",
<http://datatracker.ietf.org/wg/lisp/>.
[NVO3] "Network Virtualization Overlays (nvo3)",
<http://datatracker.ietf.org/wg/nvo3/>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments",
RFC 6967, June 2013.
Quinn & Nadeau Expires October 17, 2014 [Page 17]
Internet-Draft SFC Problem Statement April 2014
Authors' Addresses
Paul Quinn (editor)
Cisco Systems, Inc.
Email: paulq@cisco.com
Thomas Nadeau (editor)
Brocade
Email: tnadeau@lucidvision.com
Quinn & Nadeau Expires October 17, 2014 [Page 18]