Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt

[Tom Herbert <[e-mail]>]

On Wed, Jan 30, 2019 at 12:57 PM Ron Bonica <[e-mail]> wrote:
>
> Inline......
>
> > Message: 3
> > Date: Tue, 29 Jan 2019 11:45:45 -0800
> > From: Tom Herbert <[e-mail]>
> > To: int-area <[e-mail]>
> > Subject: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
> > Message-ID:
> >       <CALx6S35kwvHL5iE4Ci10LQbPzun3k1C-
> > [e-mail]>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hello,
> >
> > I have suggested text for the draft to address some previous comments made
> > on the list.
> >
> > Last paragraph in section 4.3:
> >
> > "This problem does not occur in stateful firewalls or Network Address
> > Translation (NAT) devices. Such devices maintain state so that they can afford
> > identical treatment to each fragment that belongs to a packet. Note, however,
> > that stateful firewalls and NAT devices impose the external requirement that
> > all packets of a flow and fragments of a packets for a flow must traverse the
> > same stateful device; stateless devices do not force this requirement."
> >
>
> The first two sentence that you suggest already appear in version 06 of the document.
>
> I would prefer to omit the final sentence for the following reasons:
>
> - It isn't absolutely necessary
> - It opens another can of worms that I don't want to address. Specifically, some stateful firewalls perform virtual reassembly but don't maintain TCP session state. Some stateful firewalls perform virtual reassemble and maintain TCP state. You third sentence is true for one firewall type and false for the other.
>
Yes, but as Fred mentioned, the current text is a blanket statement
that stateful firewalls don't have this problem. Some firewalls may
have implemented virtual reassembly, but others may not and might not
do anything we'd consider reasonable for handling fragments. So
similarly the statement in the draft may be "true for one firewall
type and false for the other". Also, any implication that people
should swap out their stateless devices for stateful ones because they
solve one problem without mentioning that they introduce other
problems would be a disservice IMO.

To avoid the can of worms, I suggest the whole paragraph and any
discussion about stateful devices could be removed from the draft
without loss of content.

Tom

> > Section 4.5:
> > "IP fragmentation causes problems for some routers that support Equal Cost
> > Multipath (ECMP). Many routers that support ECMP execute the algorithm
> > described in Section 4.4 in order to perform flow based forwarding; therefore,
> > the exhibit they same problematic behaviors described in Section 4.4. In IPv6,
> > the flow label may alternatively used as input to the algorithm as opposed to
> > parsing the transport layer of packets to discern port numbers. The flow label
> > should be consistently set for a packets of flow including fragments, such that
> > a device does not need to parse packets beyond the IP header for the
> > purposes of ECMP."
>
> This comment is almost identical to one made by Brian Carpenter. I have addressed his comment in Section 4.4. Rather than repeating the same text in Section 4.5, I have merged the two sections.
>
> >
> > Add to section 7.3:
> >
> > "Routers SHOULD use IPv6 flow label for ECMP routing as described in
> > [RFC6438]."
>
> Brian suggested similar text, but in a new section. Look for the new section in version 07
>
>