Subject: [Int-area] Warren Kumari's Yes on draft-ietf-intarea-frag-fragile-15: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 14:58:15 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-intarea-frag-fragile-15: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's very seldom that I ballot Yes on a document for which I'm not the
Responsible AD, but this is important enough that I'm doing so; unfortunately
there are are some bits which make me uncomfortable though, and so I spent a
while in the unusual situation of trying to decide between DISCUSS and YES -
after looking at the author list and responsible AD I'm sure that my comments
will be considered, and so I'm balloting Yes.

1: "Legacy protocols that depend upon IP fragmentation SHOULD be updated to
remove that dependency." I really don't like the  SHOULD here -- while I fully
agree that legacy protocols should be update, the RFC2119 usage feels weird -
it's unclear exactly who it is aimed at (everyone? the people who wrote the
legacy protocols? some mythical cleanup author?)

2: I'm unclear why IP-in-IP tunnels are called out at the top / in the
Introduction. There is a whole section (Packet-in-Packet Encapsulations) where
I think it would go better -- I see no harm in having people have to read down
to there to note this.

3: "NOTE 2: A non-fragmentable packet can be fragmented at its source. However,
it cannot be fragmented by a downstream node.  An IPv4 packet whose DF-bit is
set to 0 is fragmentable.  An IPv4 packet whose DF-bit is set to 1 is
non-fragmentable.  All IPv6 packets are also non-fragmentable." I have a few
issues with this: 3.1: I'm not really sure a non-fragmentable packet can be
fragmented at its source -- the packet *can* be fragmented but I'd say that
that is before it has become non-fragmentable. It's entirely possible that I'm
missing something obvious here, but a skim of 791 didn't show me what.... 3.2:
This may be a corner case, but some tunneling gear seems happy to ignore the DF
bit when it is doing reassembly on the far side of the tunnel -- the logic
seems to be that as long as what goes into the tunnel matches what comes out it
doesn't matter what actually happens *inside* the tunnel. 3.3: Related  to this
- most tunneling gear (and many firewalls) allow you to clear the DF bit in
packets -- for example, cisco has the 'crypto ipsec df-bit clear' command,
Junos allows you to do 'services ipsec-vpn rule myvpn term stomp_on_df then
clear-dont-fragment-bit;', iptables lets you 'iptables -t mangle -A POSTROUTING
-j DF --clear' 3.2 and 3.3 are common enough that I think that they deserve
mention.

