rfc9347v2.txt   rfc9347.txt 
skipping to change at line 383 skipping to change at line 383
the effective throughput of a tunnel. Senders implementing either of the effective throughput of a tunnel. Senders implementing either of
the above approaches will need to take care to not reduce the the above approaches will need to take care to not reduce the
effective capacity, and overall utility, of the tunnel through the effective capacity, and overall utility, of the tunnel through the
overuse of padding. overuse of padding.
2.2.4. Empty Payload 2.2.4. Empty Payload
To support reporting of congestion control information (described To support reporting of congestion control information (described
later) using a non-AGGFRAG_PAYLOAD-enabled SA, it is allowed to send later) using a non-AGGFRAG_PAYLOAD-enabled SA, it is allowed to send
an AGGFRAG_PAYLOAD payload with no data blocks (i.e., the ESP payload an AGGFRAG_PAYLOAD payload with no data blocks (i.e., the ESP payload
Length is equal to the AGGFRAG_PAYLOAD header length). This special length is equal to the AGGFRAG_PAYLOAD header length). This special
payload is called an empty payload. payload is called an empty payload.
Currently, this situation is only applicable in use cases without Currently, this situation is only applicable in use cases without
Internet Key Exchange Protocol Version 2 (IKEv2). Internet Key Exchange Protocol Version 2 (IKEv2).
2.2.5. IP Header Value Mapping 2.2.5. IP Header Value Mapping
[RFC4301] provides some direction on when and how to map various [RFC4301] provides some direction on when and how to map various
values from an inner IP header to the outer encapsulating header, values from an inner IP header to the outer encapsulating header,
namely the Don't Fragment (DF) bit [RFC0791], the Differentiated namely the Don't Fragment (DF) bit [RFC0791], the Differentiated
skipping to change at line 426 skipping to change at line 426
By default, the DS field SHOULD NOT be copied, although a sender MAY By default, the DS field SHOULD NOT be copied, although a sender MAY
choose to allow for configuration to override this behavior. A choose to allow for configuration to override this behavior. A
sender SHOULD also allow the DS value to be set by configuration. sender SHOULD also allow the DS value to be set by configuration.
2.2.6. IPv4 Time To Live (TTL), IPv6 Hop Limit, and ICMP Messages 2.2.6. IPv4 Time To Live (TTL), IPv6 Hop Limit, and ICMP Messages
How to modify the inner packet IPv4 TTL [RFC0791] or IPv6 Hop Limit How to modify the inner packet IPv4 TTL [RFC0791] or IPv6 Hop Limit
[RFC8200] is specified in [RFC4301]. [RFC8200] is specified in [RFC4301].
It is also specified in [RFC4301] how to apply policy to [RFC4301] specifies how to apply policy to authenticated and
authenticated and unauthenticated ICMP error packets (e.g., unauthenticated ICMP error packets (e.g., Destination Unreachable)
Destination Unreachable) arriving at or being forwarded through the arriving at or being forwarded through the endpoint, in particular,
endpoint, in particular, whether to process, ignore, or forward said whether to process, ignore, or forward said packets. With the one
packets. With the one exception that this document does not change exception that this document does not change the handling of these
the handling of these packets, they should be handled as specified in packets, they should be handled as specified in [RFC4301].
[RFC4301].
The one way in which an AGGFRAG tunnel differs in ICMP error packet The one way in which an AGGFRAG tunnel differs in ICMP error packet
mechanics is with PMTU. When fragmentation is enabled on the AGGFRAG mechanics is with PMTU. When fragmentation is enabled on the AGGFRAG
tunnel, then no ICMP "Too Big" errors need to be generated for tunnel, then no ICMP "Too Big" errors need to be generated for
arriving ingress traffic, as the arriving inner packets will be arriving ingress traffic, as the arriving inner packets will be
naturally fragmented by the AGGFRAG encapsulation. naturally fragmented by the AGGFRAG encapsulation.
Otherwise, when fragmentation has been disabled on the AGGFRAG Otherwise, when fragmentation has been disabled on the AGGFRAG
tunnel, then the treatment of arriving inner traffic exactly maps to tunnel, then the treatment of arriving inner traffic exactly maps to
that of a non-AGGFRAG ESP tunnel. Explicitly, IPv4 with DF set and that of a non-AGGFRAG ESP tunnel. Explicitly, IPv4 with DF set and
IPv6 packets that cannot fit in its own outer packet payload will IPv6 packets that cannot fit in its own outer packet payload will
generate the appropriate ICMP "Too Big" error, as described generate the appropriate ICMP "Too Big" error, as described in
[RFC4301], and IPv4 packets without DF set will be IP fragmented, as [RFC4301], and IPv4 packets without DF set will be IP fragmented, as
described in [RFC4301]. described in [RFC4301].
Packets egressing the tunnel continue to be handled as specified in Packets egressing the tunnel continue to be handled as specified in
[RFC4301]. [RFC4301].
All other aspects of PMTU and the handling of ICMP "Too Big" messages All other aspects of PMTU and the handling of ICMP "Too Big" messages
(i.e., with regards to the outer AGGFRAG/ESP tunnel packet size) also (i.e., with regards to the outer AGGFRAG/ESP tunnel packet size) also
remain unchanged from [RFC4301]. remain unchanged from [RFC4301].
skipping to change at line 513 skipping to change at line 512
congestion. Thus, if they do not guarantee the bandwidth required by congestion. Thus, if they do not guarantee the bandwidth required by
the tunnel, the tunnel's operation, as well as the rest of their the tunnel, the tunnel's operation, as well as the rest of their
network, may be negatively impacted. network, may be negatively impacted.
One expected use case for the non-congestion-controlled mode is to One expected use case for the non-congestion-controlled mode is to
guarantee the full tunnel bandwidth is available and preferred over guarantee the full tunnel bandwidth is available and preferred over
other non-tunnel traffic. In fact, a typical site-to-site use case other non-tunnel traffic. In fact, a typical site-to-site use case
might have all of the user traffic utilizing the IP-TFS tunnel. might have all of the user traffic utilizing the IP-TFS tunnel.
The non-congestion-controlled mode is also appropriate if ESP over The non-congestion-controlled mode is also appropriate if ESP over
TCP is in use [RFC8229]. However, the use of TCP is considered a TCP is in use [RFC9329]. However, the use of TCP is considered a
fallback-only solution for IPsec; it is highly not preferred. This fallback-only solution for IPsec; it is highly not preferred. This
is also one of the reasons that TCP was not chosen as the is also one of the reasons that TCP was not chosen as the
encapsulation for IP-TFS instead of AGGFRAG. encapsulation for IP-TFS instead of AGGFRAG.
2.4.2. Congestion-Controlled Mode 2.4.2. Congestion-Controlled Mode
With the congestion-controlled mode, IP-TFS adapts to network With the congestion-controlled mode, IP-TFS adapts to network
congestion by lowering the packet send rate to accommodate the congestion by lowering the packet send rate to accommodate the
congestion, as well as raising the rate when congestion subsides. congestion, as well as raising the rate when congestion subsides.
Since overhead is per packet, by allowing for maximal fixed-size Since overhead is per packet, by allowing for maximal fixed-size
skipping to change at line 724 skipping to change at line 723
4. Configuration of AGGFRAG Tunnels for IP-TFS 4. Configuration of AGGFRAG Tunnels for IP-TFS
IP-TFS is meant to be deployable with a minimal amount of IP-TFS is meant to be deployable with a minimal amount of
configuration. All IP-TFS-specific configuration should be specified configuration. All IP-TFS-specific configuration should be specified
at the unidirectional tunnel ingress (sending) side. It is intended at the unidirectional tunnel ingress (sending) side. It is intended
that non-IKEv2 operation is supported, at least, with local static that non-IKEv2 operation is supported, at least, with local static
configuration. configuration.
YANG and MIB documents have been defined for IP-TFS in [RFC9348] and YANG and MIB documents have been defined for IP-TFS in [RFC9348] and
[IPSECME-MIB-IPTFS]. [RFC9349].
4.1. Bandwidth 4.1. Bandwidth
Bandwidth is a local configuration option. For the non-congestion- Bandwidth is a local configuration option. For the non-congestion-
controlled mode, the bandwidth SHOULD be configured. For the controlled mode, the bandwidth SHOULD be configured. For the
congestion-controlled mode, the bandwidth can be configured or the congestion-controlled mode, the bandwidth can be configured or the
congestion control algorithm discovers and uses the maximum bandwidth congestion control algorithm discovers and uses the maximum bandwidth
available. No standardized configuration method is required. available. No standardized configuration method is required.
4.2. Fixed Packet Size 4.2. Fixed Packet Size
skipping to change at line 1120 skipping to change at line 1119
As noted previously in Section 2.4.2, for TFC to be maintained, the As noted previously in Section 2.4.2, for TFC to be maintained, the
encapsulated traffic flow should not be affecting network congestion encapsulated traffic flow should not be affecting network congestion
in a predictable way, and if it would be, then non-congestion- in a predictable way, and if it would be, then non-congestion-
controlled mode use should be considered instead. controlled mode use should be considered instead.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
to Indicate Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4303] Kent, S. and RFC Publisher, "IP Encapsulating Security [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December RFC 4303, DOI 10.17487/RFC4303, December 2005,
2005, <https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., Kivinen, [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
T., and RFC Publisher, "Internet Key Exchange Protocol Kivinen, "Internet Key Exchange Protocol Version 2
Version 2 (IKEv2)", STD 79, RFC 7296, (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
DOI 10.17487/RFC7296, October 2014, 2014, <https://www.rfc-editor.org/info/rfc7296>.
<https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B. and RFC Publisher, "Ambiguity of Uppercase vs [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
DOI 10.17487/RFC8174, May 2017, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
<https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[AppCrypt] Schneier, B., "Applied Cryptography: Protocols, [AppCrypt] Schneier, B., "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996. Algorithms, and Source Code in C", 1996.
[IPSECME-MIB-IPTFS] [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
Fedyk, D. and E. Kinzie, "Definitions of Managed Objects DOI 10.17487/RFC0791, September 1981,
for IP Traffic Flow Security", Work in Progress, Internet-
Draft, draft-ietf-ipsecme-mib-iptfs-11, 21 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
mib-iptfs-11>.
[RFC0791] Postel, J. and RFC Publisher, "Internet Protocol", STD 5,
RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J., Deering, S., and RFC Publisher, "Path MTU [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>. <https://www.rfc-editor.org/info/rfc1191>.
[RFC2474] Nichols, K., Blake, S., Baker, F., Black, D., and RFC [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Publisher, "Definition of the Differentiated Services "Definition of the Differentiated Services Field (DS
Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2914] Floyd, S. and RFC Publisher, "Congestion Control [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, RFC 2914, DOI 10.17487/RFC2914, September 2000,
September 2000, <https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., Black, D., and RFC Publisher, [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
"The Addition of Explicit Congestion Notification (ECN) to of Explicit Congestion Notification (ECN) to IP",
IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC4301] Kent, S., Seo, K., and RFC Publisher, "Security [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Architecture for the Internet Protocol", RFC 4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
DOI 10.17487/RFC4301, December 2005, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
<https://www.rfc-editor.org/info/rfc4301>.
[RFC4342] Floyd, S., Kohler, E., Padhye, J., and RFC Publisher, [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
"Profile for Datagram Congestion Control Protocol (DCCP) Datagram Congestion Control Protocol (DCCP) Congestion
Congestion Control ID 3: TCP-Friendly Rate Control Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
(TFRC)", RFC 4342, DOI 10.17487/RFC4342, March 2006, DOI 10.17487/RFC4342, March 2006,
<https://www.rfc-editor.org/info/rfc4342>. <https://www.rfc-editor.org/info/rfc4342>.
[RFC4821] Mathis, M., Heffner, J., and RFC Publisher, "Packetization [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
March 2007, <https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., Widmer, J., and RFC [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Publisher, "TCP Friendly Rate Control (TFRC): Protocol Friendly Rate Control (TFRC): Protocol Specification",
Specification", RFC 5348, DOI 10.17487/RFC5348, September RFC 5348, DOI 10.17487/RFC5348, September 2008,
2008, <https://www.rfc-editor.org/info/rfc5348>. <https://www.rfc-editor.org/info/rfc5348>.
[RFC6040] Briscoe, B. and RFC Publisher, "Tunnelling of Explicit [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, Notification", RFC 6040, DOI 10.17487/RFC6040, November
November 2010, <https://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC7120] Cotton, M. and RFC Publisher, "Early IANA Allocation of [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Standards Track Code Points", BCP 100, RFC 7120, Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
DOI 10.17487/RFC7120, January 2014, 2014, <https://www.rfc-editor.org/info/rfc7120>.
<https://www.rfc-editor.org/info/rfc7120>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., Black, D., and [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
RFC Publisher, "Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC7893] Stein, Y., Black, D., Briscoe, B., and RFC Publisher, [RFC7893] Stein, Y., Black, D., and B. Briscoe, "Pseudowire
"Pseudowire Congestion Considerations", RFC 7893, Congestion Considerations", RFC 7893,
DOI 10.17487/RFC7893, June 2016, DOI 10.17487/RFC7893, June 2016,
<https://www.rfc-editor.org/info/rfc7893>. <https://www.rfc-editor.org/info/rfc7893>.
[RFC8084] Fairhurst, G. and RFC Publisher, "Network Transport [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
Circuit Breakers", BCP 208, RFC 8084, BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>. <https://www.rfc-editor.org/info/rfc8084>.
[RFC8126] Cotton, M., Leiba, B., Narten, T., and RFC Publisher, [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
"Guidelines for Writing an IANA Considerations Section in Writing an IANA Considerations Section in RFCs", BCP 26,
RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S., Hinden, R., and RFC Publisher, "Internet [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Protocol, Version 6 (IPv6) Specification", STD 86, (IPv6) Specification", STD 86, RFC 8200,
RFC 8200, DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., Hinden, R., Ed., and [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
RFC Publisher, "Path MTU Discovery for IP version 6", "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8229] Pauly, T., Touati, S., Mantha, R., and RFC Publisher, "TCP [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
Encapsulation of IKE and IPsec Packets", RFC 8229, Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
DOI 10.17487/RFC8229, August 2017, 2019, <https://www.rfc-editor.org/info/rfc8546>.
<https://www.rfc-editor.org/info/rfc8229>.
[RFC8546] Trammell, B., Kuehlewind, M., and RFC Publisher, "The Wire [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Image of a Network Protocol", RFC 8546, Völker, "Packetization Layer Path MTU Discovery for
DOI 10.17487/RFC8546, April 2019, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
<https://www.rfc-editor.org/info/rfc8546>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., Völker, [RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet
T., and RFC Publisher, "Packetization Layer Path MTU Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329,
Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC9329, November 2022,
DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc9329>.
<https://www.rfc-editor.org/info/rfc8899>.
[RFC9348] Fedyk, D. and C. Hopps, "A YANG Data Model for IP Traffic [RFC9348] Fedyk, D. and C. Hopps, "A YANG Data Model for IP Traffic
Flow Security", RFC 9348, DOI 10.17487/RFC9348, December Flow Security", RFC 9348, DOI 10.17487/RFC9348, January
2022, <https://www.rfc-editor.org/info/rfc9348>. 2023, <https://www.rfc-editor.org/info/rfc9348>.
[RFC9349] Fedyk, D. and E. Kinzie, "Definitions of Managed Objects
for IP Traffic Flow Security", RFC 9349,
DOI 10.17487/RFC9349, January 2023,
<https://www.rfc-editor.org/info/rfc9349>.
Appendix A. Example of an Encapsulated IP Packet Flow Appendix A. Example of an Encapsulated IP Packet Flow
Below, an example inner IP packet flow within the encapsulating Below, an example inner IP packet flow within the encapsulating
tunnel packet stream is shown. Notice how encapsulated IP packets tunnel packet stream is shown. Notice how encapsulated IP packets
can start and end anywhere, and more than one or less than one may can start and end anywhere, and more than one or less than one may
occur in a single encapsulating packet. occur in a single encapsulating packet.
Offset: 0 Offset: 100 Offset: 2000 Offset: 600 Offset: 0 Offset: 100 Offset: 2000 Offset: 600
[ ESP1 (1404) ][ ESP2 (1404) ][ ESP3 (1404) ][ ESP4 (1404) ] [ ESP1 (1404) ][ ESP2 (1404) ][ ESP3 (1404) ][ ESP4 (1404) ]
 End of changes. 30 change blocks. 
98 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.48.