Subject: [Anima-bootstrap] bootstrap over CoAP

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 8 Jul 2016 21:59:13 +0000

Folks,

As hinted at in section 5.7.5 of the 03 bootstrapping document we wanted to put some more time and thought into what a CoAP requirement and solution would look like.
	https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-03#section-5.7.5

To expand on the thinking this draft now exists:
	https://tools.ietf.org/html/draft-pritikin-coap-bootstrap-00
	
This is of course rough thoughts. Opinions and feedback strongly solicited. Pointers to other work you want this to contrast against and or details you feel worthy of additional discussion etc are all solicited. Thanks!

See you all in Berlin,

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jul 2016 22:52:35 +1200

Max,

At my level of understanding of CoAP, which is very low, this seems
to make sense. I do have a couple of questions, which probably betray
my ignorance:

1. Is CoAP/DTLS protected against corrupt packets? (Assuming we are
talking about UDP/IPv6 there will at least be the UDP checksum.)

2. In the fragmentation scenario, what happens when a fragment is
corrupted or lost?

Regards
   Brian

On 09/07/2016 09:59, Max Pritikin (pritikin) wrote:
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 09 Jul 2016 15:46:17 +0200

> talking about UDP/IPv6 there will at least be the UDP checksum.)

DTLS ciphersuites usually authenticate the packets (and protect against
replay), so there will be very strong protection.

> 2. In the fragmentation scenario, what happens when a fragment is

I'm not sure I understood that part of the draft*), but generally CoAP
is designed so you can avoid fragmentation (and use the segmentation
provided by draft-ietf-core-block instead); the latter has per-segment
reliability (acknowledgements and retransmits).   DTLS may require
fragmentation during its handshake; this is mitigated if you can use a
PSK (symmetric) or, if you need asymmetric, ECC-based ciphersuite, which
allows the packets to stay well below 1280 bytes.

Grüße, Carsten

*) We just had an interesting exchange in the CoRE WG where some people
weren't aware of the terminology that differentiates fragmentation and
segmentation; I apologize for sticking to that.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Jul 2016 06:52:50 +1200

> replay), so there will be very strong protection.

Good, that's what I hoped to hear.

> is designed so you can avoid fragmentation 

That isn't what the draft seems to say, though. However, it's clearly talking
about application-layer fragmentation to avoid IP fragmentation.

> (and use the segmentation

Right. So the app layer chops the message into <1280 byte pieces, and one
of them is lost...?

Regards
    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 09 Jul 2016 21:40:10 +0200

> about application-layer fragmentation to avoid IP fragmentation.

(that's segmentation...  I know.)

> Right. So the app layer chops the message into <1280 byte pieces, and one

Each of those segments ("blocks") is (actually, can be, but you do want
to do this with the block-wise protocol) transmitted reliably, so it
doesn't get lost.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Jul 2016 18:33:09 +1200

> to do this with the block-wise protocol) transmitted reliably, so it

OK, so I think that a couple of sentences in draft-pritikin-coap-bootstrap
could clarify all that.

Thanks
    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Sun, 10 Jul 2016 17:14:34 +0000

> On Jul 9, 2016, at 11:33 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Thank you. We can make that happen,

- max

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Jul 2016 18:07:14 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:
    >>> Each of those segments ("blocks") is (actually, can be, but you do
    >>> want to do this with the block-wise protocol) transmitted reliably,
    >>> so it doesn't get lost.
    >>
    >> OK, so I think that a couple of sentences in
    >> draft-pritikin-coap-bootstrap could clarify all that.

Further, we anticipate that we will sometimes need to send >1280 things (chains
of certificates), and so we will need to use CoAP Block Transfer mode as
well.

6tisch-security is also considering OSCOAP rather than DTLS, but this is
very primilinary.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Sun, 17 Jul 2016 10:19:48 +0000

> On Jul 10, 2016, at 7:14 PM, Max Pritikin (pritikin) <[email-masked]> wrote:
> 
>> 

The relevant text appears to be that CoAP [RFC7252] s4.2 Confirmable and non-Confirmable messages. Draft-ietf-core-block references this in s1 "using Non-confirmable requests within block-wise transfers outside the use case of 
Section 2.8 would escalate the overall non-delivery probability”. Effectively CoAP, and then core-block, address this issue so we don’t need to say anything additional. We could mandate ‘Confirmable’ more so than is indicated in core-block. 

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Jul 2016 20:53:09 +1200

Regards
   Brian Carpenter
   (Don't blame me, I voted Remain.)

> Section 2.8 would escalate the overall non-delivery probability”. Effectively CoAP, and then core-block, address this issue so we don’t need to say anything additional. We could mandate ‘Confirmabl…

I agree that you don't need to add anything normative. I still think it would
help the reader to point out that integrity and loss recovery are provided
by this mechanism, because most people think of UDP as not providing those
properties.

   Brian