December 2010 - Test - lists.nanog.org

Re: Are you ready for RPKI in your BGP?
by Arturo Servin 09 Dec '10

09 Dec '10

There are some pieces in the RPKI puzzle. One is the definitions of protocols, that one is very advanced in the SIDR WG in the IETF. Not RFCs yet but I am sure we will se some soon. Another piece are repositories of CA's and ROAs and Trust Anchors. RIRs have they implementations or you could create your own if you want to keep your private keys. IMHO one piece missing (not the only one, but one important in this stage) is RTR (RPKI/Router Protocol) working in routers. May be is too soon to see it in production routers but I am only aware of one big vendor with testing code. Also open-source implementations (Quagga, Xorp, Bird, etc.) are not actively (or at all) working in RPKI, I would imagine that one first step for many operators is to test RPKI with these implementations. Regards, -as On 9 Dec 2010, at 06:37, nanog-request(a)nanog.org wrote: > Date: Wed, 8 Dec 2010 22:56:08 -0500 > From: Jared Mauch <jared(a)puck.nether.net> > Subject: Are you ready for RPKI in your BGP? > To: North American Network Operators Group <nanog(a)nanog.org> > Message-ID: <15FF52BA-388A-48E8-BDDE-A151E694E9AC(a)puck.nether.net> > Content-Type: text/plain; charset=us-ascii > > Are you ready for RPKI in your network? > > While there's some dubious hyperbole in the article, the work that has been undertaken in SIDR wg re: RPKI is moving along. > > http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/2010/1207… > > For those of you preparing to assign 2011 goals to your employees, or something to self-assign, this should be in the top-5 or top-10 if you configure routers for BGP. > > - Jared

2 1

Are you ready for RPKI in your BGP?
by Jared Mauch 09 Dec '10

09 Dec '10

Are you ready for RPKI in your network? While there's some dubious hyperbole in the article, the work that has been undertaken in SIDR wg re: RPKI is moving along. http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/2010/1207… For those of you preparing to assign 2011 goals to your employees, or something to self-assign, this should be in the top-5 or top-10 if you configure routers for BGP. - Jared

4 3

SONET and MAC address
by Jay Nakamura 09 Dec '10

09 Dec '10

We have a Gigabit Ethernet transport between cities by a vendor. We found that when there are identical MAC address that are on different VLANs on different side of the circuit, one of the VLAN looses packets. This situation came up because two different networks that travel over the Ethernet were using HSRP with the same virtual MAC address. The vendor says both sides are directly connected to Fujitsu SONET gear and the equipment doesn't even look at the MAC address so it's not their circuit. All I know is, I can't recreate the problem if this circuit is not in the path. I haven't worked with Fujitsu SONET gear so I don't know if their claim is true or not. I vaguely remember someone talking about some equipment actually having a builtin switch on the SONET port and that was messing up the forwarding. Also, on one side of the circuit, there is a copper to fiber media converter. I am going to find out what model this is and see if that could be the cause. Anyone have any thoughts on what I should look into or have the vendor look into? Anyone run into this situation? Thanks!

4 4

ALT-DB Question
by Chadwick Sorrell 09 Dec '10

09 Dec '10

Hello, I'm sending a new MAINT-AS object to the db-admin(a)altdb.net, but it doesn't appear to be in the database after a few weeks. Are there any requirements that I may be missing on my new request, or some sort of way I can help get it processed? Basically wondering if I'm just not waiting long enough, or if I've done something wrong. Thanks, -chad

3 2

who dis
by Randy Bush 09 Dec '10

09 Dec '10

whois don't work * i2.78.64.0/18 144.232.9.61 1555 100 0 1239 3216 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i *> 199.238.113.9 374 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * 129.250.11.41 379 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * i2.78.128.0/17 144.232.9.61 1555 100 0 1239 3216 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i *> 199.238.113.9 374 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * 129.250.11.41 379 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * i2.79.0.0/16 144.232.9.61 1555 100 0 1239 3216 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i *> 199.238.113.9 374 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i * 129.250.11.41 379 0 2914 9002 6854 35104 35104 35104 35104 29355 29355 29355 29355 29355 29355 29355 29355 29355 29355 i so who is announcing this space that i can not find in ripe (or arin) whois? randy

2 1

Re: who dis
by Randy Bush 09 Dec '10

09 Dec '10

> I got both the as and the block from ripe's whois. now i do, before i did not. my apologies. randy

1 0

