Subject: Asymmetric CIDs

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Feb 2018 09:01:13 -0800

Hi folks,

After a bunch of discussion, the CID task force came down to rough
consensus that asymmetric conn IDs were probably the right
direction (CID task force members, please feel free to voice dissent
here). Here's a complete writeup of what I think would be needed
for asymmetric connection IDs. It's not a PR, because I think
something self-contained is cleaner.

Note that if we adopt this direction, we would be sacrificing
public reset under some conditions (see previous emails to the
list) and we would need to decide if it was worth keeping at all.

OVERVIEW
The basic idea is that each side gets to dictate the connection IDs
that are used to send to it. During the handshake, you establish those
CIDs and then each side can issue new CIDs during the connection.  The
main advantage of this is that it allows for symmetric topologies in which
the client is also behind some kind of stateless LB/router rather than
just the server. See Issue #1091 for more info on this.

The overall handshake looks something like this:

Client                                      Server

Initial [CID=XXX] {recv-CID=YYY} ---------------->
<-------------- Cleartext [CID=YYY] {recv-CID=ZZZ}
Cleartext [CID=ZZZ], {recv-CID=YYY} ------------->
<-------------------------- Short header [CID=YYY]
Short header [CID=ZZZ] -------------------------->

The client's initial CID (XXX) is special, and either consists of

    (a) a randomly chosen dummy CID. Proposal: require this to be
        8 bytes or at least a minimum. This should be the same
        for all Initial packets in a connection (unless a stateless
        reject is received, as below).
    (b) a CID which it received from the server in a stateless reject

All the server's packets are sent with the client's receive CID (YYY)
and all subsequent client packets are sent with the server's receive
CID (ZZZ). The general rule is that you should send with the
connection ID that you most recently received (where recently
is defined as highest PN).

Note: I believe it's safe to just use the sending CID as the mixin
for the KDF, but I haven't thought this entirely through yet.

Finally, you can send NEW_CONNECTION_ID in either direction to provide
a new connection ID for the other side to use. The general assumption
is that you can do this at any time, just as with current QUIC, and
that any time you send to a new remote 3-tuple you should change CIDs
if you can. Note that this means that endpoints should try to make
sure that the other side has spare CIDs in case they need to migrate.

WIRE ENCODING
As we discussed in the meeting the short header should just have
an implicit length CID. This gives us the following short header:

   +-+-+-+-+-+-+-+-+
   |0|C|K| Type (5)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     [Connection ID (*)]                       +  <-
change from 64
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Packet Number (8/16/32)                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Protected Payload (*)                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that we may also be able to dispense with the C bit, if each
side just gets to say "send me this CID exactly", why do we want
to say "here is my CID but you can omit it".

We have several options about the long header. The first question
is where recv-CIDs go. In previous versions I suggested putting
them in transport parameters, or elsewhere in the TLS handshake,
and that might still be viable, though it has some drawbacks [0],
so the other alternative is to put both CIDs in in the long header.
This would look something like:

   +-+-+-+-+-+-+-+-+
   |1|   Type (7)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  DCID-Length  |                                               |
   +-+-+-+-+-+-+-+-+   Dst Connection ID (*)                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SCID-Length  |                                               |
   +-+-+-+-+-+-+-+-+   Src Connection ID (*)                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Version (32)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Packet Number (32)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Payload (*)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The semantics here are that the first value is the CID you want to
