Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Hugo Maxwell Connery]

David Conrad wants metrics for Tor.

Unsurprisingly, they have them.  Our evil spam filter is stopping me
from sending a link, but go to:

https  metrics torproject org

There you find: number of relays and bridges, advertised bandwidth, and 
connected users, as graphs over time, and much more.

As of now approx 10 000 relays + bridges with 200 000 connected users.

/Hugo

From: DNSOP [dnsop-boun...@ietf.org] on behalf of David Conrad 
[d...@virtualized.org]
Sent: Wednesday, 15 July 2015 04:37
To: Stephane Bortzmeyer
Cc: dnsop; IETF
Subject: Re: [DNSOP] Last Call:  (The .onion 
Special-Use Domain Name) to Proposed Standard

[snip]

I try to be pragmatic. Given I do not believe that refusing to put ONION in the 
special names registry will stop the use of .ONION, the size of the installed 
base of TOR implementations, and the implications of the use of that string in 
certificates, I supporting moving ONION to the special names registry.  I 
really (really) wish there was more concrete, objective metrics (e.g., size of 
installed base or some such), but my gut feeling is that TOR is pretty well 
deployed and given the CAB Forum stuff, I see no particular reason to delay 
(after all, it's not like the deployed base of TOR is likely to get smaller).

Regards,
-drc

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Shane Kerr]

All,

On Wed, 15 Jul 2015 20:33:59 -0400
Andrew Sullivan  wrote:

> On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote:
> > I am also concerned about the apparent urgency to get the initial document
> > out with points that admittedly remain contentious and/or where there isn't
> > WG consensus.  I don't think it needs perfection, but it seems unnecessary
> > to get the document published without further explicitly identifying and
> > considering the standing issues.  We've haven't had this document
> > before--I'm not sure what the rush is now.
> 
> Just on this issue, and speaking only for myself (but as one of the
> people behind this document), my view is that this WG has historically
> been one of the places where documents go to die, and I am unwilling
> to go through the exercise of proving again how great an enemy of the
> good the perfect can be.  I'd be much more inclined to remove the
> contentious definitions and publish that document than to try to get
> things perfect.

I totally agree, on all counts.

Cheers,

--
Shane

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Sara Dickinson]

> On 16 Jul 2015, at 03:15, Paul Hoffman  > wrote:
> 
> On 15 Jul 2015, at 17:33, Andrew Sullivan wrote:
>> 
>> Just on this issue, and speaking only for myself (but as one of the
>> people behind this document), my view is that this WG has historically
>> been one of the places where documents go to die, and I am unwilling
>> to go through the exercise of proving again how great an enemy of the
>> good the perfect can be.  I'd be much more inclined to remove the
>> contentious definitions and publish that document than to try to get
>> things perfect.

Firstly to say that I think this is a very worthy effort and the document will 
be of great value to the DNS community.  It should be published and I support 
the proposal that removing contentious definitions to get the draft published 
is the a best way to proceed.

>> 
>> I agree and acknowledge that there remain some definitions in there
>> that are contentious.
> 
> Not only do you agree and acknowledge that, *so does the document*. 

I have to disagree that the document goes that far - the first sentence of the 
third paragraph in the introduction states:

“The definitions here are believed to be the consensus definition of
   the DNS community, both protocol developers and operators.”

and paragraph 5 

“In this document, where the consensus definition is the same as the
   one in an RFC, that RFC is quoted.  Where the consensus definition
   has changed somewhat, the RFC is mentioned but the new stand-alone
   definition is given."

so I don’t believe any definitions that are considered contentious should be in 
the document if this wording is to be retained.

> Based on the contention and lack of consensus for some of the definitions, 
> the Introduction now says:
> 
> During the development of this document, it became clear that some 
> DNS-related terms are interpreted quite differently by different DNS experts. 
> Further, some terms that are defined in early DNS RFCs now have definitions 
> that are generally agreed to that are different from the original 
> definitions. Therefore, the authors intend to follow this document with a 
> substantial revision in the not-distant future. That revision will probably 
> have more in-depth discussion of some terms as well as new terms; it will 
> also update some of the RFCs with new definitions.


Since this paragraph appears after the first statement about consensus I read 
it as indicating the bis is likely to refine and extend the original document 
(fine) but not that readers should expect some definitions presented here to 
substantially change in a later revision. 

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Warren Kumari]

On Thu, Jul 16, 2015 at 11:15 AM, Shane Kerr  wrote:
> All,
>
> On Wed, 15 Jul 2015 20:33:59 -0400
> Andrew Sullivan  wrote:
>
>> On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote:
>> > I am also concerned about the apparent urgency to get the initial document
>> > out with points that admittedly remain contentious and/or where there isn't
>> > WG consensus.  I don't think it needs perfection, but it seems unnecessary
>> > to get the document published without further explicitly identifying and
>> > considering the standing issues.  We've haven't had this document
>> > before--I'm not sure what the rush is now.
>>
>> Just on this issue, and speaking only for myself (but as one of the
>> people behind this document), my view is that this WG has historically
>> been one of the places where documents go to die, and I am unwilling
>> to go through the exercise of proving again how great an enemy of the
>> good the perfect can be.  I'd be much more inclined to remove the
>> contentious definitions and publish that document than to try to get
>> things perfect.
>
> I totally agree, on all counts.

+1 on getting it published.

I should point out that the emphasis should be on the "historically"
in "WG has historically been one of the places where documents go to
die".

Recently this working group has been munching though and getting
documents published.

2012: 1 RFC
2013: 1 RFC
2014: 1 RFC
2015: 3 RFC, 4 documents are with the IESG / RFC Ed.

We shouldn't be figuring out how useful a WG is by the number of
documents published, but I don't think DNSOP is still where documents
go to die...

W


>
> Cheers,
>
> --
> Shane
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Andrew Sullivan]

On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote:
> We shouldn't be figuring out how useful a WG is by the number of
> documents published, but I don't think DNSOP is still where documents
> go to die...

Agreed, but I also don't want to return to that bleak past where we
could never get anything published because it wasn't perfect, and then
the number of recycles got high enough that nobody would review, so
the draft wasn't perfect, and so on.  The editors will put their heads
together once more on the basis of the most recent comments.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Suzanne Woolf]

Hi,

This is a good time to remind ourselves of how we got here.

This draft came into the WG as an individual submission, with the authors 
seeking comment but not asking for it to be a WG work item. We eventually 
adopted it in the expectation that handling it as a WG draft would lead to 
higher quality review and higher credibility for the resulting document. There 
has seemed consistently to be very strong support that this document is needed.

The chairs were in full understanding of the editors' views on the purpose of 
the document, and thought the WG was too: the intention was to get a good 
reference out in the field where people who aren’t necessarily as sophisticated 
as DNSOP regulars can use it, and then tackle the more difficult issues— where 
definitions aren’t fully consistent within the standard, or implementers and 
operators have diverged from the standard, or the standard is silent on some 
important aspect of the protocol.

At this stage, I don’t think it’s a good use of the WG’s time to revisit the 
basis for adopting the draft. Nor do I think we’re going to resolve all 
possible contentions, no matter how much more time or how many more review 
cycles we insist on. Some will be noted as part of this document; some will be 
removed to wait for the next one.

Not speaking for the editors, it does seem to me that it would be helpful for 
reviews to separate critiques of the form “I don’t think this accurately 
captures the definition of this term in existing documents” or “I think 
documentation and implementation/practice have diverged” from critiques of the 
form “I don’t like this definition or this aspect of the protocol.”

We have been through extensive review and a Working Group Last Call on this 
draft. The next revision should go ahead to the IESG.

best,
Suzanne


> On Jul 16, 2015, at 8:23 AM, Andrew Sullivan  wrote:
> 
> On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote:
>> We shouldn't be figuring out how useful a WG is by the number of
>> documents published, but I don't think DNSOP is still where documents
>> go to die...
> 
> Agreed, but I also don't want to return to that bleak past where we
> could never get anything published because it wasn't perfect, and then
> the number of recycles got high enough that nobody would review, so
> the draft wasn't perfect, and so on.  The editors will put their heads
> together once more on the basis of the most recent comments.

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Jim Reid]

On 16 Jul 2015, at 14:14, Suzanne Woolf  wrote:

> We have been through extensive review and a Working Group Last Call on this 
> draft. The next revision should go ahead to the IESG.

+1

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

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Warren Kumari]

On Thu, Jul 16, 2015 at 2:23 PM, Andrew Sullivan  
wrote:
> On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote:
>> We shouldn't be figuring out how useful a WG is by the number of
>> documents published, but I don't think DNSOP is still where documents
>> go to die...
>
> Agreed, but I also don't want to return to that bleak past where we
> could never get anything published because it wasn't perfect, and then
> the number of recycles got high enough that nobody would review, so
> the draft wasn't perfect, and so on.

+very many much lots.

I just wanted to acknowledge the fact that our chairs are now getting
documents pushed through

W

> The editors will put their heads
> together once more on the basis of the most recent comments.
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Tom Ritter]

On 16 July 2015 at 00:44, Joe Hildebrand  wrote:
> I don't see any mention of the CAB Forum stuff in the draft.  Has anyone
> done the analysis to see if CAB Forum members really will issue certs to
> .onion addresses if we do this?  Do they issue certs for .example or .local
> today?

Not only will they issue certificates .onion, but they will not be
required to revoke the certificates they have _already_ issued, and
are using happily. I know Facebook and Blockchain, a few certs for
each, and maybe a third I'm forgetting. That will only go up over
time.

On the topics of metrics, indeed https://metrics.torproject.org/ is
the place.  You missed a zero though. It's 2 *million* directly
connecting users/day on average, not 200K.

On the topic of carrot, I would suggest .carrot.alt =)  I would also
ask about your user base.

On the topic of TLD vs Special Use: Yes I can confirm we want a
special use name, not a TLD.

On the topic of reliable resource,
https://gitweb.torproject.org/torspec.git/tree/ is a great URL, this
is where we standardize our specifications and update them. Our
process is different from the IETF, but there is one.  rend-spec.txt
in particular deals with .onion - but you would need to work with the
rest of the specs to get that far.  Barring operator accidents or some
absurd explosion in DNS price, I expect torproject.org will live 40+
years reliably. It may not be as future-reliable as iana.org or
ietf.org, but that URL, and/or "the torspec repository" is probably as
reasonably reliable as any other offsite link.

I support this draft.

-tom

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

[Mark Delany]

On 06Jul15, internet-dra...@ietf.org allegedly wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
> 
> Title   : Client Subnet in DNS Queries
> Authors : Carlo Contavalli
>   Wilmer van der Gaast
>   David C Lawrence
>   Warren Kumari
>   Filename: draft-ietf-dnsop-edns-client-subnet-02.txt
>   Pages   : 27
>   Date: 2015-07-06

I was under the (perhaps mistaken) impression that there was a plan to
rewrite this spec in light of actually implementation experiences. Is
this draft that rewrite? I ask as this seems to be more a clean-up of
the original draft.

If it is the former then one issue I raised with the previous draft
remains undiscussed and unchanged. That being the notion of
caches/resolvers using white lists to constrain which servers should
be sent the ECS option.

We all know a white-list doesn't scale for an internet protocol and my
limited experience of hunting down owners, exchanging emails and
agreeing on a white list format is pretty broken and brittle.

I would think that if we're to proceed with this protocol then the
white list requirement should be removed from the spec.


Mark.

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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 02:45 PM, Francisco Obispo wrote:
It doesn’t feel right to me rewarding bad behavior. 
I don't think it's fair to characterize this as "bad behavior."   It is 
completely unsurprising behaviour, as I explained in some detail in a 
previous message: 
http://www.ietf.org/mail-archive/web/dnsop/current/msg14924.html


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

[Dave Lawrence]

Mark Delany writes:
> I was under the (perhaps mistaken) impression that there was a plan to
> rewrite this spec in light of actually implementation experiences. Is
> this draft that rewrite? I ask as this seems to be more a clean-up of
> the original draft.

There is a plan to rewrite the spec, but not in this draft.  The
existing deployed base meant that no meaningful changes to the
protocol under the current option code could be made without
significant pain.  There is no will among the providers currently
using it to assume that pain.  So yes, this draft is just a cleanup
addressing the existing implementations.

> I would think that if we're to proceed with this protocol then the
> white list requirement should be removed from the spec.

I don't see language in the current draft that makes a whitelist a
requirement.  The language I do see doesn't even use 2119
capitalization, so it's even softer than usual.  If there is a
statement in there that you think mandates whitelists, I am amenable
to modifying it.  I see that as an endpoint operational policy issue,
not a core protocol issue.

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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Richard Barnes]

On Thu, Jul 16, 2015 at 12:44 AM, Joe Hildebrand  wrote:
> On 15 Jul 2015, at 5:37, David Conrad wrote:
>
>> I try to be pragmatic. Given I do not believe that refusing to put ONION
>> in the special names registry will stop the use of .ONION, the size of the
>> installed base of TOR implementations, and the implications of the use of
>> that string in certificates, I supporting moving ONION to the special names
>> registry.  I really (really) wish there was more concrete, objective metrics
>> (e.g., size of installed base or some such), but my gut feeling is that TOR
>> is pretty well deployed and given the CAB Forum stuff, I see no particular
>> reason to delay (after all, it's not like the deployed base of TOR is likely
>> to get smaller).
>
>
> I don't see any mention of the CAB Forum stuff in the draft.  Has anyone
> done the analysis to see if CAB Forum members really will issue certs to
> .onion addresses if we do this?  Do they issue certs for .example or .local
> today?

There are at least a few CAs issuing for .onion right now, under the
exceptions that are going to expire in a few months.  So I assume that
these CAs will be interested in issuing if policy allows.

My understanding is that the basic requirement that CABF has is that a
name either be clearly a valid DNS name or clearly *not* a valid DNS
name.  (And in either case, that the applicant be able to demonstrate
control.)  Right now, that's ambiguous.  Adding .onion to the RFC 6761
registry would remove the ambiguity, since it would officially mark
names under .onion as not DNS names.

--Ricahrd



> If certificate issuance is one of the key drivers for this work, there needs
> to be information in the draft that shows that this approach will work.
>
> --
> Joe Hildebrand
>
>
> ___
> 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] I-D Action: draft-ietf-dnsop-5966bis-02.txt

[John Dickinson]

On 14/07/2015 11:31, Shane Kerr wrote:

John,

Looks pretty good, although I have a couple of comments.

First, does it make sense to discuss blocking of network prefixes
rather than IP addresses? This is mentioned a couple of times in the
text, but blocking an IPv6 address is like throwing a pebble in the
ocean. :P (I did a quick Google search to find if there are any RFC's
about this in general, but didn't notice any. Does anybody know of any
standard text about this issue?)


Sounds good to me.



Second, one possible issue for consideration is that it is already a
problem for resolver operators that a single query can cause a *lot* of
work for the resolver. This issue can be magnified with TCP pipelining:
a bad actor can connect to a resolver and queue a ton of queries in a
few packets (consider how many queries will fit in 1460 bytes).


Do you feel this is worse than flooding a server with UDP? Should we 
have rate limiting?


thanks for the review
John



Cheers,

--
Shane



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

[Mark Delany]

On 16Jul15, Dave Lawrence allegedly wrote:
> > I would think that if we're to proceed with this protocol then the
> > white list requirement should be removed from the spec.
> 
> I don't see language in the current draft that makes a whitelist a
> requirement.  The language I do see doesn't even use 2119
> capitalization, so it's even softer than usual.  If there is a
> statement in there that you think mandates whitelists

True, there is no mandate, but all implementations that I'm aware of,
have implemented a white list. While the language is softer in -02, is
it necessary at all as it will only continue to encourage white list
behavior just as the previous language did.

IOWs, why not remove 11.2 completely?


Mark.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

[Ray Bellis]

On 16/07/2015 17:10, John Dickinson wrote:
> 
> 
> On 14/07/2015 11:31, Shane Kerr wrote:
>>
>> Second, one possible issue for consideration is that it is already a
>> problem for resolver operators that a single query can cause a *lot* of
>> work for the resolver. This issue can be magnified with TCP pipelining:
>> a bad actor can connect to a resolver and queue a ton of queries in a
>> few packets (consider how many queries will fit in 1460 bytes).
> 
> Do you feel this is worse than flooding a server with UDP? Should we
> have rate limiting?

I think the pipelining is a non-issue, or rather one that already exists.

In practise most (if not all) existing DNS servers that support TCP
already suffer this potential problem.

When the client sends a whole series of queries down the connection
without waiting for an answer in general this "just works" because
servers don't routinely flush the incoming TCP read buffer every time
they respond to a packet.

Ray

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-02.txt

[Dave Lawrence]

Mark Delany writes:
> True, there is no mandate, but all implementations that I'm aware of,
> have implemented a white list. While the language is softer in -02, is
> it necessary at all as it will only continue to encourage white list
> behavior just as the previous language did.

The reality is that at least one major provider of authoritative ECS
service has realistically no chance at all of removing its whitelist
in the visible future.  At least one major recursive implementer has
found that they must use a whitelist for sending ECS as well or they
pay a significant penalty on first hit to a server that mishandles it.

That is not to say that I disagree with your basic point.  Whitelists
are a pain to accurately maintain, of that there is no doubt.  They
are, however, also reality.

> IOWs, why not remove 11.2 completely?

In my opinion, it is important to make the reader aware that such
whitelisting does exist and that ECS won't just work out of the box
between any two ECS-supporting recursive/authoritative instances.

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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis]

On 7/16/15, 9:57, "DNSOP on behalf of Tom Ritter"  wrote:

>On 16 July 2015 at 00:44, Joe Hildebrand  wrote:
>> I don't see any mention of the CAB Forum stuff in the draft.  Has anyone
>> done the analysis to see if CAB Forum members really will issue certs to
>> .onion addresses if we do this?  Do they issue certs for .example or
>>.local
>> today?
>
>Not only will they issue certificates .onion, but they will not be
>required to revoke the certificates they have _already_ issued, and
>are using happily
>On the topics of metrics, indeed https://metrics.torproject.org/...

I'd be happy (happier) if that information appeared in the draft.


>On the topic of carrot...

I don't have any users.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

[Paul Hoffman]

Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to 
end today, but it got extremely little review during the Last Call. It 
would be helpful to all of us if more people can review the document, 
say what they do or don't like about it, and so on.


--Paul Hoffman

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

Re: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

[Hosnieh Rafiee]

If there is extension on last call, I would like to be volunteer  reviewer
the document.
Best,
Hosnieh


> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman
> Sent: Thursday, July 16, 2015 9:53 PM
> To: dnsop WG
> Subject: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-
> cookies
> 
> 
> 
> Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to
end
> today, but it got extremely little review during the Last Call. It would
be helpful
> to all of us if more people can review the document, say what they do or
don't
> like about it, and so on.
> 
> --Paul Hoffman
> 
> ___
> 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] I-D Action: draft-ietf-dnsop-5966bis-02.txt

[Shane Kerr]

All,

Replying to both John & Ray's mails at once here. Hopefully that is
okay.

On Thu, 16 Jul 2015 17:22:38 +0100
Ray Bellis  wrote:

> On 16/07/2015 17:10, John Dickinson wrote:
> > 
> > 
> > On 14/07/2015 11:31, Shane Kerr wrote:
> >>
> >> Second, one possible issue for consideration is that it is already a
> >> problem for resolver operators that a single query can cause a *lot* of
> >> work for the resolver. This issue can be magnified with TCP pipelining:
> >> a bad actor can connect to a resolver and queue a ton of queries in a
> >> few packets (consider how many queries will fit in 1460 bytes).
> > 
> > Do you feel this is worse than flooding a server with UDP? Should we
> > have rate limiting?

I think it is worse than flooding with UDP. It allows "fire and forget"
actions from clients:

   # we can comfortably fit 20 queries into a single 1280-byte packet
   for i = 1 to 20:
   packet.append(EXPENSIVE_QUERY)
   conn = socket.connect_tcp("someserver", port=53)
   conn.write(packet)
   # the process can quit and the queries still go...
   exit(0)

If you have (for example) a maximum of 5 queries per client, then as
soon as one finishes you'll start another one. All from a 7-packet
exchange on the client side, versus a 40-packet exchange with UDP.
(See, TCP can be more efficient!!!)

The goal of this could be load on the resolver, load on upstream
authoritative servers, or something more creative

> I think the pipelining is a non-issue, or rather one that already exists.
> 
> In practise most (if not all) existing DNS servers that support TCP
> already suffer this potential problem.

True.

It's not clear to me whether out-of-order processing makes pipelining
better or worse, actually.

But perhaps a document about TCP in DNS might want to mention this
issue?

> When the client sends a whole series of queries down the connection
> without waiting for an answer in general this "just works" because
> servers don't routinely flush the incoming TCP read buffer every time
> they respond to a packet.

I don't even think there is a race-free way to flush the incoming
TCP read buffer. :P

Cheers,

--
Shane

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

[Ray Bellis]

On 16/07/2015 22:41, Shane Kerr wrote:

I think it is worse than flooding with UDP. It allows "fire and forget"
actions from clients:

# we can comfortably fit 20 queries into a single 1280-byte packet
for i = 1 to 20:
packet.append(EXPENSIVE_QUERY)
conn = socket.connect_tcp("someserver", port=53)
conn.write(packet)
# the process can quit and the queries still go...
exit(0)


That shoudn't be possible - as soon as the client side exits the socket 
will get closed and any subsequent writes from the server side will 
generate an error.  AIUI, some IP stacks will even flush the read buffer 
if they detect a fully closed socket?

If you have (for example) a maximum of 5 queries per client, then as
soon as one finishes you'll start another one. All from a 7-packet
exchange on the client side, versus a 40-packet exchange with UDP.
(See, TCP can be more efficient!!!)

The goal of this could be load on the resolver, load on upstream
authoritative servers, or something more creative

I don't think that works (per above)

True.

It's not clear to me whether out-of-order processing makes pipelining
better or worse, actually.

But perhaps a document about TCP in DNS might want to mention this
issue?
Perhaps.  I do see out-of-order processing as a somewhat larger issue 
than pipelining, though, simply because the possibility exists that some 
clients will assume that the packets come back in request order, and 
fail to check the QID.
I don't even think there is a race-free way to flush the incoming TCP 
read buffer

That might explain why it's not done ;-)

Ray

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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

>> Well, even worse, what happens if  decides to 
>> create a new dns-like protocol that uses .foo, does that mean that we should 
>> automatically block it?
> 
> No.   We can add it to the special-use domain name registry if the IETF has 
> consensus to do so, but there's nothing automatic about it, as Christian 
> Grothoff can testify.

Interesting choice: .FOO already exists. How is the IESG going to make a 
decision about whether to pre-empt Charleston Road Registry's use of that TLD 
in favor of 's use of that name?

Regards,
-drc



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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

Ted,

> To expand on this ever so slightly, the reason why things like this happen is 
> because the process for approving special-use allocations is perceived as too 
> heavyweight, so people don't bother to do it in anticipation of an experiment.

To be honest, I doubt this. It assumes folks who are developing these non-DNS 
protocols know/care about what the IETF thinks.

> If we want to avoid future instances of squatting, it behooves us to avoid 
> applying too much process friction onto documents of this type.   Granted, 
> it's hard to tell how much is too much, but this particular discussion was 
> kicked off in November of 2013, and here it is July of 2015, and we are still 
> talking about it.   That's a pretty heavy process.

I agree on the need for less friction, hence my interest in trying to find 
objective criteria. Lack of objective criteria pretty much guarantees the same 
sort of discussion and 'heavy process' you're complaining about.

Regards,
-drc



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

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Paul Vixie]

David Conrad wrote:
>>> Well, even worse, what happens if  decides to 
>>> create a new dns-like protocol that uses .foo, does that mean that we 
>>> should automatically block it?
>> No.   We can add it to the special-use domain name registry if the IETF has 
>> consensus to do so, but there's nothing automatic about it, as Christian 
>> Grothoff can testify.
>
> Interesting choice: .FOO already exists. How is the IESG going to make a 
> decision about whether to pre-empt Charleston Road Registry's use of that TLD 
> in favor of 's use of that name?

we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC that
describes as much as is possible to describe about that use.

-- 
Paul Vixie

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