Re: [dnssd] Paul Wouters' No Objection on draft-ietf-dnssd-srp-25: (with COMMENT)

[Ted Lemon <[e-mail]>]

There are two scenarios for SRP: the constrained-client case and the normal
client case. For the constrained client case, we do indeed use UDP, but in
this case we really want to keep it simple and avoid sending extra packets.
So for this use case we allow UDP but recommend that the SRP registrar
validate the incoming UDP packet to see that it's from the local link and
not some other link. In this case we're relying on the constrained link
being on a different interface than the infrastructure link, and the SRP
registrar being directly connected to that link.

There is a gap there, but I think requiring cookies is not the way out of
the problem. In the SNAC use case, if there is an infrastructure registrar,
the registrar might be one hop away from the requestor, so the interface
trick doesn't actually help in that case, and we can't use the hop count
either. We haven't ever tried to build a solution that does this, so it's a
bit of an open issue. We expect to write an additional spec that talks
about this use case, so we've simply left it unsolved for now.

In any case, the third paragraph of section 6.1 says all that we currently
have to say about this, and we don't make explicit requirements. DNS
cookies would solve this use case, but the cost would be an extra signature
on the second message and some extra traffic on a constrained network that
we'd just as soon avoid, so I really would like to leave solving this for a
later document.



On Mon, Mar 18, 2024 at 1:44 PM Paul Wouters via Datatracker <
[e-mail]> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-dnssd-srp-25: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for dropping by at the SEC AD office hours. Note there is is
> confusion
> still because I understood you said SRP is always TCP, but that does not
> seem
> to be the case if I read
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-25#section-6.1
>
> As a related argument is that SRP clients implement TCP, but might not
> implement DNS-COOKIES, and there is no advertisement/negotiation on whether
> COOKIES can be used, I think it is reasonable to not mention COOKIES as
> alternative for TCP in this case. I do hope a future rev of the spec might
> take
> cookies into consideration to avoid TCP.
>
>
>
>