draft-ietf-rtgwg-rfc3682bis-08.txt   draft-ietf-rtgwg-rfc3682bis-09.txt 
Routing WG V. Gill Routing WG V. Gill
Internet-Draft J. Heasley Internet-Draft J. Heasley
Obsoletes: 3682 (if approved) D. Meyer Obsoletes: 3682 (if approved) D. Meyer
Intended status: Standards Track P. Savola, Ed. Intended status: Standards Track P. Savola, Ed.
Expires: June 16, 2007 C. Pignataro Expires: August 4, 2007 C. Pignataro
December 13, 2006 January 31, 2007
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-08.txt draft-ietf-rtgwg-rfc3682bis-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2007. This Internet-Draft will expire on August 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)
to verify whether the packet was originated by an adjacent node on a to verify whether the packet was originated by an adjacent node on a
connected link has been used in many recent protocols. This document connected link has been used in many recent protocols. This document
generalizes this technique. This document obsoletes RFC 3682. generalizes this technique. This document obsoletes RFC 3682.
Table of Contents Table of Contents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11 5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12 5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 14 Appendix A. Multi-hop GTSM . . . . . . . . . . . . . . . . . . . 14
Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 14 Appendix B. Changes Since RFC3682 . . . . . . . . . . . . . . . 14
Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 14 Appendix C. Draft Changelog . . . . . . . . . . . . . . . . . . 15
Appendix C.1. Changes between -07 and -08 . . . . . . . . . . . . 15 Appendix C.1. Changes between -08 and -09 . . . . . . . . . . . . 15
Appendix C.2. Changes between -06 and -07 . . . . . . . . . . . . 15 Appendix C.2. Changes between -07 and -08 . . . . . . . . . . . . 15
Appendix C.3. Changes between -05 and -06 . . . . . . . . . . . . 15 Appendix C.3. Changes between -06 and -07 . . . . . . . . . . . . 15
Appendix C.4. Changes between -05 and -06 . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The Generalized TTL Security Mechanism (GTSM) is designed to protect The Generalized TTL Security Mechanism (GTSM) is designed to protect
a router's IP based control plane from CPU-utilization based attacks. a router's IP based control plane from CPU-utilization based attacks.
In particular, while cryptographic techniques can protect the router- In particular, while cryptographic techniques can protect the router-
based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide
variety of attacks, many attacks based on CPU overload can be variety of attacks, many attacks based on CPU overload can be
prevented by the simple mechanism described in this document. Note prevented by the simple mechanism described in this document. Note
that the same technique protects against other scarce-resource that the same technique protects against other scarce-resource
skipping to change at page 5, line 38 skipping to change at page 5, line 38
can set the TTL on the protocol packets to 255 (the maximum possible can set the TTL on the protocol packets to 255 (the maximum possible
for IP) and then reject any protocol packets that come in from for IP) and then reject any protocol packets that come in from
configured peers which do NOT have an inbound TTL of 255. configured peers which do NOT have an inbound TTL of 255.
GTSM can be disabled for applications such as route-servers and other GTSM can be disabled for applications such as route-servers and other
multi-hop peerings. In the event that an attack comes in from a multi-hop peerings. In the event that an attack comes in from a
compromised multi-hop peering, that peering can be shut down. compromised multi-hop peering, that peering can be shut down.
3. GTSM Procedure 3. GTSM Procedure
If GTSM is not built into the protocol and used as an additional If GTSM is not built into the protocol and is used as an additional
feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by
default in order to be backward-compatible with the unmodified default in order to be backward-compatible with the unmodified
protocol. protocol. However, if the protocol defines a built-in dynamic
capability negotiation for GTSM, a protocol peer MAY suggest the use
of GTSM provided that GTSM would only be enabled if both peers agree
to use it.
If GTSM is enabled for a protocol session, the following steps are If GTSM is enabled for a protocol session, the following steps are
added to the IP packet sending and reception procedures: added to the IP packet sending and reception procedures:
Sending protocol packets: Sending protocol packets:
The TTL field in all IP packets used for transmission of The TTL field in all IP packets used for transmission of
messages associated with GTSM-enabled protocol sessions MUST be messages associated with GTSM-enabled protocol sessions MUST be
set to 255. This also applies to related error handling set to 255. This also applies to related error handling
messages associated with said session, such as TCP RSTs or ICMP messages associated with said session, such as TCP RSTs or ICMP
skipping to change at page 6, line 20 skipping to change at page 6, line 24
decremented. decremented.
Receiving protocol packets: Receiving protocol packets:
The GTSM packet identification step associates each received The GTSM packet identification step associates each received
packet addressed to the router's control plane with one of the packet addressed to the router's control plane with one of the
following three trustworthiness categories: following three trustworthiness categories:
+ Unknown: these are packets that cannot be associated with + Unknown: these are packets that cannot be associated with
any registered GTSM-enabled session, and hence GTSM cannot any registered GTSM-enabled session, and hence GTSM cannot
make any judgement on the level of risk associated with make any judgment on the level of risk associated with them.
them.
+ Trusted: these are packets that have been identified as + Trusted: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, and their TTL belonging to one of the GTSM-enabled sessions, and their TTL
values are within the expected range. values are within the expected range.
+ Dangerous: these are packets that have been identified as + Dangerous: these are packets that have been identified as
belonging to one of the GTSM-enabled sessions, but their TTL belonging to one of the GTSM-enabled sessions, but their TTL
values are NOT within the expected range, and hence GTSM values are NOT within the expected range, and hence GTSM
believes there is a risk that the packets have been spoofed. believes there is a risk that the packets have been spoofed.
The exact policies applied to packets of different The exact policies applied to packets of different
classifications are not postulated in this document and are classifications are not postulated in this document and are
expected to be configurable. Configurability is likely expected to be configurable. Configurability is likely
necessary particular with the treatment of related messages necessary in particular with the treatment of related messages
such as ICMP errors and TCP RSTs. It should be noted that such as ICMP errors and TCP RSTs. It should be noted that
fragmentation may restrict the amount of information available fragmentation may restrict the amount of information available
to the classification. to the classification.
However, by default, the implementations: However, by default, the implementations:
+ SHOULD ensure that packets classified as Dangerous do not + SHOULD ensure that packets classified as Dangerous do not
compete for resources with packets classified as Trusted or compete for resources with packets classified as Trusted or
Unknown. Unknown.
skipping to change at page 9, line 19 skipping to change at page 9, line 21
inner header TTL is not changed during encapsulation. inner header TTL is not changed during encapsulation.
In the first case, the encapsulated packet is tunneled directly to In the first case, the encapsulated packet is tunneled directly to
the protocol peer (also a tunnel endpoint), and therefore the the protocol peer (also a tunnel endpoint), and therefore the
encapsulated packet's TTL can be received by the protocol peer with encapsulated packet's TTL can be received by the protocol peer with
an arbitrary value, including 255. an arbitrary value, including 255.
In the second case, the encapsulated packet is tunneled to a In the second case, the encapsulated packet is tunneled to a
decapsulator (tunnel endpoint) which then forwards it to a directly decapsulator (tunnel endpoint) which then forwards it to a directly
connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies
the following decapsulator behaviour: the following decapsulator behavior:
The TTL in the inner IP header is not changed when decapsulating. The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation, decapsulator MUST discard the datagram. If, after decapsulation,
the decapsulator forwards the datagram to one of its network the decapsulator forwards the datagram to one of its network
interfaces, it will decrement the TTL as a result of doing normal interfaces, it will decrement the TTL as a result of doing normal
IP forwarding. See also Section 4.4. IP forwarding. See also Section 4.4.
And similarly, for GRE tunnels, RFC 2784 specifies the following And similarly, for GRE tunnels, RFC 2784 specifies the following
decapsulator behaviour: decapsulator behavior:
When a tunnel endpoint decapsulates a GRE packet which has an IPv4 When a tunnel endpoint decapsulates a GRE packet which has an IPv4
packet as the payload, the destination address in the IPv4 payload packet as the payload, the destination address in the IPv4 payload
packet header MUST be used to forward the packet and the TTL of packet header MUST be used to forward the packet and the TTL of
the payload packet MUST be decremented. the payload packet MUST be decremented.
Hence the inner IP packet header's TTL, as seen by the decapsulator, Hence the inner IP packet header's TTL, as seen by the decapsulator,
can be set to an arbitrary value (in particular, 255). If the can be set to an arbitrary value (in particular, 255). If the
decapsulator is also the protocol peer, it is possible to deliver the decapsulator is also the protocol peer, it is possible to deliver the
protocol packet to it with a TTL of 255 (first case). On the other protocol packet to it with a TTL of 255 (first case). On the other
skipping to change at page 10, line 46 skipping to change at page 10, line 50
3443 states that: 3443 states that:
For each pushed Pipe Model or Short Pipe Model label, the TTL For each pushed Pipe Model or Short Pipe Model label, the TTL
field is set to a value configured by the network operator. In field is set to a value configured by the network operator. In
most implementations, this value is set to 255 by default. most implementations, this value is set to 255 by default.
In these models, the forwarding treatment at egress is based on the In these models, the forwarding treatment at egress is based on the
tunneled packet as opposed to the encapsulation packet. The ingress tunneled packet as opposed to the encapsulation packet. The ingress
TTL (iTTL) is the value of the TTL field of the header that is TTL (iTTL) is the value of the TTL field of the header that is
exposed, that is the tunneled IP datagram's TTL. The protocol exposed, that is the tunneled IP datagram's TTL. The protocol
packet's TTL as seen be the LSP termination can therefore be set to packet's TTL as seen by the LSP termination can therefore be set to
an arbitrary value (including 255). If the LSP termination router is an arbitrary value (including 255). If the LSP termination router is
also the protocol peer, it is possible to deliver the protocol packet also the protocol peer, it is possible to deliver the protocol packet
with a TTL of 255 (x = 255). with a TTL of 255 (x = 255).
Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled
packet is unchanged after the PHP operation. Therefore, the same packet is unchanged after the PHP operation. Therefore, the same
conclusions drawn regarding the Short Pipe Model LSPs without PHP and conclusions drawn regarding the Short Pipe Model LSPs without PHP and
Pipe Model LSPs (without PHP only) apply to this case. For Short Pipe Model LSPs (without PHP only) apply to this case. For Short
Pipe Model LSPs, the TTL at egress has the same value with or without Pipe Model LSPs, the TTL at egress has the same value with or without
PHP. PHP.
skipping to change at page 13, line 34 skipping to change at page 13, line 36
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002. with BGP-4", RFC 3392, November 2002.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks", in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, January 2003. RFC 3443, January 2003.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
skipping to change at page 14, line 16 skipping to change at page 14, line 14
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
8.2. Informative References 8.2. Informative References
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and [BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and
BITW' on int-area list, Message-ID: BITW' on int-area list, Message-ID:
<Pine.LNX.4.64.0606020830220.12705@netcore.fi>", <Pine.LNX.4.64.0606020830220.12705@netcore.fi>",
June 2006, <http://www1.ietf.org/mail-archive/web/ June 2006, <http://www1.ietf.org/mail-archive/web/
int-area/current/msg00267.html>. int-area/current/msg00267.html>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006. RFC 4272, January 2006.
Appendix A. Multi-hop GTSM Appendix A. Multi-hop GTSM
NOTE: This is a non-normative part of the specification. NOTE: This is a non-normative part of the specification.
skipping to change at page 14, line 38 skipping to change at page 14, line 40
recipient would check that the TTL is within "TrustRadius" (e.g., 1) recipient would check that the TTL is within "TrustRadius" (e.g., 1)
of 255 instead of 255. As such deployment is expected to have a more of 255 instead of 255. As such deployment is expected to have a more
limited applicability and different security implications, it is not limited applicability and different security implications, it is not
specified in this document. specified in this document.
Appendix B. Changes Since RFC3682 Appendix B. Changes Since RFC3682
o New text on GTSM applicability and use in new and existing o New text on GTSM applicability and use in new and existing
protocols. protocols.
o Restrict the scope to not specify multi-hop scenarios.
o Explicitly require that related messages (e.g., TCP RSTs, ICMP o Explicitly require that related messages (e.g., TCP RSTs, ICMP
errors) must also be sent and checked to have TTL=255. See errors) must also be sent and checked to have TTL=255. See
Section 6.1 for discussion on backwards compatibility. Section 6.1 for discussion on backwards compatibility.
o Clarifications relating to security with tunneling. o Clarifications relating to fragmentation, security with tunneling,
and implications of ingress filtering.
o A significant number of editorial improvements and clarifications. o A significant number of editorial improvements and clarifications.
Appendix C. Draft Changelog Appendix C. Draft Changelog
NOTE to the RFC-editor: please remove this section before NOTE to the RFC-editor: please remove this section before
publication. publication.
Appendix C.1. Changes between -07 and -08 Appendix C.1. Changes between -08 and -09
o Clarify that GTSM may be enabled on existing protocols if the
protocols include a capability negotiation feature and both
parties support GTSM.
o Editorial updates.
Appendix C.2. Changes between -07 and -08
o Describe the assumption of ingress filtering to protect against o Describe the assumption of ingress filtering to protect against
on-link attacks. on-link attacks.
o Rewrite the IP over MPLS section based on the new MPLS TTL o Rewrite the IP over MPLS section based on the new MPLS TTL
handling procedure (from Carlos Pignataro) to get the details of handling procedure (from Carlos Pignataro) to get the details of
new MPLS architecture right. new MPLS architecture right.
o Rephrase IP over IP tunneling section a bit, to make distinction o Rephrase IP over IP tunneling section a bit, to make distinction
between encapsulation and decapsulation behaviour clearer. between encapsulation and decapsulation behavior clearer.
o Make it clearer in the tunneling section that unless the tunnel o Make it clearer in the tunneling section that unless the tunnel
peer is also the protocol peer, GTSM should be able to offer peer is also the protocol peer, GTSM should be able to offer
protection. protection.
o Describe better the applicability of GTSM when tunneling. o Describe better the applicability of GTSM when tunneling.
o Rephrase Multi-hop GTSM section to mainly refer to the difficult- o Rephrase Multi-hop GTSM section to mainly refer to the difficult-
to-quantify security properties as a reason for exclusion at this to-quantify security properties as a reason for exclusion at this
point. point.
o Some editorial updates. o Some editorial updates.
Appendix C.2. Changes between -06 and -07 Appendix C.3. Changes between -06 and -07
o Be more reserved about multi-hop security properties in section o Be more reserved about multi-hop security properties in section
'Multi-Hop Protocol Sessions'. 'Multi-Hop Protocol Sessions'.
o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing o Clarify IP-in-IP tunnel decapsulation/forwarding as decrementing
TTL. TTL.
o Add text on related messages backwards compatibility. o Add text on related messages backwards compatibility.
o Editorial updates. o Editorial updates.
Appendix C.3. Changes between -05 and -06 Appendix C.4. Changes between -05 and -06
o Clarify the assumptions wrt. resource separation and protection o Clarify the assumptions wrt. resource separation and protection
based on comments from Alex Zinin. based on comments from Alex Zinin.
o Rewrite the GTSM procedure based on text from Alex Zinin. o Rewrite the GTSM procedure based on text from Alex Zinin.
o Reduce TrustRadius and multi-hop scenarios to a mention in an o Reduce TrustRadius and multi-hop scenarios to a mention in an
Appendix. Appendix.
o Describe TCP-RST, ICMP error and "related messages" handling. o Describe TCP-RST, ICMP error and "related messages" handling.
skipping to change at page 16, line 28 skipping to change at page 17, line 4
David Meyer David Meyer
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Pekka Savola (editor) Pekka Savola (editor)
Espoo Espoo
Finland Finland
Email: psavola@funet.fi Email: psavola@funet.fi
Carlos Pignataro Carlos Pignataro
Email: cpignata@cisco.com Email: cpignata@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 23 change blocks. 
29 lines changed or deleted 42 lines changed or added

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