Subject: [GROW] New I-D: draft-vegoda-no-more-unallocated-slash8s-00

From: Leo Vegoda <[email-masked]>
Date: Thu, 3 Feb 2011 06:40:09 -0800

Hi,

I have just uploaded draft-vegoda-no-more-unallocated-slash8s-00 to the I-D repository and have been advised to mention it on OPSEC and GROW, so that it can be well reviewed.

This document advises network operators to remove filters for any unicast /8s they previously filtered on the basis of being unallocated. The IANA IPv4 Address Space Registry is now fully allocated and so the practice of filtering IPv4 address space based on its registration status is no longer advisable.

Your thoughts and comments are welcome.

Kind regards,

Leo Vegoda

---

From: Arturo Servin <[email-masked]>
Date: Mon, 7 Feb 2011 11:40:47 -0200

Leo,

	I reviewed your draft and I have no comments. I support your draft and I think it is important to raise awareness regarding filtering and how this is evolving as result of the last IANA allocations to RIRs.

Regards,
.as

On 3 Feb 2011, at 12:40, Leo Vegoda wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 7 Feb 2011 11:19:01 -0500

Leo,

Which WG would you like to own this draft?

                         Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Leo Vegoda
> Sent: Thursday, February 03, 2011 9:40 AM
> To: [email-masked]; [email-masked]
> Subject: [OPSEC] New I-D: draft-vegoda-no-more-unallocated-slash8s-00
> 
> Hi,
> 
> I have just uploaded draft-vegoda-no-more-unallocated-slash8s-00 to the
> I-D repository and have been advised to mention it on OPSEC and GROW,
> so that it can be well reviewed.
> 
> This document advises network operators to remove filters for any
> unicast /8s they previously filtered on the basis of being unallocated.
> The IANA IPv4 Address Space Registry is now fully allocated and so the
> practice of filtering IPv4 address space based on its registration
> status is no longer advisable.
> 
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 07 Feb 2011 09:58:57 -0500

Hi Leo,

I support this document and think it's important and very well written.
I do have some overall comments and a couple of editorial suggestions:

At a high level, the document is arguing that with no more IANA
unallocated /8s, then existing corresponding filters should be removed,
and then lists special purpose prefixes that should not be router in the
Internet. I think that the document could benefit from making a stricter
classification of "bogons" from the Intro onwards, into "unallocated"
and "martian"; then, "martian filters" do not change, but "unallocated"
do (as continuously do, but now there is a notable milestone). These
unallocated prefix filers now need to be larger than /8, but there is
still value in filtering RIRs unallocated. So there is a choice of
whether no longer filter based on address allocation status at all, or
do it with finer granularity, with pros and cons. I think that the
document should contain the final state (martians only) but list pros
and cons of the transition (filter or not RIR unallocated prefixes). I
do not want to suggest overcomplicating the document, as its simplicity
is a plus, though.

