Re: [dnssd] SRP: name conflict while not knowing which name conflicts

[Ted Lemon <[e-mail]>]

Thanks, I've made that change.

diff --git a/draft-ietf-dnssd-srp.xml b/draft-ietf-dnssd-srp.xml
index 90a8b3c..0cb57ae 100644
--- a/draft-ietf-dnssd-srp.xml
+++ b/draft-ietf-dnssd-srp.xml
@@ -599,7 +599,7 @@
             to respond either with no RRs or to copy the RRs sent by the
client into the response. The SRP Requestor MUST NOT attempt
            to validate any RRs that are included in the response. It is
possible that a future SRP extension may include per-RR
            indications as to why the update failed, but at present this is
not specified, so if a client were to attempt to validate
-            the RRs in the response, it might reject such a response,
since it would contain RRs, but probably a set of RRs
+            the RRs in the response, it might reject such a response,
since it would contain RRs, but probably not a set of RRs
            identical to what was sent in the SRP Update.</t>
        </section>
        <section>

On Wed, Oct 12, 2022 at 7:26 AM Esko Dijk <[e-mail]>
wrote:

> Thanks Ted,
>
>
>
> That’s quite clear now, except for a nit in the final sentence:
>
>
>
> but probably a set of RRs identical to
>
>    what was sent in the SRP Update.
>
>
>
> We could change it to:
>
>
>
> but probably *not* a set of RRs identical to
>
>    what was sent in the SRP Update.
>
>
>
> PS I will review the other changes to the documents (SRP and UL) asap.
>
>
>
> Regards
>
> Esko
>
>
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Thursday, October 6, 2022 16:48
> *To:* Esko Dijk <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> I've updated section 2.3.5 as follows:
>
>
>
>            <t>
> -           The status that is returned depends on the result of
> processing the update, and can be either NoError or ServFail: all
> +           The status that is returned depends on the result of
> processing the update, and can be either NoError, ServFail, Refused or
> YXDomain: all
>             other possible outcomes should already have been accounted for
> when applying the constraints that qualify the update
> -           as an SRP Update.</t>
> +           as an SRP Update. The meanings of these responses are
> explained in <xref target="RFC2136" section="2.2"/>.</t>
> +         <t>
> +           In the case of a response other than NoError, <xref
> target="RFC2136" section="3.8"/> specifies that the server is permitted
> +            to respond either with no RRs or to copy the RRs sent by the
> client into the response. The SRP Requestor MUST NOT attempt
> +           to validate any RRs that are included in the response. It is
> possible that a future SRP extension may include per-RR
> +           indications as to why the update failed, but at present this
> is not specified, so if a client were to attempt to validate
> +            the RRs in the response, it might reject such a response,
> since it would contain RRs, but probably a set of RRs
> +           identical to what was sent in the SRP Update.</t>
>         </section>
>
>
>
> (The text indicating that the only possible error was ServFail was of
> course incorrect. I think the text was originally intended to talk about
> RCODEs other than those mentioned earlier, but the text was pretty
> confusing when I read it, hence the update.)
>
>
>
> On Mon, Oct 3, 2022 at 10:02 AM Esko Dijk <[e-mail]>
> wrote:
>
> Yes, would agree to adding a sentence on that. Best places in the document
> for this are:
>
>
>
> 2.2.5.2 “Name Conflict Handling”  (close to the YXDomain response
> explanation) , or
>
> 2.3.5 “SRP Update response”    (covers SRP-specific aspects of the
> response, in general)
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Monday, September 26, 2022 16:59
> *To:* Esko Dijk <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> RFC 2136 has some specific language here, so we can mostly refer to that,
> but I think to address your concern we should explicitly say that any
> records sent in the response should be silently ignored. We can specify
> some additional behavior in a follow-on document if it makes sense.
>
>
>
> Op ma 26 sep. 2022 om 10:50 schreef Ted Lemon <[e-mail]>
>
> Maybe we should write some conformance tests that send unknown options. :)
>
>
>
> But yes, I think you’re right.
>
>
>
> Op ma 26 sep. 2022 om 10:49 schreef Esko Dijk <[e-mail]
> >
>
> Hi Ted,
>
>
>
> I would still be in favor to insert a sentence about the possible use of
> the answer records (in case of an error) in the future.
>
>
>
> > But right now we have no text at all about how the client interprets rrs
> in the response, so I think even this is unnecessary. If it does something
> with them, it’s out of spec.
>
>
>
> In my years of experience with how software development works, an
> implementer somewhere is bound to check incoming messages very precisely
> against what the implementer thinks it should be -- never mind the spec.
> The robustness principle isn’t automatically applied, now in times of
> security breaches everywhere. It’s rather becoming “if the input looks
> slightly different from the usual, it must be wrong” and extra checks are
> coded in everywhere without thinking about extendibility.  I have seen
> implementations where nice TLVs are defined for extendability, and then
> Version 1 implementations discard any message received with an unknown TLV
> type, such that the future Version 2 implementations could never use a new
> TLV type anymore, i.e. the extendibility that was defined doesn’t exist
> anymore in practice.
>
>
>
> Especially in our case  since the base spec DNS Update precisely tells
> what the response fields can be, we have to say here that SRP deviates:
> that it can contain something else. (Which is then defined in the future,
> maybe, or maybe not.)
>
>
>
> But if the rest disagrees for good reasons then we should not add any
> text.  This additional text would have zero code impact.
>
>
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Friday, September 23, 2022 18:47
> *To:* Esko Dijk <[e-mail]>
> *Cc:* Kangping Dong <[e-mail]>; Tim Wicinski <[e-mail]>;
> [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> I just have no idea what problem you are solving here. And no, we do not
> know how to represent this in the response.
>
>
>
> I get that you have some ideas about how this could be used, but that’s
> not what I’m asking. What I’m asking is, what /problem/ does this solve?
> What bad thing happens if we don’t do this, and how does doing this make it
> better? And to be clear, by “problem” I mean “what bad experience will the
> user have that will be less bad if we do this?” Having to rename at all is
> a catastrophe. We might make that catastrophe trivially smaller. How does
> that materially benefit the end user?
>
>
>
> As for representation, right now the response can contain the update,
> verbatim. We need to specify in detail a response format that the client
> can unambiguously interpret as listing names that were in conflict. I’m not
> saying this is hard, just that we have to write it up, implement it, test
> it, feel confident it works.
>
>
>
> What we have in the document now describes what we have implemented and
> extensively interop tested. To meet that standard for this proposed update
> is at least a year of work.
>
>
>
> So if we want to do this in this document, we need a really, REALLY, good
> reason, not some ideas about how it could be used.
>
>
>
> But the bottom line is that this is harmless. If it’s useful to do this
> year’s work, let’s just do it in a follow-on document. But I really
> strongly urge you not to insist on doing it in this document. It’s not as
> small a change as you are imagining.
>
>
>
> Regarding preparing the client for this, the new spec would say how the
> client should handle this, so I don’t think that’s necessary. An existing
> client can be expected to ignore whatever is sent by a new implementation.
>
>
>
> I guess we could say that the client MUST ignore any RRs in the response.
> But right now we have no text at all about how the client interprets rrs in
> the response, so I think even this is unnecessary. If it does something
> with them, it’s out of spec.
>
>
>
> Op vr 23 sep. 2022 om 11:42 schreef Esko Dijk <[e-mail]
> >
>
> > It took you ten paragraphs to explain what the client would do with this
> information
>
> That was just explaining the benefits. Hence the more, the better. It’s
> just a perfect solution if you just want to be prepared for all possible
> futures with a minimum of effort and no nasty dependencies. It’s the
> equivalent of our local high school recommending yesterday for pupils to
> take the “STEM” profile in case they don’t know yet what future job to do
> because it leaves a maximum of options still open.  Only, less difficult to
> execute ;-)
>
>
>
> But we can also do without solving this particular issue and avoid another
> WGLC – because we do have simple name-change solutions for the SRP client
> that work already (as you also indicated).  So if we foresee potential
> issues/complexity here maybe better leave it for a later time.
>
>
>
> About the format definition: we already know how to include records into a
> DNS response so don’t agree to your point there. But true, it will take
> more than 1 sentence to explain such a new feature – maybe an entire
> subsection to do it right.
>
>
>
> Can’t we just say the SRP client MUST be prepared to receive something in
> Additional records of YXDomain, whatever it is? Just to pave the way for
> our potential future new draft. (Otherwise the SRP client may ignore the
> response as “invalid” and not heed it.)
>
> That would only be one sentence and requires no code.
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Friday, September 23, 2022 17:14
> *To:* Esko Dijk <[e-mail]>
> *Cc:* Kangping Dong <[e-mail]>; Tim Wicinski <[e-mail]>;
> [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> Eskimo, I beg to differ on the idea that this change is simple. It took
> you ten paragraphs to explain what the client would do with this
> information. We don’t know how to encode it in the response, so we have to
> invent that. We don’t have any implementations of it. So its a really big
> deal to suggest this change now, after WGLC. If this is important, I think
> someone who is interested should write up a draft proposing a solution and
> ask the WG to adopt it.
>
>
>
> Adding this to SRP now will mean that SRP standardization will take about
> an additional year, if we move very fast. I don’t think this is remotely
> worth it.
>
>
>
> Op vr 23 sep. 2022 om 10:24 schreef Esso Dijk <[e-mail]
> >
>
> Fully agree that we should not do the “renaming by the registrar” part.
> There’s some additional complexity implied by this and things that may
> break interoperability.
>
>
>
> > the leftmost label in the service instance name is the same as the
> leftmost label in the hostname
>
> This is how some implementations may work, but there’s many others that
> don’t. So we can’t make generic assumptions on naming choices.
>
> In any case a smart SRP client that picks its names like this will simply
> rename both – no additional complexity for the client then.
>
>
>
> Despite this, it is fairly simple if we say the SRP registrar SHOULD
> insert any conflicting record(s) that it knows about into the response. As
> I argued before, this doesn’t change any of the procedures we have defined
> in SRP so far.
>
>
>
> And it leaves a great amount of freedom to implementations without
> apparent disadvantages, and without interop problems:
>
>    - A SRP client that doesn’t want to bother parsing the SRP Update
>    response, can just ignore the Additional records in the YXDomain response.
>    It can apply its strategy of “change both names” for example as discussed
>    above.
>    - An SRP registrar that is on a constrained device, or just doesn’t
>    want to bother, can include 0 Additional records (equivalent to saying “I
>    don’t know what the conflict is”) which is acceptable too.
>    - An SRP registrar that is an existing implementation that people
>    don’t want to change, is still compliant.
>    - An SRP client that is an existing implementation that people don’t
>    want to change, is still compliant.  (Maybe it takes some more retries to
>    get registered – but that’s no big problem.)
>    - If in the future an SRP client gets upgraded to a “smarter” client
>    that can detect the conflicts enlisted in the YXDomain response, it may
>    become more efficient. This upgrading is independent of servers’ upgrading
>    or not.
>    - If in the future an SRP server gets upgraded to a “smarter” server
>    that can returns conflicts in the YXDomain response, things may become more
>    efficient. This upgrading is independent from clients’ upgrading or not.
>    - If the Matter approach to names wins and conflicts hardly occur for
>    this reason, and hence no-one implements the conflicting-records feature,
>    then nothing is lost – we just have a small bit of junk-DNA like text in
>    the SRP RFC.
>
>
>
> So the idea is to recommend returning known-conflict records FYI to the
> client and leaving the client free to pursue any naming strategy.
>
>
>
> Esko
>
>
>
>
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Friday, September 23, 2022 15:59
> *To:* Tim Wicinski <[e-mail]>
> *Cc:* Esko Dijk <[e-mail]>; Kangping Dong <
> [e-mail]>; [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> Okay, as I dig deeper into this, I'm realizing that things have changed /a
> lot/ since we had this conversation. First of all, for Matter accessories,
> name changes by the server are simply unacceptable. So the idea that we're
> going to signal back to the SRP client that we changed the name is no
> longer really necessary, because we aren't going to change the name. The
> current Apple Advertising Proxy implementation never does renaming.
>
>
>
> If there is a name conflict, we report it, but we have done a /lot/ of
> work to avoid gratuitous name conflicts, and I think that that work is
> actually what we should be relying on here. Effectively what we've done is
> to make the advertising proxy look more like an authoritative name server,
> and as we agreed in the discussion Kangping found, we are never going to do
> this when the SRP server is an authoritative name server.
>
>
>
> What we've done here is the TSR draft and the SRP replication draft. The
> TSR draft prevents gratuitous name conflicts when two advertising proxies
> are not doing SRP replication. The SRP replication protocol provides a way
> for multiple advertising proxies to sustain a consensus, so that conflicts
> don't occur. Between these two drafts (really, between their
> implementations) we no longer see renaming happening with our advertising
> proxies.
>
>
>
> As we move more toward unicast DNSSD as the baseline, with mDNS as the
> exception, I think that the likelihood of conflicts will drop further.
>
>
>
> My point is, do we really want to add this complexity in SRP? What is the
> problem we are trying to solve here? Most of the time, the way names are
> chosen is deterministic—the leftmost label in the service instance name is
> the same as the leftmost label in the hostname. And so if there is a name
> conflict on one, it's going to be on the other as well.
>
>
>
> So what I think we should actually do is leave the document the way it is.
> Doing what we're talking about here will create a great deal of complexity
> in the client and in the server, at a very late stage in the development of
> the protocol, with no obvious benefit.
>
>
>
> Thoughts?
>
>
>
> On Fri, Sep 23, 2022 at 9:27 AM Tim Wicinski <[e-mail]> wrote:
>
> How about just the name(s) attempted to register with that request
> which are in conflict?
>
>
>
> I vote for being explicit on the minimum the SRP registar needs to do.
>
>
>
> also, not a chair but write up all the text changes and make sure the WG
> has no issues with that.
>
>
>
> On Fri, Sep 23, 2022 at 9:14 AM Ted Lemon <[e-mail]> wrote:
>
> Okay. I ask because we should be explicit.
>
>
>
> Chairs, how do you want to approach this? I think this is a WG consensus
> that I failed to put into the document, but we didn't last call on it, so I
> don't know that it's _actually_ consensus. Do we need a new WGLC?
>
>
>
> On Fri, Sep 23, 2022 at 9:12 AM Esko Dijk <[e-mail]>
> wrote:
>
> > So it can certainly respond with a list of the names on which it found
> conflicts, but the list might not be able to be made complete
>
>
>
> I think it should respond at least with the names that it knows are in
> conflict (based on its internal database of SRP registrations for example).
> So, 0 or more records in the response.  Zero records is our current
> specified baseline.
>
> An SRP registrar implementation that wants to put in more work can
> certainly do so – we don’t need to standardize here exactly what it should
> do for that.
>
>
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Friday, September 23, 2022 14:56
> *To:* Esko Dijk <[e-mail]>
> *Cc:* Kangping Dong <[e-mail]>; Tim Wicinski <[e-mail]>;
> [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> Aargh. Thanks for catching this Eskimo, and thanks Kangping for
> remembering the conversation. I had completely forgotten, although I recall
> it now of course.
>
>
>
> One problem with this approach is that it will not be the case that the
> SRP server necessarily knows all of the names that are in conflict. So it
> can certainly respond with a list of the names on which it found conflicts,
> but the list might not be able to be made complete without more work. Do we
> want to require it to do that work?
>
>
>
> Op vr 23 sep. 2022 om 08:07 schreef Esko Dijk <[e-mail]
> >
>
> Hi Tim,
>
>
>
> > I don't think an update to 2136 is needed here, as section 2.2.3.1
> describes the differences with an SRP registrations and 2136 Updates,
>
> but this response should be tested against a DNS update response.
>
>
>
> Clear, we can just add a bullet in 2.2.3.1 then as plain DNS Update isn’t
> updated by this draft.  What’s important then is that the server, when
> receiving a DNS Update that is not an SRP Update, will not use the new
> mechanism of including the conflicting record(s). Only do this for an SRP
> Update.
>
> And for testing: do you mean sending the “new” type of YXDomain response
> to a plain DNS Update client and see what happens?  That seems not
> necessary if the SRP registrar is careful in using the “new” response
> format only for SRP clients.
>
>
>
> Esko
>
>
>
>
>
> *From:* Tim Wicinski <[e-mail]>
> *Sent:* Friday, September 23, 2022 12:28
> *To:* Esko Dijk <[e-mail]>
> *Cc:* Kangping Dong <[e-mail]>; [e-mail]; Ted Lemon <
> [e-mail]>
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
>
>
>
>
> On Fri, Sep 23, 2022 at 4:32 AM Esko Dijk <[e-mail]>
> wrote:
>
> Thanks Kangping,
>
>
>
> It looks like including the conflicting name records in the Additional
> section is a good base solution and also easy to describe in the SRP draft,
> which does not impact the states & procedures of registrar and client.
>
> It’s just additional helpful information the client may use to compose the
> retry Update.  The part about renaming by the registrar, on behalf of the
> client, seems more tricky and may impact states & procedures which were
> just WGLC-reviewed now.
>
>
>
> If we use the Additional section for a YXDomain response, this may require
> a formal update of RFC 2136 (3.8) since DNS Update only allows a server to
> repeat all records in the (error) response or to exclude all records.
>
>
>
> Esko
>
>
>
>
>
> Esko,
>
>
>
> I don't think an update to 2136 is needed here, as section 2.2.3.1
> describes the differences with an SRP registrations and 2136 Updates,
>
> but this response should be tested against a DNS update response.
>
>
>
> Kangping, I believe this is your workflow description - I pasted it here
> to assist in my readings.
>
>
>
> 1. If a name has already been registered on the SRP server or a
> name conflict error is returned by the Advertising Proxy:
>
>     the SRP server responds with the RR that includes the conflicted name.
>
>     If the client sees such records, it knows the conflicts on the SRP
> server and will retry with a new name.
>
>
>
> 2. If a name conflict is reported to the SRP server after the SRP
> update transaction has been committed:
>
>     The next time the SRP client registers, the SRP server responds with a
> CNAME record which includes the new name.
>
>     If the client sees such records, it knows the conflict on the
> multicast link and will accept the name or retry with another name.
>
>
>
> https://mailarchive.ietf.org/arch/msg/dnssd/cUJBXN9WXBguPKtTYgPYq4bo4pQ/
>
>
>
> Tim
>
>