4: What do you mean by middle box in section 6.3?
Yes, I know what is commonly called a middlebox, but I don't know of a good
reference -- as an example, I've got some honkin' big routers which do
stateless firewall filtering -- these are covered by 3.7, but are they also
middleboxes, and if not, why not?! (Note, my personal belief is that they
aren't, but I cannot really point to why, other than "I know a middlebox when I
see one". There is a discussion on some of this in "Why Operators Filter
Fragments and What It Implies" (draft-taylor-v6ops-fragdrop-02), but this also
uses the term middlebox without defining it.

Nits:
A: Whlie -- While

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Aug 2019 07:09:46 -0700

Warren,

FYI - 

#2 - IP-in-IP is the most typical case where a lack of fragmentation support causes problems. This isn’t a rare case; it’s the basis of IPsec tunnels and part of the reason why it’s impractical to simply deprecate this capability.

#3 - while it might be worth noting even more devices that are broken, it’s equally worth noting in the same breath that these are broken behaviors. 

#4 - a middlebox is any device that relays IP packets but violates RFC1812 by modifying parts of the packet beyond the IP header hop count, checksum (IPv4), and certain IP options. It is, almost by definition, a bug “in the flesh”.

Joe

> On Aug 7, 2019, at 2:58 PM, Warren Kumari via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Aug 2019 13:55:35 +0300

> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/

The tricky bit here is that throughout the document we employ RFC2119
language to quote requirements from other RFCs, while in this specific
case we use caps to stress that this is the advice we are giving out.

FWIW, the advice hopefully triggers work for any protocols expected to
work across the Internet, and that currently rely on fragmentation.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Aug 2019 07:47:53 -0700

> work across the Internet, and that currently rely on fragmentation.
Fernando,

As the document highlights the problems of fragmentation are caused by
nonconformant middlebox implementations. There is nothing inherently
wrong with the fragmentation and end hosts don't a problem with it.
IMO, this is just one example of (some) middleboxes arbitrarily
breaking end to end protocols. I am hopeful that document will also
trigger work to start fixing fix broken middlebox implementations.

Tom

---

From: Warren Kumari <[email-masked]>
Date: Fri, 9 Aug 2019 12:40:21 -0400

> case we use caps to stress that this is the advice we are giving out.

Yup. I really do support the concept / idea, but the combination of
2119 usage for requirements and uppercase to mean "... and pay
attention, this bit's important" feels odd.
I've been trying to think of some text which manages to convey this
without using uppercase, or making it overly verbose, but have failed
- perhaps we need the concept of **bold** al la Markdown?

While I still don't love it, I'm sufficiently convinced that I'm fine
leaving it as it is...

> work across the Internet, and that currently rely on fragmentation.

Yup, that would be good -- I really do approve of hte document /
concepts, I'm just trying to make it as good as can be.
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Bob Hinden <[email-masked]>
Date: Fri, 9 Aug 2019 10:27:53 -0700

Tom,

> On Aug 9, 2019, at 7:47 AM, Tom Herbert <[email-masked]> wrote:
> 
> 

I certainly hope so.  It’s certainly a big problem for the IETF if any new protocol is constrained by the worst middle box implementation.

Bob

---

From: Geoff Huston <[email-masked]>
Date: Fri, 9 Aug 2019 18:53:37 +0000

> On 9 Aug 2019, at 10:27 am, Bob Hinden <[email-masked]> wrote:
> 
> Tom,
> 

The picture gained from broad scale measurements points to a current 
reality that removes the conditionality from your observation Bob. 
If the application has to work robustly in today’s network then you 
need to design defensively and not push into areas where actual network 
behaviours deviate from some ideal. I can be as sentimental as anyone 
and decry where we have got to as being far from where we had wanted to 
be, but I’m also sufficiently pessimistic to believe that there is 
insufficient collective impetus to reverse this situation. 

ymmv.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 9 Aug 2019 15:07:50 -0400

> insufficient collective impetus to reverse this situation.

... and even if there *is* sufficient impetus, how long would it take
to be sufficiently deployed that my app / library / whatever doesn't
need to worry about breakage?

One of my machines:
$ uptime
 14:57:40 up 1304 days, 15:28,  1 user,  load average: 0.00, 0.07, 0.07

>From someone on NANOG, in ~2010:
c2948g-4.sc5> sh ver
 WS-C2948 Software, Version NmpSW: 5.5(2)
 Copyright (c) 1995-2000 by Cisco Systems, Inc.
 NMP S/W compiled on Jul 28 2000, 17:21:27
 GSP S/W compiled on Jul 28 2000, 15:57:45

 System Bootstrap Version: 4.4(1)

 Hardware Version: 2.3  Model: WS-C2948  Serial #: JAB041808VK

 Mod Port Model      Serial #              Versions
 --- ---- ---------- --------------------  ---------------------------------
 1   0    WS-X2948   JAB041808VK          Hw : 2.3
                                          Gsp: 5.5(2.0)
                                          Nmp: 5.5(2)
 2   50   WS-C2948G  JAB041808VK          Hw : 2.3

        DRAM                    FLASH                   NVRAM
 Module Total   Used    Free    Total   Used    Free  Total Used  Free
 ------ ------- ------- ------- ------- ------- -------- ---- ----- -----
 1       65536K  34318K  31218K  12288K   8583K   3705K  480K   93K  387K

 Global checksum failed.

 Uptime is 2333 days, 13 hours, 33 minutes
 ----------------------

2333 days is 6 years, 143 days; even if we fixed all middlebox
implementations today, we'd still need to wait many years for things
to be upgraded and rebooted.

W

---

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Aug 2019 15:32:54 -0700

On Fri, Aug 9, 2019, 11:53 AM Geoff Huston <[email-masked]> wrote:

> > I certainly hope so.  It’s certainly a big problem for the IETF if any
> new protocol is constrained by the worst middle box implementation.
>
>

Geoff,

The broad measurements are almost always a limited viewpoint taken at point
in time. As discussed several times in regards to fragmentation, it's not
broken for everyone all the time. It is being used productively in some
contexts. The same will be true for other protocols (EH, transport
protocols other than TCP) that one may think should be deprecated because
they're not "usable" in the Internet. This is precisely why there was a lot
of pushback on this draft which originally had much stronger language that
would have effectively deprecated fragmentation for everyone, which in turn
would have officially validated nonconformant implementations.

Tom

---

From: Geoff Huston <[email-masked]>
Date: Sat, 10 Aug 2019 01:42:24 +0000

> 
> Geoff,
> 
> The broad measurements are almost always a limited viewpoint taken at point in time.

I was referring to Internet measurements using the Internet. The conversation was (I thought) about the prospects for ever cleaning up Internet middleware on the Internet. The context of the conversation was the context of applic ations behaviour __on the Internet__.

Of course there are many other contexts. Decnet Phase III may be doing just fine in some of them and I’m sure there are many protocols and many variants are being used in many contexts. If we were ever to attempt to interpret RFCs as containing some eternal and universally applicable truth about IP as used in every possible context in every possible way then I for one am cheerfully prepared to give up at once, as I believe that this is a Sysyphalian task.

> As discussed several times in regards to fragmentation, it's not broken for everyone all the time. It is being used productively in some contexts.

Of course - but the advice is not about what may work on Thursdays on a sunny day on a downhill slope. Its more about lowest common denominator set of pragmatic considerations that start with the premise that if you have no idea where or why your application may be used, then what would be a sensible set of design choices that would maximise its applicability and robustness, irrespective of the day of the week, the inclination of the bits and the outside temperature. 

Like I said its about interpretation of these IETF documents. If you believe that RFCs are like some Networking Canon of immutable laws of moving bits then yes, many things work in many situations and its just not possible to say outright “this will not work in every case!” about almost everything. But in my mind this document is not striving for any such lofty goal. It’s pointing out that IP fragmentation is extremely fragile, and in IPv6 more so. As an app designer and if you are desirous of maximising robustness and applicability for you application then you should steer clear of fragmentation, if you can.

regards,

  Geoff

---

From: Tom Herbert <[email-masked]>
Date: Sat, 10 Aug 2019 08:39:25 -0700

Geoff,

I don't see that distinction being made in the draft. Consider the
examples in section 5.3 examples of protocols that rely on
fragmentation. These include OSPF, Packet-in-Packet encapsulation
(e.g. GRE), and UDP enhancing performance protocols like Licklider
Transmission Protocol. AFAIK, these protocols are either primarily or
always used in a controlled environment (the only example in section
5.3 of a protocol commonly used on the Internet is DNS.). Furthermore,
if they rely on fragmentation then they have been for many years and
it has long been deployed. Maybe I missed it, but I don't believe
we've been getting widespread reports of outages caused by
fragmentation, nor do we have users clamoring for change. I don't see
how these protocols are broken, nor the argument that after all these
years we've been doing something wrong or violating the standard.

But the next section states:

"Legacy protocols that depend upon IP fragmentation SHOULD be updated
to break that dependency."

Presumably, this advice applies to the protocols discussed in section
5.3 which again doesn't differentiate protocols on the Internet versus
those used in controlled networks. So this advice begs the question:
is the draft suggesting to fix things that aren't actually broken?
Conversely, one could also ask: is the draft doing enough to encourage
fixing things that are actually broken (namely nonconformant
implementations)?

Tom