Re: [QUIC] about draft-hamilton-quic-transport-protocol-00

Hi Marcelo,

Thank you again for your really careful and deep dive in to the spec!
Responses for rest of the comments inline:

Section 4.2.2 on Proof of Source Address Ownership.
>
> I understand that the STK provides less protection than a reachability
> check at the beginning of each connection, correct?
>

The STK provides proof of IP ownsership. A client includes the source
address token (which was issued by the server to it in a previous
connection) to demonstrate ownership of it's IP address. If the client has
moved to a different IP address, if the token is too old, or if the client
doesn’t have a token, then the server rejects the connection and issues a
fresh token to the client. This is very similar to TFO's cookie, as the
draft notes.

I mean, the STK proves that the client was once in that location and it can
> later leave the location and because it still has the STK, it can, by
> spoofing the source address, pretend to still be there, since only the STK
> is enough to pass this test.
>
> This means that for instance, an attacker can download a large file by
> simply sending paced ACKs to any location it once was (given that the PSN
> initial number is always 0, it doesnt even needs to guess the PSNs),
> correct?
>
> Maybe this is acceptable, but maybe it is worthwhile stating it in the
> security considerations section?
>

Yes, this is a legitimate attack vector. I'll note (also in the draft) that
there are two simple mitigations. I've added the following text in Security
Considerations. Make sense?
"
Spoofed Ack Attack

An attacker steals the victim's STK, spoofs the victim's IP, and initiates
a 0-RTT connection with a server on the victim's behalf. The attacker then
spoofs ack packets to the server which cause the server to potentially
drown the victim in data.

There are two possible mitigations to this attack. The simplest one is that
a server can unilaterally create a gap in the PSN space. In the non-attack
scenario, the client will send back NACKs for the PSNs in the gap, but the
server will eventually send a STOP_WAITING frame for those packets. In the
attack scenario, the attacker may ack a packet in the gap. If the server
sees an ack for a packet that was never sent, the connection can be aborted.

The second mitigation is that the server can require that acks for sent
packets match the encryption level of the sent packet. This mitigation is
useful if the connection has an ephemeral forward-secure key that is
generated and used for every new connection. If a packet sent is encrypted
with a forward-secure key, then any acks that are received for them must
also be forward-secure encrypted. Since the attacker will not have the
forward secure key, the attacker will not be able to generate
forward-secure encrypted ack packets.
"

Section 4.2.3 on Crypto Handshake Protocol features
>
> In the bullet about Connection establishment in 0-RTT, it requires 0-RTT
> connection establishment for subsequent connections between the same two
> endpoints, in the subsequent connections, the client and server roles must
> be preserved or they can be changed?

I mean, suppose that host A initiates a quic connection to host b. Does
> this condition requires that a future connection (with the same ports)
> initiated from host b to host A should be established in 0-RTT?
>
> I think this should be made explicitly because mixed with the STK, I
> believe it changes the threat model significantly.
>

The presumption certainly was that the roles are preserved. With QUIC's
current (non-TLS) crypto handshake, there are very clear roles, and I
believe that TLS also has a clear expectation of client/server roles. That
said, I think this consideration belongs in either the TLS mapping document
(or in TLS itself) since that document should handle any threat models that
arise from it's 0-RTT implementation with an STK and/or TFO cookie. Is
there any clarification that you think might be useful to add to the crypto
handshake requirements section?

> Nit: the paragraph on the bullet on Server Config Update is truncated.
>

Removed the truncated sentence -- thanks!

Section 5.1 on Life of a stream.
>
> It states that quic accommodates the possibility of out-of-order delivery.
> Do you mean out of order delivery within the same stream or across streams?
> clarify?
>

Across streams. I've changed the text to: "the possibility of out-of-order
delivery due to the use of multiple streams in QUIC"

I understand that the creation of a stream is very lightweight and a new
> stream is established by simply data with a new stream id, correct?
>

Correct.

> I also understand that the initial stream sequence number is always 0,
> correct? (I mean, the offset of the current data to the beginning of the
> streams is included, and the initial packet has offset 0).
>

Correct.

