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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Pascal,

Please see inline

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