Skip to main content

Autonomous System (AS) Reservation for Private Use
draft-ietf-idr-as-private-reservation-05

Yes

(Stewart Bryant)

No Objection

(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)

Note: This ballot was opened for revision 04 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (2013-04-22 for -04) Unknown
Good work, thanks.

Would be nice if section 7 supplemented what it says with a pointer to where the security considerations for private use AS numbers are to be found.
Stewart Bryant Former IESG member
Yes
Yes (for -04) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-04-23 for -04) Unknown
I support Joel's DISCUSS
Brian Haberman Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Joel Jaeggli Former IESG member
(was Discuss) No Objection
No Objection (2013-04-25 for -04) Unknown
Converting to a comment, Stuart will address.


While I recognize the 4 byte asn is some 4 billion ASNs the notion that the reservation should be 94 million ASNs seems a bit excessive. I also realize that has been discussed in some detail in the process of getting to this point.

----------------------

The operational considerations section does not discuss the interaction between 4 byte private ASNs and 2 bytes speakers that only see AS_TRANS. While 4 byte capable participants/networks will readily be able to distinguish private ASNs via simple policy filters. Two byte bgp speakers are blind to them If I recall. The could result in either unintentional or deliberate mischef. 

I do not believe that the must  in the first sentence can be enforeced by a two byte speaker.

   If Private Use ASNs are used and prefixes are originated from these
   ASNs, which are destined to the Internet, Private Use ASNs MUST be
   removed from the AS_PATH before being advertised to the global
   Internet.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-04-23 for -04) Unknown
Private use IPv4 addresses resulted in the AS112 project (RFC 6304).  Is something similar needed for private AS #s that are leaked to the internet?

On Adrian's point, I went and looked in RFC 1930 and it doesn't really say what bad things can happen.  The contents of that security consideration section are as follows:

  There are few security concerns regarding the selection of ASes.

   AS number to owner mappings are public knowledge (in WHOIS), and
   attempting to change that would serve only to confuse those people
   attempting to route IP traffic on the Internet.

Whatever bad thing can happen is mitigated by the MUST NOT be advertised, but maybe some words about what bad things can happen if they are leaked would be warranted - especially now that you're reserving so many more #s.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-04-19 for -04) Unknown
The value 94,967,295 appears odd to me, I expected a
power of 2, but maybe that's just my binary-bias and I'm
not decimal-diverse enough;-)
Ted Lemon Former IESG member
No Objection
No Objection (2013-04-24 for -04) Unknown
It would be nice if the operational considerations gave stronger advice about the use of AS_PATH filtering to mitigate the leakage of these private use ASNs onto the internet. I suppose people reading the document probably already know what to do, though, so I'm not insisting on this change--I'd just like to point out that the advice is perhaps more gentle than is warranted.