MasterCard problems
by Kiriki Delany 09 Dec '10

09 Dec '10

It's a national security issue that the federal and state governments cannot temporarily accept payment from visa/mc? Really? Is this because cash or checks are not viable solutions? This is the result of privatization of government. Pay close to attention to what privatization means. It's a loss of critical accountability. Demand government not rely on a private payment provider. It's a gross neglect of national security for payment processing to be beholden to visa/mc. They have no responsibility to the citizens of the US. I don't think is actually the case, as mc/visa take fee's of all transactions they process. Most vendors prefer cash or a check, I would assume the feds do as well. Of course if you have no actual cash anymore, and can only finance your debts on credit, well..... yet more evidence the lack of regulation of credit card companies is a national security risk. -Kiriki -----Original Message----- From: Matthew Black [mailto:black@csulb.edu] Sent: Wednesday, December 08, 2010 3:20 PM To: nanog(a)nanog.org Subject: Re: Mastercard problems O> ----- Original Message ----- >From:James Downs <egon(a)egon.cc> > To:andrew.wallace <andrew.wallace(a)rocketmail.com> > Cc:Christopher Morrow <morrowc.lists(a)gmail.com>; "nanog(a)nanog.org" ><nanog(a)nanog.org> > Sent:Wednesday, 8 December 2010, 21:30:20 > Subject:Re: Mastercard problems [snip] > Yikes.. you consider a private company's business to be the financial and >payment system of the United States? Yes, I do. Especially when government agencies accept payments through MasterCard, et al. matthew black comments reflect my opinions and may not represent those of my employer.

1 0

Re: Mastercard problems
by andrew.wallace 09 Dec '10

09 Dec '10

"MasterCard works closely with the U.S. Secret Service, the FBI, the Postal Inspection Service, Interpol, Europol and counterpart organizations throughout the world to facilitate investigation and prosecution." http://www.mastercard.com/us/merchant/security/collaborating_experts.html Andrew ----- Original Message ----- From:James Downs <egon(a)egon.cc> To:andrew.wallace <andrew.wallace(a)rocketmail.com> Cc:Christopher Morrow <morrowc.lists(a)gmail.com>; "nanog(a)nanog.org" <nanog(a)nanog.org> Sent:Wednesday, 8 December 2010, 21:30:20 Subject:Re: Mastercard problems On Dec 8, 2010, at 12:30 PM, andrew.wallace wrote: > I would say the attack falls under the jurisdiction of the US secret service since this is an attack on the financial system. > > "Today the agency's primary investigative mission is to safeguard the payment and financial systems of the United States." --- secretservice.gov Yikes.. you consider a private company's business to be the financial and payment system of the United States? -j

3 2

.com/.net DNSSEC operational message
by Matt Larson 08 Dec '10

08 Dec '10

VeriSign is in the process of deploying DNSSEC in the .net and .com zones. This message contains operational information related to the .net DNSSEC deployment that might be of interest to the Internet operational community. The .net DNSSEC deployment is underway. On September 25, 2010, the .net registry system was upgraded to allow ICANN-accredited registrars to submit DS records for domains under .net. On October 29, 2010, a deliberately unvalidatable .net zone began to be published. (This zone was a signed version of the .net zone with the key material deliberately obscured so that it could not be used for validation.) VeriSign recently began incrementally "unblinding" the .net zone: one at a time, each authoritative server for .net was changed from serving the unvalidatable .net zone to the signed .net zone with the official keys unobscured. As of approximately 2100 UTC on December 7, all authoritative servers for .net were serving the signed .net zone with the actual, unobscured production keys. The final step in DNSSEC deployment in .net will be publishing its DS record in the root zone, which is currently scheduled for December 9, 2010. If you have any questions or comments, please send email to info(a)verisign-grs.com or reply to this message.

1 0

Start accepting longer prefixes as IPv4 depletes?
by Jeff Wheeler 08 Dec '10

08 Dec '10

How many networks already leak numerous unnecessary /24s to their transit providers, who accept them (not having been asked to do anything else), and contribute to table bloat? Quite a lot of networks do this. Imagine if there are many possible inter-domain routes that are being filtered by transit networks, because their customers accidentally announce some number of /25-/32 networks to them. These do not affect us today; but I would hate to see all those accidental announcements suddenly appear in my routing table; or for my transit providers to have the bear the expense of dealing with them. -- Jeff S Wheeler <jsw(a)inconcepts.biz> Sr Network Operator / Innovative Network Concepts

2 1