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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
Sent: lundi 10 février 2020 13:25
To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: Secdir last call review of draft-ietf-6lo-fragment-recovery-08

Thanks Pascal. Updated text looks good.

Cheers,
-Tiru

From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 10, 2020 5:48 PM
To: Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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


>>>[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.

> 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.

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) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 10, 2020 1:06 PM
To: Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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;

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.

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.

> [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.

Thanks for the clarification.

> [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.

Okay.

> [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.

Got it.

Cheers,
-Tiru

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