Draft: draft-ietf-quic-transport

Commentary: First cut at this , sorry about it being so long . It 's fairly hard to write this , particularly since the existing documentation is so sparse . Hopefully this is clear enough . I have n't had time to properly proof - read it , so it 's probably not very good . But I thought I 'd share what I got . This includes some basic countermeasures , but they are n't very good . I think that 's OK , but we should discuss . 
 I like the general text . I am worried that the response to these attacks may need to evolve over time as we understand them better . I was looking at ways to say that . No specific suggestion yet . 
 ~This has been around for a week now and I 've heard no serious concerns but a fair bit of support . I 'm marking this proposal - ready.~ Gah ! This is the PR :-/ The issue 's already been marked :-) 
 A server might be able to control 0 - RTT content , but it ca n't control 0 - RTT keys because those are derived from the ClientHello , which includes a nonce value the server ca n't predict ( ) . I note here that this is true for our TLS integration , but might not be true for other cryptographic handshakes . 
 Thanks . Of course you are correct . I was only think about Early Secret , a value that can be estimated by the server . But in this case , it is clientearlytraffic_secret that matters , and that incorporates ClientHello . 
 Server - side request forgery ( SSRF ) is an attack technique where a malicious server takes advantage of a client that is in a privileged location of the network to attack unprotected servers from the client location . This relies on there being a server that has no protections at all . This server takes actions without authenticating the requester . That is , the server assumes that because the request reached it , the request was authorized . These servers are often deployed with the assumption that access to the network is tightly controlled and so rely on that access control alone . Historically , these servers were very common in enterprise networks , but that is no longer best practice . It is . however , still common to find services deployed on loopback addresses that fail to properly authenticate requests . A simple example exploits bugs in URL parsing of clients to embed messages . The attacker asks the client to navigate to . The client connects to the IP address , ignoring the junk , but includes all of the junk in the TLS Server Name Indication ( SNI ) field it sends . As a result , data that is controlled by the attacker is sent in the clear to the vulnerable server . For this style of attack , the trick is finding a server that will read past the TLS junk that precedes the instruction to find and execute the instruction . And do n't laugh , ( that paper describes a form of SSRF as well , but the victim was a middlebox ) . With TLS ( and presumably DTLS ) , is also possible to use or session tickets to the same end , without relying on bugs in the client . SSRF often does n't produce any feedback directly to the attacker , but it can be used to establish control over the vulnerable host , which might lead to opening communication channels . From the protocol side , the key enablers for SSRF are mechanisms that allow an endpoint to control the destination address and part of the ( unencrypted ) content of messages sent by a peer . So what opportunities are there for SSRF in QUIC ? With some exceptions , QUIC offers few options for an adversary to send to a destination address that does not understand QUIC . As far as controlling the content of messages goes , Initial protection using the client - chosen Destination Connection ID is pretty effective , but the same does not apply to other messages . The fact that this is an encrypted protocol does n't help as much as you would like , thanks to use of XOR - based stream ciphers . That means we need to examine the cases where destinations can be controlled , as those are where QUIC is most vulnerable . The destination for the very first Initial packets from a client is open to server control . An attacker can , through control over the IP addresses returned by DNS or    , affect where connection attempts go . Once a connection is established , address validation is used to ensure that a target address is willing to communicate . However , address validation requires that some packets be sent to an address prior to validating it . As migration is currently only possible for a client , this means we need to consider the potential for clients to mount this style of attack using a server . This requires source address spoofing to fake a connection migration . As servers are not permitted to initiate migration , preferred address is the only way that a server can cause a client to send any other type of packet to an address that it does not control . For a completely new connection , we can assume that the victim does n't support QUIC and does not respond with valid QUIC messages . Therefore , it is safe to assume that the client wo n't send any other type of message other than Initial in cases other than when it migrates to a preferred address . For content , the most obvious fields are the Destination Connection ID in every packet and the Token field of Initial packets . Use of encryption for Initial messages and the randomized destination connection ID ensures that a server controls none of the message plaintext for Initial messages . This means that Initial messages are mostly safe . The exception here is the Token field , which is server controlled . Encryption does n't help a great deal . As the attacker has encryption keys and we use ciphers that are effectively stream ciphers , an attacker has a reasonable chance of predicting how encryption will transform a large proportion of packets . An attacker that can control the content of frames and can predict the packet number that is used can therefore provide content that encrypts to ciphertext of its choosing . This relies on being able to predict frame placement , but implementations are fairly consistent and so are expected to be somewhat predictable . Browsers in particular offer a number of ways for adversaries to control client behavior . Similarly , servers often allow clients to create or alter content in ways that might be suited to this style of exploitation . As altering content seems to be broadly feasible , our primary focus needs to be on those cases where packets are sent to an address that has not been validated . This leaves three avenues to explore more : preferred address , address validation tokens in Initial packets , and spoofed migrations by a client . The preferred address is a pretty good SSRF enabler . The entire point is to enable server specify an address , so controlling destination is trivial . For content , we only have short headers as a client can not migrate prior to confirming the handshake , after which we only use packets with short headers . The effect is that a client will send a UDP datagram containing one uncontrolled byte ( this is in the range that includes all ASCII alphabet characters ) and then up to 20 attacker - controlled bytes to a destination of the attacker 's choice . The remainder of the datagram can not be directly controlled by the attacker . However , the attacker has encryption keys and can probably predict the packet number . Therefore , if it can control the content of frames , it has an opportunity to affect what appears in the encrypted datagram . Thus we need to consider what might be included in this packet . If we look at probing frames , the packet likely contains PATHCHALLENGE , which is explicitly not controlled . Other likely candidates for inclusion in this packet are the other probing frames ( PADDING , NEWCONNECTIONID , and maybe PATHRESPONSE ) , which offer an attacker limited options for control , even if frame composition is attacker controlled . We can also assume here that the attacker is unable to effectively control the encoded packet number , so it would have to work around those bytes . Frames that carry application data ( STREAM or DATAGRAM ) are definitely more open to control . In some settings ( browsers in particular ) the contents of these frames might be controlled by the attacker . Therefore , frames carrying application data offer the attacker the means of indirectly controlling large portions of plaintext . This only depends on being able to predict packet numbers and to know the likely placement of frames in the packet , both of which have to be regarded as easy . That said , if clients refuse to migrate to a preferred address without first validating it , this option will not be useful to an attacker . NEWTOKEN provides a server with some ability to control both destination and content . The attacker can alter DNS records or use    to select a target . The server has less control over the Initial packet generally , but the token is only limited in length by the size of the packets that carry it , so it provides a lot more space to play with than a connection ID . There is a little more uncontrolled junk ( at least 16 bytes ) ahead of the token than with preferred address . That junk is not likely to be a major barrier , especially with the extra space on offer . The TLS attacks mentioned above deal with more than twice this amount of junk . Retry also provides an opportunity as the server selects the connection ID and token . As the server is unable to change the IP address the client uses after a Retry , Retry can not be used to select a target . ( As an aside for Retry , controlling the connection ID provides control over the Initial encryption keys . In theory , this removes the defense offered by Initial protection as the server can choose connection IDs until encryption produces the content it desires . As the client is required to use the same CRYPTO frames , the attacker only has to iterate through values until it gets what it wants . However , this control is limited to a small number of bytes as the cost increases exponentially with the number of bits that the server wishes to control . Using the Token field is considerably easier . ) This case is the inverse of SSRF in that it is the client that performs the attack with the goal of using the privileged position of the server . To mount the attack , the client needs to inject its payload into a connection ID and then spoof its source address to match the intended target . All of these cases can be exploited without observable effect . Packets are sent as part of an existing connection that continues to operate normally , or packets are sent as part of a connection establishment that is performed while another connection remains active ( assuming that NEWTOKEN is used with    and not DNS targeting ; DNS targeting could be more obvious ) . This means that the exploits have no natural pressures that force them to be exposed . The victim might notice if the attacker has to try many times to be successful or the endpoint that is mounting the attack might notice unusual activity , but only if there are measures in place to look for an attack . Both preferred address and NEWTOKEN do require that new connections be established , which might limit the rate at which an attacker can retry the attack . Spoofing addresses is not limited in the same way . If the same connection ID is used , then the attack is limited only by the rate at which the server is willing to use the address ( or addresses ) . Yes , we should care . Though it takes a horribly insecure configuration to be vulnerable to this sort of attack , that does not mean attacks wo n't happen or that clients or the IETF wo n't be held responsible . See also the law of the internet : blame attaches to the last thing that changed . Browsers are very careful in defending against this style of attack . CORS is a horrible tax that every cross origin request pays for this . That does n't mean that only browsers need to worry about defenses . There are a lot of deployments that understand this attack well and have deployed defenses for TCP . These likely include a suite of patterns that can be used to identify and defend against known attacks . The risk with QUIC is that these defenses are less mature or non - existent for UDP . This analysis assumes that removing any of these features that might be exploited this way is not desirable . It further assumes that adding new mechanisms , particularly those that might degrade performance , is not tenable . These problems might be worth doing something about , but they are still largely the fault of servers that act on unauthenticated instructions . It should not be entirely up to QUIC to address these concerns . Anything that makes QUIC substantially worse to protect such servers is not worth considering . For instance , control over cleartext could be achieved using . Requiring additional round trips for address validation might help narrow the options for attack . However , both would likely adversely affect performance . That does n't mean doing absolutely nothing , as that would not be responsible . For NEWTOKEN , we have a mitigation that seems pretty effective : do n't send the token . As the protocol does not depend on successful use of a token , we can simply recommend that clients not include a token in Initial packets when the server address changes . We might allow heuristics so that tokens can be used when the server addresses stays within the same subnet ( of unspecified size ) or same AS or something along those lines . That should retain most of the value of the mechanism without dramatically increasing exposure . Even if heuristics are used , this would require that the attacker be adjacent to the victim , which should be effective in blunting the attack . seems like the best countermeasure for attacks that use client address spoofing . Assuming that the attacker is n't in the same network , ingress filtering will easily prevent this attack . Aiming to prevent control over the cleartext of packets is difficult and likely to be ineffective . Spoofing can be made to look like NAT rebinding . Insisting on address validation prior to validating the address is an undesirable imposition that will affect performance pretty badly relative to just making a new connection . If we assume the use of ingress filtering where there are servers that might be vulnerable , it should not be necessary to require address validation . For spoofing , we could recommend that implementations not send toward an address that has failed address validation for some period . This will limit the rate at which spoofing might be used . Unfortunately , there does n't appear to be a single crisp thing we can recommend for preferred addresses . One possible option we have is to prohibit the use of preferred address to elevate privileges . That is , prevent a server from picking a preferred address from a portion of the network that might have different protections . ( Does anyone remember Microsoft 's concept of Zones from Internet Explorer days ? ) How we identify this elevation becomes challenging though , and it is not always clear that an apparent " elevation " is truly illegitimate . We might advise clients to avoid preferred addresses that go from an apparently public IP to a link - local or 1918 address , but that sort of restriction could affect real use cases in ways that we do n't want . To give a concrete example , an ISP might operate their network in a private address range and use NAT for traffic that leaves the network . A server that is hosted inside that network might be reachable using a public address ( which might be unicast ) , but it could offer clients a more direct connection using the preferred address mechanism that includes a private address . Prohibiting use of loopback ( 127.0.01 or : :1 ) preferred addresses from non - loopback servers seems like it might be safe , but that too might preemptively exclude valid uses . I do n't have any such use case right now , so it seems like this is a reasonable recommendation . People who might eventually discover a use case will need to deal with that recommendation . You might consider sending a garbage long header packet prior to address validation , but that does n't really change the dynamics much . A long header adds 5 more bytes ahead of the attacker - controlled connection ID . That might make it marginally harder to exploit , but it 's not enough of an improvement to justify recommending it . We can prohibit the sending of non - probing frames to a preferred address prior to address validation . That 's a pretty big change , but I think that it is reasonable given the attack . That reduces the amount of controlled cleartext to the connection ID , not the majority of the packet . Restricting to non - probing frames adds a performance hit if a client is forced to migrate before acting on a preferred address , but that seems like a tolerable loss . This seems like a lot . I 've certainly written a lot of words . But I think that the attack is not that serious . The protections we might deploy for two of the three attacks are n't that onerous , and we can do a little bit to mitigate risk for preferred addresses . The important thing here is to ensure that we document the risks . This is one of those areas where building a protocol on top of UDP exposes new operational risks . I 'm proposing that we simply document the risks and add some small mitigations provided that they do n't cost much . I 'll propose a PR with that proposal . 
 Interesting . In the issue you mention loopback but then goes on to use a local router address . I was thinking loopback was on the clients machine . It is often the case that documentation servers run on localhost to display content , and some applications may be written to either directly use a browser interface , or indirectly via electron , to a locally hosted server . These type of applications are generally not hardened and therefore comparatively easy to exploit . In the worst case , such applications insist on running on port 80 or some other privileged port , thereby having elevated permissions . But , how does this new attack differ from a HTTP redirect from a random web server , where part of the url is designed til trigger a vulnerability ? I can see some level of same domain protection for HTTPS , but as far as I am aware , such protections do not apply to redirects . EDIT : Or does CORS cover that ? No matter how often I read about CORS , it never sinks in ... 
 Thank you for raising the issue . I agree that NEWTOKEN tokens and SPA are concerning . At the same time , I am not sure how much we have to worry about the encrypted payload being used as the attack vector . 1 - RTT packet protection key that is being used for encrypting the frames is not controlled by the attacker . The key is derived from the input of both endpoints . I am not sure how practical it would be to assume that a rouge server can calculate what the corresponding plaintext would be for an encrypted text that it wants to use for the attack , when the encryption keys are not obtained until the handshake is performed . Regarding the amount of effort we should be spending to address this issue , I would point out that SSRF as we know today can induce a browser to send two types of TCP messages : 1 ) HTTP GET request ( or preflight ) , 2 ) first flight of TLS over TCP . I think we can call close the issue if we can make certain that the QUIC packets that the browsers send is as controlled as either of the two patterns . Encrypted data meets the 2nd requirement . QUIC Initial packets are roughly as random and as binary as   of TLS over TCP . Encrypted part of QUIC packets are random and as binary as 0 - RTT records of TLS over TCP . Therefore , I think what we need to discuss is limited to NEWTOKEN tokens and the DCID of SPA . 
 PS . My bad , I think I missed the fact that we are using CTR mode for encryption . Yes , the server can control the bits that are sent by the client . 
 Yes , loopback is same host . But local router addresses ( the example was just an address from a private address range ) , are also potentially vulnerable . Yes , but those servers rarely take instructions that have any real consequence , so they do n't tend to be exploitable . That 's not uniformly true of course . Privileged ports can mean that the process serving that port is privileged , yes . But it does n't have to mean that . Of course , if it is , then it can potentially do a lot of harm . One thing with HTTP is that we do n't really protect against this sort of thing very well . Mostly because the Internet and Web grew up together and people more or less assumed at first that this sort of thing was OK . So we generally allow attackers to make requests over HTTP . But it 's only a subset of requests that are designated as " safe " . Later , as we realized that some of the HTTP stuff was dangerous we CORS . For those things we believe to be " dangerous " , CORS effectively does the same thing that address validation does for QUIC : it checks whether the server is willing to accept a request using a " safe " check ( an OPTIONS request which includes minimal attacker controlled content ) before it makes any request with any of the " dangerous " content that might be controlled by an attacker . Of course , we would love not to have to do CORS . It 's a horrible waste when most servers do n't suffer from these problems to spend a whole round trip negotiating its use . The CSRF paper mentioned in the pull request is the one that basically started all of this . It 's fairly accessible if you are interested in learning more . 
 thanks for elaborating . On local document servers : their parsers might not be hardened since it is " just local " and bad input , e.g. url 512 characters might lead to a crash leading to arbitrary code execution . On privileged ports , yes , it is good praxis to not serve requests with privileged permissions . 
 Bringing this to the issue as well , since it 's not directly a comment on the text of the PR . It 's perhaps a bit of a nuclear option , but if we 're concerned about the peer being able to control the ciphertext by predicting the input plaintext , there seem to be some options for introducing entropy there : Require the inclusion of a PATH_CHALLENGE frame ( with its unpredictable data ) in any packets we 're concerned about ; comparable to the PR 's recommendation to send probing frames only until the path is validated . Change our encryption model to append a certain amount of entropy before encrypting and drop those bytes after decrypting Additionally , an implementation could deliberately break large CRYPTO / STREAM frames into smaller chunks and then randomize the order of frames within the packet . That 's not a protocol change , but would make the packet ciphertext unpredictable even given an attacker who can predict what you will send in those frames . I do n't claim to have any specialty in cryptography , so I 'd be happy ( but also disappointed ) to learn why those do n't actually keep the attacker from potentially controlling the ciphertext . 
 Adding PATH_CHALLENGE just adds a few unpredictable bytes , it does n't really address the problem of control . For that , you need something like the masking in websockets . The problem with something like masking is that it adds a fixed overhead to packets because you need to tell the recipient what the unpredictable stuff was and the size is determined by the number of attempts you might allow ( see below ) . Maybe that only applies to packets that are sent prior to address validation , so maybe you could repurpose one of the long header packet types ( 0 - RTT ? ) to carry a masked payload in those cases , but it 's a massive change . I do n't even want to think about making that sort of change right now ... The refragmenting idea is interesting . The analysis supports the view that it is unnecessary for CRYPTO . It might be too much work otherwise as well . Skipping a random offset for STREAM frames might work , but you have to work through all the ways that an adversary might try to game out whatever strategy you adopt . You need to ensure that the number of potential variations is at least the square of the number of attempts that an attacker might have ( if you have 100 attempts , that 's a minimum of 10,000 variations ) or you hit the birthday bound and attacks become feasible in the aggregate . Getting variations that high is n't necessarily that easy . I 'm not sure if it is worthwhile chasing that down . 
 I tend to agree with what says . Among those two alternatives , masking ( or re - encoding ) might be a better solution . But as I stated on the mailing list , that does not need to happen now . We can wait and see if that 's necessary , and if it turns out to be , define an extension for that purpose . 
 Ah , I missed that we 're dealing with stream ciphers , so you ca n't rely on a few unpredictable bytes on the input to scramble the entire output . That does reduce the effectiveness of both ideas . 
 There is discussion here and on the list , this is clearly a design issue and passes the bar of raising some legitimate security concern . 
 Thank you for all the efforts that have gone into this PR . Rereading it , I wonder if we should be talking about 0 - RTT too , I think that 0 - RTT can be also used as an attack vector . The attacker has the knowledge regarding the packet protection keys that will be used for 0 - RTT , and it is easy to guess what packet number will be used . Based on that , much like NEWTOKEN tokens , I think it might be the case that we have to recommend to not _ use 0 - RTT when the client resumes a connection to a different server address . I'm concerned about this new SHOULD NOT , but maybe I 'm misunderstanding it ?