send to and the second one is the value you want used to send to you
(I've inverted these to keep the order the same as short header).

Two notes about this encoding:

1. I think we agreed that we didn't want arbitrary length CIDs up to
255 bytes, and yet we have room in this length byte. I propose we
limit it to 31 bytes and then grease the remaining 3 bits [1].

2. Because the client sends its CID first, there's no way to get the
current QUIC semantics of the server just dictates the CID.  I propose
we fix that by defining a special sentinel CID (all 1s, all 0s,
whatever) of whatever our maximum length is that means "just use your
own CID".

We can endlessly bikeshed on this structure.

Finally, we will need to update NEW_CONNECTION_ID to allow a variable
length CID. This would look like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Sequence (i)                       ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  CID-Length   |                                               |
   +-+-+-+-+-+-+-+-+       Connection ID (*)                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                   Stateless Reset Token (128)                 +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[0] However, in the transport parameters design, if the server's
handshake gets reordered, the client might need to send some ACKs with
the initial CID. However, we've agreed that the client's IP address
has to be stable, so this isn't a problem. Alternately, you could
change C->S CIDs in the short header if that was easier.

[1] An alternative would be to have a sparse range (e.g., you can
express 0-7 and then 8-22 by 2s, assuming I have counted correctly)
and then we could pack both lengths into a single byte. As I said,
lots of opportunities for bikeshedding here.

---

From: Ian Swett <[email-masked]>
Date: Fri, 16 Feb 2018 12:25:58 -0500

Thanks for the excellent summary EKR.  I like this design and think the
breakage of stateless reset in certain cases is acceptable, since it only
applies if both sides must have their preferred connection ID present in
order to route correctly, which is a use case that's impossible in the
status quo.  I have not come up with any other downsides.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 16 Feb 2018 17:43:27 +0000

Thanks for the write up.

(I thought the CID task force was to discuss CID length and its encoding, but this is much bigger.)

I want to point out that asym CID is sacrificing not only public reset (sometimes) but also the ability to route ICMP (& ICMPv6) Error packets back to the server.

The issue with the proposed short-header encoding is that it makes packet numbers useless for network troubleshooting, since they are located at an unpredictable offset, unless you’ve seen the negotiation and remembered CID lengths for each connection.

P.S.
  The issue # seems incorrect.  Are you referring to issue #745?

From: Eric Rescorla [mailto:[email-masked]]
Sent: Friday, February 16, 2018 12:01 PM
To: IETF QUIC WG <[email-masked]>
Subject: Asymmetric CIDs

Hi folks,

OVERVIEW

Client                                      Server

WIRE ENCODING

   +-+-+-+-+-+-+-+-+
   |0|C|K| Type (5)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     [Connection ID (*)]                       +  <- change from 64
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Packet Number (8/16/32)                ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Protected Payload (*)                   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+
   |1|   Type (7)  |

    0                   1                   2                   3

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Feb 2018 09:49:03 -0800

Thanks for the write-up, some questions in-line.

> for the KDF, but I haven't thought this entirely through yet.

For the client, is this the dummy randomly generated Initial CID?

If not randomly generated appropriately, is there a risk here that the KDF
isn't as strong (see my concern in a previous email)?

> sure that the other side has spare CIDs in case they need to migrate.

Is there any sense in which you can "go back" to a previously used CID, or
are they burned once a new one is used?  The situation I'm thinking of is a
variant of the parking lot problem--if someone goes in and out of range of
a WiFi service for which they have a current DHCP lease, they can alternate
between Cellular and WiFi without actually changing origin IP.  Can they go
back to a previously used CID in that case?  My intuition is that this
should be no, but the implication is that the stack of spare CIDs may need
to be larger as a result; if we did allow it, then the  minimum number of
spare CIDs is a simple function of the number of available network
interfaces.  We could either estimate that and pick a number or ask each
side to state how many spare CIDs they'd prefer (knowing they may get
fewer).

> Well, it's only worth painting if there are bikes coming in. I'm not sure
at this point what having the server dictate both sides of this gives you
in a structure that presumes they are asymmetric.

> length CID. This would look like this:
Ted

---

From: Martin Duke <[email-masked]>
Date: Fri, 16 Feb 2018 09:52:43 -0800

Thanks for writing this up, ekr. This incorporates many of the suggestions
I made in objection to this project (perhaps coincidentally) and I like it
a lot.

Advantages of this:
- In the common case where most of the data is server->client, clients can
get away with shorter Conn IDs to reduce overhead.
- Omit-conn-id just becomes a case where length = 0. Does this sidestep
some of Google's transition issues?
- If a client sends NEW_CONNECTION_ID, that indicates an intention to
migrate, and is a good cue for the server to send the same. We should add a
SHOULD to specify this behavior.

I must be missing something, however, regarding implicit CIDs.

If there's a NAT rebinding, how is the server supposed to extract the CID?
Furthermore, this obviates the entire concept of using Connection ID for
routing; it's not obviously a savings to store CID length in a table vs.
just storing the destination server.

Lastly, if we encode the length somewhere that seems to solve the Stateless
Reset issue.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Feb 2018 08:14:57 -1000

I like the concept, but I would like to understand how we avoid linkability on migration.

-- Christian Huitema 

