FWIW - it also involves forwarding all the fragments according to info
in the first, which might include NAT translation and/or port-based
forwarding.
That state can also be soft - first-fragments create the entry and
non-first frags are queued until a first-frag comes through.
Joe
On 2018-10-15 13:45, Templin (US), Fred L wrote:
> Hi Ron,
>
> There is a technique known as "Virtual Fragmentation Reassembly" where
> the middlebox gathers all fragments of a datagram, performs any necessary
> checks and then releases the fragments without reassembling them so that
> the destination host still has to reassemble. Is this one of the techniques
> you
> are referring to?
>
> Thanks - Fred
>
> -----Original Message-----
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Monday, October 15, 2018 1:39 PM
> To: Fred Baker <fredbaker.i...@gmail.com>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-01.txt
>
> 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
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
