Re: [Anima] [dnssd] CoAP resource discovery and DNS-SD

[Toerless Eckert]

My concern is if/how we can specify MTI (Mandatory to implement) zero-touch
interoperable requirements for discovery.

In our non-constrained ANIMA work (ANI), we have MUST requirements sufficient 
for
zero-touch discovery/interoperability (via GRASP).

If we can find an agreeable MTI, then we can put it into a section that
says something like "these discovery requirements are REQUIRED, unless an
installation-type specification (IETF or non-IETF) replaces/amends them"

installation-type = mesh-type = (6TiSCH, Thread, ISA 100 Wireless, JupiterMesh, 
Wi-SUN FAN, etc)

If i go with coap/core-link, i can simply use coap over ff05::fd to
discover the registrar. That is just expecting L3 multicast in the LLN,
which luckily does sem to exist in networks such as thread and hopefully
to know the registrar all the time). And we have IETF protocols such as
MPL to support L3 multicast in LLN.

For DNS-SD i wouldn't know a standardized zero-touch method to discover
a DNS-SD/SRP server for an l3 network because mDNS is not intended to work 
across
L3 hops but just link-local (at least with IETF standards). RFC8766
seems also like a non-zero touch optiond and complexity mismatch given
how we likely wouldn't want to use it for ongoing discovery (but just
unicast-DNS with SRP).

We could specify that installation-types supporting discovery of a
server that is known to support unicast-DNS-SD/SRP would use that
to discover  the registrar, and the registrar would register itself.
And in minimum deployments, the registrar itself would run DNS-SD/SRP server.

Thoughts ?

Toerless


On Wed, May 18, 2022 at 08:18:48AM +, Esko Dijk wrote:
> Thanks for the example. I also don’t have a number-of-bits / round-trips 
> comparison at hand. There are various alternatives now (GRASP, CoAP 
> discovery, CoRE RD, DNS-SD SRP, mDNS, and ‘proprietary’ including the 
> distribution of Registrar location in network-wide config data).
> In the selection of protocol efficiency / traffic reduction plays a role, but 
> certainly also aspects like footprint, code re-use & maintainability, 
> security (e.g. the less protocols on a device, the lower the attack surface) 
> and familiarity with certain protocols.
> 
> For these reasons one implementer or standard may want to choose GRASP, while 
> another chooses DNS-SD SRP or CoAP discovery. All these implementations will 
> then not be mutually interoperable. But is this a problem?
> The key thing is that within a single interoperable (IPv6) mesh standard 
> (e.g. 6TiSCH, Thread, ISA 100 Wireless, JupiterMesh, Wi-SUN FAN, etc) that 
> would choose to support BRSKI, or Constrained BRSKI, one particular method is 
> chosen and then also tested/certified for interoperability.
> So the right details would be defined in those standards bodies for sure.
> 
> That said, it would be good if IETF can define the best discovery options for 
> Constrained BRSKI and how to use those – e.g. as we do for GRASP in BRSKI.  
> Similar details could be added for some of the other alternatives, perhaps.
> 
> Esko
> 
> 
> From: Ted Lemon 
> Sent: Wednesday, May 18, 2022 02:01
> To: Toerless Eckert 
> Cc: Esko Dijk ; dn...@ietf.org
> Subject: Re: [dnssd] CoAP resource discovery and DNS-SD
> 
> Bear in mind that with dns name compression, you don’t repeat any domain 
> name—you just store a pointer for each subsequent repetition of the same 
> terminal label sequence. So default.service.arpa is a little longer, but 
> doesn’t multiply.
> 
> On Tue, May 17, 2022 at 17:28 Toerless Eckert 
> mailto:t...@cs.fau.de>> wrote:
> Thanks, Esko
> 
> Actually a client would discover a new service instance with quering the PTR 
> RR,
> so rfc6763 12.1. is relevant, but yes, it does  ask to include all dependent 
> RRs.
> Here is what i think is the minimum generic case for a single service 
> instance with one locator address.
> 
> _service-name._udp.localPTR   
> service-instance-name._service-name._udp.local
>  service-instance-name._service-name._udp.local SRV   prio weight port 
> service-instance-locator.local
>  service-instance-name._service-name._udp.local TXT   'key=value;...'
>  service-instance-locator.local   IPv6-addr
> 
> I have not tried to figure out how many bits that would be, especially in 
> comparison
> to coap/core-link encoding.
> 
> Actually, when one uses only unicast DNS and SRP, i guess you wouldn't
> use .local, but .default.service.arpa, which would make all the messages 
> somewhat bigger
> (thinking about how the ANIMA REST URLs where explicitly shortened, but then 
> DNS
>  adds the overhead back ...). I wonder how much of those details are better 
> defined
> in the ANIMA drafts so that we do ensure interoperability...
> 
> Cheers
> Toerless
> 
> On Tue, May 17, 2022 at 04:08:48PM +, Esko Dijk wrote:
> > Toerless, there was also the below point in your mail:
> >
> > > In coap, like in GRASP, we can map all necessary service elements into
> > > a 

