draft-ietf-i2rs-protocol-security-requirements-09.txt   draft-ietf-i2rs-protocol-security-requirements-10.txt 
I2RS working group S. Hares I2RS working group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Migault Intended status: Informational D. Migault
Expires: February 20, 2017 J. Halpern Expires: March 12, 2017 J. Halpern
Ericsson Ericsson
August 19, 2016 September 8, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-09 draft-ietf-i2rs-protocol-security-requirements-10
Abstract Abstract
This presents security-related requirements for the I2RS protocol for This presents security-related requirements for the I2RS protocol
mutual authentication, transport protocols, data transfer and which provides a new interface to the routing system described in the
transactions. I2RS architecture document (RFC7921). The I2RS protocol is a re-use
protocol implemented by re-using portions of existing IETF protocols
and adding new features to these protocols. The I2RS protocol re-
uses security features of a secure transport (E.g. TLS, SSH, DTLS)
such as encryption, message integrity, mutual peer authentication,
and replay protection. The new security features I2RS adds are: a
priority mechanism to handle multi-headed write transactions, an
opaque secondary identifier which identifies an application using the
I2RS client, and an extremely constrained read-only non-secure
transport. This document provides the detailed requirements for
these security features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 20, 2017. This Internet-Draft will expire on March 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3 2.2. Security Definitions . . . . . . . . . . . . . . . . . . 5
2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 3 2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5
3. Security-Related Requirements . . . . . . . . . . . . . . . . 5 3. Security Features and Protocols: Re-used and New . . . . . . 7
3.1. Mutual authentication of an I2RS client and an I2RS Agent 5 3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7
3.2. Transport Requirements Based on Mutual Authentication . . 6 3.2. New Security Features . . . . . . . . . . . . . . . . . . 8
3.3. Data Confidentiality Requirements . . . . . . . . . . . . 7 3.3. I2RS Protocol Security Requirements vs. IETF Management
3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 8 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Role-Based Data Model Security . . . . . . . . . . . . . 8 4. Security-Related Requirements . . . . . . . . . . . . . . . . 10
3.6. Security of the environment . . . . . . . . . . . . . . . 9 4.1. I2RS Peers(agent and client) Identity Authentication . . 11
4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Identity Validation Before Role-Based Message Actions . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.4. Multi-Channel Transport: Secure Transport and Insecure
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 4.5. Management Protocol Security . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 10 4.6. Role-Based Data Model Security . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Security of the environment . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Interface to the Routing System (I2RS) provides read and write The Interface to the Routing System (I2RS) provides read and write
access to information and state within the routing process. An I2RS access to information and state within the routing process. An I2RS
client interacts with one or more I2RS agents to collect information client interacts with one or more I2RS agents to collect information
from network routing systems. from network routing systems. [RFC7921] describes the architecture
of this interface, and this documents assumes the reader is familiar
with this architecture and its definitions. Section 2 highlights
some of the references the reader is required to be familiar with.
This document describes the requirements for the I2RS protocol in the The I2RS interface is instantiated by the I2RS protocol connecting an
security-related areas of mutual authentication of the I2RS client I2RS client and an I2RS agent associated with a routing system. The
and agent, the transport protocol carrying the I2RS protocol I2RS protocol is a re-use protocol implemented by re-using portions
messages, and the atomicity of the transactions. These requirements of existing IETF protocols, and adding new features to these
align with the description of the I2RS architecture found in protocols. As a re-use protocol, it can be considered a higher-level
[RFC7921] document which solves the problem described in [RFC7920]. protocol since it can be instantiated in multiple management
protocols (e.g. NETCONF [RFC6241] or RESTCONF
[I-D.ietf-netconf-restconf]) operating over a secure transport. The
security for the I2RS protocol comes from the managmenet protocols
operating over a a secure transport which carries traffic over
multiple links.
[I-D.ietf-i2rs-ephemeral-state] discusses I2RS role-based access This document is part of the requirements for I2RS protocol which
control that provides write conflict resolution in the ephemeral data also include:
store using the I2RS Client Identity, I2RS Secondary Identity and
priority. The draft [RFC7922] describes the traceability framework
and its requirements for I2RS. The draft [RFC7923] describes the
requirements for I2RS to be able to publish information or have a
remote client subscribe to an information data stream.
1.1. Requirements Language o I2RS architecture [RFC7921],
o I2RS ephemeral state requirements [I-D.ietf-i2rs-ephemeral-state],
o publication/subscription requirements [RFC7922], and
o traceability [RFC7923].
Since the I2RS "higher-level" protocol changes the interface to the
routing systems, it is important that implementers understand the new
security requirements for the environment the I2RS protocol operates
in. These secuirty requirements for the I2RS environment are
specified in [I-D.ietf-i2rs-security-environment-reqs], and the
summary of the I2RS protocol security environment found in the I2RS
Architecture [RFC7920].
I2RS reuses the secure transport protocols (TLS, SSH, DTLS) which
support encryption, message integrity, peer authentication, and key
distribution protocols. Optionally, implementers may utilize AAA
protocols (Radius over TLS or Diameter over TLS) to securely
distribute identity information.
Section 3 provides an overview of security features and protocols
being re-used (section 3.1) and the new security features being
required (section 3.2). Section 3 also explores how existing and new
security features and protocols would be paired with existing IETF
management protocols (section 3.3).
The new features I2RS extends to these protocols are a priority
mechanism to handle multi-headed reads, an opaque secondary
identifier to allow traceability of an application utilizing a
specific I2RS client to communicate with an I2RS agent, and insecure
transport constrained to be utilized only for read-only data which
publically available data (e.g. public BGP Events, public telemetry
information, web service available) and some legacy data.
Section 4 provides the I2RS protocol security requirements by the
following security features:
o peer identity authentication (section 4.1),
o peer identity validation before role-based message actions
(section 4.2)
o peer identity and client redundancy (section 4.3),
o multi-channel transport requirements: Secure transport and
insecure Transport (section 4.4),
o management protocol security requirements (section 4.5),
o role-based security (section 4.6),
o security environment (section 4.7)
Protocols designed to be I2RS higher-layer protocols need to fulfill
these security requirements.
2. Definitions
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Definitions 2.2. Security Definitions
2.1. Security Definitions
This document utilizes the definitions found in the following This document utilizes the definitions found in the following
documents: [RFC4949] and [RFC7921] documents: [RFC4949] and [RFC7921]
Specifically, this document utilizes the following definitions from Specifically, this document utilizes the following definitions from
[RFC4949]: [RFC4949]:
o access control, o access control,
o Authentication, o authentication,
o Data Confidentiality, o data confidentiality,
o Data Integrity, o data integrity,
o Data Privacy, o data privacy,
o Identity, o identity,
o Identifier, o identifier,
o Mutual Authentication, o mutual authentication,
o role, o role,
o role-based access control, o role-based access control,
o security audit trail, and o security audit trail, and
o trust. o trust.
[RFC7922] describes traceability for I2RS interface and the I2RS [RFC7922] describes traceability for I2RS interface and the I2RS
protocol. Traceability is not equivalent to a security audit trail. protocol. Traceability is not equivalent to a security audit trail
or simple logging of information. A security audit trail may utilize
traceability information.
2.2. I2RS Specific Definitions This document also requires that the user is familiar with the
pervasive security requirements in [RFC7258].
2.3. I2RS Specific Definitions
The document utilizes the following concepts from the I2RS
architecture: [RFC7921]:
o I2RS client, I2RS agent, and I2RS protocol (section 2),
o I2RS higher-layer protocol (section 7.2)
o scope: read scope, notification scope, and write scope (section
2),
o identity and scope of the identity (section 2),
o roles or security rules (section 2),
o identity and scope, and secondary identity (section 2),
o routing system/subsytem (section 2),
o I2RS assumed security environment (section 4),
o I2RS identity and authorization (section 4.1),
o I2RS authorization, scope of Authorization in I2RS client and
agent (section 4.2),
o client redundancy with a single client identity (section 4.3),
o restrictions on I2RS in personal devices (section 4.4),
o communication channels and I2RS high-layer protocol (section 7.2),
o active communication versus connectivity (section 7.5),
o multi-headed control (section 7.8), and
o transaction, message, multi-message atomicity (section 7.9).
This document assumes the reader is familar with these terms.
This document discusses the security of the multiple I2RS
communication channels which operate over the higher-layer I2RS
protocol. The higher-layer I2RS protocol combines a secure transport
and I2RS contextual information, and re-uses IETF protocols and data
models to create the secure transport and the I2RS data-model driven
contextual information. To describe how the I2RS high-layer protocol
combines other protocols into the I2RS higher-layer protocol, the
following terms are used:
I2RS component protocols I2RS component protocols
Protocols which are combined to create the I2RS protocol. Protocols which are re-used and combined to create the I2RS
protocol.
I2RS Higher-level protocol I2RS secure-transport component protocols
The I2RS secure transport protocols that support the I2RS higher-
layer protocol.
The I2RS protocol exists as a higher-level protocol which may I2RS management component protocols
combine other protocols (NETCONF, RESTCONF, IPFIX and others)
within a specific I2RS client-agent relationship with a specific
trust for ephemeral configurations, event, tracing, actions, and
data flow interactions. The protocols included in the I2RS
protocol protocol are defined as I2RS component protocols. (Note:
Version 1 of the I2RS protocol will combine only NETCONF and
RESTCONF. Experiments with other protocols such as IPFIX have
shown these are useful to combine with NETCONF and RESTCONF
features.)
I2RS message The I2RS management protocol which provide the management
information context.
is a complete data message of one of the I2RS component protocols. I2RS AAA component protocols
The I2RS component protocols may require multiple IP-packets to
send one protocol message.
I2RS multi-message atomicity The I2RS AAA protocols supporting the I2RS higher-layer protocol.
An I2RS operation (read, write, event, action) must be contained The I2RS higher-layer protocol requires implementation of a I2RS
within one I2RS message. Each I2RS operation must be atomic. secure-transport component protocol and the I2RS management component
While it is possible to have an I2RS operation which is contained protocol. The I2RS AAA component protocol is optional.
in multiple I2RS (E.g. write in multiple messages), this is not
supported in order to simplify the first version of I2RS.
Multiple-message atomicity of I2RS operations would be used in a
roll-back of a grouping of commands (e.g. multiple writes).
I2RS transaction 3. Security Features and Protocols: Re-used and New
is a unit of I2RS functionality. Some examples of I2RS 3.1. Security Protocols Re-Used by the I2RS Protocol
transactions are:
* The I2RS client issues a read request to a I2RS agent, and the I2RS also requires a secure transport protocol and key distribution
I2RS Agent responding to the read request protocols. The secure transport features required by I2RS are peer
authentication, confidentiality, data integrity, and replay
protection for I2RS messages. According to
[I-D.ietf-taps-transports], the secure transport protocols which
support peer authentication, confidentiality, data integrity, and
replay protection are the following:
* The I2RS client issues a write of ephemeral configuration 1. TLS [RFC5246] over TCP or SCTP,
values into an I2RS agent's data model, followed by the I2RS
agent response to the write.
* An I2RS client may issue an action request, the I2RS agent 2. DTLS over UDP with replay detection and anti-DoS stateless cookie
responds to the action-request, and then responds when action mechanism required for the I2RS protocol, and the I2RS protocol
is complete. Actions can be single step processes or multiple allow DTLS options of record size negotiation and and conveyance
step process. of "don't" fragment bits to be optional in deployments.
* An I2RS client requests to receive an event notification, and 3. HTTP over TLS (over TCP or SCTP), and
the I2RS Agent sets up to send the events.
* An I2RS agent sends events to an I2RS Client on an existing 4. HTTP over DTLS (with the requirements and optional features
connection. specified above in item 2).
An I2RS action may require multiple I2RS messages in order to The following protocols will need to be extended to provide
complete a transation. confidentiality, data integrity, peer authentication, and key
distribution protocols: SSH, SCTP, or the ForCES TML layer over SCTP.
I2RS secondary identifier The specific type of key management protocols an I2RS secure
transport uses depends on the transport. Key management protocols
utilized for the I2RS protocols SHOULD support automatic rotation.
The I2RS architecture document [RFC7921] defines a secondary An I2RS implementer may use AAA protocols over secure transport to
identity as the entity of some non-I2RS entity (e.g. application) distribute the identities for I2RS client and I2RS agent and role
which has requested a particular I2RS client perform an operation. authorization information. Two AAA protocols are: Diameter [RFC6733]
The I2RS secondary identifier represents this identity so it may and Radius [RFC2865]. To provide the best security I2RS peer
be distinguished from all others. identities, the AAA protocols MUST be run over a secure transport
(Diameter over secure transport (TLS over TCP) [RFC6733]), Radius
over a secure transport (TLS) [RFC6614]).
I2RS routing system 3.2. New Security Features
Layer three (L3) routing systems which include physical routers, The new features are priority, an opaque secondary identifier, and an
virtual routers (in hypervisors or load splitters), and other insecure protocol for read-only data constrained to specific standard
devices supporting L3 routing in order to forward packets based on usages. The I2RS protocol allows multi-headed control by several
L3 headers. I2RS clients. This multi-headed control is based on the assumption
that the operator deploying the I2RS clients, I2RS agents, and the
I2rs protocol will coordinate the read, write, and notification scope
so the I2RS clients will not contend for the same write scope.
However, just in case there is an unforseen overlap of I2RS clients
attempting to write a particular piece of data, the I2RS architecture
[RFC7921] provides the concept of each I2RS client having a priority.
The I2RS client with the highest priority will have its write
succeed. This document specifies requirements for this new concept
of priority.
3. Security-Related Requirements The opaque secondary identifier identifies an application which is
using the I2RS client to I2RS agent communication to manage the
routing system. The secondary identifier is opaque to the I2RS
protocol. In order to protect personal privacy, the secondary
identifier should not contain personal identifiable information.
The security for the I2RS protocol requires mutually authenticated The last new security feature is the ability to allow non-
I2RS clients and I2RS agents communicating over a secure transport. confidential data to be transfered over a non-secure transport. It
The I2RS protocol MUST be able to provide atomicity of an I2RS is expected that most I2RS data models will describe information that
transaction, but it is not required to have multi-message atomicity will be transferred with confidentiality. Therefore, any model which
and roll-back mechanism transactions. Multiple messages transactions transfers data over a non-secure transport is marked. The use of a
may be impacted by the interdependency of data. This section non-secure transport is optional, and an implementer SHOULD create
discusses the details of these security requirements. knobs that allow data marked as non-confidential to be sent over a
secure transport.
There are dependencies in some of the requirements below. For Non-confidential data can only be read or notification scope
confidentiality (section 3.3) and integrity (section 3.4) to be transmission of events. Non-confidential data cannot be write scope
achieved, the client-agent must have mutual authentication (section or notification scope configuration. An example of non-confidential
3.1) and secure transport (section 3.2). Since I2RS does not itself data is the telemetry information that is publically known (e.g. BGP
provide confidentiality and integrity, it depends on running over a route-views data or web site status data) or some legacy data (e.g.
secure Transport that provides these features. interface) which cannot be transported in secure transport. The IETF
I2RS Data models MUST indicate in the data model the specific data
which is non-confidential.
3.1. Mutual authentication of an I2RS client and an I2RS Agent Most I2RS data models will expect that the information described in
the model will be transferred with confidentiality. Therefore, it is
The I2RS architecture [RFC7921] sets the following requirements: 3.3. I2RS Protocol Security Requirements vs. IETF Management Protocols
Table 1 below provides a partial list of the candidate management
protocols and the secure transports each one of the support. One
column in the table indicates the transport protocol will need I2RS
security extensions.
Mangement
Protocol Transport Protocol I2RS Extensions
========= ===================== =================
NETCONF TLS over TCP (*1) None required (*2)
RESTCONF HTTP over TLS with None required (*2)
X.509v3 certificates,
certificate validation,
mutual authentication:
1) authenticated
server identity,
2) authenticated
client identity
(*1)
FORCES TML overs SCTP Needs extension to
(*1) TML to run TML
over TLS over SCTP,
or DTLS described
above. The
IPSEC mechanism is
not sufficient for
I2RS traveling over
multiple hops
(router + link)
(*2)
IPFIX SCTP, TCP, UDP Needs to extension
TLS or DTLS for to support TLS or
secure client (*1) DTLS with options
described above. (*2)
*1 - Key management protocols
MUST support appropriate key rotation.
*2 - Identity and Role authorization distributed
by Diameter or Radius MUST use Diameter over TLS
or Radius over TLS.
4. Security-Related Requirements
This section discusses security requirements based on the following
security functions:
o peer identity authentication (section 4.1),
o Peer Identity validation before Role-based Message Actions
(section 4.2)
o peer identity and client redundancy (section 4.3),
o multi-channel transport requirements: Secure transport and
insecure Transport (section 4.4),
o management protocol security requirements (section 4.5),
o role-based security (section 4.6),
o security environment (section 4.7)
The I2RS Protocol depends upon a secure transport layer for peer
authentication, data integrity, confidentiality, and replay
protection. The optional insecure transport can only be used
restricted set of publically data available (events or information)
or a select set of legacy data. Data passed over the insecure
transport channel MUST not contain any data which identifies a person
or any "write" transactions.
4.1. I2RS Peers(agent and client) Identity Authentication
The following requirements specify the security requirements for Peer
Identity Authentication for the I2RS protocol:
o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
identity, and at least one unique identifier that uniquely identity, and at least one unique identifier that uniquely
identifies each party in the I2RS protocol context. identifies each party in the I2RS protocol context.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
mutual identification of the I2RS client and I2RS agent. mutual identification of the I2RS client and I2RS agent.
o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a o SEC-REQ-03: Identifier distribution and the loading of these
I2RS client, MUST confirm that the I2RS client has a valid identifiers into I2RS agent and I2RS client SHOULD occur outside
identifier. the I2RS protocol prior to the I2RS protocol establishing a
connection between I2RS client and I2RS agent. AAA protocols MAY
be used to distribute these identifiers, but other mechanism can
be used.
o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from Explanation:
an I2RS agent, MUST confirm the I2RS agent has a valid identifier.
o SEC-REQ-05: Identifier distribution and the loading of these These requirements specify the requirements for I2RS peer (I2RS agent
identifiers into I2RS agent and I2RS Client SHOULD occur outside and I2RS client) authentication. A secure transport (E.g. TLS) will
the I2RS protocol prior to the I2RS protocol establishing a authenticate based on these identities. The AAA protocol
connection between I2RS client and I2RS agent. (One mechanism distributing I2RS identity information SHOULD transport its
such mechanism is AAA protocols.) information over a secure transport.
o SEC-REQ-06: Each Identifier MUST have just one priority. 4.2. Identity Validation Before Role-Based Message Actions
o SEC-REQ-07: Each Identifier is associated with one secondary The requirements for I2RS clients with Secure Connections are the
following:
SEC-REQ-04: An I2RS agent receiving a request from an I2RS client
MUST confirm that the I2RS client has a valid identity.
SEC-REQ-05: An I2RS client receiving an I2RS message over a secure
transport MUST confirm that the I2RS agent has a valid identifier.
SEC-REQ-06: An I2RS agent receiving an I2RS message over an
insecure transport MUST confirm that the content is suitable for
transfer over such a transport.
Explanation:
Each I2RS client has a scope based on its identity and the security
roles (read, write, or events) associated with that identity, and
that scope must be considered in processing an I2RS messages sent on
a communication channel. An I2RS communication channel may utilize
multiple transport sessions, or establish a transport session and
then close the transport session. Therefore, it is important that
the I2RS peers are operating utilizing valid peer identities when a
message is processed rather than checking if a transport session
exists.
4.3. Peer Identity, Priority, and Client Redundancy
Requirements:
SEC-REQ-07: Each I2RS Identifier MUST be associated with just one
priority.
SEC-REQ-08: Each Identifier is associated with one secondary
identifier during a particular I2RS transaction (e.g. read/write identifier during a particular I2RS transaction (e.g. read/write
sequence), but the secondary identifier may vary during the time a sequence), but the secondary identifier may vary during the time a
connection between the I2RS client and I2RS agent is active. connection between the I2RS client and I2RS agent is active.
Since a single I2RS client may be use by multiple applications,
the secondary identifier may vary as the I2RS client is utilize by
different application each of whom have a unique secondary
identity and identifier.
3.2. Transport Requirements Based on Mutual Authentication Explanation:
SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a The I2RS architecture also allows multiple I2RS clients with unique
secure transport and optionally MAY be able to transfer data over a identities to connect to an I2RS agent (section 7.8). The I2RS
non-secure transport. A secure transport MUST provide data deployment using multiple clients SHOULD coordinate this multi-headed
confidentiality, data integrity, and replay prevention. control of I2RS agents by I2RS clients so no conflict occurs in the
write scope. However, in the case of conflict on a write scope
variable, the error resolution mechanisms defined by the I2RS
architecture multi-headed control ([RFC7921], section 7.8) allow the
I2RS agent to deterministically choose one I2RS client. The I2RS
client with highest priority is given permission to write the
variable, and the second client receives an error message.
The default I2RS transport is a secure transport. A single I2RS client may be associated with multiple applications
with different tasks (e.g. weekly configurations or emergency
configurations). The secondary identity is an opaque value that the
I2RS client passes to the I2RS agent so that this opaque value can be
placed in the tracing file or event stream to identify the
application using the I2RS client to I2RS agent communication.
A non-secure transport can be used for publishing telemetry data or One example of the use of the secondary identity is the situation
other operational state that was specifically indicated to non- where an operator of a network has two applications that use an I2RS
confidential in the data model in the Yang syntax. Since the non- client. The first application is a weekly configuration application
secure transport is optional, the operator may transmit this data that uses the I2RS protocol to change configurations. The second
over a secure transport. The following are further restrictions on application is an application that allows operators to makes
the non-secure transport: emergency changes to routers in the network. Both of these
applications use the same I2RS client to write to an I2RS agent. In
order for traceability to determine which application (weekly
configuration or emergency) wrote some configuration changes to a
router, the I2RS client sends a different opaque value for each of
the applications. The weekly configuration secondary opaque value
could be "xzzy-splot" and the emergency secondary opaque value could
be "splish-splash".
o The configuration of ephemeral data in the I2RS Agent by the I2RS A second example is if the I2RS client is used for monitoring of
client SHOULD be done over a secure transport. critical infrastructure. The operator of a network using the I2RS
client may desire I2RS client redundancy where the monitoring
application wth the I2RS client is deployed on two different boxes
with the same I2RS client identity (see [RFC7921] section 4.3) These
two monitoring applications pass to the I2RS client whether the
application is the primary or back up application, and the I2RS
client passes this information in the I2RS secondary identitifier as
the figure below shows. The primary applications secondary
identifier is "primary-monitoring", and the backup application
secondary identifier is "backup-monitoring". The I2RS tracing
information will include the secondary identifier information along
with the transport information in the tracing file in the agent.
o It is anticipated that the passing of most I2RS ephemeral state Example 2: Primary and Backup Application for Monitoring
operational status SHOULD be done over a secure transport. Identification sent to agent
o As [I-D.ietf-i2rs-ephemeral-state] notes, each data model SHOULD Application A--I2RS client--Secure transport(#1)
indicate whether the transport exchanging the data between I2RS [I2RS identity 1, secondary identifier: "primary-monitoring"]-->
client and I2RS agent is secure or insecure.
SEC-REQ-09: A secure transport MUST be associated with a key Application B--I2RS client--Secure transport(#2)
management solution that can guarantee that only the entities having [I2RS identity 1, secondary identifier: "backup-monitoring"]-->
sufficient privileges can get the keys to encrypt/decrypt the
sensitive data. Per BCP107 [RFC4107] this key management system Figure 1
SHOULD be automatic, but MAY be manual in the following scenarios:
4.4. Multi-Channel Transport: Secure Transport and Insecure Transport
Requirements:
SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
secure transport and optionally MAY be able to transfer data over
a non-secure transport. The default transport is a secure
transport, and this means it is mandatory to implement (MTI) in
all I2RS agents, and in any I2RS client which: a) performs a Write
scope transaction which is sent to the I2RS agent or b):
configures an Event Scope transaction. It is mandatory to use
(MTU) on any I2RS client's Write transaction or the configuration
of an Event Scope transaction.
SEC-REQ-10: The secure transport MUST provide data
confidentiality, data integrity, and practical replay prevention.
SEC-REQ-11: The I2RS client and I2RS agent protocol SHOULD
implement mechanisms that mitigate DoS attacks. For the secure
transport, this means the secure transport must support DoS
prevention. For the insecure transport protocol, the I2RS higher-
layer protocol MUST contain a transport management layer that
considers the detection of DoS attacks and provides a warning over
a secure-transport channel.
SEC-REQ-12: A secure transport MUST be associated with a key
management solution that can guarantee that only the entities
having sufficient privileges can get the keys to encrypt/decrypt
the sensitive data.
SEC-REQ-13: A machine-readable mechanism to indicate that a data-
model contains non-confidential data MUST be provided. A non-
secure transport MAY be used to publish only read scope or
notification scope data if the associated data model indicates
that that data is non-confidential.
SEC-REQ-14: The I2RS protocol MUST be able to support multiple
secure transport sessions providing protocol and data
communication between an I2RS agent and an I2RS client. However,
a single I2RS agent to I2RS client connection MAY elect to use a
single secure transport session or a single non-secure transport
session conforming the requirements above.
SEC-REQ-15: Deployment configuration knobs SHOULD be created to
allow operators to send "non-confidential" Read scope (data or
Event streams) over a secure transport.
Explanation:
The I2RS architecture defines three scopes: read, write, and
notification scope. Insecure data can only be used for read scope
and notification scope of "non-confidential data". The configuration
of ephemeral data in the I2RS agent uses either write scope for data
or write scope for configuration of event notification streams. The
requirement to use secure transport for configuration prevents
accidental or malevolent entities from altering the I2RS routing
system through the I2RS agent.
It is anticipated that the passing of most I2RS ephemeral state
operational status SHOULD be done over a secure transport.
In most circumstances the secure transport protocol will be
associated with a key management system. Most deployments of the
I2RS protocol will allow for automatic key management systems. Since
the data models for the I2RS protocol will control key routing
functions, it is important that deployments of I2RS use automatic key
management systems.
Per BCP107 [RFC4107] while key management system SHOULD be automatic,
the systems MAY be manual in the following scenarios:
a) The environment has limited bandwidth or high round-trip times. a) The environment has limited bandwidth or high round-trip times.
b) The information being protected has low value. b) The information being protected has low value.
c) The total volume of traffic over the entire lifetime of the c) The total volume of traffic over the entire lifetime of the
long-term session key will be very low. long-term session key will be very low.
d) The scale of the deployment is limited. d) The scale of the deployment is limited.
Most I2RS environments (Clients and Agents) will not have the Operators deploying the I2RS protocol selecting manual key management
environment described by BCP107 [RFC4107] but a few I2RS use cases SHOULD consider both short and medium term plans. Deploying
required limited non-secure light-weight telemetry messages that have automatic systems initially may save effort over the long-term.
these requirements. An I2RS data model must indicate which portions
can be served by manual key management.
SEC-REQ-10: The I2RS protocol MUST be able to support multiple secure 4.5. Management Protocol Security
transport sessions providing protocol and data communication between
an I2RS Agent and an I2RS client. However, a single I2RS Agent to
I2RS client connection MAY elect to use a single secure transport
session or a single non-secure transport session.
SEC-REQ-11: The I2RS Client and I2RS Agent protocol SHOULD implement Requirements:
mechanisms that mitigate DoS attacks.
3.3. Data Confidentiality Requirements SEC-REQ-16: In a critical infrastructure, certain data within
routing elements is sensitive and read/write operations on such
data SHOULD be controlled in order to protect its confidentiality.
To achieve this, higher-layer protocols MUST utilize a secure
transport, and SHOULD provide access control functions to protect
confidentiality of the data.
SEC-REQ-12: In a critical infrastructure, certain data within routing SEC-REQ-17: An integrity protection mechanism for I2RS MUST be
elements is sensitive and read/write operations on such data SHOULD provided that will be able to ensure the following:
be controlled in order to protect its confidentiality. For example,
most carriers do not want a router's configuration and data flow
statistics known by hackers or their competitors. While carriers may
share peering information, most carriers do not share configuration
and traffic statistics. To achieve this, access control to sensitive
data needs to be provided, and the confidentiality protection on such
data during transportation needs to be enforced.
3.4. Data Integrity Requirements 1) the data being protected is not modified without detection
during its transportation,
SEC-REQ-13: An integrity protection mechanism for I2RS MUST be 2) the data is actually from where it is expected to come from,
provided that will be able to ensure the following: and
1) the data being protected is not modified without detection 3) the data is not repeated from some earlier interaction the
during its transportation, higher layer protocol (best effort).
2) the data is actually from where it is expected to come from, The I2RS higher-layer protocol operating over a secure transport
and provides this integrity. The I2RS higher-layer protocol operating
over an insecure transport SHOULD provide some way for the client
receiving non-confidential read-scoped or event-scoped data over
the insecure connection to detect when the data integrity is
questionable; and in the event of a questionable data integrity
the I2RS client should disconnect the insecure transport
connection.
3) the data is not repeated from some earlier interaction of the SEC-REQ-18: The I2RS higher-layer protocol MUST provide a
protocol. (That is, when both confidentiality and integrity of mechanism for message traceability (requirements in [RFC7922])
data is properly protected, it is possible to ensure that that supports the tracking higher-layer functions run across
encrypted data is not modified or replayed without detection.) secure connection or a non-secure transport.
SEC-REQ-14: The I2RS client to I2RS agent transport protocol MUST Explanation:
protect against replay attack.
Requirements SEC-REQ-13 and SEC-REQ-14 are requirements for the Most carriers do not want a router's configuration and data flow
secure channel which must be supported as the default by every I2RS statistics known by hackers or their competitors. While carriers may
Agent, and by every I2RS client communicating over a secure share peering information, most carriers do not share configuration
transport. In order to provide some traceability or notification for and traffic statistics. To achieve this, the I2RS higher-layer
the non-secure protocol, SEC-REQ-15 suggests traceability and protocol (e.g NETCONF) needs to have access control (NACM [RFC6536])
notification are important to include for any non-secure protocol. to sensitive data needs to be provided, and the confidentiality
protection on such data during transportation needs to be enforced.
SEC-REQ-15: The I2RS protocol MUST provide a mechanism for message Integrity of data is important even if the I2RS protocol is sending
traceability and notification requirements requirements found in non-confidential data over an insecure connection. The ability to
[RFC7922] and [RFC7923] that can be supported in communication trace I2RS protocol messages that enact I2RS transactions provides a
channel that is non-secure to trace or notify about potential minimal aid to helping operators check how messages enact
security issues. transactions on a secure or insecure transport.
3.5. Role-Based Data Model Security 4.6. Role-Based Data Model Security
The I2RS Architecture [RFC7921] defines a role or security role as The I2RS Architecture [RFC7921] defines a role or security role as
specifying read, write, or notification access by a I2RS client to specifying read, write, or notification access by a I2RS client to
data within an agent's data model. data within an agent's data model.
SEC-REQ-16: The rules around what role is permitted to access and SEC-REQ-19: The rules around what I2RS security role is permitted
manipulate what information plus a secure transport (which protects to access and manipulate what information over a secure transport
the data in transit) SHOULD ensure that data of any level of (which protects the data in transit) SHOULD ensure that data of
sensitivity is reasonably protected from being observed by those any level of sensitivity is reasonably protected from being
without permission to view it, so that privacy requirements are met. observed by those without permission to view it, so that privacy
requirements are met.
SEC-REQ-17: Role security MUST work when multiple transport SEC-REQ-20: Role security MUST work when multiple transport
connections are being used between the I2RS client and I2RS agent as connections are being used between the I2RS client and I2RS agent
the I2RS architecture [RFC7921] states. These transport message as the I2RS architecture [RFC7921] describes.
streams may start/stop without affecting the existence of the client/
agent data exchange. TCP supports a single stream of data. SCTP
[RFC4960] provides security for multiple streams plus end-to-end
transport of data.
SEC-REQ-18: I2RS clients MAY be used by multiple applications to Sec-REQ-21: If an I2RS agents or an I2RS client is tightly
configure routing via I2RS agents, receive status reports, turn on correlated with a person, then the I2RS protocol and data models
the I2RS audit stream, or turn on I2RS traceability. Application SHOULD provide additional security that protects the person's
software using I2RS client functions may host multiple secure privacy.
identities, but each connection will use only one identifier with one
priority. Therefore, the security of each I2RS Client to I2RS Agent Explanation:
connection is unique.
I2RS higher-layer uses management protocol E.g. NETCONF, RESTCONF)
to pass messages in order to enact I2RS transactions. Role Security
must secure data (sensitivity and normal data) in a router even when
it is operating over multiple connections at the same time. NETCONF
can run over TLS (over TCP or SCTP) or SSH. RESTCONF runs over HTTP
over a secure transport (TLS). SCTP [RFC4960] provides security for
multiple streams plus end-to-end transport of data. Some I2RS
functions may wish to operate over DTLS which runs over UDP
([RFC6347]), DDCP ([RFC6238]), and SCTP ([RFC5764]).
Please note the security of the application to I2RS client connection Please note the security of the application to I2RS client connection
is outside of the I2RS protocol or I2RS interface. is outside of the I2RS protocol or I2RS interface.
Sec-REQ-19: If an I2RS agents or an I2RS client is tightly correlated One example of I2RS privacy concerns related to a person is if I2RS
with a person, then the I2RS protocol and data models SHOULD provide agent is running on someone's phone to control tethering, and the
additional security that protects the person's privacy. An example I2RS client might be the client tracking such tethering. This
of an I2RS agent correlated with a person is a I2RS agent running on protection of the privacy of the person involves the I2RS client and
someone's phone to control tethering, and an example of a I2RS client the I2RS agent communication anonymizing the any data related to the
might be the client tracking such tethering. This protection MAY person's identity or locatino.
require a variety of forms including: "operator-applied knobs", roles
that restrict personal access, data-models with specific "privacy
roles", and access filters.
3.6. Security of the environment A variety of forms of managemen may set policy on roles: "operator-
applied knobs", roles that restrict personal access, data-models with
specific "privacy roles", and access filters.
4.7. Security of the environment
The security for the implementation of a protocol also considers the The security for the implementation of a protocol also considers the
protocol environment. The environmental security requirements are protocol environment. The environmental security requirements are
found in: [I-D.ietf-i2rs-security-environment-reqs]. found in: [I-D.ietf-i2rs-security-environment-reqs].
4. Acknowledgement 5. Security Considerations
This is a document about security requirements for the I2RS protocol
and data modules. Security considerations for the I2RS protocol
include both the protocol and the security environment.
6. IANA Considerations
This draft is requirements, and does not request anything of IANA.
7. Acknowledgement
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric
Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia
Atlas, and Jeff Haas for their contributions to the I2RS security Atlas, and Jeff Haas for their contributions to the I2RS security
requirements discussion and this document. The authors would like to requirements discussion and this document. The authors would like to
thank Bob Moskowitz for his review of the requirements. thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Alvaro
Retana, Ben Campbell, and Alissa Cooper for their review of these
5. IANA Considerations requirements.
This draft includes no request to IANA.
6. Security Considerations
This is a document about security requirements for the I2RS protocol 8. References
and data modules. The whole document is security considerations.
7. References 8.1. Normative References
7.1. Normative References [I-D.ietf-i2rs-security-environment-reqs]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security-
environment-reqs-01 (work in progress), April 2016.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <http://www.rfc-editor.org/info/rfc4107>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Statement for the Interface to the Routing System", Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
RFC 7920, DOI 10.17487/RFC7920, June 2016, 2014, <http://www.rfc-editor.org/info/rfc7258>.
<http://www.rfc-editor.org/info/rfc7920>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016, System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<http://www.rfc-editor.org/info/rfc7921>. <http://www.rfc-editor.org/info/rfc7921>.
7.2. Informative References [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", RFC 7922, DOI 10.17487/RFC7922, June
2016, <http://www.rfc-editor.org/info/rfc7922>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements
for Subscription to YANG Datastores", RFC 7923,
DOI 10.17487/RFC7923, June 2016,
<http://www.rfc-editor.org/info/rfc7923>.
8.2. Informative References
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-15 (work in Requirements", draft-ietf-i2rs-ephemeral-state-16 (work in
progress), July 2016. progress), August 2016.
[I-D.ietf-i2rs-security-environment-reqs] [I-D.ietf-netconf-restconf]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Security Requirements", draft-ietf-i2rs-security- Protocol", draft-ietf-netconf-restconf-16 (work in
environment-reqs-01 (work in progress), April 2016. progress), August 2016.
[I-D.ietf-taps-transports]
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services
provided by IETF transport protocols and congestion
control mechanisms", draft-ietf-taps-transports-11 (work
in progress), July 2016.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[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,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
the Routing System (I2RS) Traceability: Framework and (TLS) Protocol Version 1.2", RFC 5246,
Information Model", RFC 7922, DOI 10.17487/RFC7922, June DOI 10.17487/RFC5246, August 2008,
2016, <http://www.rfc-editor.org/info/rfc7922>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
for Subscription to YANG Datastores", RFC 7923, Security (DTLS) Extension to Establish Keys for the Secure
DOI 10.17487/RFC7923, June 2016, Real-time Transport Protocol (SRTP)", RFC 5764,
<http://www.rfc-editor.org/info/rfc7923>. DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
Time-Based One-Time Password Algorithm", RFC 6238,
DOI 10.17487/RFC6238, May 2011,
<http://www.rfc-editor.org/info/rfc6238>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
[RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
Statement for the Interface to the Routing System",
RFC 7920, DOI 10.17487/RFC7920, June 2016,
<http://www.rfc-editor.org/info/rfc7920>.
Authors' Addresses Authors' Addresses
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Email: shares@ndzh.com Email: shares@ndzh.com
 End of changes. 88 change blocks. 
269 lines changed or deleted 684 lines changed or added

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