target = "https://www.rfc-editor.org/rfc/rfc9000#section-21.5.6"

# 21.5.6.  Generic Request Forgery Countermeasures
#
# The most effective defense against request forgery attacks is to
# modify vulnerable services to use strong authentication.  However,
# this is not always something that is within the control of a QUIC
# deployment.  This section outlines some other steps that QUIC
# endpoints could take unilaterally.  These additional steps are all
# discretionary because, depending on circumstances, they could
# interfere with or prevent legitimate uses.
# 
# Services offered over loopback interfaces often lack proper
# authentication.  Endpoints MAY prevent connection attempts or
# migration to a loopback address.  Endpoints SHOULD NOT allow
# connections or migration to a loopback address if the same service
# was previously available at a different interface or if the address
# was provided by a service at a non-loopback address.  Endpoints that
# depend on these capabilities could offer an option to disable these
# protections.
# 
# Similarly, endpoints could regard a change in address to a link-local
# address [RFC4291] or an address in a private-use range [RFC1918] from
# a global, unique-local [RFC4193], or non-private address as a
# potential attempt at request forgery.  Endpoints could refuse to use
# these addresses entirely, but that carries a significant risk of
# interfering with legitimate uses.  Endpoints SHOULD NOT refuse to use
# an address unless they have specific knowledge about the network
# indicating that sending datagrams to unvalidated addresses in a given
# range is not safe.
# 
# Endpoints MAY choose to reduce the risk of request forgery by not
# including values from NEW_TOKEN frames in Initial packets or by only
# sending probing frames in packets prior to completing address
# validation.  Note that this does not prevent an attacker from using
# the Destination Connection ID field for an attack.
# 
# Endpoints are not expected to have specific information about the
# location of servers that could be vulnerable targets of a request
# forgery attack.  However, it might be possible over time to identify
# specific UDP ports that are common targets of attacks or particular
# patterns in datagrams that are used for attacks.  Endpoints MAY
# choose to avoid sending datagrams to these ports or not send
# datagrams that match these patterns prior to validating the
# destination address.  Endpoints MAY retire connection IDs containing
# patterns known to be problematic without using them.
# 
#    |  Note: Modifying endpoints to apply these protections is more
#    |  efficient than deploying network-based protections, as
#    |  endpoints do not need to perform any additional processing when
#    |  sending to an address that has been validated.

[[spec]]
level = "MAY"
quote = '''
Endpoints MAY prevent connection attempts or
migration to a loopback address.
'''

[[spec]]
level = "SHOULD"
quote = '''
Endpoints SHOULD NOT allow
connections or migration to a loopback address if the same service
was previously available at a different interface or if the address
was provided by a service at a non-loopback address.
'''

[[spec]]
level = "SHOULD"
quote = '''
Endpoints SHOULD NOT refuse to use
an address unless they have specific knowledge about the network
indicating that sending datagrams to unvalidated addresses in a given
range is not safe.
'''

[[spec]]
level = "MAY"
quote = '''
Endpoints MAY choose to reduce the risk of request forgery by not
including values from NEW_TOKEN frames in Initial packets or by only
sending probing frames in packets prior to completing address
validation.
'''

[[spec]]
level = "MAY"
quote = '''
Endpoints MAY
choose to avoid sending datagrams to these ports or not send
datagrams that match these patterns prior to validating the
destination address.
'''

[[spec]]
level = "MAY"
quote = '''
Endpoints MAY retire connection IDs containing
patterns known to be problematic without using them.
'''