| ICNRG | I. Moiseenko |
| Internet-Draft | UCLA |
| Intended status: Experimental | D. Oran |
| Expires: April 23, 2020 | Network Systems Research and Design |
| October 21, 2019 |
Path Steering in CCNx and NDN
draft-oran-icnrg-pathsteering-00
Path Steering is a mechanism to discover paths to the producers of ICN content objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multipath congestion control algorithms and for network measurement and management. This specification derives directly from the design published in Path Switching in Content Centric and Named Data Networks (4th ACM Conference on Information-Centric Networking - ICN'17) and therefore does not recapitulate the design motivations, implementation details, or evaluation of the scheme. Some technical details are different however, and where there are differences, the design documented here is to be considered definitive.
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 April 23, 2020.
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.
Path Steering is a mechanism to discover paths to the producers of ICN content objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multipath congestion control algorithms and for network measurement and management. This specification derives directly from the design published in [Moiseenko2017] and therefore does not recapitulate the design motivations, implementation details, or evaluation of the scheme. That publication should be considered a normative reference as it is not likely a reader will be able to understand all elements of this design without first having read the reference. Some technical details are different however, and where there are differences, the design documented here is to be considered definitive.
There are a number of important use cases to justify extending ICN architectures such as CCNx or NDN to provide these capabilities. These are summarized as follows:
Path discovery and subsequent path steering in ICN networks is facilitated by the symmetry of forward and reverse paths in the CCNx and NDN architectures. Path discovery is achieved by a consumer endpoint transmitting an ordinary Interest message and receiving a Content (Data) message containing an end-to-end path label constructed on the reverse path by the forwarding plane. Path steering is achieved by a consumer endpoint including a path label in the Interest message, which is forwarded to each nexthop through the corresponding egress interfaces in conjunction with longest name prefix match (LNPM) FIB lookup.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
We elucidate the design using CCNx semantics and extend its Packet Encoding as defined in Section 3.2. While the terminology is slightly different, this design can be applied also to NDN, by extending its bespoke packet encodings (See Section 3.3).
End-to-end Path Discovery for CCNx is achieved by creating a path label and placing it as a hop-by-hop TLV in a CCNx Content (Data) message. The path label is constructed hop-by-hop as the message traverses the reverse path of transit CCNx forwarders (Figure 1). The path label is updated by adding to the existing path label the nexthop label of the interface at which the Content (Data) message has arrived. Eventually, when the Content(Data) message arrives at the consumer, the path label identifies the complete path the Content (Data) message took to reach the consumer.
Consumer Interest 1 ___ Interest 2
| | ^ |
| | | |
| | | |
Forwarder 1 v | V
| (nexthop 1) (nexthop 1) ^ (nexthop 1)
| | | |
| | | |
Forwarder 2 v | v
(nexthop 3) / \ (nexthop 2) (nexthop 2) ^ (nexthop 2)
/ \ | | |
/ \ | | |
/ \ | | |
/ \ | | |
/ \ | | |
Forwarder 4 Forwarder 3 v | v
(nexthop 5) \ / (nexthop 4) (nexthop 4) ^ (nexthop 4)
\ / | | |
\ / | | |
\ / | | |
\ / | | |
\ / | | |
\ / v | v
Producer ___ Data 1 ___
or
Content Store
Figure 1: Basic example of path discovery and steering
Due to the symmetry of forward and reverse paths in CCNx, a consumer application can reuse a discovered path label to fetch the same or similar (e.g. next chunk, or next Application Data Unit, or next pointer in a Manifest) Content (Data) message over the discovered network path. This Path Steering is achieved by processing the Interest message's path label at each transit ICN forwarder and forwarding the Interest through the specified nexthop among those identified as feasible by LNPM FIB lookup (Figure 2).
------------------------------------------------------------------------
FORWARD PATH
------------------------------------------------------------------------
Interest +---------+ +-----+ (path label) +--------+ (match) Interest
-------->| Content |->| PIT | ------------>| Label |---------------->
| Store | +-----+ | Lookup |
+---------+ | \ (no path label) +--------+
| | \ |\ (path label mismatch)
Data | | \ | \
<---------+ v \ | \
aggregate \ | \
\ | \
\ | +-----+ Interest
+--------------|---->| FIB | --------->
| +-----+
Interest-Return (NACK) v | (no route)
<----------------------------------------------+<-------+
------------------------------------------------------------------------
REVERSE PATH
------------------------------------------------------------------------
Interest-return(NACK) +-----+ (update path label) Interest-Return(NACK)
<---------------------| |<-----------------------------------------
| |
Data +---------+ | PIT | (update path label) Data
<------| Content |<---| |<-----------------------------------------
| Store | | |
+---------+ +-----+
|
| (no match)
v
Figure 2: Path Steering CCN / NDN data plane
Over time, the state of interfaces and the FIB on forwarders may change such that, at any particular forwarder, a given nexthop is no longer valid for a given prefix. In this case, the path label will point to a now-invalid nexthop. This is detected by failure to find a match between the decoded nexthop ID and the nexthops of the FIB entry after LNPM FIB lookup.
On detecting an invalid path label, the forwarder SHOULD respond to the Interest with an Interest-Return. We therefore define a new Invalid path label response code for the Interest Return message and include the current path label as a hop-by-hop header. Each transit forwarder processing the Interest-Return message updates the path label in the same manner as Content (Data) messages, so that the consumer receiving the Interest-Return (NACK) can easily identify which path label is no longer valid.
A consumer may alternatively request that a forwarder detecting the inconsistency forward the Interest by means of normal LNPM FIB lookup rather than returning an error. The consumer endpoint, if it cares, can keep enough information about outstanding Interests to determine if the path label sent with the Interest fails to match the path label in the corresponding returned Content (Data), and use that information to replace stale path labels. It does so by setting the FALLBACK MODE flag of the path label TLV in its Interest message.
[Moiseenko2017] presents various options for how to represent a path label, with different tradeoffs in flexibility, performance and space efficiency. For this specification, we choose the Polynomial encoding which achieves reasonable space efficiency at the cost of establishing a hard limit on the length of paths that can be represented.
The polynomial encoding utilizes a fixed-size bit array. Each transit ICN forwarder is allocated a fixed sized portion of the bit array. This design allocates 12 bits (i.e. 4095 as a generator polynomial) to each intermediate ICN forwarder. This should match the scalability of today's commercial routers that support up to 4096 physical and logical interfaces and usually do not have more than a few hundred active ones.
+------------------------------------------------------------------+
| Path Label bitmap |
+----------+-----------------+-----------------+-------------------+
| index | nexthop label | nexthop label | |
+----------+-----------------+-----------------+-------------------+
|<- 8bit ->|<---- 12bit ---->|<---- 12bit ---->|<----------------->|
Figure 3: Fixed size path label
A forwarder that receives a Content (Data) message encodes the nexthop label in the next available slot and increments label index. Conversely, a forwarder that receives an Interest message reads the current nexthop label and decrements label index. Therefore, the extra computation required at each hop to forward either an interest or Content Object message with a path label is minimized and constitutes a fairly trivial additional overhead compared to FIB lookup and other required operations.
This approach results in individual path label TLV instances being of fixed pre-computed size. While this places a hard upper bound on the maximum number of network hops that can be represented, this is not a significant a practical problem in NDN and CCNx, since the size can be pre-set during Content(Data) message encoding based on the exact number of network hops traversed by the Interest message. Even long paths of 24 hops will fit in a path label bitmap of 36 bytes if nexthop label is encoded in 12 bits.
A Path label TLV is the tuple: {[Flags], [Path Label Hop Count], [Nexthop Label], [Path label bitmap]}.
| Flag | Value (hex) |
|---|---|
| DISCOVERY MODE | 0x00 |
| FALLBACK MODE | 0x01 |
| STRICT MODE | 0x02 |
The Path Label Hop Count (PLHC) MUST be incremented by NDN and CCNx forwarders if the Interest packet carries a path label and DISCOVERY mode flag is set. A producer node or a forwarder with cached data packet MUST use PLHC in calculation of a path label bitmap size suitable for encoding the entire path to the consumer. The Path Label Hop Count (PLHC) MUST be set to zero in newly created Data or Interest-Return (NACK) packets. A consumer node MUST reuse Path Label Hop Count (PLHC) together with the Path label bitmap (PLB) in order to correctly forward the Interest(s) along the corresponding network path.
If an NDN or CCNx forwarder supports path labeling, the Nexthop label MUST be used to determine the correct egress interface for an Interest packet carrying either the FALLBACK MODE or STRICT MODE flag. If any particular NDN or CCNx forwarder is configured to decrypt path labels of Interest packets (Section "Security considerations"), then the forwarder MUST
If any particular NDN or CCNx forwarder is NOT configured to decrypt path labels of Interest packets, then path label decryption SHOULD NOT be performed.
The Nexthop label MUST be ignored by NDN and CCNx forwarders if present in Data or Interest-Return (NACK) packets. If any particular NDN or CCNx forwarder is configured to encrypt path labels of Data and Interest-Return (NACK) packets (Section Security Considerations), then the forwarder MUST encrypt existing path label with its own symmetric key, append the nexthop label of the ingress interface to the path label, and increment Path Label Hop Count (PLHC). If any particular NDN or CCNx forwarder is NOT configured to encrypt path labels of Interest packets, then path label encryption SHOULD NOT be performed.
NDN and CCNx forwarders MUST fallback to longest name prefix match (LNPM) FIB lookup if an Interest packet carries an invalid nexthop label and the FALLBACK MODE flag is set.
CCNx forwarders MUST respond with an Interest Return packet specifying the T_RETURN_INVALID_PATH_LABEL code if Interest packet carries an invalid path label and the STRICT MODE flag is set.
CCNx forwarders MUST respond with an Interest Return packet specifying the T_RETURN_MALFORMED_INTEREST code if the Interest packet carries a path label TLV with both FALLBACK MODE and STRICT MODE flags set.
Path Label is an optional Hop-by-Hop header TLV that can be present in CCNx Interest, InterestReturn and Content Object packets.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PATH_LABEL | Length + 4 |
+---------------+---------------+---------------+---------------+
| Flags | Path Label | Nexthop Label |
| | Hop Count | |
+---------------+---------------+---------------+---------------+
/ /
/ Path label bitmap (Length octets) /
/ /
+---------------+---------------+---------------+---------------+
Figure 4: Path label Hop-by-Hop header TLV for CCNx
Path Label is an optional TLV in NDN Interest, Data and NACK packets. The Path Label TLV SHOULD NOT take part in Interest, Data or NACK signature calculation as it is potentially modified at every network hop.
PathLabel = PATH-LABEL-TYPE TLV-LENGTH
PathLabelFlags
PathLabelBitmap
PathLabelFlags = PATH-LABEL-FLAGS-TYPE
TLV-LENGTH ; == 1
OCTET
NexthopLabel = PATH-LABEL-NEXTHOP-LABEL-TYPE
TLV-LENGTH ; == 2
2 OCTET
PathLabelHopCount = PATH-LABEL-HOP-COUNT-TYPE
TLV-LENGTH ; == 1
OCTET
PathLabelBitmap = PATH-LABEL-BITMAP-TYPE
TLV-LENGTH ; == 64
64 OCTET
Figure 5: Path label TLV for NDN
| Flag | Value (hex) |
|---|---|
| PATH-LABEL-TYPE | 0x09 |
| PATH-LABEL-FLAGS-TYPE | 0x0B |
| PATH-LABEL-BITMAP-TYPE | 0x0D |
| PATH-LABEL-NEXTHOP-LABEL-TYPE | 0x0E |
| PATH-LABEL-HOP-COUNT-TYPE | 0x0F |
IANA is requested to make the following assignments:
A path is invalidated by renumbering nexthop label(s). A malicious consumer can attempt to mount an attack by transmitting Interests with path labels which differ only in a single now-invalid nexthop label in order to brute force a valid nexthop label. If such an attack succeeds, a malicious consumer would be capable of steering Interests over a network path that may not match the paths computed by the routing algorithm or learned adaptively by the forwarders.
When a label lookup fails, by default an Invalid path label Interest-Return (NACK) message is returned to the consumer. This contains a path label identical to the one included in the corresponding Interest message. A malicious consumer can therefore analyze the message's Hop Count field to infer which specific nexthop label had failed and direct an attack to influence path steering at that hop. This threat can be mitigated by the following countermeasures:
ICN protocols can be susceptible to a variety of cache poisoning attacks, where a colluding consumer and producer arrange for bogus content (with either invalid or inappropriate signatures) to populate forwarder caches. These are generally confined to on-path attacks. It is also theoretically possible to launch a similar attack without a cooperating producer such that the caches of on-path routers become poisoned with the content from off-path routers (i.e. physical connectivity, but no route in a FIB for a given prefix). We estimate that without any prior knowledge of the network topology, the complexity of this type of attack is in the ballpark of Breadth-First-Search and Depth-First-Search algorithms with the additional burden of transmitting 2^31 Interests in order to crack a nexthop label on each hop. Relatively short periodic update of nexthop labels and anti- label scan heuristics implemented in the ICN forwarder may successfully mitigate this type of attack.
If the countermeasures listed above do not provide sufficient protection against malicious mis-steering of Interests, the path label can be made opaque to the consumer endpoint via hop-by-hop symmetric cryptography applied to the path labels (Figure 6). This method is viable due to the symmetry of forward and reverse paths in CCNx and NDN architectures combined with ICN path steering requiring only reads/writes of the topmost nexthop label (i.e. active nexthop label) in the path label. This way a path steering capable ICN forwarder receiving a Data (Content) message encrypts the current path label with its own non-shared symmetric key prior to adding a new nexthop label to the path label. The Data (Content) message is forwarded downstream with unencrypted topmost (i.e active) nexthop label and encrypted remaining content of the path label. As a result, a consumer endpoint receives a Data (Content) message with a unique path label exposing only the topmost nexthop label as cleartext. A path steering forwarder receiving an Interest message performs label lookup using the topmost nexthop label, decrypts the path label with its own non-shared symmetric key, and forwards the message upstream.
Cryptographic protection of a path label does not require any key negotiation among ICN forwarders, and is no more expensive than MACsec or IPsec. It is also quite possible that strict hop-by-hop path label encryption is not necessary and path label encryption only on the border routers of the trusted administrative or routing domains may suffice.
Producer
| ^
| |
Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+
|nexthop label=456 | v | |nexthop label=456 |
|encrypted path label={}| Forwarder 3 |encrypted path label={}|
+-----------------------+ | ^ +-----------------------+
| |
path label is encrypted | | path label is decrypted
with Forwarder 3 | | with Forwarder 3
symmetric key | | symmetric key
| |
| |
| |
| |
| |
Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+
|nexthop label=634 | v | |nexthop label=634 |
|encrypted path label= | Forwarder 2 |encrypted path label= |
| {456} | | ^ | {456} |
+-----------------------+ | | +-----------------------+
| |
path label is encrypted | | path label is decrypted
with Forwarder 2 | | with Forwarder 2
symmetric key | | symmetric key
| |
| |
| |
| |
| |
Path Label TLV | | Path Label TLV
+-----------------------+ | | +-----------------------+
|nexthop label=912 | v | |nexthop label=912 |
|encrypted path label= | Forwarder 1 |encrypted path label= |
| {634, encrypted path | | ^ | {634, encrypted path |
| label {456}} | | | | label {456}} |
+-----------------------+ | | +-----------------------+
| |
path label is encrypted | | path label is decrypted
with Forwarder 1 | | with Forwarder 1
symmetric key | | symmetric key
| |
| |
| |
| |
v |
Consumer
Figure 6: Path label protection with hop-by-hop symmetric cryptography
| [Moiseenko2017] | Moiseenko, I. and D. Oran, "Path Switching in Content Centric and Named Data Networks, in 4th ACM Conference on Information-Centric Networking (ICN 2017)", DOI 10.1145/3125719.3125721, September 2017. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8569] | Mosko, M., Solis, I. and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019. |
| [RFC8609] | Mosko, M., Solis, I. and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019. |