> So, similar to the question i posed about the initial PSN, how does quic
> prevent old packets to reappear and be confused as being part of the new
> stream while they were part of an older stream? It cannot be done using the
> offset, since for all connection it starts in 0. I guess it could be done
> using the PSN, but then the receiver needs to check that all PSN of packets
> for a new stream are higher than the PSN of the packet that terminated the
> older stream, is this the proposed approach?

Probably it is worthwhile clarifying what are the means that quic deals
> with old packets re emerging after the connection/stream has ended, given
> that it does not relies on the sequence number to do so, afaict.
>

Within the connection, the Section 5.2 says " A QUIC endpoint MUST NOT
reuse a StreamID on a given connection," so such STREAM frames will be
considered duplicates. Do you think this can be clarified better somewhere?

> In particular, in section 5.1.1 it states that a stream is open by sending
> or receiving a data packet with that particular stream ID. I assume that
> the data packet MUST contain a 0 offset to create the new stream? is this
> correct?
>

Not necessarily, since the packet containing a STREAM frame with a 0 offset
may have been dropped in the network. A STREAM frame with an offset > 0 may
be accepted, but the data will not get delivered to the application until
the intiial gap within the stream is filled.

Section 5.2 on Stream Identifiers.
>
> I guess you should reserve a range of identifiers for future use, in case
> other "special" streams are needed in the future?
>

I'm not sure what the point of reserving any  would be, since if a special
stream is needed in the future, this usage can be negotiated with either an
option or with a version change.

Section 5.4 on Sending and Receiving data.
>
> Is the initial offset for the data packet sent on a stream set to zero? If
> this is the case, would be good to state it.
>

I've added this sentence: "The first byte of data that is sent on a stream
has the stream offset 0."

Section 6. on Packetization and reliability. What is the initial PSN in a
> given connection? State it explicitly.
>

Added "The initial PSN used, at both the client and the server, MUST be 0.
That is, the first packet in both directions of the connection MUST have a
PSN of 0."

> It is stated that a sender MAY wait for a short period of time to bundle
> multiple frames. I guess it would be useful to provide guidance on what you
> consider a short period of time. Is that 500ms as in the delayed acks or
> are you thinking much less?
>

MUCH less. This is definitely a MAY, and I am not sure if recommending
something here makes sense, since the expectations in any deployment will
be different about how much waiting makes sense. How's the following: "An
implementation may use heuristics about expected application sending
behavior to determine whether and for how long to wait. This waiting period
is an implementation decision, and an implementation should be careful to
delay conservatively, since any delay is likely to increase
application-visible latency."

Later on, it states that only ACK, STOP_WAITING and PADDING frames MUST not
> be retransmitted, but all other frames must be retransmitted. This implies
> than that WINDOW_UPDATE and BLOCKED frames must be retransmitted, but i am
> not sure if this makes sense. I mean, maybe there were other WINDOW_UPDATE
> frames than were sent after this one so retransmitting this one probably
> doesnt make sense, since the information it contains may be stalled, no?
>

You're correct that WINDOW_UPDATE and BLOCKED frames are retransmitted.
It's hard to construct a scenario however where a WINDOW_UPDATE frame keeps
getting dropped, but the client still sends enough data to cause a new
revised WINDOW_UPDATE frame to be sent... I agree that in this case the
sender would be retransmitted useless information, but I don't think we
need to optimize for this case.

I still dont understand why having both connection and stream flow control
> is useful. I would assume that only stream flow control would be useful. Or
> having one or the other in a given connection, but i fail to understand why
> is useful to have both of them simultaneously in the same connection.
>

I've answered this above, let me know if there's more clarification that
can be had in the doc.

Section 6 states
>
>    Regular QUIC Packets are "containers" of frames; a packet is never
>    retransmitted whole, but frames in a lost packet may be rebundled and
>    transmitted in a subsequent packet as necessary.
>
> So, let me see if i understand this.
>
> This means that if the sender sends packet with PSN 5, and if the packet
> is lost (i.e. there is a timeout for that packet), the packet with PSN 5
> NOT retransmitted. the frames in the packet with PSN 5 are then
> retransmitted in other packets with other PSN (other than 5). If this
> correct?
>

