Hi Fred,
The first iteration of Section 7.3 actually included the word "reassemble".
That is one possible implementation.
I dropped the word when I realized that there may be other ways to get the
desired behavior. While they don't all require reassembly, that all require the
maintenance of a little more state.
Ron
> -----Original Message-----
> From: Fred Baker <fredbaker.i...@gmail.com>
> Sent: Monday, October 15, 2018 3:50 PM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
>
>
>
> > On Oct 15, 2018, at 12:11 PM, Ron Bonica <rbon...@juniper.net> wrote:
> >
> > So, the spirit of the robustness principle, all parties should be
> > conservative in
> what they do and liberal in what they accept.
> >
> > - Application developers should avoid reliance on IP Fragmentation. (Don't
> trip on the bad behavior or middle boxes if you can avoid it).
> > - Middle box developers should produce devices that don't behave badly in
> the presence of fragmentation. This may mean that middle boxes should
> become more stateful to support fragmentation.
>
> I might add one thought to 7.3: recommend that middle boxen reassemble a
> datagram before operating on it. The attacks that happen with fragmentation
> result in issues with reassembly, and the obvious solution is to detect the
> situation and drop the datagram in question.
>
> I would also comment that the first fragment created (the one at offset zero)
> might not be the first fragment received. The second bullet in 7.3, the one
> about selecting a next-hop, assumes that the first fragment is also the first
> one
> received. However, if the datagram were reassembled before operating on it,
> that wouldn't be an issue.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