[Anima] Artart last call review of draft-ietf-anima-constrained-join-proxy-10

[Rich Salz via Datatracker]

Reviewer: Rich Salz
Review result: Ready with Nits

A block diagram that show the participants and the protocols (like DTLS or
RFC4944, etc) would be very helpful to someone new to this field.  Like me.

Sec 1.
"Once a Pledge is enrolled, it can act as constrained Join Proxy between other
Pledges and the enrolling Registrar."  Is that a special function of JP-based
enrollment, or could anyone in the mesh be a JP? The 1,2 item list has a
spurious "that" in the second entry. The "Similar to..." part in the last
paragraph is a sentence fragment.

Sec 4.
Oh, you have a diagram here.  Spread out the distance between R and J so that
"multi-hop" fits on one line maybe. Consider adding to it and moving it to Sec
1.  Or at least in Sec 1 have a forward pointer. Repeating "(P)" and "(J)"
after the first instance is distracting. Type "untill" in last paragraph. Why
is "legal" in quotes? "An enrolled device can..." same question as above: ANY
enrolled device could?

Sec 5.1
Maybe "such as by" instead of "for example" The parenthetical about "Discovery
can also" and the sentence about DNS-SD probably belong in section 6.  In
Figure 2, I was briefly confused by the label "Src_IP" and the content having
"IP_p" etc.

Sec 5.2
The phrase "but may also reduce" maybe "and may also reduce"? Is are paragraphs
2 and 3 redundant?  Why use JPY and not, say, SJP?  "The registrar should not
assume..."  KEY POINT.

Sec 5.3
Why does the text say "ifindex" but the Figure 4 CDDL says "index"? Since there
can be more than five elements, what is the meaning of extra elements? Ignore
them? Maybe MUST send only five? "Completely opaque to the receiver" really
means the receiving Registrar, right?

Sec 6
I was confused about "near" and "remote"  Maybe "near and far" or "local and
remote" ? The rest of Sec 6, describing the different discovery methods seems
reasonable.  (I am not well-qualified to say more than that)

Sec 7
This could be moved into 5 as a new subsection. If not, sec 5 should have a
forward pointer to the comparison.

Sec 8
I like the list of possibilities for evil, and why they're not new. The "enroll
itself" item should have the last two sentence fragments merged "With ..., the
chance ..."  Next item "Also this is assumed" maybe "This, too, is assumed"  I
think you could bundle all of the items which require having the private key,
for example, and point out that you depend on the security of DTLS to prevent
these things, rather than say "unlikely"


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10

[Spencer Dawkins at IETF]

Peter,

On Wed, May 18, 2022 at 2:06 AM Peter van der Stok 
wrote:

> HI Esko, Spencer,
>
> I will add a sentence in at the end of section 5.3.
>
> It is recommended to use the block option [RFC7959] and make sure that the
> block size allows the addition of the JPY header without violating MTU
> sizes.
>
> thanks for the reminder,
>

Oh, thank you!

Best,

Spencer


