Subject: [secdir] Secdir last call review of draft-ietf-6lo-fragment-recovery-08

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 3 Feb 2020 13:53:38 +0000

Reviewer: Tirumaleswar Reddy
Review result: Ready with nits

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: Ready with nits

[1] It is not clear to me how the Security sections of I-D.ietf-core-cocoa apply to this specification ?
[2] The security considerations section discusses I-D.ietf-lwig-6lowpan-virtual-reassembly but that document does not discuss any security considerations yet.
[3] It is not clear how the DoS attack of bogus first fragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7 are tackled ?
[4] How does the document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

Cheers,
-Tiru

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Feb 2020 07:35:46 +0000

Hello Tiru;

Many thanks for your review!

Please see below

> [1] It is not clear to me how the Security sections of I-D.ietf-core-cocoa apply to this specification ?

The specification depends on a Retransmission TimeOut (RTO) estimation that can be attacked. Adding the reference to cocoa was a earlier review comment that we got. Cocoa computes an RTO in a similar type of network. I agreed that the recommendation made sense but still, I can probably dig that email and start a thread with the reviewer if you think it is irrelevant.

> [2] The security considerations section discusses I-D.ietf-lwig-6lowpan-virtual-reassembly but that document does not discuss any security considerations yet.

Correct. When it does I hope it describes the issue that this specification discusses. In any fashion we use it to explain a difference: "here's a traditional drawback of fragments and here's why it does not hurt us", as opposed to an inheritance.
If you think that the text is not helpful, we can open another thread on that.

> [3] It is not clear how the DoS attack of bogus first fragments is handled and other attacks discussed in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-3.7 are tackled ?

They are not, apart from whatever protection we get from the requirement in L2 security (we are talking about an homogeneous mesh). This section is highly relevant. This is all detailed in section 7 of draft-ietf-6lo-minimal-fragment that this specification inherits.

> [4] How does the document align with the recommendations given in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17#section-6 ?

Section 6 says that IP fragmentation should be avoided by new protocols. This Is not IP fragmentation, it is lower layer. We cannot avoid it if we are to support IPv6 that has a MIN MTU of 1280 bytes and the 6LoWPAN MTU is lower than that, see RFC 4944.

Please let me know if you have a recommendation for a change, I saw questions but not real hiunt on how to act on them.

Many thanks again!

Pascal

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 10 Feb 2020 08:38:23 +0000

Hi Pascal,

Please see inline

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Monday, February 10, 2020 1:06 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hello Tiru;

Please see below

If coca is relevant, please add more details on how it is relevant. The security considerations in cocao is only discussing network access control to prevent an attacker from dropping packets to eventually increase the RTO.

Thanks for the clarification.

Okay.

Got it.

Cheers,
-Tiru

Many thanks again!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Feb 2020 12:18:12 +0000

Hello Tiru

> If coca is relevant, please add more details on how it is relevant. The security considerations in cocao is only discussing network access control to prevent an attacker from dropping packets to ev…

Makes sense. I checked the status of cocoa and it appears stuck(
IESG state<https://datatracker.ietf.org/help/state/draft/iesg>
Expired (IESG: Dead)
).
Maybe the safest is to import the idea that we wanted to cover and avoid the reference.

What about schanging the first 3 paragraphs as follows:
"
   This document specifies an instantiation of a 6LoWPAN Fragment
   Forwarding technique.  "On Forwarding 6LoWPAN Fragments over a
   Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] provides the
   generic description of Fragment Forwarding and this specification
   inherits from it.  The generic considerations in the Security
   sections of [I-D.ietf-6lo-minimal-fragment] apply equally to this
   document.

   This specification does not recommend a particular algorithm for the
   estimation of the duration of the RTO that covers the detection of
   the loss of a fragment with the 'X' flag set; regardless, an attacker
   on the path may slow down or discard packets, which in turn can
   affect the throughput of fragmented packets.

   Compared to "Transmission of IPv6 Packets over IEEE 802.15.4
   Networks" [RFC4944], this specification reduces the datagram_tag to 8
   bits and the tag wraps faster than with [RFC4944].  But for a
   constrained network where a node is expected to be able to hold only
   one or a few large packets in memory, 256 is still a large number.
   Also, the acknowledgement mechanism allows cleaning up the state
   rapidly once the packet is fully transmitted or aborted.

"

Many thanks again, Tiru.

Pascal

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 10, 2020 1:06 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08

Please see below

Okay.

Got it.

Cheers,
-Tiru

Many thanks again!

Pascal

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 10 Feb 2020 12:25:21 +0000

Thanks Pascal. Updated text looks good.

Cheers,
-Tiru

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Monday, February 10, 2020 5:48 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08

"

Many thanks again, Tiru.

Pascal

Please see below

Okay.

Got it.

Cheers,
-Tiru

Many thanks again!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Feb 2020 12:31:59 +0000

Great!

I posted v11. The diffs are visible here https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-11.

Please let me know if I missed something.

Many thanks again, Tiru.

Pascal

From: Konda, Tirumaleswar Reddy <[email-masked]>
Sent: lundi 10 février 2020 13:25
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08

Cheers,
-Tiru

"

Many thanks again, Tiru.

Pascal

Please see below

Okay.

Got it.

Cheers,
-Tiru

Many thanks again!

Pascal