Re: [Int-dir] Intdir last call review of draft-ietf-6lo-minimal-fragment-04

["Bernie Volz (volz)" <[e-mail]>]

Thanks much Dave for the review (and same day it was assigned)!

- Bernie 

> On Nov 6, 2019, at 6:10 PM, Dave Thaler via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Dave Thaler
> Review result: Ready with Issues
> 
> The title implies the document specifies a forwarding mechanism, but it does
> not, it merely provides discussion of two mechanisms in other docs (RFC 4944
> and draft-ietf-lwig-6lowpan-virtual-reassembly). I would recommend at least
> changing the title to be more clear as to the purpose of the doc.
> 
> Technical confusion
> -------------------
> 1) Page 3 says the reassembly buffer contains "the link-layer address that node
> B uses to forward the
>   fragments".  I cannot tell whether this is referring to B's link-layer
>   address that it received the fragment on, or B's link-layer address that it
>   uses as a source link-layer address for forwarding it on, or the link-layer
>   address of the next hop to which B forwards.
> 
> 2) Page 3 also says the reassembly buffer contains "the link-layer address of
> the next hop that is resolved
>   on the first fragment".  I found this similarly confusing.  What does it
>   mean to resolve something "on" the first fragment?  Does it mean "during
>   processing of the first fragment"?  Maybe I missed it, but I couldn't find
>   in RFC 4944 anywhere that says that it would do next-hop resolution before
>   the datagram can be reassembled.  That would seem like a waste, if the
>   fragments are then discarded (e.g., due to timer expiry) without actually
>   doing any forwarding.
> 
> 3) Section 3 talks about "MAC address" specifically whereas section 1 always
> talked about the more
>   generic "link-layer address".  Why the inconsistency?
> 
> 4) Section 3 talks about "a 1280-byte reassembly buffer for each packet", but
> section 2.2 talks assumes
>   a "1 kB reassembly buffer".  1k != 1280 bytes.  Why the inconsistency?
> 
> 5) Section 3 explains that "the first fragment must always be forwarded first",
> but does not explain
>   what the behavior is if a fragment other than the first fragment is received
>   before the first fragment. Figure 1 shows that the fragments can be received
>   out of order, since there fragment 6 is received before 5, which is received
>   before 4.   Presumably it is either queued or dropped.  If it's queued, then
>   section 4 is insufficient, which talks about an attacker generating a large
>   number of bogus "fragment 1" fragments, since if you queue the first
>   fragment received even if it's not "fragment 1", then the same attack
>   presumably exists, it's not specific to "fragment 1" packets.
> 
> Grammatical nits:
> -----------------
> 
> Abstract has "... to forwarding ...", which should be "to forward" or "for
> forwarding"
> 
> Abstract has "to the virtual Reassembly Buffer", which seems incorrect both in
> terms of capitalization (since sectoin 3 has VRB) and grammar.  Suggest "to
> using virtual reassembly buffers".
> 
> Section 1, first paragraph: "though possibly" is likely a typo for "through
> possibly"
> 
> Section 1, 6th paragraph: "a same datagram" is oddly worded.  Suggest either "a
> datagram" or "the same datagram"
> 
> Section 2.2, grammar issue in "Assuming 1 kB reassembly buffer".  Either
> "buffers" plural or "Assuming a ..."
> 
> 
> _______________________________________________
> Int-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-dir