RE: negotiating Packet Number Protection

[Gabriel Montenegro <[e-mail]>]

Thanks folks for the comments and suggestions.

They seem reasonable, namely

  *   relaxing from a MUST NOT to a SHOULD NOT on internet-facing clients
  *   requiring disable_migration as well.

New version here: https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-01

Is this simple enough to include in the transport document? Alternatively, it would be great if this could be published as an informational (or experimental) document to make it a stable reference.

Thanks,

Gabriel

From: QUIC <[e-mail]> On Behalf Of Christian Huitema
Sent: 7 September, 2018 21:20
To: [e-mail]
Subject: Re: negotiating Packet Number Protection


On the "migration" point. I think that proposing the "no packet number protection" option without also proposing the "migration not supported" option should be treated as a protocol error.

-- Christian Huitema

On 9/7/2018 10:10 AM, Lucas Pardue wrote:
I agree with relaxing the MUST for Internet-facing.

There may be some future applications of future versions of QUIC where the benefits of PNP are harder to rationalise (i.e. traceabiity of mutlicasted QUIC packets that share a packet number). Indeed, there may be some other schemes that a benefit from a readble and/or deterministic packet number. However, that's all a long way off. What I like about the extension for the QUIC we have today is that it sets the right frame up for implementations that might want to do things slightly differently.

Regards
Lucas
________________________________
From: QUIC [[e-mail]<mailto:[e-mail]>] on behalf of Ian Swett [ianswett=[e-mail]<mailto:ianswett=[e-mail]>]
Sent: 07 September 2018 13:38
To: Mikkel Fahnøe Jørgensen
Cc: Martin Thomson; IETF QUIC WG; Christian Huitema; gabriel.montenegro=[e-mail]<mailto:gabriel.montenegro=[e-mail]>
Subject: Re: negotiating Packet Number Protection
I agree with Mikkel that the MUST not enable it on the public internet is either too strong or potentially impractical to enforce, so I would be inclined to change that to a SHOULD.

I would request that this MUST not be used when voluntary/intentional connection migration is enabled.

On Thu, Sep 6, 2018 at 11:30 PM Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>> wrote:
The MUST not disable PNP on internet facing nodes is too strong - you want a deployment to be able to move to a new DC while talking to the old DC - although ossification could br a concern, it is not egen limited to quasi stationært use cases.

________________________________
From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Christian Huitema <[e-mail]<mailto:[e-mail]>>
Sent: Friday, September 7, 2018 4:09:01 AM
To: Martin Thomson; Gabriel.Montenegro=[e-mail]<mailto:[e-mail]>
Cc: QUIC WG
Subject: Re: negotiating Packet Number Protection

This draft requests assignment of single byte code point. I would rather
not do that know, as we are discussing reserving several consecutive
codes for ACK variants and options. Would it be a deal breaker if the
option used a longer code?

-- Christian Huitema


On 9/6/2018 5:05 PM, Martin Thomson wrote:
> This is an entirely appropriate use of transport parameters and it
> looks like the design works as intended.  I tend to think that the
> IETF doesn't need to publish this - this sort of extension is why we
> have relatively loose registration policies - but I'm happy to have
> that conversation at the appropriate time.
> On Fri, Sep 7, 2018 at 8:55 AM Gabriel Montenegro
> <Gabriel.Montenegro=[e-mail]<mailto:[e-mail]>> wrote:
>> Folks,
>>
>>
>>
>> We just submitted a draft to negotiate Packet Number Protection. This would allow disabling it in environments (e.g., in a datacenter) where it may no be needed if both sides agree. Browsers, of course, would probably not bother with this.
>>
>>
>>
>> https://tools.ietf.org/html/draft-montenegro-quic-negotiate-pnp-00<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-montenegro-quic-negotiate-pnp-00&data=02%7C01%7CGabriel.Montenegro%40microsoft.com%7C82c986f3194048f795e108d615427fd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719772700583188&sdata=bwlaL%2FgyUxAxXBl%2BrraKlkCvZKYtxV8i8oI55ijCzK4%3D&reserved=0>
>>
>>
>>
>> thanks,
>>
>>
>>
>> Gabriel, Nick, Praveen



----------------------------

http://www.bbc.co.uk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.co.uk&data=02%7C01%7CGabriel.Montenegro%40microsoft.com%7C82c986f3194048f795e108d615427fd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719772700583188&sdata=trJmli6Qlnd3PUJejUnkLP5SUWMuonzJXvIPuFtLt7c%3D&reserved=0>
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------