On 23-Nov-22 23:09, Esko Dijk wrote:
Hello Brian,
GRASP is a CBOR-based protocol and the values of GRASP objectives MUST be in
CBOR.
Yes, I was also thinking about such a solution. You could define an objective
'service announcement' and include a CBOR byte string there that encodes one or
more advertised services in today's DNS(-SD) format. And a pure-GRASP element
such as distance/range to all these services can be additionally encoded in
CBOR. Similarly an objective 'service query' is defined, with same CBOR byte
string encoding the Question(s).
... That's a substantial reduction in complexity.
True, for the GRASP node that doesn't have to include the DNS parser. And for
the programmers of it :) But another kind of complexity comes in return, that
is, documents and format definitions in the IETF (specifically now here in the
ANIMA WG). It creates a mapping of DNS onto CBOR format that is not 100%
complete. And the documents hint at future extensions to include features of
DNS to make it more complete, which means more documents, while the basic DNS
format already has all these things. Both formats may diverge in subtle ways
that will only emerge later. But I do understand the desire to 'modernize' the
DNS format; a similar effort is done in CoRE to encode a URI as a CBOR
structure which avoids a node having to do URI parsing. (It's 'preparsed' so to
speak.) But it did lead to a lot of discussions, iterations, and unexpected
semantic problems in that case.
... they had no choice, but do we seriously want to force that complexity onto
constrained nodes?
Some constrained nodes do include DNS-SD; e.g. in OpenThread the optional DNS
client has all this and looks like ~10KB compiled on an embedded platform. It's
still an impressive amount of source code though.
So I'm trying to establish what is the constraint on an ACP-node here, probably
not flash size, but rather wanting to avoid DNS code complexity which might
open up opportunities for error and (therefore) potential attacks?
What the draft does is *centralize* the lookups and the complexity. It gives
the distributed clients a central place to do lookups for them.
The draft says "Future work can also define DNS-SD <-> GRASP gateway
functions.", so a centralized gateway seems not in scope? (Gateway like GetDNSSD2.py is
implementing ...? )
Yes. I don't think it's possible to implement what Toerless proposes *without*
such a gateway, in fact.
It also says "Also, the document allows for automatically discovering DNS-SD
servers." which to me reads as the ACP-node uses GRASP to find a DNS(-SD) server and
then it can use that server in the classic way. Similar to how you discover an NTP time
server and then use that server in the classic way.
You could, but (IMHO) the only purpose of the proposal is to off-load the
DNS-SD details from the client system. In fact I find it strange that the IOT
world is not aggressively doing this (and not only for DNS-SD; for almost every
protocol that was originally designed for 1980's mini-computers and mainframes).
My strong impression of the draft is that it defines an mDNS-like lookup of
services, which services can then be used in the way they're supposed to. Any
node on the ACP could offer a particular service, like NTP, DNS, Radius, etc
and the distributed discovery then helps to find one or more (nearby) instances
of a wanted service. That doesn't look centralized to me, but maybe other
authors could chime in.
Toerless needs to answer, but do remember that the original target for ANIMA
was *not* IOT devices, but network elements in an enterprise or ISP network
Flooding is a bad idea at that scale. It's a weakness in the GRASP model and is
the motivation for work like draft-ietf-anima-grasp-distribution, but we aren't
done with that yet.
Indeed this was one of the motivations for the dnssd WG "SRP" protocol, e.g. in
context of constrained mesh networks with potentially 100s of nodes, to avoid the
all-to-all communication model of mDNS.
So the draft may emphasize some scalability recommendations, like only
advertising a few key services needed to bootstrap the system (NTP, logging,
Radius, central DNS server, ... ) and not that every ACP-node starts
advertising a bunch of services. (As that wouldn't scale.)
Agreed.
Brian
Regards
Esko
-----Original Message-----
From: Brian E Carpenter <[email protected]>
Sent: Tuesday, November 22, 2022 21:14
To: Esko Dijk <[email protected]>; [email protected]
Cc: Toerless Eckert <[email protected]>
Subject: Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04
On 22-Nov-22 23:57, Esko Dijk wrote:
Hi all,
From a DNS/DNS-SD background and interest I started looking into
draft-eckert-anima-grasp-dnssd-04. Also saw some earlier list discussion on
this topic (GRASP + DNS-SD).
It looks like the draft mainly aims to provide a “multi-hop mDNS like
functionality over an ACP by using GRASP” with unsolicited (flooded) service
announcements, plus service queries. That looks quite useful to have (looking
at draft-eckert-anima-services-dns-autoconfig-02 for the motivation for this.)
First question is, why do we want to define a separate GRASP i.e. CBOR format
for the DNS(-SD) information?
That's an easy one. GRASP is a CBOR-based protocol and the values of GRASP
objectives
MUST be in CBOR. Of course, exactly how the DNS information is respresented in
CBOR is a matter of design choice. I'll leave Toerless to explain the choice
that he proposes.
I'll just say that it wasn't too hard to implement it in Python, which is of
course a very natural language for expressing JSON-like structures. If you want
to see how I chose to do it, please see
https://github.com/becarpenter/graspy/blob/master/ASA-examples/GetDNSSD2.py
Starting at line 203, it fetches the PTR record, then looks for SRV records. If
it finds any, at line 235 it parses SRV records to extract the fields, retrieve
relevant A and AAAA and TXT records, parse them, and bundle the results into a
single JSON-like object.
Also see
https://github.com/becarpenter/graspy/blob/master/ASA-examples/AskDNSSD2.py for
the other end of a GRASP transaction. That end (the client, if you like)
doesn't need to understand or parse the DNS RRs at all, just the JSON-like
object. That's a substantial reduction in complexity.
For example in CoRE WG for constrained nodes currently the draft
draft-ietf-core-dns-over-coap-01 defines the re-use of the DNS format and no
specific redefinition of this format as CBOR. And this intends to work for
constrained nodes (like e.g. ACPna?) So if we still want to use a CBOR based
format we should have a clear motivation for this. (I understood there may be
some concerns on code size of the DNS format parser?)
Exactly. I suggest that that something like Toerless's format would be ideal,
with a server like my GetDNSSD2 doing the hard work for a whole crowd of
constrained nodes. (I'm not of course suggesting Python for that, more likely
Rust would do the job.) The transport doesn't have to be GRASP, of course (but
I happen to like it :-).
And ideally in case CoRE WG or another WG does start to define a CBOR-based DNS
format (there was talk about this at IETF 115, opportunity for even more
compact representations) then such format would ideally be equal to the one
carried in GRASP, I think. Otherwise we will have so many different formats!
Yes.
Re-using the existing DNS formats will save a lot of redefining things, now and
in the future. If there are worries that some DNS-SD features (like e.g.
‘_sub’) are too complex for ACP-nodes then the draft could focus on a
particular constrained ‘profile’ of DNS-SD that rules out such constructs. So,
a generic IETF-wide new encoding of DNS-as-CBOR is maybe useful, but doing this
for GRASP specifically? I have some doubts here.
I disagree. DNS-SD in particular is a very baroque way of using multiple DNS
RRs to express information that should be unified. I don't at all blame the
DNS-SD team for doing this, they had no choice, but do we seriously want to
force that complexity onto constrained nodes?
Second question is, do we need to better motivate in the draft the 100%
distributed nature of the service discovery mechanism?
I think that's a bit beside the point. What the draft does is *centralize* the
lookups and the complexity. It gives the distributed clients a central place to
do lookups for them. It's intrinsic to GRASP that the central lookup, GetDNSSD2
in my implementation) could in fact be duplicated for redundancy, but one
GetDNSSD2 could support hundreds of AskDNSSD2 clients.
Since the dnssd WG is now moving towards more centralized approaches, avoiding
mDNS and avoiding multicast/flooding: using Service Registration Protocol
(SRP). In this solution there are 1 or a few SRP Registrars to which nodes can
register their service(s); and DNS clients may discover those services again
using (unicast) DNS queries to one of the SRP Registrars.
I wasn't aware of that. I don't think it changes the argument though; it just
means that an SRP Registrar would be the ideal node to host a GetDNSSD2
instance.
Perhaps one motivation is that in the bootstrap scenario, no SRP Registrars are
defined yet so hence SRP cannot be used. And the case of multiple SRP
Registrars requires automatic sync’ing between Registrars which is complex /
not suitable for an ACP. And a single SRP Registrar could be possible but is
then a single-point-of-failure and nothing works if this drops out.
I'm not sure. Getting the first GetDNSSD2 instance up has the same problem as
getting the first SRP Registrar up, I suspect.
Third question, what if every ACP-node starts flooding some service(s) – is
that scalable to 100s or 1000s of nodes? Maybe we want to avoid this situation.
It wasn’t clear to me yet if such use cases are intended. E.g.
draft-eckert-anima-services-dns-autoconfig-02 mentions “SSH server” as a
service which is what every ACP-node would have.
Flooding is a bad idea at that scale. It's a weakness in the GRASP model and is
the motivation for work like draft-ietf-anima-grasp-distribution, but we aren't
done with that yet.
Regards,
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