Correct.

> This means that there will be holes in the sequence of packets received by
> the receiver i.e. any packet that get's lost, is simply lost and will never
> be received by the receiver. Am i understanding this correctly?
>

Correct.

>    A receiver acknowledges receipt of a received packet by sending one
>    or more ACK frames containing the PSN of the received packet.  To
>    avoid perpetual acking between endpoints, a receiver MUST NOT
>    generate an ack in response to every packet containing only ACK
>    frames.
>
> Does this means that ACKs transmission is unreliable, correct?
>

Correct.

> Since packets are never retransmitted with the same PSN, this basically
> means that if an ACK is lost, then the sender gives up on this packet and
> eventually will retransmit the data in other packets with a different PSN,
> correct?
>

Correct.

>
> Section 7.1.1 on Mid-stream RST_STREAM
>
> After a RST, when the stream identifier can be reused? probably some
> guidance about this would be useful.
>

As I clarified above, a stream ID can never be reused.

Section 7.1.4.
>
> Is the BLOCKED frame reliably transmitted? I assume it is, but, does it
> make sense?
>

Yes, it is reliably transmitted.

> I mean, if a sender sends a blocked frame and it get's lost, but after
> that the receiver open the window, then retransmitting the BLOCKED frame is
> not useful (doesnt harm neither i guess)
>
> OTOH, what if the BLOCKED frame get's lost? Do we end up with the silly
> window syndrome?
>

The BLOCKED frame is really a debugging frame... it's good to know at the
receiver that the sender was flow control blocked. Since the receiver is
expected to have sent a WINDOW_UPDATE well in advance, and since the
BLOCKED frame is not a required part of the flow control machinery, it
doesn't cause SWS. It's currently required for the sender to send, but not
required to be processed by the receiver beyond maybe logging it somewhere.
I've modified the text in Section 7.1.4 to say:

"If a sender does not receive a WINDOW_UPDATE frame when it has run out of
flow control credit, the sender will be blocked and MUST send a BLOCKED
frame. A BLOCKED frame is expected to be useful for debugging at the
receiver. A receiver SHOULD NOT wait for a BLOCKED frame before sending
with a WINDOW_UPDATE, since doing so will cause at least one roundtrip of
quiescence. For smooth operation of the congestion controller, it is
generally considered best to not let the sender go into quiescence if
avoidable. To avoid blocking a sender, and to reasonably account for the
possibiity of loss, a receiver should send a WINDOW_UPDATE frame at least
two roundtrips before it expects the sender to get blocked."

Is that clearer?

I guess we could do what TCP does i.e. periodically transmit the BLOCKED
> msg when there is no window (which is different from reliably transmitting
> the BLOCKED message, since it is periodically sent only when the window is
> 0)
>
>
> Section 8 on connection termination
>
> After a connection close, does the same stream identifier can be reused
> for a new connection? shouldnt also be a hold time to avoid delayed packets
> of the old connection? How much time would be safe?
>

Do you mean Connection ID? Again, since the expectation is that the keys
will be different. Of course that depends on the KDF, but that depends on
the crypto protocol in use. I think the clarification that I added above to
the crypto requirements should be enough. What do you think?

> Section 10.4
>
> I understand ACK frames are unreliably transmitted.
>
> Also, I understand that packets are never retransmitted with the same PSN.
> So, if a packet is lost, there will be a hole in the receiver for that PSN
> and the data will be sent in other packets with othew PSN. Hence, you
> cannot have cummulative acks.
>

Correct.

> So, this means that it is possible for a packet to be received by the
> receiver but that all the ACKs for that packet to be lost on the way back
> and then the sender will timeout and retransmit, right? (I guess that is
> ok, since data will be retransmitted in other packets)
>

Correct.

> Let me verify that I understand when a stop waiting frames should be sent
> by the sender. I guess that a sender should send a given PSN X in a stop
> waiting frame if all the packet with PSN lower than X have been received or
> have timed out, correct?
>

Correct. I would say when all PSNs <= X are no longer considered in flight.

Thanks again,
- jana

> Regards, marcelo
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>