On the more editorial side, I think that perhaps slightly more emphasis
on the fact that this is filtering on the "source" (even on the title)
can prevent potential confusions. Similarly, a note of caution as to the
application of filters (as some of the blocks can "appear", but not be
Internet-routed.

My 2¢. Thanks !

-- Carlos.

---

From: Leo Vegoda <[email-masked]>
Date: Tue, 8 Feb 2011 10:50:49 -0800

Hi Carlos,

> I do have some overall comments and a couple of editorial suggestions:

Thank you.

> do not want to suggest overcomplicating the document, as its simplicity

I would like to avoid the use of jargon words like "bogons" and "martians" if possible as I expect the total number of people who know and use them is small enough that their inclusion would make it a more difficult read for many. 

I would appreciate more operator feedback as regards the benefit of using strict filters based on the prefixes allocated by the RIRs. Looking at the latest RIPE NCC enhanced statistics file (http://albatross.ripe.net/delegated-extended/) there are about 250 IPv4 blocks to filter. Not all of these blocks are bit aligned, so the number of prefixes to filter based on the RIPE NCC alone is likely to be higher than that. And there are five RIRs. How many operators are going to be happy maintaining a list of something in the order a thousand prefixes and updating it every day to avoid broken connectivity?

> can prevent potential confusions.

Thanks. I will add this.

> Similarly, a note of caution as to the

If I understand you correctly, you'd like to see extra language clarifying that these filters should only be applied at borders and not internally. Right?

Many thanks,

Leo

---

From: Leo Vegoda <[email-masked]>
Date: Tue, 8 Feb 2011 10:52:29 -0800

Hi Ron,

> Which WG would you like to own this draft?

GROW, if that's OK with everyone else.

Thanks,

Leo

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Feb 2011 14:51:26 -0500

> GROW, if that's OK with everyone else.

Apologies for not responding earlier -- I read the doc and have been ruminating on how we could fit in OpSec (it's well written and useful), but unfortunately I think that GROW is the better place for it....

W

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 08 Feb 2011 16:17:05 -0500

Hi Leo,

Thanks for the quick reply. Please see inline.

On 2/8/2011 1:50 PM, Leo Vegoda wrote:
> I would like to avoid the use of jargon words like "bogons" and
> "martians" if possible as I expect the total number of people who know
> and use them is small enough that their inclusion would make it a more
> difficult read for many.
>

I am not sure if those two terms fall under jargon, but my point was
that the I-D describes filters for two types of addresses: unallocated,
and martian, and the document would benefit from differentiating them.
Perhaps there are proper descriptors or you can coin new words to define
them. I meant to emphasize the fact that there are two different things,
and not the use of these terms themselves.

I'll note though that, although there are not many occurrences, these
terms are defined in RFCs (and in my experience are well understood in
the *NOC community, that the I-Dis targeting).

http://tools.ietf.org/html/rfc3871
              Operational Security Requirements for Large
       Internet Service Provider (ISP) IP Network Infrastructure

   Bogon.

      A "Bogon" (plural: "bogons") is a packet with an IP source address
      in an address block not yet allocated by IANA or the Regional
      Internet Registries (ARIN, RIPE, APNIC...) as well as all
      addresses reserved for private or special use by RFCs.  See
      [RFC3330] and [RFC1918].

   Martian.

      Per [RFC1208] "Martian: Humorous term applied to packets that turn
      up unexpectedly on the wrong network because of bogus routing
      entries.  Also used as a name for a packet which has an altogether
      bogus (non-registered or ill-formed) Internet address."  For the

http://tools.ietf.org/html/rfc4778
               Current Operational Security Practices in
                 Internet Service Provider Environments

   o  DoS Mitigation - Many DoS attacks are mitigated using a
      combination of techniques including: MD5 authentication, the GTSM
      feature, filtering routing advertisements to bogons, and filtering
      routing advertisements to one's own network.

http://tools.ietf.org/html/rfc4948
   Report from the IAB workshop on Unwanted Traffic March 9-10, 2006

   Bogon
   A bogon is an IP packet that has a source address taken for a range
   of addresses that has not yet been allocated to legitimate users, or
   is a private [RFC1918] or reserved address [RFC3330].

   Bogon prefix
   A bogon prefix is a route that should never appear in the Internet
   routing table, e.g., from the private or unallocated address blocks.

#grep -i bogon rfc*txt | wc -l
      19
#grep -i martian rfc*txt | wc -l
      44

> I would appreciate more operator feedback as regards the benefit of
> using strict filters based on the prefixes allocated by the RIRs.
> Looking at the latest RIPE NCC enhanced statistics file
> (http://albatross.ripe.net/delegated-extended/) there are about 250 IPv4
> blocks to filter. Not all of these blocks are bit aligned, so the number
> of prefixes to filter based on the RIPE NCC alone is likely to be higher
> than that. And there are five RIRs. How many operators are going to be
> happy maintaining a list of something in the order a thousand prefixes
> and updating it every day to avoid broken connectivity?
> 
> If I understand you correctly, you'd like to see extra language
> clarifying that these filters should only be applied at borders and not
> internally. Right?
> 

Sure.

Thanks,

-- Carlos.