> On Feb 16, 2018, at 7:52 AM, Martin Duke <[email-masked]> wrote:
> 
> Thanks for writing this up, ekr. This incorporates many of the suggestions I made in objection to this project (perhaps coincidentally) and I like it a lot.
> 
> Advantages of this:
> - In the common case where most of the data is server->client, clients can get away with shorter Conn IDs to reduce overhead.
> - Omit-conn-id just becomes a case where length = 0. Does this sidestep some of Google's transition issues?
> - If a client sends NEW_CONNECTION_ID, that indicates an intention to migrate, and is a good cue for the server to send the same. We should add a SHOULD to specify this behavior.
> 
> If there's a NAT rebinding, how is the server supposed to extract the CID? Furthermore, this obviates the entire concept of using Connection ID for routing; it's not obviously a savings to store CID length in a table vs. just storing the destination server.
> 
> Lastly, if we encode the length somewhere that seems to solve the Stateless Reset issue.
> 
> 
>> Thanks for the excellent summary EKR.  I like this design and think the breakage of stateless reset in certain cases is acceptable, since it only applies if both sides must have their preferred connection ID present in order to route correctly, which is a use case that's impossible in the status quo.  I have not come up with any other downsides.
>>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 16 Feb 2018 18:25:56 +0000

++ what Christian says.
The fact that it now takes two implementations to prevent linkability (either side messes it up, and that half-path is exposed, likely rendering it all exposed) is a bit sad.
-=R

From: QUIC <[email-masked]> on behalf of Christian Huitema <[email-masked]>
Date: Friday, February 16, 2018 at 10:16 AM
To: Martin Duke <[email-masked]>
Cc: Ian Swett <[email-masked]>, IETF QUIC WG <[email-masked]>, Eric Rescorla <[email-masked]>
Subject: Re: Asymmetric CIDs

On Feb 16, 2018, at 7:52 AM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for writing this up, ekr. This incorporates many of the suggestions I made in objection to this project (perhaps coincidentally) and I like it a lot.

Advantages of this:

On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the excellent summary EKR.  I like this design and think the breakage of stateless reset in certain cases is acceptable, since it only applies if both sides must have their preferred connection ID present in order to route correctly, which is a use case that's impossible in the status quo.  I have not come up with any other downsides.

On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

OVERVIEW

Client                                      Server

WIRE ENCODING

   +-+-+-+-+-+-+-+-+
   |0|C|K| Type (5)|

   +-+-+-+-+-+-+-+-+
   |1|   Type (7)  |

    0                   1                   2                   3

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Feb 2018 10:38:55 -0800

> If there's a NAT rebinding, how is the server supposed to extract the CID?

The assumption is that the server either:

(a) always uses the same CID length
(b) has a structured CID which starts with the length.

But that we don't need to mandate which one in the protoocl

> just storing the destination server.

I don't think you hae to do this, but maybe I am confused. See above and
tell me if you think I'm wrong

-Ekr

---

From: Martin Duke <[email-masked]>
Date: Fri, 16 Feb 2018 11:08:14 -0800

That sounds workable to me. Thanks for clarifying. However, if this is the
case then how is Stateless Reset broken?

If a load balancer is encoding different lengths in the CID, that
introduces additional overhead to a LB/Server communication protocol as
I've drafted. It's solvable but annoying.

On Fri, Feb 16, 2018 at 10:38 AM, Eric Rescorla <[email-masked]> wrote:

>> Thanks for writing this up, ekr. This incorporates many of the
>> suggestions I made in objection to this project (perhaps coincidentally)
>> and I like it a lot.
>>
>> Advantages of this:
>> - In the common case where most of the data is server->client, clients
>> can get away with shorter Conn IDs to reduce overhead.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Feb 2018 11:31:41 -0800

> case then how is Stateless Reset broken?

The server knows it's CID (from the offending packet) but doesn't know the
client's CID (because it's statelsss), so when it sends SR, there's a
chance it gets misrouted at the client.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Feb 2018 14:10:04 -0800

To be explicit, I am concerned by the following scenario:

1) Client sends a PATH CHALLENGE to server from a new client address
with never-seen-before connection ID, obtained previously in NEW
CONNECTION ID frame from server

2) Server respond by sending reply to new address with
previously-negotiated-and-used CID of client.

3) Instant linkage.

The key is of course that the server picks a different CID to respond to
the migration, normally in a NEW CONNECTION ID frame.

