Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

[Mark Andrews]

> On 10 Jul 2020, at 01:34, Marek Majkowski  wrote:
> 
> On Thu, Jul 9, 2020 at 3:35 AM Mark Andrews  wrote:
>>> I have two problems with this proposal. First, it doesn't mention IPv4
>>> vs IPv6 differences at all. In IPv4 landscape fragmentation, while a
>>> security issue, is generally fine. In the IPv6 world, fragmentation is
>>> disastrous - packets with extension headers are known to be dropped.
>> 
>> Not really. UNKNOWN extensions tend to get dropped but the fragmentation
>> header is a KNOWN extension header.
> 
> https://labs.apnic.net/presentations/store/2019-09-11-ipv6-fail.pdf
> 
> Slide 34 and 35 indicate, with IPv6:
> - 38% recursive resolvers fail to reassemble packets with
> fragmentation extension header

Which means 62% of the world properly handles fragmented UDP packets.

Also I forget how Geoff was actually performing the test.  Where any of
the responses greater than the advertised EDNS buffer size sent?  Was
fragmentation introduced when the UDP response size was less that 1280?

> - 22% of browsers fail to process TCP packets with fragmentation header

Which seems to be a very strange test to perform given that TCP segments
are supposed to be atomic on IPv6.

> This data is from 2017 - around that time I did similar experiments
> with similar results. Delivery of fragmented packets in IPv6 sometimes
> work, but this is more of an exception than a rule.
> 
>>> Second, this proposal assumes that path MTU detection works correctly.
>>> This is surprisingly optimistic. Let's consider IPv6 - in IPv6 the
>>> smaller path MTU < 1500 is very common.
>> 
>> Which is why IPV6_USE_MIN_MTU exists (RFC 3542).  USE THE SOCKET OPTION.
>> It was put there specifically to support DNS over UDP and other applications
>> like that.  I know this as I proposed the predecessor option back in 1999
>> which became IPV6_USE_MIN_MTU.
> 
> You are suggesting to always use at most 1280 byte packets in IPv6.
> The draft we are discussing does not suggest that. Did I misunderstand
> something?

I’m suggesting that if you send UDP/IPv6 packets > 1280 that you force them to 
be
fragmented into 1280 octet fragments.

I’m suggesting that we force DNS/TCP/IPv6 packets to never be bigger that 1280 
for
regular requests.  AXFR/IXFR would be a potential exception.  Clients and 
servers
can do this by setting the MSS to an appropriate value (1280-IPv6 header 
size-TCP
header size).  Setting IPV6_USE_MIN_MTU should also achieve this as TCP is 
supposed
to take into account path MTU which is 1280 when this option is set.

The IETF has designed IPv6 such that it is possible to run a DNS server that
will never receive a ICMPv6 PTB to traffic it sends even if other applications
on the server do.

> Marek

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Brian Dickson]

On Wed, Jul 15, 2020 at 10:16 AM Erik Nygren  wrote:

> We landed on 63 in the draft version we just published  (to align with max
> label lengths).
> There's no reason they *need* to be short as they are just in presentation
> form, so their length
> comes down to usability and finding the right words.  The longest
> currently is 15 and it would
> be better to avoid future ones needing to be artificially constrained.  Is
> there a reason we'd
> want to decrease this (eg, to 31)?
>

These key names are table entries in an IANA table, and never go over the
wire.
So, while it might be a reasonable design choice to limit the character set
to match DNS labels, i.e. US ASCII, that's not technically a requirement.
I'm not suggesting doing otherwise, but, it should at least be called out
as a conscious decision.
Maybe an alternative solution would be "any valid A-label", which would
potentially support UTF table entries encoded with puny-code?

As for length, as long as it is long enough to encode "bikeshed-colour", I
don't really care. :-)

Brian


>
> On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson 
> wrote:
>
>> How about 2 or 10 ?
>> why do  the names to need to be long ?
>>
>> Olafur
>>
>>
>> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  wrote:
>>
>>> Or 64?
>>>
>>>
>>>
>>> - Erik
>>>
>>>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>>>
>>> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz >> 40google@dmarc.ietf.org> wrote:
>>>
 How about 255 characters?

 On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  wrote:

