Re: MUST is an aspiration

On Thu, Sep 12, 2019 at 5:07 AM Fred Baker <fredbaker.ietf@gmail.com> wrote:
>
> On Sep 12, 2019, at 5:19 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
> > If they don't exist (they don't), then such a MUST in an RFC is an aspiration. It's a theoretical goal, one that in practice has been proven not to be 100% true in similar scenarios where things "MUST" not leak  (RFC 1918 leaks, route leaks, DNS PTR lookup for private addresses etc.)
>
> For the record, I doubt that “MUST” was ever something observed, at least following the publication of RFCs 1122/1123/1812. The first use was in RFC 1122/1123 and 1812, and in those it was something that was true of an algorithm - if <something> wasn’t the case (such as if ARP was sent FROM a broadcast address), something decidedly and demonstrably failed. In subsequent specifications, it was always something those participating in the relevant consensus wanted to be true, and gave them a tool to say to a developer or vendor that they had to MAKE true. Hence the logic behind “SHOULD”; the developer could point out a case where a “MUST” requirement didn’t work, and they were asked to document it.
>
> Something I have observed about specifications that presumed that they only applied in a defined corner of the Internet (usually in enterprise or residential networks, but in this case is an AS that uses the capability) was that they invariably made it out of the hinterlands onto the backbone. The most obvious cases are private and Martian addresses, but they are not the only ones, by a long shot. Hence, it seems to me that while the requirement is that “the hinterland should not let this out”, the practical requirement is that if you connect in some way with such a hinterland, you should implement defensive measures in case they do. Again, BGP is the obvious example - “you should not advertise ULA or private addresses”, and “you should filter out announcements from your neighbor of private and ULA addresses” - barring an agreement to the contrary.

... it's worse than that / some more concrete data:

RFC6996 (Autonomous System (AS) Reservation for Private Use) speaketh thusly:
"If Private Use ASNs are used and prefixes originate from these ASNs,
Private Use ASNs MUST be removed from AS path attributes (including
AS4_PATH if utilizing a four-octet AS number space) before being
advertised to the global Internet."

but looking on routeviews shows there to be (assuming I've gotten my
regexp right  -- show ip bgp regexp
_(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]|65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])_
): Displayed  573 routes and 13092222 total paths

RFC1918 doesn't contain RFC2119 language, but it does make it clear
that this space should be filtered out of routing announcements -- and
yet (using RV again) we see 7 routes for RFC1918 space (5 for
10.0.0.0/8 and 2 for 192.168.0.0/16).

Routing information is (relatively) easy to control the flow of, but
filtering IP packets at the border is operationally trickier, and will
leak more...

W

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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