draft-ietf-sfc-proof-of-transit-03.txt   draft-ietf-sfc-proof-of-transit-04.txt 
Network Working Group F. Brockners, Ed. Network Working Group F. Brockners, Ed.
Internet-Draft S. Bhandari, Ed. Internet-Draft S. Bhandari, Ed.
Intended status: Experimental Cisco Intended status: Experimental Cisco
Expires: March 14, 2020 T. Mizrahi, Ed. Expires: May 24, 2020 T. Mizrahi, Ed.
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
S. Dara S. Dara
Seconize Seconize
S. Youell S. Youell
JPMC JPMC
September 11, 2019 November 21, 2019
Proof of Transit Proof of Transit
draft-ietf-sfc-proof-of-transit-03 draft-ietf-sfc-proof-of-transit-04
Abstract Abstract
Several technologies such as Traffic Engineering (TE), Service Several technologies such as Traffic Engineering (TE), Service
Function Chaining (SFC), and policy based routing are used to steer Function Chaining (SFC), and policy based routing are used to steer
traffic through a specific, user-defined path. This document defines traffic through a specific, user-defined path. This document defines
mechanisms to securely prove that traffic transited said defined mechanisms to securely prove that traffic transited said defined
path. These mechanisms allow to securely verify whether, within a path. These mechanisms allow to securely verify whether, within a
given path, all packets traversed all the nodes that they are given path, all packets traversed all the nodes that they are
supposed to visit. supposed to visit.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2020. This Internet-Draft will expire on May 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
3.3.3. Solution Deployment Considerations . . . . . . . . . 11 3.3.3. Solution Deployment Considerations . . . . . . . . . 11
3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12
3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12
4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13
5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15
5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16 5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16
5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16
5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 21 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 22
7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 23
7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 23 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 24
7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 23 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 24
7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 23 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 25
7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 24 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 25
7.8. Controller Operation . . . . . . . . . . . . . . . . . . 24 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 25
7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 24 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 26
7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 25 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 26
7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 25 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Several deployments use Traffic Engineering, policy routing, Segment Several deployments use Traffic Engineering, policy routing, Segment
Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
packets through a specific set of nodes. In certain cases, packets through a specific set of nodes. In certain cases,
regulatory obligations or a compliance policy require operators to regulatory obligations or a compliance policy require operators to
prove that all packets that are supposed to follow a specific path prove that all packets that are supposed to follow a specific path
are indeed being forwarded across and exact set of pre-determined are indeed being forwarded across and exact set of pre-determined
nodes. nodes.
skipping to change at page 17, line 32 skipping to change at page 17, line 32
+--rw active-profile-index? profile-index-range +--rw active-profile-index? profile-index-range
+--rw pot-profile-list* [pot-profile-index] +--rw pot-profile-list* [pot-profile-index]
+--rw pot-profile-index profile-index-range +--rw pot-profile-index profile-index-range
+--rw prime-number uint64 +--rw prime-number uint64
+--rw secret-share uint64 +--rw secret-share uint64
+--rw public-polynomial uint64 +--rw public-polynomial uint64
+--rw lpc uint64 +--rw lpc uint64
+--rw validator? boolean +--rw validator? boolean
+--rw validator-key? uint64 +--rw validator-key? uint64
+--rw bitmask? uint64 +--rw bitmask? uint64
+--rw opot-masks
+--rw downstream-mask* uint64
+--rw upstream-mask* uint64
<CODE ENDS> <CODE ENDS>
5.2.3. YANG Model 5.2.3. YANG Model
<CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang" <CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang"
module ietf-pot-profile { module ietf-pot-profile {
yang-version 1; yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile";
prefix ietf-pot-profile; prefix ietf-pot-profile;
organization "IETF SFC Working Group"; organization "IETF SFC Working Group";
contact "WG Web: <https://tools.ietf.org/wg/sfc/> contact "WG Web: <https://tools.ietf.org/wg/sfc/>
WG List: <mailto:sfc@ietf.org>"; WG List: <mailto:sfc@ietf.org>";
description "This module contains a collection of YANG description
definitions for proof of transit configuration "This module contains a collection of YANG
parameters. The model is meant for proof of definitions for proof of transit configuration
transit and is targeted for communicating the parameters. The model is meant for proof of
POT-Profile between a controller and nodes transit and is targeted for communicating the
participating in proof of transit."; POT-Profile between a controller and nodes
participating in proof of transit.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2016-06-15 { revision 2016-06-15 {
description description
"Initial revision."; "Initial revision.";
reference reference
""; "";
} }
typedef profile-index-range { typedef profile-index-range {
type int32 { type int32 {
skipping to change at page 19, line 51 skipping to change at page 20, line 28
} }
leaf bitmask { leaf bitmask {
type uint64; type uint64;
default 4294967295; default 4294967295;
description description
"Number of bits as mask used in controlling "Number of bits as mask used in controlling
the size of the random value generation. the size of the random value generation.
32-bits of mask is default."; 32-bits of mask is default.";
} }
uses opot-profile;
} }
}
grouping opot-profile {
description "Grouping containing OPoT related data.";
container opot-masks {
must "count(downstream-mask) = count(upstream-mask)";
description "Masking information for OPoT support.";
leaf-list downstream-mask {
type uint64;
max-elements 2;
description "Secret stream used to demask the PoT metadata.
The mask is used between nodes adjacent in the path
and MUST have a length equal to the sum of the ones
of RND and CML.";
}
leaf-list upstream-mask {
type uint64;
max-elements 2;
description "Secret stream used to mask the PoT metadata.
The mask is used between nodes adjacent in the path
and MUST have a length equal to the sum of the ones
of RND and CML.";
}
}
} }
container pot-profiles { container pot-profiles {
description "A group of proof of transit profiles."; description "A group of proof of transit profiles.";
list pot-profile-set { list pot-profile-set {
key "pot-profile-name"; key "pot-profile-name";
ordered-by user; ordered-by user;
description description
"Set of proof of transit profiles that group parameters "Set of proof of transit profiles that group parameters
skipping to change at page 25, line 38 skipping to change at page 26, line 48
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and
advice. advice.
9. Contributors 9. Contributors
In addition to editors and authors listed on the title page, the In addition to editors and authors listed on the title page, the
following people have contributed to this document: following people have contributed substantially to this document and
should be considered coauthors:
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-11 Kit Creek Road 7200-11 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
United States United States
Email: cpignata@cisco.com Email: cpignata@cisco.com
John Leddy John Leddy
Email: john@leddy.net Email: john@leddy.net
skipping to change at page 26, line 30 skipping to change at page 27, line 41
Phone: +34 913 129 041 Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com Email: diego.r.lopez@telefonica.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- d., and J. Lemon, "Data Fields for In-situ OAM", draft-
data-06 (work in progress), July 2019. ietf-ippm-ioam-data-08 (work in progress), October 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
 End of changes. 12 change blocks. 
33 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/