draft-ietf-masque-ip-proxy-reqs-02.txt   draft-ietf-masque-ip-proxy-reqs-03.txt 
Network Working Group A. Chernyakhovsky Network Working Group A. Chernyakhovsky
Internet-Draft D. McCall Internet-Draft D. McCall
Intended status: Informational D. Schinazi Intended status: Informational D. Schinazi
Expires: 1 November 2021 Google LLC Expires: 28 February 2022 Google LLC
30 April 2021 27 August 2021
Requirements for a MASQUE Protocol to Proxy IP Traffic Requirements for a MASQUE Protocol to Proxy IP Traffic
draft-ietf-masque-ip-proxy-reqs-02 draft-ietf-masque-ip-proxy-reqs-03
Abstract Abstract
There is interest among MASQUE working group participants in There is interest among MASQUE working group participants in
designing a protocol that can proxy IP traffic over HTTP. This designing a protocol that can proxy IP traffic over HTTP. This
document describes the set of requirements for such a protocol. document describes the set of requirements for such a protocol.
Discussion of this work is encouraged to happen on the MASQUE IETF Discussion of this work is encouraged to happen on the MASQUE IETF
mailing list masque@ietf.org or on the GitHub repository which mailing list masque@ietf.org or on the GitHub repository which
contains the draft: https://github.com/ietf-wg-masque/draft-ietf- contains the draft: https://github.com/ietf-wg-masque/draft-ietf-
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 1 November 2021. This Internet-Draft will expire on 28 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Consumer VPN . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Consumer VPN . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Point to Point Connectivity . . . . . . . . . . . . . . . 4 2.2. Point to Point Connectivity . . . . . . . . . . . . . . . 4
2.3. Point to Network Connectivity . . . . . . . . . . . . . . 4 2.3. Point to Network Connectivity . . . . . . . . . . . . . . 4
2.4. Network to Network Connectivity . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. IP Session Establishment . . . . . . . . . . . . . . . . 4
3.1. IP Session Establishment . . . . . . . . . . . . . . . . 5
3.2. Proxying of IP packets . . . . . . . . . . . . . . . . . 5 3.2. Proxying of IP packets . . . . . . . . . . . . . . . . . 5
3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 5 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 5
3.4. IP Assignment . . . . . . . . . . . . . . . . . . . . . . 5 3.4. IP Assignment . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Route Negotiation . . . . . . . . . . . . . . . . . . . . 5 3.5. Identity . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Identity . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Transport Security . . . . . . . . . . . . . . . . . . . 5
3.7. Transport Security . . . . . . . . . . . . . . . . . . . 6 3.7. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6
3.8. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 3.8. Indistinguishability . . . . . . . . . . . . . . . . . . 6
3.9. Indistinguishability . . . . . . . . . . . . . . . . . . 6 3.9. Support HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . 6
3.10. Support HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . 6 3.10. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 6
3.11. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 6 3.11. Statefulness . . . . . . . . . . . . . . . . . . . . . . 6
3.12. Statefulness . . . . . . . . . . . . . . . . . . . . . . 7 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7
4.2. Reliable Transmission of IP Packets . . . . . . . . . . . 7 4.2. Reliable Transmission of IP Packets . . . . . . . . . . . 7
4.3. Configuration of Congestion and Flow Control . . . . . . 7 4.3. Configuration of Congestion and Flow Control . . . . . . 7
4.4. Data Transport Compression . . . . . . . . . . . . . . . 8 4.4. Data Transport Compression . . . . . . . . . . . . . . . 7
5. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 8 5. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8
5.2. Translation . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Translation . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. IP Packet Extraction . . . . . . . . . . . . . . . . . . 9 5.3. IP Packet Extraction . . . . . . . . . . . . . . . . . . 8
5.4. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9
Informative References . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
There exist several IETF standards for proxying IP in a way that is There exist several IETF standards for proxying IP in a way that is
authenticated and confidential, such as IKEv2/IPsec [IKEV2]. authenticated and confidential, such as IKEv2/IPsec [IKEV2].
However, those are distinguishable from common Internet traffic and However, those are distinguishable from common Internet traffic and
often blocked. Additionally, large server deployments have expressed often blocked. Additionally, large server deployments have expressed
interest in using a VPN solution that leverages existing security interest in using a VPN solution that leverages existing security
protocols such as QUIC [QUIC] or TLS [TLS] to avoid adding another protocols such as QUIC [QUIC] or TLS [TLS] to avoid adding another
protocol to their security posture. protocol to their security posture.
skipping to change at page 4, line 39 skipping to change at page 4, line 39
network with addressing separate from the physical transport. An network with addressing separate from the physical transport. An
example of this is Wireguard. example of this is Wireguard.
2.3. Point to Network Connectivity 2.3. Point to Network Connectivity
Point-to-Network connectivity is the more traditional remote-access Point-to-Network connectivity is the more traditional remote-access
"VPN" use case, frequently used when a user needs to connect to a "VPN" use case, frequently used when a user needs to connect to a
different network (such as an enterprise network) for access to different network (such as an enterprise network) for access to
resources that are not exposed to the public Internet. resources that are not exposed to the public Internet.
2.4. Network to Network Connectivity
Network-to-Network connectivity is also called a site-to-site VPN.
Similar to the point-to-network use case, the goal is to connect two
networks that are not exposed publicly. The site-to-site aspects
make this transparent to the user; the entire networks are connected
to each other and route packets transparently without a VPN client
installed on the user's device. This style of connectivity can also
be used to connect devices that cannot run VPN clients through to the
network.
3. Requirements 3. Requirements
This section lists requirements for a protocol that can proxy IP over This section lists requirements for a protocol that can proxy IP over
an HTTP connection. an HTTP connection.
3.1. IP Session Establishment 3.1. IP Session Establishment
The protocol will allow the client to request establishment of an IP The protocol will allow the client to request establishment of an IP
Session, along with configuration options and one or more associated Session, along with configuration options and one or more associated
Data Transports. The server will have the ability to accept or deny Data Transports. The server will have the ability to accept or deny
skipping to change at page 5, line 28 skipping to change at page 5, line 16
The protocol will establish Data Transports, which will be able to The protocol will establish Data Transports, which will be able to
forward IP packets. The Data Transports MUST be able to take IP forward IP packets. The Data Transports MUST be able to take IP
datagrams input on one side and egress them unmodified in their datagrams input on one side and egress them unmodified in their
entirety on the other side, although extensions may enable IP packets entirety on the other side, although extensions may enable IP packets
to be modified in transit. The protocol will support both IPv6 to be modified in transit. The protocol will support both IPv6
[IPV6] and IPv4 [IPV4]. [IPV6] and IPv4 [IPV4].
3.3. Maximum Transmission Unit 3.3. Maximum Transmission Unit
The protocol will allow endpoints to inform each other of the Maximum The protocol will allow tunnel endpoints to inform each other of the
Transmission Unit (MTU) they are willing to forward. This will allow Maximum Transmission Unit (MTU) they are willing to forward. This
avoiding IP fragmentation, especially as IPv6 does not allow IP will allow avoiding some IP fragmentation, especially as IPv6 does
fragmentation by nodes along the path. not allow IP fragmentation by nodes along the path. In cases where
the tunnel endpoint is not the same as the communication endpoint,
tunnel endpoints are expected to apply the guidance on UDP tunnels in
[TUNNELS].
3.4. IP Assignment 3.4. IP Assignment
The client will be able to request to be assigned an IP address The client will be able to request to be assigned an IP address
range, optionally specifying a preferred range. In response to that range, optionally specifying a preferred range. In response to that
request, the server will either assign a range of its choosing to the request, the server will either assign a range of its choosing to the
client, or decline the request. For symmetry, the server may request client, or decline the request. For symmetry, the server may request
assignment of an IP address range from the client, and the client assignment of an IP address range from the client, and the client
will either assign a range or decline the request. will either assign a range or decline the request. Endpoints will
also have the ability to assign an IP address range to their peer,
3.5. Route Negotiation and to communicate that assignment to the peer, without having
received a request.
At any point in an IP Session (not limited to its initial
negotiation), the protocol will allow both client and server to
inform its peer that it can route a set of IP prefixes. Both
endpoints can also request a route to a given prefix, and the peer
can choose to provide that route or not. This can be used to inform
peers of a default route for all prefixes.
Note that if an endpoint provides its peer with a route, the peer is
in no way obligated to route its traffic through the endpoint.
3.6. Identity 3.5. Identity
When negotiating the creation of an IP Session, the protocol will When negotiating the creation of an IP Session, the protocol will
allow both endpoints to exchange an identifier. As examples, the allow both endpoints to exchange an identifier. As examples, the
identity could be a user name, an email address, a token, or a fully- identity could be a user name, an email address, a token, or a fully-
qualified domain name. Note that this requirement does not cover qualified domain name. Note that this requirement does not cover
authenticating the identifier. authenticating the identifier.
3.7. Transport Security 3.6. Transport Security
The protocol MUST be run over a protocol that provides mutual The protocol MUST be run over a protocol that provides mutual
authentication, confidentiality and integrity. Using QUIC or TLS authentication, confidentiality and integrity. Using QUIC or TLS
would meet this requirement. would meet this requirement.
3.8. Flow Control 3.7. Flow Control
The protocol will allow the ability to proxy IP packets without flow The protocol will allow the ability to proxy IP packets without flow
control, at least when HTTP/3 is in use. QUIC DATAGRAM frames are control, at least when HTTP/3 is in use. QUIC DATAGRAM frames are
not flow controlled and would meet this requirement. The document not flow controlled and would meet this requirement. The document
defining the protocol will provide guidance on how best to use flow defining the protocol will provide guidance on how best to use flow
control to improve IP Session performance. control to improve IP Session performance.
3.9. Indistinguishability 3.8. Indistinguishability
A passive network observer not participating in the encrypted A passive network observer not participating in the encrypted
connection should not be able to distinguish IP proxying from regular connection should not be able to distinguish IP proxying from regular
encrypted HTTP Web traffic by only observing non-encrypted parts of encrypted HTTP Web traffic by only observing non-encrypted parts of
the traffic. Specifically, any data sent unencrypted (such as the traffic. Specifically, any data sent unencrypted (such as
headers, or parts of the handshake) should look like the same headers, or parts of the handshake) should look like the same
unencrypted data that would be present for Web traffic. Traffic unencrypted data that would be present for Web traffic. Traffic
analysis is out of scope for this requirement. analysis is out of scope for this requirement.
3.10. Support HTTP/2 and HTTP/3 3.9. Support HTTP/2 and HTTP/3
The IP proxying protocol discussed in this document will run over The IP proxying protocol discussed in this document will run over
HTTP. The protocol SHOULD strongly prefer to use HTTP/3 [H3] and HTTP. The protocol SHOULD strongly prefer to use HTTP/3 [H3] and
SHOULD use the QUIC DATAGRAM frames [DGRAM] when available to improve SHOULD use the QUIC DATAGRAM frames [DGRAM] when available to improve
performance. The protocol MUST also support HTTP/2 [H2] as a performance. The protocol MUST also support HTTP/2 [H2] as a
fallback when UDP is blocked on the network path. Proxying IP over fallback when UDP is blocked on the network path. Proxying IP over
HTTP/2 MAY result in lower performance than over HTTP/3. HTTP/2 MAY result in lower performance than over HTTP/3.
3.11. Multiplexing 3.10. Multiplexing
Since recent HTTP versions support concurrently running multiple Since recent HTTP versions support concurrently running multiple
requests over the same connection, the protocol SHOULD support requests over the same connection, the protocol SHOULD support
multiple independent instances of IP proxying over a given HTTP multiple independent instances of IP proxying over a given HTTP
connection. connection.
3.12. Statefulness 3.11. Statefulness
The protocol should limit the amount of state a MASQUE client or The protocol should limit the amount of state a MASQUE client or
server needs to operate. Keeping minimal state simplifies server needs to operate. Keeping minimal state simplifies
reconnection in the presence of failures and can facilitate reconnection in the presence of failures and can facilitate
extensibility. extensibility.
4. Extensibility 4. Extensibility
The protocol will provide a mechanism by which clients and servers The protocol will provide a mechanism by which clients and servers
can add extension information to the exchange that establishes the IP can add extension information to the exchange that establishes the IP
skipping to change at page 9, line 13 skipping to change at page 9, line 5
collocated with it. collocated with it.
5.3. IP Packet Extraction 5.3. IP Packet Extraction
How packets are forwarded between the IP proxying connection and the How packets are forwarded between the IP proxying connection and the
physical network is out of scope. For example, this can be physical network is out of scope. For example, this can be
accomplished on some operating systems using a TUN interface. How accomplished on some operating systems using a TUN interface. How
this is done is deliberately not specified and will be left to this is done is deliberately not specified and will be left to
individual implementations. individual implementations.
5.4. Trust
All the use-cases described in Section 2 require some level of trust
between endpoints. However, how this trust is established and what
decisions endpoints make based on this trust is considered out of
scope. For example, if an endpoint doesn't sufficiently trust its
peer, it would be well advised to validate the IP addresses used by
that peer - however that is considered out of scope for the document
that will describe an IP proxying protocol.
6. Security Considerations 6. Security Considerations
This document only discusses requirements on a protocol that allows This document only discusses requirements on a protocol that allows
IP proxying. That protocol will need to document its security IP proxying. That protocol will need to document its security
considerations. considerations.
7. IANA Considerations 7. IANA Considerations
This document requests no actions from IANA. This document requests no actions from IANA.
skipping to change at page 9, line 34 skipping to change at page 9, line 36
The authors would like to thank participants of the MASQUE working The authors would like to thank participants of the MASQUE working
group for their feedback. group for their feedback.
References References
Normative References Normative References
[DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", Work in Progress, Internet- Datagram Extension to QUIC", Work in Progress, Internet-
Draft, draft-ietf-quic-datagram-02, 16 February 2021, Draft, draft-ietf-quic-datagram-03, 12 July 2021,
<https://tools.ietf.org/html/draft-ietf-quic-datagram-02>. <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
datagram-03>.
[H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/rfc/rfc7540>. <https://www.rfc-editor.org/rfc/rfc7540>.
[H3] Bishop, M., "Hypertext Transfer Protocol Version 3 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3
(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
quic-http-34, 2 February 2021, quic-http-34, 2 February 2021,
<https://tools.ietf.org/html/draft-ietf-quic-http-34>. <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
http-34>.
[IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>. <https://www.rfc-editor.org/rfc/rfc791>.
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>. <https://www.rfc-editor.org/rfc/rfc8200>.
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft, and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-34, 14 January 2021, draft-ietf-quic-transport-34, 14 January 2021,
<https://tools.ietf.org/html/draft-ietf-quic-transport- <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
34>. transport-34>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
Informative References Informative References
[CONNECT-UDP] [CONNECT-UDP]
Schinazi, D., "The CONNECT-UDP HTTP Method", Work in Schinazi, D., "The CONNECT-UDP HTTP Method", Work in
Progress, Internet-Draft, draft-ietf-masque-connect-udp- Progress, Internet-Draft, draft-ietf-masque-connect-udp-
03, 5 January 2021, <https://tools.ietf.org/html/draft- 04, 12 July 2021, <https://datatracker.ietf.org/doc/html/
ietf-masque-connect-udp-03>. draft-ietf-masque-connect-udp-04>.
[IKEV2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [IKEV2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/rfc/rfc7296>. 2014, <https://www.rfc-editor.org/rfc/rfc7296>.
[OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>. <https://www.rfc-editor.org/rfc/rfc6749>.
[TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-10, 12 September 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-10>.
Authors' Addresses Authors' Addresses
Alex Chernyakhovsky Alex Chernyakhovsky
Google LLC Google LLC
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California 94043, Mountain View, California 94043,
United States of America United States of America
Email: achernya@google.com Email: achernya@google.com
Dallas McCall Dallas McCall
Google LLC Google LLC
 End of changes. 25 change blocks. 
62 lines changed or deleted 63 lines changed or added

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