> Can we please have a length limit on key names?  At the moment they
> could be a billion characters long as they don’t go over the wire.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 <+61%202%209871%204742>  INTERNET:
> ma...@isc.org
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>> --
>> Ólafur Gudmundsson | Engineering Director
>> www.cloudflare.com blog.cloudflare.com
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Tommy Pauly]

This is only the presentation format—in wire format, these are alway 2-byte 
integers. Thus, there isn’t any effect on packet size.

Thanks,
Tommy

> On Jul 15, 2020, at 10:34 AM, Ólafur Guðmundsson 
>  wrote:
> 
> DoU i.e. DNS over UDP packet size impact,
>  
> Olafur
> 
> 
> On Wed, Jul 15, 2020 at 1:16 PM Erik Nygren  > wrote:
> We landed on 63 in the draft version we just published  (to align with max 
> label lengths).
> There's no reason they *need* to be short as they are just in presentation 
> form, so their length
> comes down to usability and finding the right words.  The longest currently 
> is 15 and it would
> be better to avoid future ones needing to be artificially constrained.  Is 
> there a reason we'd
> want to decrease this (eg, to 31)?
> 
> On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson  > wrote:
> How about 2 or 10 ? 
> why do  the names to need to be long ? 
> 
> Olafur 
> 
> 
> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  > wrote:
> Or 64?  
> 
> 
> 
> - Erik
> 
>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
> 
> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz  > wrote:
> How about 255 characters?
> 
> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  > wrote:
> Can we please have a length limit on key names?  At the moment they could be 
> a billion characters long as they don’t go over the wire..
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742   INTERNET: 
> ma...@isc.org 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
> 
> 
> -- 
> Ólafur Gudmundsson | Engineering Director 
> www.cloudflare.com  blog.cloudflare.com 
> 
> 
> -- 
> Ólafur Gudmundsson | Engineering Director 
> www.cloudflare.com  blog.cloudflare.com 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Ólafur Guðmundsson]

DoU i.e. DNS over UDP packet size impact,

Olafur


On Wed, Jul 15, 2020 at 1:16 PM Erik Nygren  wrote:

> We landed on 63 in the draft version we just published  (to align with max
> label lengths).
> There's no reason they *need* to be short as they are just in presentation
> form, so their length
> comes down to usability and finding the right words.  The longest
> currently is 15 and it would
> be better to avoid future ones needing to be artificially constrained.  Is
> there a reason we'd
> want to decrease this (eg, to 31)?
>
> On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson 
> wrote:
>
>> How about 2 or 10 ?
>> why do  the names to need to be long ?
>>
>> Olafur
>>
>>
>> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  wrote:
>>
>>> Or 64?
>>>
>>>
>>>
>>> - Erik
>>>
>>>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>>>
>>> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz >> 40google@dmarc.ietf.org> wrote:
>>>
 How about 255 characters?

 On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  wrote:

> Can we please have a length limit on key names?  At the moment they
> could be a billion characters long as they don’t go over the wire.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 <+61%202%209871%204742>  INTERNET:
> ma...@isc.org
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>> --
>> Ólafur Gudmundsson | Engineering Director
>> www.cloudflare.com blog.cloudflare.com
>>
>

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Erik Nygren]

We landed on 63 in the draft version we just published  (to align with max
label lengths).
There's no reason they *need* to be short as they are just in presentation
form, so their length
comes down to usability and finding the right words.  The longest currently
is 15 and it would
be better to avoid future ones needing to be artificially constrained.  Is
there a reason we'd
want to decrease this (eg, to 31)?

On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson 
wrote:

> How about 2 or 10 ?
> why do  the names to need to be long ?
>
> Olafur
>
>
> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  wrote:
>
>> Or 64?
>>
>>
>>
>> - Erik
>>
>>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>>
>> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz > 40google@dmarc.ietf.org> wrote:
>>
>>> How about 255 characters?
>>>
>>> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  wrote:
>>>
 Can we please have a length limit on key names?  At the moment they
 could be a billion characters long as they don’t go over the wire.
 --
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 <+61%202%209871%204742>  INTERNET:
 ma...@isc.org

 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop

>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> --
> Ólafur Gudmundsson | Engineering Director
> www.cloudflare.com blog.cloudflare.com
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] HTTPS and SVBC key names.

[Ólafur Guðmundsson]

How about 2 or 10 ?
why do  the names to need to be long ?

Olafur


On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren  wrote:

> Or 64?
>
>
>
> - Erik
>
>  [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
>
> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz  40google@dmarc.ietf.org> wrote:
>
>> How about 255 characters?
>>
>> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews  wrote:
>>
>>> Can we please have a length limit on key names?  At the moment they
>>> could be a billion characters long as they don’t go over the wire.
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742 <+61%202%209871%204742>  INTERNET:
>>> ma...@isc.org
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Time for WGLC?

[Benno Overeinder]

Hi Ben,

> On 15 Jul 2020, at 00:38, Ben Schwartz  
> wrote:
> 
> Oh, and regardless, we would like some agenda time.

Thanks, we reserve a slot for the draft.

> On Tue, Jul 14, 2020 at 2:19 PM Ben Schwartz  wrote:
> DNSOP chairs,
> 
> SVCB/HTTPS draft-01 has incorporated a lot of feedback, and I think it's 
> really in good shape (apart from "TODO REMOVE" sections)..  There are several 
> implementations in development.  Is it time to start a WGLC?
> 

The draft is indeed in good shape.  The DNSOP chairs will be meeting 
(virtually) soon and will discuss the start of the WGLC.

Best regards,

— Benno

--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] OARConline 32b Workshop, August 11th, Registration and Call for Contributions now open

[Ralph Dolmans]

Hi all,

A reminder that the presentation proposal submissions deadline for
OARConline 32b is approaching. Please submit your abstracts by July 23rd
(23:59 UTC) if you would like to present at the workshop, via:



Regards,
Ralph

On 30-06-2020 12:30, Ralph Dolmans wrote:
> OARC is hosting an online meeting on August 11th, 13:00 - 15:00 UTC. The
> Programme Committee is seeking contributions from the community.
> 
> All DNS-related subjects are welcome, and we remain interested in
> content which is timely and operationally relevant in light of the
> COVID-19 pandemic. Suggestions for discussion topics are also very welcome.
> 
> As the session is limited to 2 hours we'd like to encourage brevity;
> presentations should not be longer than 20 minutes (this does not
> include time for questions).
> 
> **Workshop Milestones:**
> 
> * 30 Jun 2020 - Submissions open via Indico
> * 23 Jul 2020 - Deadline for submission (23:59 UTC)
> * 30 Jul 2020 - Initial Contribution list published
> * 4 Aug 2020 - Full agenda published
> * 6 Aug 2020 - Deadline for slideset submission
> * 11 Aug 2020 - OARConline 32b Workshop
> 
> The Registration page and details for presentation submission are
> published at:
> 
> 
> 
> 
> To allow the Programme Committee to make objective assessments of
> submissions, so as to ensure the quality of the workshop, submissions
> SHOULD include slides. Draft slides are acceptable on submission.
> 
> Additional information for speakers of OARConline 32b:
> 
>   * your talk will be broadcast live and recorded for future reference
>   * your presentation slides will be available for delegates and others
> to download and refer to, before, during and after the meeting
>   * you will be expected to attend a rehearsal some time in the two
> weeks running up to the workshop. We will work with all accepted
> speakers on a convenient time for all. It would be very useful to have
> your slides (even if draft) ready for this.
> 
> If you have questions or concerns you can contact the Programme Committee:
> 
> https://www.dns-oarc.net/oarc/programme
> 
> via 
> 
> Ralph Dolmans, for the DNS-OARC Programme Committee
> 
> OARC depends on sponsorship to fund its workshops and associated social
> events.  Please contact  if your organization is
> interested in becoming a sponsor.
> 
> (Please note that OARC is run on a non-profit basis, and is not in a
> position to reimburse expenses or time for speakers at its meetings.)
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop