Hi Zahed > On 14 Dec 2023, at 09:43, Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com> > wrote: > > Hi all, > > I will take this discussion as a confirmation that the error reporting is > also applicable to DoQ. In that case, just focusing on TCP might not be the > best solution and it seems like having a general statement on source address > spoofing protection is more sensible here.
The error reporting is also applicable to DoQ. I will make that clear in the update. > The TSVART reviewer also raised question about the lack of congestion control > discussion when UDP is used as transport, that was the reason I wanted to > understand a bit more on the error reporting rate. A rate estimation can give > us some idea about the worst case scenario here. This is to make sure we have > looked into the possibility of congesting the path when we are defining > something new. I would appreciate some information on that as well. Please keep in mind that error reporting makes use of current DNS. Nothing more, nothing less. It is not that error reporting makes use of UDP, but that error reporting makes use of the DNS, with all the congestion control features (and lack thereof) that comes with DNS. Warmly, Roy > > //Zahed > > On Wed, Dec 13, 2023 at 9:52 PM Bob Harold <rharo...@umich.edu> wrote: > > On Wed, Dec 13, 2023 at 1:27 PM Joe Abley <jab...@strandkip.nl> wrote: > On 13 Dec 2023, at 18:12, Paul Wouters <p...@nohats.ca> wrote: > > > On Wed, 13 Dec 2023, Joe Abley wrote: > > > >>> On 13 Dec 2023, at 16:37, Paul Wouters <p...@nohats.ca> wrote: > >>> > >>> It should probably change TCP to “source IP validated transports (dns > >>> over stuff, tcp and udp cookies) > >> > >> Since it is possible to imagine networks in which source address spoofing > >> is not possible, and hence in which queries received over UDP could be > >> said to fit that description, any phrase like that would need a careful > >> definition. > > > > Why? If the network has a guarantee against source spoofing, isn't it by > > definition that its UDP is a "source IP validated transport" ? > > Well, because private networks leak all over the place, and I think we want > to be conservative in what we recommend is implemented. > > More generally, "validated" invites the question of who is validating what > and how, and I think there is a big set of possible answers to that question. > > >> However if we just mean "all transports currently defined that are not > >> UDP" we could just say that. Anticipating the full range of variables > >> associated with future transports that are not yet specified seems a bit > >> much. > > > > I dont think we should say that. Especially also because UDP with > > COOKIES is a source ip validated transport. > > Imagining that we fixed the phrase to accommodate the case of UDP transport > with cookies, why? > > Joe > > I like "source IP validated transport" but perhaps we could say "transports > that are protected against source address spoofing". I think that makes it > obvious what we are trying to protect against. > > -- > Bob Harold > > _______________________________________________ > 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