On 2/16/2018 10:25 AM, Roberto Peon wrote:
>
> ++ what Christian says.
> The fact that it now takes two implementations to prevent linkability
> (either side messes it up, and that half-path is exposed, likely
> rendering it all exposed) is a bit sad.
>
> -=R
>
>  
>
>  
>
> *From: *QUIC <[email-masked]> on behalf of Christian Huitema
> <[email-masked]>
> *Date: *Friday, February 16, 2018 at 10:16 AM
> *To: *Martin Duke <[email-masked]>
> *Cc: *Ian Swett <[email-masked]>, IETF QUIC WG <[email-masked]>,
> Eric Rescorla <[email-masked]>
> *Subject: *Re: Asymmetric CIDs
>
>  
>

---

From: Nick Banks <[email-masked]>
Date: Fri, 16 Feb 2018 22:17:10 +0000

Perhaps the client should send a NEW_CONNECTION_ID with the PATH_CHALLENGE and require the server to use that to respond.

- Nick

From: QUIC <[email-masked]> On Behalf Of Christian Huitema
Sent: Friday, February 16, 2018 2:10 PM
To: Roberto Peon <[email-masked]>; Martin Duke <[email-masked]>
Cc: Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>; Eric Rescorla <[email-masked]>
Subject: Re: Asymmetric CIDs

1) Client sends a PATH CHALLENGE to server from a new client address with never-seen-before connection ID, obtained previously in NEW CONNECTION ID frame from server

2) Server respond by sending reply to new address with previously-negotiated-and-used CID of client.

3) Instant linkage.

The key is of course that the server picks a different CID to respond to the migration, normally in a NEW CONNECTION ID frame.

From: QUIC <[email-masked]><mailto:[email-masked]> on behalf of Christian Huitema <[email-masked]><mailto:[email-masked]>
Date: Friday, February 16, 2018 at 10:16 AM
To: Martin Duke <[email-masked]><mailto:[email-masked]>
Cc: Ian Swett <[email-masked]><mailto:[email-masked]>, IETF QUIC WG <[email-masked]><mailto:[email-masked]>, Eric Rescorla <[email-masked]><mailto:[email-masked]>
Subject: Re: Asymmetric CIDs

---

From: Ian Swett <[email-masked]>
Date: Fri, 16 Feb 2018 17:45:02 -0500

I agree that could be a concern, but I think it's no more difficult to
solve than the status quo.  It just means both sides need to have more
connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases when
other connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm expecting the
connection ID from server to client will be 0 bytes in length, making this
a non-issue.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 16 Feb 2018 22:56:13 +0000

That would make multipath hard/interesting.

I expect non-zero length (-> client) CIDs when multipath is not theoretical.
-=R

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Ian Swett <[email-masked]>
Date: 2/16/18 2:45 PM (GMT-08:00)
To: Nick Banks <[email-masked]>
Cc: huitema <[email-masked]>, Roberto Peon <[email-masked]>, Martin Duke <[email-masked]>, IETF QUIC WG <[email-masked]>, Eric Rescorla <[email-masked]>
Subject: Re: Asymmetric CIDs

I agree that could be a concern, but I think it's no more difficult to solve than the status quo.  It just means both sides need to have more connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases when other connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm expecting the connection ID from server to client will be 0 bytes in length, making this a non-issue.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 16 Feb 2018 16:22:46 -0800

This looks good to me.

Path migration might involve CID validation so a connection shuts down if a
single endpoint messes up linkage.

The stateless reset has been discussed - problem with routing to peer (I
don’t recall if reset can go both ways, but I think is is currently only
server to client ATM) with ACID it would be more relevant to also discuss
opposite reset because the use case would/could be p2p servers.

I think perhaps getting rid of reset would be good. As an alternative a
PATH_CHALLENGE or a PING could be used if one endpoint thinks the other end
is a tad silent. The sub protocol for updating router CID could also be
extended to filter out noisy clients by cancelling a CID that is not in use.

The stateless retry concern has not been discussed in this thread, I
suppose. It is mentioned in the ACID issue:

https://github.com/quicwg/base-drafts/issues/1089

Kind Regards,
Mikkel Fahnøe Jørgensen

On 16 February 2018 at 23.56.35, Roberto Peon ([email-masked]) wrote:

