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

From: Ron Bonica <[email-masked]>
Date: Wed, 30 Jan 2019 20:57:02 +0000

Inline......

> Message: 3
> Date: Tue, 29 Jan 2019 11:45:45 -0800
> From: Tom Herbert <[email-masked]>
> To: int-area <[email-masked]>
> Subject: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
> Message-ID:
> 	<CALx6S35kwvHL5iE4Ci10LQbPzun3k1C-
> [email-masked]>
> 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.

> 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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 30 Jan 2019 16:56:26 -0800

> - 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…
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

---

From: Ron Bonica <[email-masked]>
Date: Thu, 31 Jan 2019 02:20:52 +0000

Done

> -----Original Message-----
> Sent: Wednesday, January 30, 2019 7:56 PM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]; Brian E Carpenter <[email-masked]>
> Subject: Re: I-D Action: draft-ietf-intarea-frag-fragile-06.txt
> 
> > > I have suggested text for the draft to address some previous
> > > comments made on the list.
> > >
> > > "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."
> > >
> >
> > - 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:
> > >

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jan 2019 07:59:23 -0800

The problem with dropping the entire paragraph is the section title - talking about stateless firewalls begs the question of stateful ones. This is reinforced later in the recommendations. The sentences you remove were the only thing that tied the two together, which IMO is important.

Also note that draft-tunnels points out significant issues in some of the RFCs cited here, e.g., 4459. Part of the reason why fragmentation doesn’t work well is the errors in those prior docs.

Joe

> On Jan 30, 2019, at 6:20 PM, Ron Bonica <[email-masked]> wrote:
> 
> Done
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Thu, 31 Jan 2019 13:56:37 -0800

> The problem with dropping the entire paragraph is the section title - talking about stateless firewalls begs the question of stateful ones. This is reinforced later in the recommendations. The sent…

Joe,

The term "Stateless firewalls" is unambiguous in this context. In a
stateless firewall, each packet is inspected and judge based solely on
it's content. So when packets are fragmented, any data the firewall
inspects that is beyond the networking layer is not available in the
fragment so that presents a problem to them. It's straight forward to
quantify the problems and suggested solutions.

The term "Stateful firewalls" on the other hand is quite ambiguous.
Without any further context, all we can deduce is that the device
maintains some state-- we don't know what state the firewall maintains
or how it's using it. It's incorrect to say that stateful firewalls
solve any problem just by virtue of being "stateful". I believe Ron
actually provided the missing, maybe implied, context when he
mentioned "Some stateful firewalls perform virtual reassemble". That
might be true, but then that gets us back to the unspecified protocol
for "virtual reassembly". Note, that the term itself implies that it's
a different process than what hosts do which is just "reassembly".
Without a specification, I don't still see how virtual reassembly can
be a normative requirement.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jan 2019 15:10:21 -0800

On 2019-01-31 13:56, Tom Herbert wrote:

> it's content.

My statement above has no relation to any potential ambiguity in the
term. 

--- 

However, the term stateless is inaccurate in a few places: 

(Sec 4.6) NAT is a stateful procedure for an otherwise stateless
protocol as well. The same could be argued for load balancers that
retain similar state through a connection for a flow (i.e., not just
hashing the flow or tuple, but doing round-robin per-flow/tuple 'sticky'
routing) 

(Sec 7.3) The problem is not just stateless middle boxes, but also
certain stateful ones (e.g., NATs, some load balancers, etc.) 

--- 

Thus "stateful" actually is both ambiguous and inaccurate here. 

You appear to want to distinguish between the state needed for virtual
reassembly and the state needed to maintain NAT translations or sticky
round-robin load balancing, but there's no simple term that
differentiates them. They're both content-dependent, context-dependent,
and stateful. 

Further, as you note there are no *specified* algorithms for virtual
reassembly, nor are there any *specified* for NAT translation table
maintenance or sticky load balancing. Everyone comes up with their own
and the basic concept is well enough defined as to not need a
specification. 

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 31 Jan 2019 16:39:57 -0800

On Thu, Jan 31, 2019 at 3:10 PM Joe Touch <[email-masked]> wrote:
> My statement above has no relation to any potential ambiguity in the term.
>
> ---
>
> (Sec 4.6) NAT is a stateful procedure for an otherwise stateless protocol as well. The same could be argued for load balancers that retain similar state through a connection for a flow (i.e., not just hashing the flow or tuple, but doing round-robin per-flow/tuple 'sticky' routing)
>
> (Sec 7.3) The problem is not just stateless middle boxes, but also certain stateful ones (e.g., NATs, some load balancers, etc.)
>
> ---
>
> You appear to want to distinguish between the state needed for virtual reassembly and the state needed to maintain NAT translations or sticky round-robin load balancing, but there's no simple term that differentiates them. They're both content-dependent, context-dependent, and stateful.
>
>
> Further, as you note there are no *specified* algorithms for virtual reassembly, nor are there any *specified* for NAT translation table maintenance or sticky load balancing. Everyone comes up with their own and the basic concept is well enough defined as to not need a specification.
>
In that case, if it's so obvious and well defined then there shouldn't
be any issue in either providing a reference to a description or
specifying it in the draft (if authors do choose discuss virtual
reassembly in the draft).

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Jan 2019 16:43:31 -0800

Reassembly is described in detail in RFC 791. 

Joe

> On Jan 31, 2019, at 4:39 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 31 Jan 2019 17:02:56 -0800

> Reassembly is described in detail in RFC 791.
That describes "reassembly" not "virtual reassembly". I cannot find
any IETF publication that refers to virtual reassembly in the context
of IP fragmentation. If it  is exactly the same thing, then why is it
different terminology? What makes virtual reassembly "virtual"? All
this may seem obvious to you, but for those of us that are uninitiated
it would be very nice if terminology is clearly defined before using
it in a standards specification.

Tom

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 1 Feb 2019 01:03:43 +0000

> From: Int-area [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Thursday, January 31, 2019 4:40 PM
> To: Joe Touch <[email-masked]>
> Cc: Ron Bonica <[email-masked]>; int-area <[email-masked]>
> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt
> 
> > The problem with dropping the entire paragraph is the section title - talking about stateless firewalls begs the question of stateful
> ones. This is reinforced later in the recommendations. The sentences you remove were the only thing that tied the two together,
> which IMO is important.
> >
> >
> > Joe,
> >
> > (Sec 4.6) NAT is a stateful procedure for an otherwise stateless protocol as well. The same could be argued for load balancers that
> retain similar state through a connection for a flow (i.e., not just hashing the flow or tuple, but doing round-robin per-flow/tuple
> 'sticky' routing)
> >
> > You appear to want to distinguish between the state needed for virtual reassembly and the state needed to maintain NAT
> translations or sticky round-robin load balancing, but there's no simple term that differentiates them. They're both content-
> dependent, context-dependent, and stateful.
> >
> >
> > Further, as you note there are no *specified* algorithms for virtual reassembly, nor are there any *specified* for NAT translation
> table maintenance or sticky load balancing. Everyone comes up with their own and the basic concept is well enough defined as to not
> need a specification.
> >

I have been telling everyone about virtual fragmentation reassembly for
years. You will find it in many of my docs. Here is what cisco says about it:

https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html

Fred

---

From: Tom Herbert <[email-masked]>
Date: Thu, 31 Jan 2019 17:16:37 -0800

> https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html

Hi Fred,

It does seem that Cisco configuration manuals and marketing materials
are the best source of information on virtual reassembly.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configuration/xe-3s/frre-xe-3s-book/virt-frag-reassembly.html
is a little more interesting in that it provides a few more details.
In particular the requirement that all fragments must traverse the
same intermediate device is mentioned:

"The reassembly process requires all fragments within an IP datagram.
If fragments within an IP datagram are sent to different devices due
to load balancing VFR may fail and fragments may be dropped."

Tom