draft-ietf-i2nsf-capability-data-model-18.txt   draft-ietf-i2nsf-capability-data-model-19.txt 
I2NSF Working Group S. Hares, Ed. I2NSF Working Group S. Hares, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track J. Jeong, Ed. Intended status: Standards Track J. Jeong, Ed.
Expires: 19 March 2022 J. Kim Expires: 1 April 2022 J. Kim
Sungkyunkwan University Sungkyunkwan University
R. Moskowitz R. Moskowitz
HTT Consulting HTT Consulting
Q. Lin Q. Lin
Huawei Huawei
15 September 2021 28 September 2021
I2NSF Capability YANG Data Model I2NSF Capability YANG Data Model
draft-ietf-i2nsf-capability-data-model-18 draft-ietf-i2nsf-capability-data-model-19
Abstract Abstract
This document defines an information model and the corresponding YANG This document defines an information model and the corresponding YANG
data model for the capabilities of various Network Security Functions data model for the capabilities of various Network Security Functions
(NSFs) in the Interface to Network Security Functions (I2NSF) (NSFs) in the Interface to Network Security Functions (I2NSF)
framework to centrally manage the capabilities of the various NSFs. framework to centrally manage the capabilities of the various NSFs.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 19 March 2022. This Internet-Draft will expire on 1 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Information Model of I2NSF NSF Capability . . . . . . . . . . 4 3. Information Model of I2NSF NSF Capability . . . . . . . . . . 4
3.1. Design Principles and ECA Policy Model . . . . . . . . . 5 3.1. Design Principles and ECA Policy Model . . . . . . . . . 5
3.2. Conflict, Resolution Strategy and Default Action . . . . 8 3.2. Conflict, Resolution Strategy and Default Action . . . . 8
4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 10 4. Overview of YANG Data Model . . . . . . . . . . . . . . . . . 10
5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12 5. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Network Security Function (NSF) Capabilities . . . . . . 12 5.1. Network Security Function (NSF) Capabilities . . . . . . 12
6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15 6. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.1. Normative References . . . . . . . . . . . . . . . . . . 51 10.1. Normative References . . . . . . . . . . . . . . . . . . 51
10.2. Informative References . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Configuration Examples . . . . . . . . . . . . . . . 57 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 57
A.1. Example 1: Registration for the Capabilities of a General A.1. Example 1: Registration for the Capabilities of a General
Firewall . . . . . . . . . . . . . . . . . . . . . . . . 58 Firewall . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2. Example 2: Registration for the Capabilities of a A.2. Example 2: Registration for the Capabilities of a
Time-based Firewall . . . . . . . . . . . . . . . . . . . 59 Time-based Firewall . . . . . . . . . . . . . . . . . . . 59
A.3. Example 3: Registration for the Capabilities of a Web A.3. Example 3: Registration for the Capabilities of a Web
Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.4. Example 4: Registration for the Capabilities of a VoIP/ A.4. Example 4: Registration for the Capabilities of a VoIP/
VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 62 VoLTE Filter . . . . . . . . . . . . . . . . . . . . . . 62
A.5. Example 5: Registration for the Capabilities of a HTTP and A.5. Example 5: Registration for the Capabilities of a HTTP and
HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 63 HTTPS Flood Mitigator . . . . . . . . . . . . . . . . . . 63
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 64
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 65
skipping to change at page 3, line 32 skipping to change at page 3, line 32
Security Capabilities describe the functions that Network Security Security Capabilities describe the functions that Network Security
Functions (NSFs) can provide for security policy enforcement. Functions (NSFs) can provide for security policy enforcement.
Security Capabilities are independent of the actual security policy Security Capabilities are independent of the actual security policy
that will implement the functionality of the NSF. that will implement the functionality of the NSF.
Every NSF SHOULD be described with the set of capabilities it offers. Every NSF SHOULD be described with the set of capabilities it offers.
Security Capabilities enable security functionality to be described Security Capabilities enable security functionality to be described
in a vendor-neutral manner. Security Capabilities are a market in a vendor-neutral manner. Security Capabilities are a market
enabler, providing a way to define customized security protection by enabler, providing a way to define customized security protection by
unambiguously describing the security features offered by a given unambiguously describing the security features offered by a given
NSF. Note that this YANG data model structurizes the NSF Monitoring NSF. Note that this YANG data model constructs the structure of the
Interface YANG data model [I-D.ietf-i2nsf-nsf-monitoring-data-model] NSF Monitoring Interface YANG data model
and the NSF-Facing Interface YANG Data Model [I-D.ietf-i2nsf-nsf-monitoring-data-model] and the NSF-Facing
[I-D.ietf-i2nsf-nsf-facing-interface-dm]. Interface YANG Data Model [I-D.ietf-i2nsf-nsf-facing-interface-dm].
This document provides an information model and the corresponding This document provides an information model and the corresponding
YANG data model [RFC6020][RFC7950] that defines the capabilities of YANG data model [RFC6020][RFC7950] that defines the capabilities of
NSFs to centrally manage the capabilities of those NSFs. The NSFs NSFs to centrally manage the capabilities of those NSFs. The NSFs
can register their own capabilities into a Network Operator can register their own capabilities into a Network Operator
Management (Mgmt) System (i.e., Security Controller) with this YANG Management (Mgmt) System (i.e., Security Controller) with this YANG
data model through the registration interface [RFC8329]. With the data model through the registration interface [RFC8329]. With the
database of the capabilities of those NSFs that are maintained database of the capabilities of those NSFs that are maintained
centrally, those NSFs can be more easily managed [RFC8329]. centrally, those NSFs can be more easily managed [RFC8329].
skipping to change at page 4, line 39 skipping to change at page 4, line 39
diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
3. Information Model of I2NSF NSF Capability 3. Information Model of I2NSF NSF Capability
This section provides the I2NSF Capability Information Model (CapIM). This section provides the I2NSF Capability Information Model (CapIM).
A CapIM is a formalization of the functionality that an NSF A CapIM is a formalization of the functionality that an NSF
advertises. This enables the precise specification of what an NSF advertises. This enables the precise specification of what an NSF
can do in terms of security policy enforcement, so that computer- can do in terms of security policy enforcement, so that computer-
based tasks can unambiguously refer to, use, configure, and manage based tasks can unambiguously refer to, use, configure, and manage
NSFs. Capabilities MUST be defined in a vendor- and technology- NSFs. Capabilities MUST be defined in a vendor- and technology-
independent manner (e.g., regardless of the differences among vendors independent manner (i.e., regardless of the differences among vendors
and individual products). and individual products).
Humans can refer to categories of security controls and understand Humans can refer to categories of security controls and understand
each other. For instance, network security experts agree on what is each other. For instance, network security experts agree on what is
meant by the terms "NAT", "filtering", and "VPN concentrator". As a meant by the terms "NAT", "filtering", and "VPN concentrator". As a
further example, network security experts unequivocally refer to further example, network security experts unequivocally refer to
"packet filters" as stateless devices that allow or deny packet "packet filters" as stateless devices that allow or deny packet
forwarding based on various conditions (e.g., source and destination forwarding based on various conditions (e.g., source and destination
IP addresses, source and destination ports, and IP protocol type IP addresses, source and destination ports, and IP protocol type
fields) [Alshaer]. fields) [Alshaer].
However, more information is required in case of other devices, like However, more information is required in case of other devices, like
stateful firewalls or application layer filters. These devices stateful firewalls or application layer filters. These devices
filter packets or communications, but there are differences in the filter packets or communications, but there are differences in the
packets and communications that they can categorize and the states packets and communications that they can categorize and the states
they maintain. Humans deal with these differences by asking more they maintain. Humans deal with these differences by asking more
questions to determine the specific category and functionality of the questions to determine the specific category and functionality of the
device. Machines can follow a similar approach, which is commonly device. Machines can follow a similar approach, which is commonly
referred to as question-answering [Hirschman] [Galitsky]. In this referred to as question-answering [Hirschman]. In this context, the
context, the CapIM and the derived data model can provide important CapIM and the derived data model can provide important and rich
and rich information sources. information sources.
Analogous considerations can be applied for channel protection Analogous considerations can be applied for channel protection
protocols, where we all understand that they will protect packets by protocols, where we all understand that they will protect packets by
means of symmetric algorithms whose keys could have been negotiated means of symmetric algorithms whose keys could have been negotiated
with asymmetric cryptography, but they may work at different layers with asymmetric cryptography, but they may work at different layers
and support different algorithms and protocols. To ensure and support different algorithms and protocols. To ensure
protection, these protocols apply integrity, optionally protection, these protocols apply integrity, optionally
confidentiality, anti-reply protections, and authentication. confidentiality, anti-reply protections, and authentication.
The CapIM is intended to clarify these ambiguities by providing a The CapIM is intended to clarify these ambiguities by providing a
skipping to change at page 8, line 5 skipping to change at page 8, line 5
include matching attributes of a packet or flow, and comparing the include matching attributes of a packet or flow, and comparing the
internal state of an NSF with a desired state. internal state of an NSF with a desired state.
* Action: An action is used to control and monitor aspects of NSFs * Action: An action is used to control and monitor aspects of NSFs
to handle packets or flows when the event and condition clauses to handle packets or flows when the event and condition clauses
are satisfied. NSFs provide security functions by executing are satisfied. NSFs provide security functions by executing
various Actions. Examples of I2NSF actions include providing various Actions. Examples of I2NSF actions include providing
intrusion detection and/or protection, web and flow filtering, and intrusion detection and/or protection, web and flow filtering, and
deep packet inspection for packets and flows. deep packet inspection for packets and flows.
An I2NSF Policy Rule is made up of three Boolean clauses: an Event An I2NSF Policy Rule is made up of three clauses: an Event clause, a
clause, a Condition clause, and an Action clause. This structure is Condition clause, and an Action clause. This structure is also
also called an ECA (Event-Condition-Action) Policy Rule. A Boolean called an ECA (Event-Condition-Action) Policy Rule. A Boolean clause
clause is a logical statement that evaluates to either TRUE or FALSE. is a logical statement that evaluates to either TRUE or FALSE. It
It may be made up of one or more terms; if more than one term is may be made up of one or more terms; if more than one term is
present, then each term in the Boolean clause is combined using present, then each term in the Boolean clause is combined using
logical connectives (i.e., AND, OR, and NOT). logical connectives (i.e., AND, OR, and NOT).
An I2NSF ECA Policy Rule has the following semantics: An I2NSF ECA Policy Rule has the following semantics:
IF <event-clause> is TRUE IF <event-clause> is TRUE
IF <condition-clause> is TRUE IF <condition-clause> is TRUE
THEN execute <action-clause> [constrained by metadata] THEN execute <action-clause> [constrained by metadata]
skipping to change at page 16, line 6 skipping to change at page 16, line 6
This section introduces a YANG module for NSFs' capabilities, as This section introduces a YANG module for NSFs' capabilities, as
defined in the Section 3. defined in the Section 3.
It makes references to It makes references to
* [RFC0768] * [RFC0768]
* [RFC0791] * [RFC0791]
* [RFC0792] * [RFC0792]
* [RFC0793]
* [RFC0854] * [RFC0854]
* [RFC0959] * [RFC0959]
* [RFC1939] * [RFC1939]
* [RFC2474] * [RFC2474]
* [RFC2616]
* [RFC2818] * [RFC2818]
* [RFC3168] * [RFC3168]
* [RFC3261] * [RFC3261]
* [RFC3501] * [RFC3501]
* [RFC4250]
* [RFC4340] * [RFC4340]
* [RFC4443] * [RFC4443]
* [RFC4766] * [RFC4766]
* [RFC4960] * [RFC4960]
* [RFC5101] * [RFC5103]
* [RFC5321] * [RFC5321]
* [RFC5595] * [RFC5595]
* [RFC6335] * [RFC6335]
* [RFC6437] * [RFC6437]
* [RFC6691] * [RFC6691]
* [RFC6864] * [RFC6864]
* [RFC7230] * [RFC7230]
* [RFC7231] * [RFC7231]
* [RFC7323]
* [RFC7323]
* [RFC8200] * [RFC8200]
* [RFC8329] * [RFC8329]
* [RFC8805] * [RFC8805]
* [IEEE802.3-2018] * [IEEE802.3-2018]
* [IANA-Protocol-Numbers] * [IANA-Protocol-Numbers]
* [I-D.ietf-tcpm-rfc793bis] * [I-D.ietf-tcpm-rfc793bis]
* [I-D.ietf-tcpm-accurate-ecn] * [I-D.ietf-tcpm-accurate-ecn]
* [I-D.ietf-tsvwg-udp-options] * [I-D.ietf-tsvwg-udp-options]
* [I-D.ietf-i2nsf-nsf-monitoring-data-model] * [I-D.ietf-i2nsf-nsf-monitoring-data-model]
<CODE BEGINS> file "ietf-i2nsf-capability@2021-09-15.yang" <CODE BEGINS> file "ietf-i2nsf-capability@2021-09-28.yang"
module ietf-i2nsf-capability { module ietf-i2nsf-capability {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability"; "urn:ietf:params:xml:ns:yang:ietf-i2nsf-capability";
prefix prefix
nsfcap; nsfcap;
organization organization
"IETF I2NSF (Interface to Network Security Functions) "IETF I2NSF (Interface to Network Security Functions)
Working Group"; Working Group";
contact contact
"WG Web: <https://tools.ietf.org/wg/i2nsf> "WG Web: <https://tools.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Editor: Jaehoon Paul Jeong Editor: Susan Hares
<mailto:shares@ndzh.com>
Editor: Jaehoon (Paul) Jeong
<mailto:pauljeong@skku.edu> <mailto:pauljeong@skku.edu>
Editor: Jinyong Tim Kim Editor: Jinyong (Tim) Kim
<mailto:timkim@skku.edu> <mailto:timkim@skku.edu>
Editor: Patrick Lingga Editor: Robert Moskowitz
<mailto:patricklink@skku.edu> <mailto:rgm@htt-consult.com>
Editor: Susan Hares Editor: Qiushi Lin
<mailto:shares@ndzh.com>"; <mailto:linqiushi@huawei.com>
Editor: Patrick Lingga
<mailto:patricklink@skku.edu>";
description description
"This module is a YANG module for I2NSF Network Security "This module is a YANG module for I2NSF Network Security
Functions (NSFs)'s Capabilities. Functions (NSFs)'s Capabilities.
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
skipping to change at page 18, line 26 skipping to change at page 18, line 28
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.";
// RFC Ed.: replace XXXX with an actual RFC number and remove // RFC Ed.: replace XXXX with an actual RFC number and remove
// this note. // this note.
revision "2021-09-15"{ revision "2021-09-28"{
description "Initial revision."; description "Initial revision.";
reference reference
"RFC XXXX: I2NSF Capability YANG Data Model"; "RFC XXXX: I2NSF Capability YANG Data Model";
// RFC Ed.: replace XXXX with an actual RFC number and remove // RFC Ed.: replace XXXX with an actual RFC number and remove
// this note. // this note.
} }
/* /*
* Identities * Identities
skipping to change at page 23, line 34 skipping to change at page 23, line 38
reference reference
"RFC 8805: A Format for Self-Published IP Geolocation Feeds - "RFC 8805: A Format for Self-Published IP Geolocation Feeds -
An access control for a geographical location (i.e., An access control for a geographical location (i.e.,
geolocation) that has the corresponding IP prefix."; geolocation) that has the corresponding IP prefix.";
} }
identity directional { identity directional {
description description
"Base identity for directional traffic flow capability"; "Base identity for directional traffic flow capability";
reference reference
"RFC 5101: Specification of the IP Flow Information "RFC 5103: Bidirectional Flow Export Using IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Export (IPFIX) - Terminology Unidirectional and Bidirectional
Traffic Flow Information - Terminology Unidirectional Flow";
and Bidirectional Flow";
} }
identity unidirectional { identity unidirectional {
base directional; base directional;
description description
"Identity for unirectional traffic flow."; "Identity for unidirectional traffic flow.";
reference reference
"RFC 5101: Specification of the IP Flow Information "RFC 5103: Bidirectional Flow Export Using IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Export (IPFIX) - Terminology Unidirectional Flow";
Traffic Flow Information - Terminology Unidirectional
Flow";
} }
identity bidirectional { identity bidirectional {
base directional; base directional;
description description
"Identity for bidirectional traffic flow."; "Identity for bidirectional traffic flow.";
reference reference
"RFC 5101: Specification of the IP Flow Information "RFC 5103: Bidirectional Flow Export Using IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Export (IPFIX) - Terminology Bidirectional Flow";
Traffic Flow Information - Terminology Bidirectional
Flow";
} }
identity protocol { identity protocol {
description description
"Base identity for protocols"; "Base identity for protocols";
} }
identity ethernet { identity ethernet {
base protocol; base protocol;
description description
skipping to change at page 31, line 8 skipping to change at page 31, line 8
description description
"Base identity for Layer 4 protocol condition capabilities, "Base identity for Layer 4 protocol condition capabilities,
e.g., TCP, UDP, SCTP, and DCCP"; e.g., TCP, UDP, SCTP, and DCCP";
} }
identity tcp { identity tcp {
base transport-protocol; base transport-protocol;
description description
"Base identity for TCP condition capabilities"; "Base identity for TCP condition capabilities";
reference reference
"RFC 793: Transmission Control Protocol "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
(TCP) Specification"; (TCP) Specification";
} }
identity udp { identity udp {
base transport-protocol; base transport-protocol;
description description
"Base identity for UDP condition capabilities"; "Base identity for UDP condition capabilities";
reference reference
"RFC 768: User Datagram Protocol"; "RFC 768: User Datagram Protocol";
} }
skipping to change at page 31, line 46 skipping to change at page 31, line 45
identity source-port-number { identity source-port-number {
base tcp; base tcp;
base udp; base udp;
base sctp; base sctp;
base dccp; base dccp;
description description
"Identity for matching TCP, UDP, SCTP, and DCCP source port "Identity for matching TCP, UDP, SCTP, and DCCP source port
number condition capability"; number condition capability";
reference reference
"RFC 793: Transmission Control Protocol - Port Number "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
(TCP) Specification (TCP) Specification
RFC 768: User Datagram Protocol RFC 768: User Datagram Protocol
RFC 4960: Stream Control Transmission Protocol RFC 4960: Stream Control Transmission Protocol
RFC 4340: Datagram Congestion Control Protocol"; RFC 4340: Datagram Congestion Control Protocol";
} }
identity destination-port-number { identity destination-port-number {
base tcp; base tcp;
base udp; base udp;
base sctp; base sctp;
base dccp; base dccp;
description description
"Identity for matching TCP, UDP, SCTP, and DCCP destination "Identity for matching TCP, UDP, SCTP, and DCCP destination
port number condition capability"; port number condition capability";
reference reference
"RFC 793: Transmission Control Protocol - Port Number "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
(TCP) Specification"; (TCP) Specification";
} }
identity flags { identity flags {
base tcp; base tcp;
description description
"Identity for TCP control bits (flags) condition capability"; "Identity for TCP control bits (flags) condition capability";
reference reference
"RFC 793: Transmission Control Protocol - Flags "RFC 3168: The Addition of Explicit Congestion Notification
RFC 3168: The Addition of Explicit Congestion Notification
(ECN) to IP - TCP Header Flags (ECN) to IP - TCP Header Flags
draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
(TCP) Specification (TCP) Specification
draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback draft-ietf-tcpm-accurate-ecn: More Accurate ECN Feedback
in TCP"; in TCP";
} }
identity tcp-options { identity tcp-options {
base tcp; base tcp;
description description
"Identity for TCP options condition capability."; "Identity for TCP options condition capability.";
reference reference
"RFC 793: Transmission Control Protocol - Options "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol
(TCP) Specification (TCP) Specification
RFC 6691: TCP Options and Maximum Segment Size RFC 6691: TCP Options and Maximum Segment Size
RFC 7323: TCP Extensions for High Performance"; RFC 7323: TCP Extensions for High Performance";
} }
identity total-length { identity total-length {
base udp; base udp;
description description
"Identity for matching UDP total-length condition capability. "Identity for matching UDP total-length condition capability.
The UDP total length can be smaller than the IP transport The UDP total length can be smaller than the IP transport
skipping to change at page 33, line 52 skipping to change at page 33, line 46
base protocol; base protocol;
description description
"Base identity for Application protocol"; "Base identity for Application protocol";
} }
identity http { identity http {
base application-protocol; base application-protocol;
description description
"The identity for Hypertext Transfer Protocol."; "The identity for Hypertext Transfer Protocol.";
reference reference
"RFC 2616: Hypertext Transfer Protocol (HTTP) "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message
RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing Syntax and Routing
RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics
and Content"; and Content";
} }
identity https { identity https {
base application-protocol; base application-protocol;
description description
"The identity for Hypertext Transfer Protocol Secure."; "The identity for Hypertext Transfer Protocol Secure.";
reference reference
"RFC 2818: HTTP over TLS (HTTPS) "RFC 2818: HTTP over TLS (HTTPS)
RFC7230: Hypertext Transfer Protocol (HTTP/1.1): Message RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing Syntax and Routing
RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics
and Content"; and Content";
} }
identity ftp { identity ftp {
base application-protocol; base application-protocol;
description description
"The identity for File Transfer Protocol."; "The identity for File Transfer Protocol.";
reference reference
"RFC 959: File Transfer Protocol (FTP)"; "RFC 959: File Transfer Protocol (FTP)";
} }
skipping to change at page 43, line 18 skipping to change at page 43, line 16
description description
"Conditions capabilities. "Conditions capabilities.
If a network security function has the condition If a network security function has the condition
capabilities, the network security function capabilities, the network security function
supports rule execution according to conditions of supports rule execution according to conditions of
IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6."; IPv4, IPv6, TCP, UDP, SCTP, DCCP, ICMP, or ICMPv6.";
reference reference
"RFC 768: User Datagram Protocol - UDP. "RFC 768: User Datagram Protocol - UDP.
RFC 791: Internet Protocol - IPv4. RFC 791: Internet Protocol - IPv4.
RFC 792: Internet Control Message Protocol - ICMP. RFC 792: Internet Control Message Protocol - ICMP.
RFC 793: Transmission Control Protocol - TCP.
RFC 4443: Internet Control Message Protocol (ICMPv6) RFC 4443: Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification for the Internet Protocol Version 6 (IPv6) Specification
- ICMPv6. - ICMPv6.
RFC 4960: Stream Control Transmission Protocol - SCTP. RFC 4960: Stream Control Transmission Protocol - SCTP.
RFC 8200: Internet Protocol, Version 6 (IPv6) RFC 8200: Internet Protocol, Version 6 (IPv6)
Specification - IPv6. Specification - IPv6.
RFC 8329: Framework for Interface to Network Security RFC 8329: Framework for Interface to Network Security
Functions - I2NSF Flow Security Policy Structure."; Functions - I2NSF Flow Security Policy Structure.
draft-ietf-tcpm-rfc793bis-25: Transmission Control
Protocol (TCP) Specification";
leaf-list ethernet-capability { leaf-list ethernet-capability {
type identityref { type identityref {
base ethernet; base ethernet;
} }
description description
"Media Access Control (MAC) capabilities"; "Media Access Control (MAC) capabilities";
reference reference
"IEEE 802.3: IEEE Standard for Ethernet"; "IEEE 802.3: IEEE Standard for Ethernet";
} }
skipping to change at page 44, line 40 skipping to change at page 44, line 39
- ICMPv6"; - ICMPv6";
} }
leaf-list tcp-capability { leaf-list tcp-capability {
type identityref { type identityref {
base tcp; base tcp;
} }
description description
"TCP packet capabilities"; "TCP packet capabilities";
reference reference
"RFC 793: Transmission Control Protocol - TCP "draft-ietf-tcpm-rfc793bis-25: Transmission Control
draft-ietf-tcpm-rfc793bis-25: Transmission Control
Protocol (TCP) Specification"; Protocol (TCP) Specification";
} }
leaf-list udp-capability { leaf-list udp-capability {
type identityref { type identityref {
base udp; base udp;
} }
description description
"UDP packet capabilities"; "UDP packet capabilities";
reference reference
skipping to change at page 51, line 38 skipping to change at page 51, line 29
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
1983, <https://www.rfc-editor.org/info/rfc854>. 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<https://www.rfc-editor.org/info/rfc959>. <https://www.rfc-editor.org/info/rfc959>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
skipping to change at page 52, line 16 skipping to change at page 52, line 5
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>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <https://www.rfc-editor.org/info/rfc4254>. January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
skipping to change at page 53, line 19 skipping to change at page 53, line 5
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message [RFC4766] Wood, M. and M. Erlinger, "Intrusion Detection Message
Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766, Exchange Requirements", RFC 4766, DOI 10.17487/RFC4766,
March 2007, <https://www.rfc-editor.org/info/rfc4766>. March 2007, <https://www.rfc-editor.org/info/rfc4766>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export
Export (IPFIX) Protocol for the Exchange of IP Traffic Using IP Flow Information Export (IPFIX)", RFC 5103,
Flow Information", RFC 5101, DOI 10.17487/RFC5101, January DOI 10.17487/RFC5103, January 2008,
2008, <https://www.rfc-editor.org/info/rfc5101>. <https://www.rfc-editor.org/info/rfc5103>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>. <https://www.rfc-editor.org/info/rfc5321>.
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol
(DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595,
September 2009, <https://www.rfc-editor.org/info/rfc5595>. September 2009, <https://www.rfc-editor.org/info/rfc5595>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
skipping to change at page 54, line 28 skipping to change at page 54, line 15
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance", Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014, RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>. <https://www.rfc-editor.org/info/rfc7323>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
skipping to change at page 56, line 23 skipping to change at page 56, line 5
[I-D.ietf-i2nsf-registration-interface-dm] [I-D.ietf-i2nsf-registration-interface-dm]
Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park,
"I2NSF Registration Interface YANG Data Model", Work in "I2NSF Registration Interface YANG Data Model", Work in
Progress, Internet-Draft, draft-ietf-i2nsf-registration- Progress, Internet-Draft, draft-ietf-i2nsf-registration-
interface-dm-11, 21 August 2021, interface-dm-11, 21 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-i2nsf- <https://www.ietf.org/archive/id/draft-ietf-i2nsf-
registration-interface-dm-11.txt>. registration-interface-dm-11.txt>.
10.2. Informative References 10.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012, RFC 6691, DOI 10.17487/RFC6691, July 2012,
<https://www.rfc-editor.org/info/rfc6691>. <https://www.rfc-editor.org/info/rfc6691>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
skipping to change at page 57, line 25 skipping to change at page 57, line 8
numbers/protocol-numbers.xhtml, September 2020. numbers/protocol-numbers.xhtml, September 2020.
[IEEE802.3-2018] [IEEE802.3-2018]
Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for
Ethernet", August 2018, Ethernet", August 2018,
<https://ieeexplore.ieee.org/document/8457469>. <https://ieeexplore.ieee.org/document/8457469>.
[Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and [Alshaer] Shaer, Al., Hamed, E., and H. Hamed, "Modeling and
management of firewall policies", 2004. management of firewall policies", 2004.
[Galitsky] Galitsky, B. and R. Pampapathi, "Can many agents answer
questions better than one", First
Monday http://dx.doi.org/10.5210/fm.v10i1.1204, 2005.
[Hirschman] [Hirschman]
Hirschman, L. and R. Gaizauskas, "Natural Language Hirschman, L. and R. Gaizauskas, "Natural Language
Question Answering: The View from Here", Natural Language Question Answering: The View from Here", Natural Language
Engineering 7:4, pgs 275-300, Cambridge University Press , Engineering 7:4, pgs 275-300, Cambridge University Press ,
November 2001. November 2001.
[Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns", [Hohpe] Hohpe, G. and B. Woolf, "Enterprise Integration Patterns",
ISBN 0-32-120068-3 , 2003. ISBN 0-32-120068-3 , 2003.
[Martin] Martin, R.C., "Agile Software Development, Principles, [Martin] Martin, R.C., "Agile Software Development, Principles,
Patterns, and Practices", Prentice-Hall , ISBN: Patterns, and Practices", Prentice-Hall , ISBN:
0-13-597444-5 , 2002. 0-13-597444-5 , 2002.
[OODMP] "http://www.oodesign.com/mediator-pattern.html". [OODMP] "https://www.oodesign.com/mediator-pattern.html".
[OODOP] "http://www.oodesign.com/mediator-pattern.html". [OODOP] "https://www.oodesign.com/mediator-pattern.html".
[OODSRP] "http://www.oodesign.com/mediator-pattern.html". [OODSRP] "https://www.oodesign.com/mediator-pattern.html".
Appendix A. Configuration Examples Appendix A. Configuration Examples
This section shows configuration examples of "ietf-i2nsf-capability" This section shows configuration examples of "ietf-i2nsf-capability"
module for capabilities registration of general firewall. module for capabilities registration of general firewall.
A.1. Example 1: Registration for the Capabilities of a General Firewall A.1. Example 1: Registration for the Capabilities of a General Firewall
This section shows a configuration example for the capabilities This section shows a configuration example for the capabilities
registration of a general firewall in either an IPv4 network or an registration of a general firewall in either an IPv4 network or an
 End of changes. 53 change blocks. 
100 lines changed or deleted 74 lines changed or added

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