> Peter
>
> Spencer Dawkins at IETF schreef op 2022-05-17 17:31:
>
> Hi, Esko,
>
> On Tue, May 17, 2022 at 4:37 AM Esko Dijk 
> wrote:
>
> Hi Peter, Spencer,
>
>
>
> For some more detail on Peter's 'No' answer:
>
>
> I was expecting that answer. 
>
> Thanks for the additional details!
>
>
>
>
> Since the Pledge communicates (link-local) with the Join Proxy using
> DTLS-over-UDP on a network that is likely 6LoWPAN (1280 byte MTU limit)
> mesh, it could happen in theory that the Pledge sends out a DTLS handshake
> UDP packet with a length that brings the carrying IPv6 packet length at
> 1280.
>
> In this case the DTLS record size is also something close to 1280. (We
> never did the exact calculations.)
>
>
>
> This may pose a problem for the stateless Join Proxy that appends a few
> bytes to the DTLS record (to relay it further to the Registrar) so the
> total length of the IPv6 packet sent to Registrar could exceed 1280. (And
> the Join Proxy is still on the mesh network with 1280 byte MTU).
>
> But in any case in the constrained-voucher draft we have written about
> this:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-6.7
>
>
>
> So even though we don't know for sure it is a problem, as we haven't done
> the calculations in detail, it's preemptively solved by recommending the
> Pledge to break up the handshake into smaller parts. Then,  the Join Proxy
> doesn't need to do anything special anymore and it always works.
>
> That also helps with performance on the mesh network due to reduction of
> 6LoWPAN fragmentation.
>
>
> @Spencer do you think the Constrained Join Proxy draft should mention the
> potential issue also?  E.g. a reference to above section 6.7 is easy to
> make.
>
>
> The reference you described is exactly what I was thinking of (I was more
> familiar with COAP before blockwise transfer was specified in
> https://datatracker.ietf.org/doc/rfc7959/, but I knew it had been
> standardized).
>
> If you can preemptively avoid a potential problem by adding a reference to
> the document and section you provided, without slowing this document down,
> that would be great.
>
> And thanks again for a quick response to a really late directorate review.
>
> (I know we're not talking about
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher,
> but I didn't see RFC 7959 listed as a reference there, and it seems like
> that should be normative. But do the right thing, of course!
>
> Best,
>
> Spencer
>
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Anima  *On Behalf Of * Peter van der Stok
> *Sent:* Tuesday, May 17, 2022 10:22
> *To:* Spencer Dawkins 
> *Cc:* tsv-...@ietf.org; anima@ietf.org;
> draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@ietf.org
> *Subject:* Re: [Anima] Tsvart last call review of
> draft-ietf-anima-constrained-join-proxy-10
>
>
>
> Hi Spencer,
>
> thanks for your kind words.
>
> Indeed the answer is no. (at least for the coming 20 years).
>
> Greetings and thanks,
>
> Peter
>
> Spencer Dawkins via Datatracker schreef op 2022-05-17 01:09:
>
> Reviewer: Spencer Dawkins
> Review result: Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-...@ietf.org if you reply to or forward this review.
>
> This is a well-written specification. My only question - and I expect the
> answer will be "no" - is whether there is any concern that sizes of the
> resources that are being passed around might exceed the MTU between the
> pledge
> and the registrar, and whether there should be a mention of this
> possibility in
> the specification.
>
> Best,
>
> Spencer
>
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Constrained BRSKI - discovery of Registrar as a security risk ?

[Esko Dijk]

Hello,

There is one particular security aspect for Constrained BRSKI that I think has 
not been discussed so far. It is the following: a device that needs to locate 
the Registrar may do this using discovery. Particular cases:

  1.  Join Proxy discovers the Registrar  (to which to relay DTLS records from 
a Pledge)
  2.  Already-enrolled device discovers the Registrar (to renew its certificate 
using EST, e.g. if it is about to expire)

Now there are various discovery protocols that could be used by a client, but 
most of these are not secured i.e. it lacks authentication that a discovered 
Registrar is actually a real, authentic Registrar. Any on-network (or on-link, 
in case of link-local discovery) attacker node could claim to be a Registrar.
For case 2 above the client can easily authenticate the Registrar once doing 
its DTLS connection to it. If it doesn’t check out, the client can try the next 
Registrar in the list.
But for case 1 the Join Proxy doesn’t authenticate the Registrar – that would 
be a task of the Pledge.  So the Join Proxy might just pick a ‘malicious’ 
Registrar instead of the real one.

For BRSKI + GRASP I understand the risk of a ‘malicious’ Registrar is reduced 
by operation on the autonomic control plane, separate from the user plane 
traffic. Every device that onboards there is authenticated. But for Constrained 
BRSKI use cases where the 6LoWPAN Border Routers do *not* join an autonomic 
control plane, and/or the mesh network also doesn’t provide a separated control 
plane,  this risk may be non-neglible as I understand it. For example if a 
small-site network uses unprotected Ethernet an attacker could just plug in a 
fake-Registrar device.

For case 1 if the Join Proxy selects the ‘wrong’ Registrar this can then result 
in a DoS situation, in which the Pledge cannot onboard. So it would need to 
select a new, other Join Proxy with a high risk of running into the same 
problem again. This only causes DoS for the Pledge.
Also the Pledge will provisionally accept any Registrar (authentication only 
happens afterwards when it receives the Voucher).  So in case that the MASA 
server is applying a TOFU (Trust On First Use) policy for Domains it doesn’t 
know, the Pledge may then become onboarded into the wrong (malicious) domain.

For reference, BRSKI RFC 8995 writes:


   A MASA without any supply-chain integration can simply accept

   registrars without any authentication or on a blind TOFU basis as

   described in Section 
7.4.2.

   ...

   A MASA has the option of not verifying ownership before responding

   with a voucher.  This is expected to be a common operational model

Doing that would lead to a “Pledge hijack” risk. So how should this be 
addressed?

  1.  Make Registrar discovery more secure in some way so that only authentic 
Registrars are discovered?
  2.  Require that a Registrar can authenticate in some way to the MASA server 
?   (Stronger than “RECOMMENDED” as now in 8995)
  3.  Enforce operation of Constrained BRSKI only on some separate, secured 
control plane? (E.g. require Border Routers to use BRSKI to onboard into an 
autonomic control plane)
  4.  We add a note to the Constrained BRSKI security considerations on this 
and leave it up to the implementer?

Regards
Esko

IoTconsultancy.nl  |  Email/Teams: 
esko.d...@iotconsultancy.nl|   +31 6 
2385 8339

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10

[Peter van der Stok]

 HI Esko, Spencer,

I will add a sentence in at the end of section 5.3.

It is recommended to use the block option [RFC7959] and make sure that 
the block size allows the addition of the JPY header without violating 
MTU sizes.


thanks for the reminder,

Peter
Spencer Dawkins at IETF schreef op 2022-05-17 17:31:


Hi, Esko,

On Tue, May 17, 2022 at 4:37 AM Esko Dijk  
wrote:



Hi Peter, Spencer,

For some more detail on Peter's 'No' answer:


I was expecting that answer. 

Thanks for the additional details!

Since the Pledge communicates (link-local) with the Join Proxy using 
DTLS-over-UDP on a network that is likely 6LoWPAN (1280 byte MTU 
limit) mesh, it could happen in theory that the Pledge sends out a 
DTLS handshake UDP packet with a length that brings the carrying IPv6 
packet length at 1280.


In this case the DTLS record size is also something close to 1280. (We 
never did the exact calculations.)


This may pose a problem for the stateless Join Proxy that appends a 
few bytes to the DTLS record (to relay it further to the Registrar) so 
the total length of the IPv6 packet sent to Registrar could exceed 
1280. (And the Join Proxy is still on the mesh network with 1280 byte 
MTU).


But in any case in the constrained-voucher draft we have written about 
this:


https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-6.7

So even though we don't know for sure it is a problem, as we haven't 
done the calculations in detail, it's preemptively solved by 
recommending the Pledge to break up the handshake into smaller parts. 
Then,  the Join Proxy doesn't need to do anything special anymore and 
it always works.


That also helps with performance on the mesh network due to reduction 
of 6LoWPAN fragmentation.


@Spencer do you think the Constrained Join Proxy draft should mention 
the potential issue also?  E.g. a reference to above section 6.7 is 
easy to make.


The reference you described is exactly what I was thinking of (I was 
more familiar with COAP before blockwise transfer was specified in 
https://datatracker.ietf.org/doc/rfc7959/, but I knew it had been 
standardized).


If you can preemptively avoid a potential problem by adding a reference 
to the document and section you provided, without slowing this document 
down, that would be great.


And thanks again for a quick response to a really late directorate 
review.


(I know we're not talking about 
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher, 
but I didn't see RFC 7959 listed as a reference there, and it seems 
like that should be normative. But do the right thing, of course!


Best,

Spencer

Regards

Esko

From: Anima  On Behalf Of Peter van der Stok
Sent: Tuesday, May 17, 2022 10:22
To: Spencer Dawkins 
Cc: tsv-...@ietf.org; anima@ietf.org; 
draft-ietf-anima-constrained-join-proxy@ietf.org; 
last-c...@ietf.org
Subject: Re: [Anima] Tsvart last call review of 
draft-ietf-anima-constrained-join-proxy-10


Hi Spencer,

thanks for your kind words.

Indeed the answer is no. (at least for the coming 20 years).

Greetings and thanks,

Peter

Spencer Dawkins via Datatracker schreef op 2022-05-17 01:09:

Reviewer: Spencer Dawkins
Review result: Ready

This document has been reviewed as part of the transport area review 
team's
ongoing effort to review key IETF documents. These comments were 
written
primarily for the transport area directors, but are copied to the 
document's
authors and WG to allow them to address any issues raised and also to 
the IETF

discussion list for information.

When done at the time of IETF Last Call, the authors should consider 
this

review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

This is a well-written specification. My only question - and I expect 
the

answer will be "no" - is whether there is any concern that sizes of the
resources that are being passed around might exceed the MTU between the 
pledge
and the registrar, and whether there should be a mention of this 
possibility in

the specification.

Best,

Spencer___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima