Hi Leo, Thanks for the quick reply. Please see inline.
On 2/8/2011 1:50 PM, Leo Vegoda wrote: > Hi Carlos, > > On 7 Feb 2011, at 6:58, Carlos Pignataro wrote: >> >> 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: > > Thank you. > >> 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. > > 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? > >> 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. > > Thanks. I will add this. > >> Similarly, a note of caution as to the >> application of filters (as some of the blocks can "appear", but not be >> Internet-routed. > > 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. > Many thanks, > > Leo > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
