draft-ietf-tsvwg-transport-encrypt-00.txt   draft-ietf-tsvwg-transport-encrypt-01.txt 
TSVWG G. Fairhurst TSVWG G. Fairhurst
Internet-Draft University of Aberdeen Internet-Draft University of Aberdeen
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: March 31, 2019 University of Glasgow Expires: April 25, 2019 University of Glasgow
September 27, 2018 October 22, 2018
The Impact of Transport Header Confidentiality on Network Operation and The Impact of Transport Header Confidentiality on Network Operation and
Evolution of the Internet Evolution of the Internet
draft-ietf-tsvwg-transport-encrypt-00 draft-ietf-tsvwg-transport-encrypt-01
Abstract Abstract
This document describes implications of applying end-to-end This document describes implications of applying end-to-end
encryption at the transport layer. It identifies in-network uses of encryption at the transport layer. It identifies in-network uses of
transport layer header information. It then reviews the implications transport layer header information. It then reviews the implications
of developing end-to-end transport protocols that use authentication of developing end-to-end transport protocols that use authentication
to protect the integrity of transport information or encryption to to protect the integrity of transport information or encryption to
provide confidentiality of the transport protocol header and expected provide confidentiality of the transport protocol header and expected
implications of transport protocol design and network operation. implications of transport protocol design and network operation.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3 2. Context and Rationale . . . . . . . . . . . . . . . . . . . . 3
3. Current uses of Transport Headers within the Network . . . . 9 3. Current uses of Transport Headers within the Network . . . . 9
3.1. Observing Transport Information in the Network . . . . . 9 3.1. Observing Transport Information in the Network . . . . . 9
3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15 3.2. Transport Measurement . . . . . . . . . . . . . . . . . . 15
3.3. Use for Network Diagnostics and Troubleshooting . . . . . 18 3.3. Use for Network Diagnostics and Troubleshooting . . . . . 18
3.4. Observing Headers to Implement Network Policy . . . . . . 19 3.4. Observing Headers to Implement Network Policy . . . . . . 19
4. Encryption and Authentication of Transport Headers . . . . . 19 4. Encryption and Authentication of Transport Headers . . . . . 19
4.1. Authenticating the Transport Protocol Header . . . . . . 21
4.2. Encrypting the Transport Payload . . . . . . . . . . . . 22
4.3. Encrypting the Transport Header . . . . . . . . . . . . . 22
4.4. Authenticating Transport Information and Selectively
Encrypting the Transport Header . . . . . . . . . . . . . 22
4.5. Optional Encryption of Header Information . . . . . . . . 23
5. Addition of Transport Information to Network-Layer Protocol 5. Addition of Transport Information to Network-Layer Protocol
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Implications of Protecting the Transport Headers . . . . . . 24 6. Implications of Protecting the Transport Headers . . . . . . 24
6.1. Independent Measurement . . . . . . . . . . . . . . . . . 24 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 24
6.2. Characterising "Unknown" Network Traffic . . . . . . . . 25 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 25
6.3. Accountability and Internet Transport Protocols . . . . . 25 6.3. Accountability and Internet Transport Protocols . . . . . 25
6.4. Impact on Research, Development and Deployment . . . . . 26 6.4. Impact on Research, Development and Deployment . . . . . 26
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. Informative References . . . . . . . . . . . . . . . . . . . 31 11. Informative References . . . . . . . . . . . . . . . . . . . 31
Appendix A. Revision information . . . . . . . . . . . . . . . . 37 Appendix A. Revision information . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
This document describes implications of applying end-to-end We are seeing increased interest in, and deployment of, new protocols
that employ end-to-end encryption at the transport layer, including
the transport layer headers. An example of such a transport is the
QUIC transport protocol [I-D.ietf-quic-transport], currently being
standardised in the IETF. Encryption of transport layer headers and
payload data has many benefits in terms of protecting user privacy.
These benefits have been widely discussed, and we strongly support
them. There are also, however, some costs, in that the wide use of
transport encryption requires changes to network operations, and
complicates network measurement for research, operational, and
standardisation purposes.
This document discusses some consequences of applying end-to-end
encryption at the transport layer. It reviews the implications of encryption at the transport layer. It reviews the implications of
developing end-to-end transport protocols that use encryption to developing end-to-end transport protocols that use encryption to
provide confidentiality of the transport protocol header and expected provide confidentiality of the transport protocol header, and
implications of transport protocol design and network operation. It consider the effect of such changes on transport protocol design and
also considers anticipated implications on transport and application network operation. It also considers anticipated implications on
evolution. transport and application evolution.
2. Context and Rationale 2. Context and Rationale
The transport layer provides end-to-end interactions between The transport layer provides end-to-end interactions between
endpoints (processes) using an Internet path. Transport protocols endpoints (processes) using an Internet path. Transport protocols
layer directly over the network-layer service and are sent in the layer directly over the network-layer service and are sent in the
payload of network-layer packets. They support end-to-end payload of network-layer packets. They support end-to-end
communication between applications, supported by higher-layer communication between applications, supported by higher-layer
protocols, running on the end systems (or transport endpoints). This protocols, running on the end systems (or transport endpoints). This
simple architectural view hides one of the core functions of the simple architectural view hides one of the core functions of the
skipping to change at page 3, line 44 skipping to change at page 3, line 50
There are many motivations for deploying encrypted transports There are many motivations for deploying encrypted transports
[RFC7624] (i.e., transport protocols that use encryption to provide [RFC7624] (i.e., transport protocols that use encryption to provide
confidentiality of some or all of the transport-layer header confidentiality of some or all of the transport-layer header
information), and encryption of transport payloads (i.e. information), and encryption of transport payloads (i.e.
confidentiality of the payload data). The increasing public concerns confidentiality of the payload data). The increasing public concerns
about the interference with Internet traffic have led to a rapidly about the interference with Internet traffic have led to a rapidly
expanding deployment of encryption to protect end-user privacy, in expanding deployment of encryption to protect end-user privacy, in
protocols like QUIC [I-D.ietf-quic-transport], but also expected to protocols like QUIC [I-D.ietf-quic-transport], but also expected to
form a basis of future protocol designs. form a basis of future protocol designs.
Some network operators and access providers, have come to rely on the Some network operators and access providers have come to rely on the
in-network measurement of transport properties and the functionality in-network measurement of transport properties and the functionality
provided by middleboxes to both support network operations and provided by middleboxes to both support network operations and
enhance performance. There can therefore be implications when enhance performance. There can therefore be implications when
working with encrypted transport protocols that hide transport header working with encrypted transport protocols that hide transport header
information from the network. These present architectural challenges information from the network. These present architectural challenges
and considerations in the way transport protocols are designed, and and considerations in the way transport protocols are designed, and
ability to characterise and compare different transport solutions ability to characterise and compare different transport solutions
[Measure]. Implementations of network devices are encouraged to
[Measure], Section 3.2. Implementations of network devices are avoid side-effects when protocols are updated. Introducing
encouraged to avoid side-effects when protocols are updated. cryptographic integrity checks to header fields can also prevent
Introducing cryptographic integrity checks to header fields can also undetected manipulation of the field by network devices, or
prevent undetected manipulation of the field by network devices, or
undetected addition of information to a packet. However, this does undetected addition of information to a packet. However, this does
not prevent inspection of the information by a device on path, and it not prevent inspection of the information by a device on path, and it
is possible that such devices could develop mechanisms that rely on is possible that such devices could develop mechanisms that rely on
the presence of such a field, or a known value in the field. the presence of such a field, or a known value in the field.
Reliance on the presence and semantics of specific header information Reliance on the presence and semantics of specific header information
leads to ossification: An endpoint could be required to supply a leads to ossification. An endpoint could be required to supply a
specific header to receive the network service that it desires. In specific header to receive the network service that it desires. In
some cases, this could be benign or advantageous to the protocol some cases, this could be benign or advantageous to the protocol
(e.g., recognising the start of a connection, or explicitly exposing (e.g., recognising the start of a connection, or explicitly exposing
protocol information can be expected to provide more consistent protocol information can be expected to provide more consistent
decisions by on-path devices than the use of diverse methods to infer decisions by on-path devices than the use of diverse methods to infer
semantics from other flow properties). In some cases, this is not semantics from other flow properties); in other cases this is not
beneficial (e.g., a mechanism implemented in a network device, such beneficial (e.g., a mechanism implemented in a network device, such
as a firewall, that required a header field to have only a specific as a firewall, that required a header field to have only a specific
known set of values could prevent the device from forwarding packets known set of values could prevent the device from forwarding packets
using a different version of a protocol that introduces a new feature using a different version of a protocol that introduces a new feature
that changes the value present in this field, preventing evolution of that changes the value present in this field, preventing evolution of
the protocol). the protocol).
Examples of the impact of ossification on transport protocol design Examples of the impact of ossification on transport protocol design
and ease of deployment can be seen in the case of Multipath TCP and ease of deployment can be seen in the case of Multipath TCP
(MPTCP) and the TCP Fast Open option. The design of MPTCP had to be (MPTCP) and the TCP Fast Open option. The design of MPTCP had to be
skipping to change at page 5, line 4 skipping to change at page 5, line 9
examples have included middleboxes that rewrite TCP sequence and examples have included middleboxes that rewrite TCP sequence and
acknowledgement numbers but are unaware of the (newer) SACK option acknowledgement numbers but are unaware of the (newer) SACK option
and don't correctly rewrite selective acknowledgements to match the and don't correctly rewrite selective acknowledgements to match the
changes made to the fixed TCP header; or devices that inspect, and changes made to the fixed TCP header; or devices that inspect, and
change, TCP MSS options that can interfere with path MTU discovery. change, TCP MSS options that can interfere with path MTU discovery.
A protocol design that uses header encryption can provide A protocol design that uses header encryption can provide
confidentiality of some or all of the protocol header information. confidentiality of some or all of the protocol header information.
This prevents an on-path device from knowledge of the header field. This prevents an on-path device from knowledge of the header field.
It therefore prevents mechanisms being built that directly rely on It therefore prevents mechanisms being built that directly rely on
the information or seeks to imply semantics of an exposed header the information or seek to imply semantics of an exposed header
field. Using encryption to provide confidentiality of the transport field. Using encryption to provide confidentiality of the transport
layer brings some well-known privacy and security benefits and can layer brings some well-known privacy and security benefits and can
therefore help reduce ossification of the transport layer. In therefore help reduce ossification of the transport layer. In
particular, it is important that protocols either do not expose particular, it is important that protocols either do not expose
information where the usage may change in future protocols, or that information where the usage may change in future protocols, or that
methods that utilise the information are robust to potential changes methods that utilise the information are robust to potential changes
as protocols evolve over time. To avoid unwanted inspection, a as protocols evolve over time. To avoid unwanted inspection, a
protocol could also intentionally vary the format and value of header protocol could also intentionally vary the format and value of header
fields (sometimes known as Greasing [I-D.thomson-quic-grease]). fields (sometimes known as Greasing [I-D.thomson-quic-grease]).
However, while encryption hides the protocol header information, it However, while encryption hides the protocol header information, it
skipping to change at page 5, line 47 skipping to change at page 5, line 52
The data can also inform Internet engineering research, and help The data can also inform Internet engineering research, and help
in the development of new protocols, methodologies, and in the development of new protocols, methodologies, and
procedures. Concealing the transport protocol header information procedures. Concealing the transport protocol header information
makes the stream performance unavailable to passive observers makes the stream performance unavailable to passive observers
along the path, and likely leads to the development of alternative along the path, and likely leads to the development of alternative
methods to collect or infer that data. methods to collect or infer that data.
Providing confidentiality of the transport payload, but leaving Providing confidentiality of the transport payload, but leaving
some, or all, of the transport headers unencrypted, possibly with some, or all, of the transport headers unencrypted, possibly with
authentication, can provide the majority of the privacy and authentication, can provide the majority of the privacy and
security benefits while allowing some measurement. security benefits while supporting operations and research.
Protection from Denial of Service: Observable transport headers Protection from Denial of Service: Observable transport headers
currently provide useful input to classify traffic and detect currently provide useful input to classify traffic and detect
anomalous events (e.g., changes in application behaviour, anomalous events (e.g., changes in application behaviour,
distributed denial of service attacks). To be effective, this distributed denial of service attacks). To be effective, this
protection needs to be able to uniquely disambiguate unwanted protection needs to be able to uniquely disambiguate unwanted
traffic. An inability to separate this traffic using packet traffic. An inability to separate this traffic using packet
header information may result in less-efficient identification of header information may result in less-efficient identification of
unwanted traffic or development of different methods (e.g. rate- unwanted traffic or development of different methods (e.g. rate-
limiting of uncharacterised traffic). limiting of uncharacterised traffic).
skipping to change at page 9, line 37 skipping to change at page 9, line 39
concerning IP address sharing are described in [RFC6269]. concerning IP address sharing are described in [RFC6269].
3.1. Observing Transport Information in the Network 3.1. Observing Transport Information in the Network
If in-network observation of transport protocol headers is needed, If in-network observation of transport protocol headers is needed,
this requires knowledge of the format of the transport header: this requires knowledge of the format of the transport header:
o Flows need to be identified at the level required to perform the o Flows need to be identified at the level required to perform the
observation; observation;
o The protocol and version of the header need to be visible. As o The protocol and version of the header need to be visible, e.g.,
by defining the wire image [I-D.trammell-wire-image]. As
protocols evolve over time and there may be a need to introduce protocols evolve over time and there may be a need to introduce
new transport headers. This may require interpretation of new transport headers. This could require interpretation of
protocol version information or connection setup information; protocol version information or connection setup information;
o The location and syntax of any observed transport headers needs to o The location and syntax of any observed transport headers needs to
be known. IETF transport protocols can specify this information. be known. IETF transport protocols can specify this information.
The following subsections describe various ways that observable The following subsections describe various ways that observable
transport information has been utilised. transport information has been utilised.
3.1.1. Flow Identification 3.1.1. Flow Identification
skipping to change at page 11, line 38 skipping to change at page 11, line 38
important to understand the pattern of loss, than the loss rate, important to understand the pattern of loss, than the loss rate,
because losses can often occur as bursts, rather than randomly- because losses can often occur as bursts, rather than randomly-
timed events. timed events.
Throughput and Goodput: The throughput achieved by a flow can be Throughput and Goodput: The throughput achieved by a flow can be
determined even when a flow is encrypted, providing the individual determined even when a flow is encrypted, providing the individual
flow can be identified. Goodput [RFC7928] is a measure of useful flow can be identified. Goodput [RFC7928] is a measure of useful
data exchanged (the ratio of useful/total volume of traffic sent data exchanged (the ratio of useful/total volume of traffic sent
by a flow). This requires ability to differentiate loss and by a flow). This requires ability to differentiate loss and
retransmission of packets (e.g., by observing packet sequence retransmission of packets (e.g., by observing packet sequence
numbers in the TCP or the Real Time Protocol, RTP, headers numbers in the TCP or the Real-time Transport Protocol, RTP,
[RFC3550]). headers [RFC3550]).
Latency: Latency is a key performance metric that impacts Latency: Latency is a key performance metric that impacts
application response time and user-perceived response time. It application response time and user-perceived response time. It
often indirectly impacts throughput and flow completion time. often indirectly impacts throughput and flow completion time.
Latency determines the reaction time of the transport protocol Latency determines the reaction time of the transport protocol
itself, impacting flow setup, congestion control, loss recovery, itself, impacting flow setup, congestion control, loss recovery,
and other transport mechanisms. The observed latency can have and other transport mechanisms. The observed latency can have
many components [Latency]. Of these, unnecessary/unwanted queuing many components [Latency]. Of these, unnecessary/unwanted queuing
in network buffers has often been observed as a significant in network buffers has often been observed as a significant
factor. Once the cause of unwanted latency has been identified, factor. Once the cause of unwanted latency has been identified,
skipping to change at page 15, line 41 skipping to change at page 15, line 41
the packet header information of (randomly) selected packets. The the packet header information of (randomly) selected packets. The
utility of these measurements depends on the type of bearer and utility of these measurements depends on the type of bearer and
number of mechanisms used by network devices. Simple routers are number of mechanisms used by network devices. Simple routers are
relatively easy to manage, a device with more complexity demands relatively easy to manage, a device with more complexity demands
understanding of the choice of many system parameters. This level of understanding of the choice of many system parameters. This level of
complexity exists when several network methods are combined. complexity exists when several network methods are combined.
This section discusses topics concerning observation of transport This section discusses topics concerning observation of transport
flows, with a focus on transport measurement. flows, with a focus on transport measurement.
3.2.1. Point of Measurement 3.2.1. Point of Observation
Often measurements can only be understood in the context of the other On-path measurements are particularly useful for locating the source
flows that share a bottleneck. A simple example is monitoring of of problems or to assess the performance of a network segment or a
AQM. For example, FQ-CODEL [RFC8290], combines sub queues particular device configuration. Often issues can only be understood
(statistically assigned per flow), management of the queue length in the context of the other flows that share a particular path,
(CODEL), flow-scheduling, and a starvation prevention mechanism. common network device, interface port, etc. A simple example is
Usually such algorithms are designed to be self-tuning, but current monitoring of a network device that uses a scheduler or active queue
methods typically employ heuristics that can result in more loss management technique [RFC7567], where it may be desirable to
under certain path conditions (e.g., large RTT, effects of multiple understand whether algorithms are correctly controlling latency, or
bottlenecks [RFC7567]). overload protection. This understanding implies knowledge of how
traffic is assigned to any sub-queues used for flow scheduling, but
can also require information about how the traffic dynamics impact
active queue management, starvation prevention mechanisms and
circuit-breakers.
In-network measurements can distinguish between upstream and Sometimes multiple on-path observation points are needed. By
downstream metrics with respect to a measurement point. These are correlating observations of headers at multiple points along the path
particularly useful for locating the source of problems or to assess (e.g., at the ingress and egress of a network segment), an observer
the performance of a network segment or a particular device can determine the contribution of a portion of the path to an
configuration. By correlating observations of headers at multiple observed metric (to locate a source of delay, jitter, loss,
points along the path (e.g., at the ingress and egress of a network reordering, congestion marking, etc.).
segment), an observer can determine the contribution of a portion of
the path to an observed metric (to locate a source of delay, jitter,
loss, reordering, congestion marking, etc.).
3.2.2. Use by Operators to Plan and Provision Networks 3.2.2. Use by Operators to Plan and Provision Networks
Traffic measurements (e.g., traffic volume, loss, latency) is used by Traffic measurements (e.g., traffic volume, loss, latency) is used by
operators to help plan deployment of new equipment and configurations operators to help plan deployment of new equipment and configurations
in their networks. Data is also important to equipment vendors who in their networks. Data is also important to equipment vendors who
need to understand traffic trends and patterns of usage as inputs to need to understand traffic trends and patterns of usage as inputs to
decisions about planning products and provisioning for new decisions about planning products and provisioning for new
deployments. This measurement information can also be correlated deployments. This measurement information can also be correlated
with billing information when this is also collected by an operator. with billing information when this is also collected by an operator.
skipping to change at page 16, line 43 skipping to change at page 16, line 43
3.2.3. Service Performance Measurement 3.2.3. Service Performance Measurement
Traffic measurements (e.g., traffic volume, loss, latency) can be Traffic measurements (e.g., traffic volume, loss, latency) can be
used by various actors to help analyse the performance offered to the used by various actors to help analyse the performance offered to the
users of a network segment, and inform operational practice. users of a network segment, and inform operational practice.
While active measurements may be used in-network, passive While active measurements may be used in-network, passive
measurements can have advantages in terms of eliminating unproductive measurements can have advantages in terms of eliminating unproductive
test traffic, reducing the influence of test traffic on the overall test traffic, reducing the influence of test traffic on the overall
traffic mix, and the ability to choose the point of measurement traffic mix, and the ability to choose the point of observation
Section 3.2.1. However, passive measurements may rely on observing Section 3.2.1. However, passive measurements may rely on observing
transport headers. transport headers.
3.2.4. Measuring Transport to Support Network Operations 3.2.4. Measuring Transport to Support Network Operations
Information provided by tools observing transport headers can help Information provided by tools observing transport headers can help
determine whether mechanisms are needed in the network to prevent determine whether mechanisms are needed in the network to prevent
flows from acquiring excessive network capacity. Operators can flows from acquiring excessive network capacity. Operators can
implement operational practices to manage traffic flows (e.g., to implement operational practices to manage traffic flows (e.g., to
prevent flows from acquiring excessive network capacity under severe prevent flows from acquiring excessive network capacity under severe
congestion) by deploying rate-limiters, traffic shaping or network congestion) by deploying rate-limiters, traffic shaping or network
transport circuit breakers [RFC8084]. transport circuit breakers [RFC8084].
Congestion Control Compliance of Traffic: Congestion control is a Congestion Control Compliance of Traffic: Congestion control is a
key transport function [RFC2914]. Many network operators key transport function [RFC2914]. Many network operators
implicitly accept that TCP traffic to comply with a behaviour that implicitly accept that TCP traffic complies with a behaviour that
is acceptable for use in the shared Internet. TCP algorithms have is acceptable for use in the shared Internet. TCP algorithms have
been continuously improved over decades, and they have reached a been continuously improved over decades, and they have reached a
level of efficiency and correctness that custom application-layer level of efficiency and correctness that custom application-layer
mechanisms will struggle to easily duplicate [RFC8085]. mechanisms will struggle to easily duplicate [RFC8085].
A standards-compliant TCP stack provides congestion control may A standards-compliant TCP stack provides congestion control may
therefore be judged safe for use across the Internet. therefore be judged safe for use across the Internet.
Applications developed on top of well-designed transports can be Applications developed on top of well-designed transports can be
expected to appropriately control their network usage, reacting expected to appropriately control their network usage, reacting
when the network experiences congestion, by back-off and reduce when the network experiences congestion, by back-off and reduce
skipping to change at page 18, line 29 skipping to change at page 18, line 29
performance, capacity planning, management of security threats performance, capacity planning, management of security threats
(including denial of service), and responding to user performance (including denial of service), and responding to user performance
questions. Sections 3.1.2 and 5 of [RFC8404] provide further questions. Sections 3.1.2 and 5 of [RFC8404] provide further
examples. These tasks seldom involve the need to determine the examples. These tasks seldom involve the need to determine the
contents of the transport payload, or other application details. contents of the transport payload, or other application details.
A network operator supporting traffic that uses transport header A network operator supporting traffic that uses transport header
encryption can see only encrypted transport headers. This prevents encryption can see only encrypted transport headers. This prevents
deployment of performance measurement tools that rely on transport deployment of performance measurement tools that rely on transport
protocol information. Choosing to encrypt all the information protocol information. Choosing to encrypt all the information
reduces the operator's ability to observe transport performance, and reduces the ability of an operator to observe transport performance,
may limit the ability of network operators to trace problems, make and may limit the ability of network operators to trace problems,
appropriate QoS decisions, or response to other queries about the make appropriate QoS decisions, or response to other queries about
network service. For some this will be blessing, for others it may the network service. For some this will be blessing, for others it
be a curse. For example, operational performance data about may be a curse. For example, operational performance data about
encrypted flows needs to be determined by traffic pattern analysis, encrypted flows needs to be determined by traffic pattern analysis,
rather than relying on traditional tools. This can impact the rather than relying on traditional tools. This can impact the
ability of the operator to respond to faults, it could require ability of the operator to respond to faults, it could require
reliance on endpoint diagnostic tools or user involvement in reliance on endpoint diagnostic tools or user involvement in
diagnosing and troubleshooting unusual use cases or non-trivial diagnosing and troubleshooting unusual use cases or non-trivial
problems. A key need here is for tools to provide useful information problems. A key need here is for tools to provide useful information
during network anomalies (e.g., significant reordering, high or during network anomalies (e.g., significant reordering, high or
intermittent loss). Although many network operators utilise intermittent loss). Although many network operators utilise
transport information as a part of their operational practice, the transport information as a part of their operational practice, the
network will not break because transport headers are encrypted, and network will not break because transport headers are encrypted, and
skipping to change at page 20, line 8 skipping to change at page 20, line 8
4. Encryption and Authentication of Transport Headers 4. Encryption and Authentication of Transport Headers
End-to-end encryption can be applied at various protocol layers. It End-to-end encryption can be applied at various protocol layers. It
can be applied above the transport to encrypt the transport payload. can be applied above the transport to encrypt the transport payload.
Encryption methods can hide information from an eavesdropper in the Encryption methods can hide information from an eavesdropper in the
network. Encryption can also help protect the privacy of a user, by network. Encryption can also help protect the privacy of a user, by
hiding data relating to user/device identity or location. Neither an hiding data relating to user/device identity or location. Neither an
integrity check nor encryption methods prevent traffic analysis, and integrity check nor encryption methods prevent traffic analysis, and
usage needs to reflect that profiling of users, identification of usage needs to reflect that profiling of users, identification of
location and fingerprinting of behaviour can take place even on location and fingerprinting of behaviour can take place even on
encrypted traffic flows. encrypted traffic flows. Any header information that has a clear
definition in the protocol's message format(s), or is implied by that
definition, and is not cryptographically confidentiality-protected
can be unambiguously interpreted by on-path observers
[I-D.trammell-wire-image].
There are several motivations: There are several motivations:
o One motive to use encryption is a response to perceptions that the o One motive to use encryption is a response to perceptions that the
network has become ossified by over-reliance on middleboxes that network has become ossified by over-reliance on middleboxes that
prevent new protocols and mechanisms from being deployed. This prevent new protocols and mechanisms from being deployed. This
has lead to a perception that there is too much "manipulation" of has lead to a perception that there is too much "manipulation" of
protocol headers within the network, and that designing to deploy protocol headers within the network, and that designing to deploy
in such networks is preventing transport evolution. In the light in such networks is preventing transport evolution. In the light
of this, a method that authenticates transport headers may help of this, a method that authenticates transport headers may help
skipping to change at page 21, line 27 skipping to change at page 21, line 30
understand the dynamics of protocols and traffic patterns. understand the dynamics of protocols and traffic patterns.
Whatever the motives, a decision to use pervasive of transport header Whatever the motives, a decision to use pervasive of transport header
encryption will have implications on the way in which design and encryption will have implications on the way in which design and
evaluation is performed, and which can in turn impact the direction evaluation is performed, and which can in turn impact the direction
of evolution of the TCP/IP stack. While the IETF can specify of evolution of the TCP/IP stack. While the IETF can specify
protocols, the success in actual deployment is often determined by protocols, the success in actual deployment is often determined by
many factors [RFC5218] that are not always clear at the time when many factors [RFC5218] that are not always clear at the time when
protocols are being defined. protocols are being defined.
The next subsections briefly review some security design options for The following briefly reviews some security design options for
transport protocols. A Survey of Transport Security Protocols transport protocols. A Survey of Transport Security Protocols
[I-D.ietf-taps-transport-security] provides more details concerning [I-D.ietf-taps-transport-security] provides more details concerning
commonly used encryption methods at the transport layer. commonly used encryption methods at the transport layer.
4.1. Authenticating the Transport Protocol Header Authenticating the Transport Protocol Header: Transport layer header
information can be authenticated. An integrity check that
Transport layer header information can be authenticated. An protects the immutable transport header fields, but can still
integrity check that protects the immutable transport header fields, expose the transport protocol header information in the clear,
but can still expose the transport protocol header information in the allowing in-network devices to observes these fields. An
clear, allowing in-network devices to observes these fields. An integrity check can not prevent in-network modification, but can
integrity check can not prevent in-network modification, but can avoid a receiving accepting changes and avoid impact on the
avoid a receiving accepting changes and avoid impact on the transport transport protocol operation.
protocol operation.
An example transport authentication mechanism is TCP-Authentication
(TCP-AO) [RFC5925]. This TCP option authenticates the IP pseudo
header, TCP header, and TCP data. TCP-AO protects the transport
layer, preventing attacks from disabling the TCP connection itself
and provides replay protection. TCP-AO may interact with
middleboxes, depending on their behaviour [RFC3234].
The IPsec Authentication Header (AH) [RFC4302] was designed to work
at the network layer and authenticate the IP payload. This approach
authenticates all transport headers, and verifies their integrity at
the receiver, preventing in-network modification.
4.2. Encrypting the Transport Payload
The transport layer payload can be encrypted to protect the content
of transport segments. This leaves transport protocol header
information in the clear. The integrity of immutable transport
header fields could be protected by combining this with an integrity
check (Section 4.1).
Examples of encrypting the payload include Transport Layer Security An example transport authentication mechanism is TCP-
(TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS) over UDP Authentication (TCP-AO) [RFC5925]. This TCP option authenticates
[RFC6347] [RFC7525], and TCPcrypt [I-D.ietf-tcpinc-tcpcrypt], which the IP pseudo header, TCP header, and TCP data. TCP-AO protects
permits opportunistic encryption of the TCP transport payload. the transport layer, preventing attacks from disabling the TCP
connection itself and provides replay protection. TCP-AO may
interact with middleboxes, depending on their behaviour [RFC3234].
4.3. Encrypting the Transport Header The IPsec Authentication Header (AH) [RFC4302] was designed to
work at the network layer and authenticate the IP payload. This
approach authenticates all transport headers, and verifies their
integrity at the receiver, preventing in-network modification.
The network layer payload could be encrypted (including the entire Encrypting the Transport Payload: The transport layer payload can be
transport header and the payload). This method provides encrypted to protect the content of transport segments. This
confidentiality of the entire transport packet. It therefore does leaves transport protocol header information in the clear. The
not expose any transport information to devices in the network, which integrity of immutable transport header fields could be protected
also prevents modification along a network path. by combining this with an integrity check.
One example of encryption at the network layer is use of IPsec Examples of encrypting the payload include Transport Layer
Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. This Security (TLS) over TCP [RFC8446] [RFC7525], Datagram TLS (DTLS)
encrypts and authenticates all transport headers, preventing over UDP [RFC6347] [RFC7525], and TCPcrypt
visibility of the transport headers by in-network devices. Some [I-D.ietf-tcpinc-tcpcrypt], which permits opportunistic encryption
Virtual Private Network (VPN) methods also encrypt these headers. of the TCP transport payload.
4.4. Authenticating Transport Information and Selectively Encrypting Encrypting the Transport Headers and Payload: The network layer
the Transport Header payload could be encrypted (including the entire transport header
and the payload). This method provides confidentiality of the
entire transport packet. It therefore does not expose any
transport information to devices in the network, which also
prevents modification along a network path.
A transport protocol design can encrypt selected header fields, while One example of encryption at the network layer is use of IPsec
also choosing to authenticate fields in the transport header. This Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode.
allows specific transport header fields to be made observable by This encrypts and authenticates all transport headers, preventing
network devices. End-to end integrity checks can prevent an endpoint visibility of the transport headers by in-network devices. Some
from undetected modification of the immutable transport headers. Virtual Private Network (VPN) methods also encrypt these headers.
Mutable fields in the transport header provide opportunities for Selectively Encrypting Transport Headers and Payload: A transport
middleboxes to modify the transport behaviour (e.g., the extended protocol design can encrypt selected header fields, while also
headers described in [I-D.trammell-plus-abstract-mech]). This choosing to authenticate the entire transport header. This allows
considers only immutable fields in the transport headers, that is, specific transport header fields to be made observable by network
fields that may be authenticated End-to-End across a path. devices. End-to end integrity checks can prevent an endpoint from
undetected modification of the immutable transport headers.
An example of a method that encrypts some, but not all, transport Mutable fields in the transport header provide opportunities for
information is GRE-in-UDP [RFC8086] when used with GRE encryption. middleboxes to modify the transport behaviour (e.g., the extended
headers described in [I-D.trammell-plus-abstract-mech]). This
considers only immutable fields in the transport headers, that is,
fields that may be authenticated End-to-End across a path.
4.5. Optional Encryption of Header Information An example of a method that encrypts some, but not all, transport
information is GRE-in-UDP [RFC8086] when used with GRE encryption.
There are implications to the use of optional header encryption in Optional Encryption of Header Information: There are implications to
the design of a transport protocol, where support of optional the use of optional header encryption in the design of a transport
mechanisms can increase the complexity of the protocol and its protocol, where support of optional mechanisms can increase the
implementation and in the management decisions that are required to complexity of the protocol and its implementation and in the
use variable format fields. Instead, fields of a specific type ought management decisions that are required to use variable format
to always be sent with the same level of confidentiality or integrity fields. Instead, fields of a specific type ought to always be
protection. sent with the same level of confidentiality or integrity
protection.
5. Addition of Transport Information to Network-Layer Protocol Headers 5. Addition of Transport Information to Network-Layer Protocol Headers
Transport protocol information can be made visible in a network-layer Transport protocol information can be made visible in a network-layer
header. This has the advantage that this information can then be header. This has the advantage that this information can then be
observed by in-network devices. This has the advantage that a single observed by in-network devices. This has the advantage that a single
header can support all transport protocols, but there may also be header can support all transport protocols, but there may also be
less desirable implications of separating the operation of the less desirable implications of separating the operation of the
transport protocol from the measurement framework. transport protocol from the measurement framework.
skipping to change at page 27, line 38 skipping to change at page 27, line 38
have used UDP, and much of this traffic utilises RTP format headers have used UDP, and much of this traffic utilises RTP format headers
in the payload of the UDP datagram. Since these protocol headers in the payload of the UDP datagram. Since these protocol headers
have been fixed for decades, a range of tools and analysis methods have been fixed for decades, a range of tools and analysis methods
have became common and well-understood. Over this period, the have became common and well-understood. Over this period, the
transport protocol headers have mostly changed slowly, and so also transport protocol headers have mostly changed slowly, and so also
the need to develop tools track new versions of the protocol. the need to develop tools track new versions of the protocol.
Confidentiality and strong integrity checks have properties that are Confidentiality and strong integrity checks have properties that are
being incorporated into new protocols and which have important being incorporated into new protocols and which have important
benefits. The pace of development of transports using the WebRTC benefits. The pace of development of transports using the WebRTC
data channel and the rapid deployment of QUIC prototype transports data channel and the rapid deployment of QUIC transport protocol can
can both be attributed to using a combination of UDP transport and both be attributed to using the combination of UDP as a substrate
confidentiality of the UDP payload. while providing confidentiality and authentication of the
encapsulated transport headers and payload.
The traffic that can be observed by on-path network devices is a The traffic that can be observed by on-path network devices is a
function of transport protocol design/options, network use, function of transport protocol design/options, network use,
applications and user characteristics. In general, when only a small applications, and user characteristics. In general, when only a
proportion of the traffic has a specific (different) characteristic. small proportion of the traffic has a specific (different)
Such traffic seldom leads to an operational issue although the characteristic, such traffic seldom leads to operational concern,
ability to measure and monitor it is less. The desire to understand although the ability to measure and monitor it is less. The desire
the traffic and protocol interactions typically grows as the to understand the traffic and protocol interactions typically grows
proportion of traffic increases in volume. The challenges increase as the proportion of traffic increases in volume. The challenges
when multiple instances of an evolving protocol contribute to the increase when multiple instances of an evolving protocol contribute
traffic that share network capacity. to the traffic that share network capacity.
An increased pace of evolution therefore needs to be accompanied by An increased pace of evolution therefore needs to be accompanied by
methods that can be successfully deployed and used across operational methods that can be successfully deployed and used across operational
networks. This leads to a need for network operators (at various networks. This leads to a need for network operators (at various
level (ISPs, enterprises, firewall maintainer, etc) to identify level (ISPs, enterprises, firewall maintainer, etc) to identify
appropriate operational support functions and procedures. appropriate operational support functions and procedures.
Protocols that change their transport header format (wire format) or Protocols that change their transport header format (wire format) or
their behaviour (e.g., algorithms that are needed to classify and their behaviour (e.g., algorithms that are needed to classify and
characterise the protocol), will require new tooling needs to be characterise the protocol), will require new tooling to be developed
developed to catch-up with the changes. If the currently deployed to catch-up with the changes. If the currently deployed tools and
tools and methods are no longer relevant and performance may not be methods are no longer relevant then performance may not be correctly
correctly measured. This can increase the response-time after measured. This can increase the response-time after faults, and can
faults, and can impact the ability to manage the network resulting in impact the ability to manage the network resulting in traffic causing
traffic causing traffic to be treated inappropriately (e.g., rate traffic to be treated inappropriately (e.g., rate limiting because of
limiting because of being incorrectly classified/monitored). There being incorrectly classified/monitored). There are benefits in
are benefits in exposing consistent information to the network that exposing consistent information to the network that avoids traffic
avoids traffic being mis-classified and then receiving a default being mis-classified and then receiving a default treatment by the
treatment by the network. network.
As a part of its design a new protocol specification therefore needs As a part of its design a new protocol specification therefore needs
to weigh the benefits of ossifying common headers, versus the to weigh the benefits of ossifying common headers, versus the
potential demerits of exposing specific information that could be potential demerits of exposing specific information that could be
observed along the network path to provide tools to manage new observed along the network path, to provide tools to manage new
variants of protocols. Several scenarios to illustrate different variants of protocols. Several scenarios to illustrate different
ways this could evolve are provided below: ways this could evolve are provided below:
o One scenario is when transport protocols provide consistent o One scenario is when transport protocols provide consistent
information to the network by intentionally exposing a part of the information to the network by intentionally exposing a part of the
transport header. The design fixes the format of this information transport header. The design fixes the format of this information
between versions of the protocol. This ossification of the between versions of the protocol. This ossification of the
transport header allows an operator to establish tooling and transport header allows an operator to establish tooling and
procedures that enable it to provide consistent traffic management procedures that enable it to provide consistent traffic management
as the protocol evolves. In contrast to TCP (where all protocol as the protocol evolves. In contrast to TCP (where all protocol
skipping to change at page 29, line 4 skipping to change at page 29, line 4
information, rather than inferring information from other information, rather than inferring information from other
characteristics of the flow traffic). The exposed transport characteristics of the flow traffic). The exposed transport
information can be used by operators to provide troubleshooting, information can be used by operators to provide troubleshooting,
measurement and any necessary functions appropriate to the class measurement and any necessary functions appropriate to the class
of traffic (priority, retransmission, reordering, circuit of traffic (priority, retransmission, reordering, circuit
breakers, etc). breakers, etc).
o An alternative scenario adopts different design goals, with a o An alternative scenario adopts different design goals, with a
different outcome. A protocol that encrypts all header different outcome. A protocol that encrypts all header
information forces network operators to act independently from information forces network operators to act independently from
apps/transport developments to provide the transport information apps/transport developments to extract the information they need
they need. A range of approaches may proliferate, as in current to manage their network. A range of approaches may proliferate,
networks, operators can add a shim header to each packet as a flow as in current networks. Some operators can add a shim header to
as it crosses the network; other operators/managers could develop each packet as a flow as it crosses the network; other operators/
heuristics and pattern recognition to derive information that managers could develop heuristics and pattern recognition to
classifies flows and estimates quality metrics for the service derive information that classifies flows and estimates quality
being used; some could decide to rate-limit or block traffic until metrics for the service being used; some could decide to rate-
new tooling is in place. In many cases, the derived information limit or block traffic until new tooling is in place. In many
can be used by operators to provide necessary functions cases, the derived information can be used by operators to provide
appropriate to the class of traffic (priority, retransmission, necessary functions appropriate to the class of traffic (priority,
reordering, circuit breakers, etc). Troubleshooting, and retransmission, reordering, circuit breakers, etc).
measurement becomes more difficult, and more diverse. This could Troubleshooting, and measurement becomes more difficult, and more
require additional information beyond that visible in the packet diverse. This could require additional information beyond that
header and when this information is used to inform decisions by visible in the packet header and when this information is used to
on-path devices it can lead to dependency on other characteristics inform decisions by on-path devices it can lead to dependency on
of the flow. In some cases, operators might need access to keying other characteristics of the flow. In some cases, operators might
information to interpret encrypted data that they observe. Some need access to keying information to interpret encrypted data that
use cases could demand use of transports that do not use they observe. Some use cases could demand use of transports that
encryption. do not use encryption.
The outcome could have significant implications on the way the The outcome could have significant implications on the way the
Internet architecture develops. It exposes a risk that significant Internet architecture develops. It exposes a risk that significant
actors (e.g., developers and transport designers) achieve more actors (e.g., developers and transport designers) achieve more
control of the way in which the Internet architecture develops.In control of the way in which the Internet architecture develops.In
particular, there is a possibility that designs could evolve to particular, there is a possibility that designs could evolve to
significantly benefit of customers for a specific vendor, and that significantly benefit of customers for a specific vendor, and that
communities with very different network, applications or platforms communities with very different network, applications or platforms
could then suffer at the expense of benefits to their vendors own could then suffer at the expense of benefits to their vendors own
customer base. In such a scenario, there could be no incentive to customer base. In such a scenario, there could be no incentive to
skipping to change at page 30, line 26 skipping to change at page 30, line 26
It therefore prevents mechanisms being built that directly rely on It therefore prevents mechanisms being built that directly rely on
the information or seeks to imply semantics of an exposed header the information or seeks to imply semantics of an exposed header
field. Hiding headers can limit the ability to measure and field. Hiding headers can limit the ability to measure and
characterise traffic. characterise traffic.
Exposed transport headers are sometimes utilised as a part of the Exposed transport headers are sometimes utilised as a part of the
information to detect anomalies in network traffic. This can be used information to detect anomalies in network traffic. This can be used
as the first line of defence yo identify potential threats from DOS as the first line of defence yo identify potential threats from DOS
or malware and redirect suspect traffic to dedicated nodes or malware and redirect suspect traffic to dedicated nodes
responsible for DOS analysis, malware detection, or to perform packet responsible for DOS analysis, malware detection, or to perform packet
scrubbing "Scrubbing" (the normalization of packets so that there are "scrubbing" (the normalization of packets so that there are no
no ambiguities in interpretation by the ultimate destination of the ambiguities in interpretation by the ultimate destination of the
packet). These techniques are currently used by some operators to packet). These techniques are currently used by some operators to
also defend from distributed DOS attacks. also defend from distributed DOS attacks.
Exposed transport headers are sometimes also utilised as a part of Exposed transport headers are sometimes also utilised as a part of
the information used by the receiver of a transport protocol to the information used by the receiver of a transport protocol to
protect the transport layer from data injection by an attacker. In protect the transport layer from data injection by an attacker. In
evaluating this use of exposed header information, it is important to evaluating this use of exposed header information, it is important to
consider whether it introduces a significant DOS threat. For consider whether it introduces a significant DOS threat. For
example, an attacker could construct a DOS attack by sending packets example, an attacker could construct a DOS attack by sending packets
with a sequence number that falls within the currently accepted range with a sequence number that falls within the currently accepted range
skipping to change at page 32, line 37 skipping to change at page 32, line 37
[I-D.thomson-quic-grease] [I-D.thomson-quic-grease]
Thomson, M., "More Apparent Randomization for QUIC", Thomson, M., "More Apparent Randomization for QUIC",
draft-thomson-quic-grease-00 (work in progress), December draft-thomson-quic-grease-00 (work in progress), December
2017. 2017.
[I-D.trammell-plus-abstract-mech] [I-D.trammell-plus-abstract-mech]
Trammell, B., "Abstract Mechanisms for a Cooperative Path Trammell, B., "Abstract Mechanisms for a Cooperative Path
Layer under Endpoint Control", draft-trammell-plus- Layer under Endpoint Control", draft-trammell-plus-
abstract-mech-00 (work in progress), September 2016. abstract-mech-00 (work in progress), September 2016.
[I-D.trammell-wire-image]
Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", draft-trammell-wire-image-04 (work in
progress), April 2018.
[Latency] Briscoe, B., "Reducing Internet Latency: A Survey of [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of
Techniques and Their Merits", November 2014. Techniques and Their Merits, IEEE Comm. Surveys &
Tutorials. 26;18(3) p2149-2196", November 2014.
[Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- [Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement-
based Protocol Design", June 2017. based Protocol Design, Eur. Conf. on Networks and
Communications, Oulu, Finland.", June 2017.
[RFC1273] Schwartz, M., "Measurement Study of Changes in Service- [RFC1273] Schwartz, M., "Measurement Study of Changes in Service-
Level Reachability in the Global TCP/IP Internet: Goals, Level Reachability in the Global TCP/IP Internet: Goals,
Experimental Design, Implementation, and Policy Experimental Design, Implementation, and Policy
Considerations", RFC 1273, DOI 10.17487/RFC1273, November Considerations", RFC 1273, DOI 10.17487/RFC1273, November
1991, <https://www.rfc-editor.org/info/rfc1273>. 1991, <https://www.rfc-editor.org/info/rfc1273>.
[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,
skipping to change at page 37, line 43 skipping to change at page 37, line 43
Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on Kathleen Moriarty (on 08/05/2018 and 17/05/2018), Joe Touch on
11/05/2018, and Spencer Dawkins. 11/05/2018, and Spencer Dawkins.
-09 Updated security considerations. -09 Updated security considerations.
-10 Updated references, split the Introduction, and added a paragraph -10 Updated references, split the Introduction, and added a paragraph
giving some examples of why ossification has been an issue. giving some examples of why ossification has been an issue.
-00 This is the first revision submitted as a working group document. -00 This is the first revision submitted as a working group document.
-01 This resolved some reference issues. Updated section on
observation by devices on the path.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen AB24 3UE
Scotland Scotland
EMail: gorry@erg.abdn.ac.uk EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
 End of changes. 44 change blocks. 
168 lines changed or deleted 184 lines changed or added

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