Paragraph (version B):
A client that migrates to a preferred address MUST validate the
address it chooses before migrating; see forgery-spa.
Paragraph (version B):
A request forgery attack occurs where an endpoint causes its peer to
issue a request towards a victim, with the request controlled by the
endpoint.  Request forgery attacks aim to provide an attacker with
access to capabilities of its peer that might otherwise be
unavailable to the attacker.  For a networking protocol, a request
forgery attack is often used to exploit any implicit authorization
conferred on the peer by the victim due to the peer's location in the
network.
Paragraph (version B):
For request forgery to be effective, an attacker needs to be able to
influence what packets the peer sends and where these packets are
sent.  If an attacker can target a vulnerable service with a
controlled payload, that service might perform actions that are
attributed to the attacker's peer, but decided by the attacker.
Paragraph (version B):
For example, cross-site request forgery CSRF exploits on the Web
cause a client to issue requests that include authorization cookies
COOKIE, allowing one site access to information and actions that are
intended to be restricted to a different site.
Paragraph (version B):
As QUIC runs over UDP, the primary attack modality of concern is one
where an attacker can select the address to which its peer sends UDP
datagrams and can control some of the unprotected content of those
packets.  As much of the data sent by QUIC endpoints is protected,
this includes control over ciphertext.  An attack is successful if an
attacker can cause a peer to send a UDP datagram to a host that will
perform some action based on content in the datagram.
Paragraph (version B):
This section discusses ways in which QUIC might be used for request
forgery attacks.
Paragraph (version B):
This section also describes limited countermeasures that can be
implemented by QUIC endpoints.  These mitigations can be employed
unilaterally by a QUIC implementation or deployment, without
potential targets for request forgery attacks taking action.  However
these countermeasures could be insufficient if UDP-based services do
not properly authorize requests.
Paragraph (version B):
Outside of the encrypted portion of packets, QUIC offers an endpoint
several options for controlling the content of UDP datagrams that its
peer sends.  The Destination Connection ID field offers direct
control over bytes that appear early in packets sent by the peer; see
connection-id.  The Token field in Initial packets offers a server
control over other bytes of Initial packets; see packet-initial.
Paragraph (version B):
There are no measures in this version of QUIC to prevent indirect
control over the encrypted portions of packets.  It is necessary to
assume that endpoints are able to control the contents of frames that
a peer sends, especially those frames that convey application data,
such as STREAM frames.  Though this depends to some degree on details
of the application protocol, some control is possible in many
protocol usage contexts.  As the attacker has access to packet
protection keys, they are likely to be capable of predicting how a
peer will encrypt future packets.  Successful control over datagram
content then only requires that the attacker be able to predict the
packet number and placement of frames in packets with some amount of
reliability.
Paragraph (version B):
This section assumes that limiting control over datagram content is
not feasible.  The focus of the mitigations in subsequent sections is
on limiting the ways in which datagrams that are sent prior to
address validation can be used for request forgery.
Paragraph (version B):
An attacker acting as a server can choose the IP address and port on
which it advertises its availability, so Initial packets from clients
are assumed to be available for use in this sort of attack.  The
address validation implicit in the handshake ensures that - for a new
connection - a client will not send other types of packet to a
destination that does not understand QUIC or is not willing to accept
a QUIC connection.
Paragraph (version B):
Initial packet protection (Section 5.2 of QUIC-TLS) makes it
difficult for servers to control the content of Initial packets sent
by clients.  A client choosing an unpredictable Destination
Connection ID ensures that servers are unable to control any of the
encrypted portion of Initial packets from clients.
Paragraph (version B):
However, the Token field is open to server control and does allow a
server to use clients to mount request forgery attacks.  Use of
tokens provided with the NEW_TOKEN frame (validate-future) offers the
only option for request forgery during connection establishment.
Paragraph (version B):
Clients however are not obligated to use the NEW_TOKEN frame.
Request forgery attacks that rely on the Token field can be avoided
if clients send an empty Token field when the server address has
changed from when the NEW_TOKEN frame was received.
Paragraph (version B):
Sending a Retry packet (packet-retry) offers a server the option to
change the Token field.  After sending a Retry, the server can also
control the Destination Connection ID field of subsequent Initial
packets from the client.  This also might allow indirect control over
the encrypted content of Initial packets.  However, the exchange of a
Retry packet validates the server's address, thereby preventing the
use of subsequent Initial packets for request forgery.
Paragraph (version B):
Servers can specify a preferred address, which clients then migrate
to after confirming the handshake; see preferred-address.  The
Destination Connection ID field of packets that the client sends to a
preferred address can be used for request forgery.
Paragraph (version B):
A client MUST NOT send non-probing frames to a preferred address
prior to validating that address; see address-validation.  This
greatly reduces the options that a server has to control the
encrypted portion of datagrams.
Paragraph (version B):
Clients are able to present a spoofed source address as part of an
apparent connection migration to cause a server to send datagrams to
that address.
Paragraph (version B):
The Destination Connection ID field in any packets that a server
subsequently sends to this spoofed address can be used for request
forgery.  A client might also be able to influence the ciphertext.
Paragraph (version B):
A server that only sends probing packets (probing) to an address
prior to address validation provides an attacker with only limited
control over the encrypted portion of datagrams.  However,
particularly for NAT rebinding, this can adversely affect
performance.  If the server sends frames carrying application data,
an attacker might be able to control most of the content of
datagrams.
Paragraph (version B):
This document does not offer specific countermeasures that can be
implemented by endpoints aside from the generic measures described in
forgery-generic.  However, countermeasures for address spoofing at
the network level, in particular ingress filtering BCP38, are
especially effective against attacks that use spoofing and originate
from an external network.
Paragraph (version B):
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 others steps that QUIC
endpoints could take unilaterally.  These additional steps are all
discretionary as, depending on circumstances, they could interfere
with or prevent legitimate uses.
Paragraph (version B):
Similarly, endpoints could regard a change in address to 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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.