-------- Original message --------
From: Ian Swett <[email-masked]>
Date: 2/16/18 2:45 PM (GMT-08:00)
To: Nick Banks <[email-masked]>
Cc: huitema <[email-masked]>, Roberto Peon <[email-masked]>, Martin Duke
<[email-masked]>, IETF QUIC WG <[email-masked]>, Eric Rescorla <
[email-masked]>
Subject: Re: Asymmetric CIDs

---

From: Christian Huitema <[email-masked]>
Date: Sat, 17 Feb 2018 00:12:02 -0800

On 2/16/2018 4:22 PM, Mikkel Fahnøe Jørgensen wrote:

> This looks good to me.
>
> Path migration might involve CID validation so a connection shuts down
> if a single endpoint messes up linkage.

"Implement migration correctly, or the connection will break on
migration." That may work if the QUIC stack wants to actually make
migration work. And I suppose that a stack that does not care about
migration would simply not provide "NEW CONNECTION ID" in the first
place. If one peer sends data with a CID, the responder needs to also
select a new asymmetric CID in the replies, and must not send a reply if
no such new asymmetric CID is available -- with suitable exception for
0-length CID. This requires that a new asymmetric CID is available, and
as Nick suggested this can be made foolproof by sending a NEW CID frame
in the migration packets.

My point is mostly that iwhen we write the asymmetric CID PR, we must
actually specify the migration behavior.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Feb 2018 11:30:42 +1100

The breakage of a stateless reset is limited.  It is only a problem
for clients that use - and depend on - connection IDs.

A stateless reset will not carry the client-selected connection ID.
It will appear - to the network - to be a change in connection ID.  If
we change connection IDs occasionally for other reasons, then this
won't be a significant problem.

The main problem is in ensuring that the packet arrives at the right
place at the client.  However, it is possible that we can suggest
routing based on address tuple over short timescales at clients.  In
that case, the reset might still arrive at the right place.  That, or
exceptional processing for unrouteable packets.

BTW, I like ekr's idea of making the number space for connection IDs
sparse.  A (short-ish) fixed limit is necessary to ensure that the
stateless reset can be constructed such that it appears plausible and
that means at least overhead + max(connection ID) + AEAD expansion +
an ACK frame.

Would also add the idea of a minimum size for connection IDs.  A one
octet connection ID has awful linkability properties that are pretty
much irredeemable.  You can get 8-22 with single octet steps if you
are willing to make 1-7 invalid.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 19 Feb 2018 11:07:24 -0800

I don’t want to shoot down ACID at all, but if a stateless reset is
intended to be invisible (not sure why? ossification?, hardly replay?) then
it cannot reflect the clients CID because it would light up like a
Christmas tree simply because the CID is the same in both directions,
unless CID’s are somehow encrypted which would be hard for stateless reset.

On the other hand, if the reset is intentionally visible, then peer routers
could attempt to match the reverse routing path, or do some internal
broadcasting find and terminate the relevant destination.

Resets should exponentially back off, but that binds state which could be
exploited to a degree.

Resets could enter a strange ping pong pattern, especially when not routed
correctly: B sends reset to A, A does not understand reset and sends a
reset to B to silence A, which in turn sends a reset to A.

A and B is cluster, so there could be many endpoint in each so back-off
would not kick in.

As I said before, I’d prefer clients to stop sending when peer is not
responding. If a reset is to work, the other end needs to cooperate anyway.
Routers could drop packets of unwanted CID’s. This would also handle cases
where peer receives packets and ACK’s but the return path is broken
(eventually timeout will kill, but it could happen faster with a challenge).

Kind Regards,
Mikkel Fahnøe Jørgensen

On 19 February 2018 at 01.30.50, Martin Thomson ([email-masked])
wrote:

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Feb 2018 15:56:28 +0900

2018-02-17 7:45 GMT+09:00 Ian Swett <[email-masked]>:
> I agree that could be a concern, but I think it's no more difficult to solve
> than the status quo.  It just means both sides need to have more connection
> IDs, not just one side.
>

Another approach will be to use the first N octets of the stateless
reset token (provided by the server) as the connection ID.

For example, if the stateless reset token is 00 01 02 03 04 ... 7f,
and if the length of the CID is 4 octets, the server will use 00 01 02
03 as the CID and 04..7f as the payload of a stateless reset.

> connection ID from server to client will be 0 bytes in length, making this a
> non-issue.

Agreed.

-- 
Kazuho Oku