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

This isn’t a formal protocol spec and there is no equivalent detailed specification for stateful firewalls or load balancers. 

> On Feb 1, 2019, at 8:15 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Fri, Feb 1, 2019 at 7:39 AM Templin (US), Fred L
> <Fred.L.Templin@boeing.com> wrote:
>> 
>> Hi Tom,
>> 
>>> -----Original Message-----
>>> From: Tom Herbert [mailto:tom@herbertland.com]
>>> Sent: Thursday, January 31, 2019 5:17 PM
>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>>> Cc: Joe Touch <touch@strayalpha.com>; Ron Bonica <rbonica@juniper.net>; int-area <int-area@ietf.org>
>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt
>>> 
>>> On Thu, Jan 31, 2019 at 5:03 PM Templin (US), Fred L
>>> <Fred.L.Templin@boeing.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Tom Herbert
>>>>> Sent: Thursday, January 31, 2019 4:40 PM
>>>>> To: Joe Touch <touch@strayalpha.com>
>>>>> Cc: Ron Bonica <rbonica@juniper.net>; int-area <int-area@ietf.org>
>>>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-06.txt
>>>>> 
>>>>>> On Thu, Jan 31, 2019 at 3:10 PM Joe Touch <touch@strayalpha.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2019-01-31 13:56, Tom Herbert wrote:
>>>>>> 
>>>>>> On Thu, Jan 31, 2019 at 7:59 AM Joe Touch <touch@strayalpha.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 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,
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>> 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).
>>>> 
>>>> 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
>>> 
>>> 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."
>> 
>> Yes, of course the fragments all need to go through the same destination where
>> VFR is caching the fragments. That is assured due to the IP destination address
>> for unicast, but not necessarily for anycast. But, for anycast, the considerations
>> are no different for middleboxes than they are for anycast final destinations.
>> 
>> An analogy for VFR is that the middlebox receives the pieces of a puzzle from
>> the network. It checks each piece to make sure it is OK and holds them until
>> all pieces have arrived, but then instead of assembling the puzzle it forwards
>> the pieces on to the next hop destination, with the realization that there could
>> be NATs-within-NATs. Then, when the final destination receives all pieces it
>> assembles the puzzle.
>> 
>> I don' t think there needs to be a spec for this because the behavior is
>> inherently understood from the title (*Virtual* Fragment Reassembly).
>> 
> Fred,
> 
> I don't see this. It is not at all clear from three words that
> everyone could draw the same conclusions on what the protocol is and
> how it works. Your description above about the interaction between
> multicast and unicast is not obvious from the title. Neither is it
> obvious there is on only compliant way to implement the protocol
> (there are at least three variants that have been implemented with
> varying degrees of interoperability problems). I still maintain that
> if virtual reassembly were to be used in a normative context, it needs
> a normative definition. If nothing else, that ensures there is no
> ambiguity in what the protocol is, how it works, and what
> implementations need to do to be interoperable-- after all that is the
> goal of formal protocol specifications.
> 
> Tom
> 
>> Thanks - Fred
>> 
>>> Tom
>>> 
>>>> 
>>>> Fred
>>>>> 
>>>>> Tom
>>>>> 
>>>>>> Joe
>>>>> 
>>>>> _______________________________________________
>>>>> Int-area mailing list
>>>>> Int-area@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/int-area