October 2014 - Test - lists.nanog.org

Re: [outages] GApps admin = rogered
by Blair Trosper 09 Oct '14

09 Oct '14

Was not there at the time I sent the email. I was thorough in checking. 100% sure. On Thu, Oct 9, 2014 at 6:22 PM, Mitch Patterson <mitpatterson(a)gmail.com> wrote: > Shows an issue to me > > TimeDescription > 10/9/14 7:11 PM > We're investigating reports of an issue with Admin console. We will > provide more information shortly. > Users are seeing the Admin console refresh continuously on loading. > > On Thu, Oct 9, 2014 at 7:07 PM, Blair Trosper via Outages < > outages(a)outages.org> wrote: > >> Just a heads up to our friends at Google Apps. >> >> Despite the status page saying all is peachy: >> http://www.google.com/appsstatus#hl=en&v=status >> >> ...the administration page for any Google Apps for domains is totally >> rogered. It's either an endless redirect loop or a deluge of errors. >> >> I'd call for premium support, but I can't even see that. >> >> Again, a friendly heads up and nudge that perhaps the status page should >> at least be updated to reflect the fact that it's non-operational. >> >> _______________________________________________ >> Outages mailing list >> Outages(a)outages.org >> https://puck.nether.net/mailman/listinfo/outages >> >> >

2 1

Re: Marriott wifi blocking
by Jay Ashworth 09 Oct '14

09 Oct '14

----- Original Message ----- > From: "Chris Marget" <chris(a)marget.com> > You [I] said: > > > It is OK for an enterprise wifi system to make this sort of attack > > *on rogue APs which are trying to pretend to be part of it (same ESSID). > > I'm curious to hear how you'd rationalize containing a copycat AP > under the current rules. > > In fact, I remain fuzzy on when spoofed de-auth frames would *ever* be okay > when used against unwilling clients within the FCC's jurisdiction given > their position that spoofed control frames constitute interference under > part 15 rules. > > This thread and similar discussions elsewhere contain assertions that > enterprise networks "need to defend themselves" in some circumstances, > or that "containing" an AP with a copycat SSID would certainly be okay. > > I'm not so sure. > > The "need to manage our RF space" arguments ring hollow to me. I certainly > understand why someone would *want* to manage the spectrum, but that's > just not anyone's privilege when using ISM bands. If the need is great > enough, get some licensed spectrum and manage that. I wasn't making that argument. I was making the "if someone tries to pretend to be part of my network, so that my users will inadvertantly attach to them and possibly leak 'classified' data, *then that rogue user is making a 1030 attack on my network*. > A copycat AP is unquestionably hostile, and likely interfering with users, > but I'm unconvinced that the hostility triggers a privilege to attack it > under part 15 rules. In addition to not being allowed to interfere, we also > have: You're not attacking it, per se; you are defensively disconnecting from it *users who are part of your own network*; these are endpoints *you are administratively allowed to exert control over*, from my viewpoint. > 2. This device must accept any interference received, including > interference that may cause undesired operation. > > Certificate-based authentication would solve that problem anyway, > wouldn't it? Probably. And yes, any system big enough to do this stuff is likely big enough to run 1x as well. > A "rogue" AP plugged into a wired port is best solved at the wired port, I'm not sure anyone was actually mooting this. > Even large private campuses like oil refineries probably wouldn't be in the > clear doing this sort of thing unless they're able to stop law enforcement, > delivery drivers, paramedics and firefighters at the gate in order to get > them to agree to receive spoofed de-auth frames. Again: you've shifted topics here from "enterprise rogue protection" (stay off *my* ESSID) to "Marriott Attack" (stay off all ESSIDs that *aren't* mine); different thing entirely. I make a clear distinction (now that it's not 3am :-) between what Marriott is doing, and what enterprises doing rogue protection are doing, as noted above. Still not a lawyer. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

17 40

GApps admin = rogered
by Blair Trosper 09 Oct '14

09 Oct '14

Just a heads up to our friends at Google Apps. Despite the status page saying all is peachy: http://www.google.com/appsstatus#hl=en&v=status ...the administration page for any Google Apps for domains is totally rogered. It's either an endless redirect loop or a deluge of errors. I'd call for premium support, but I can't even see that. Again, a friendly heads up and nudge that perhaps the status page should at least be updated to reflect the fact that it's non-operational.

1 0

Strategies for migrating lots of customers into L3VPN / route-leaking [x-post from j-nsp]
by Daniel Rohan 09 Oct '14

09 Oct '14

[apologies for the x-post-- I didn't get any responses from the j-nsp list, so I thought I'd try a larger audience- edited to remove some juniper jargon] Hi all, I'm working on virtualizing a regional network with about 500 customer sites into an L3VPN. All of my customer routes (plus our internet routes) currently exist in the global table on our routers. The end-state I’d like to achieve is to have our provider's Internet routes isolated into a VRF and our customers isolated into their own VRF with vrf-import policies leaking the routes between the two. Before someone asks “why?” I’ll just stop that and say that it’s likely that in the near future I’ll have different customer classes demanding different upstream providers on the same physical gear but still wanting the same path/latency to the other customer classes we provide today. So- I’d like to move our customer routes piecemeal into a VRF in as controlled a way as possible without causing network segmentation or having to constrain traffic through specific paths. That way we could move reasonable sections of the network into the L3VPN over a period of a few weeks. My first thought was to set up route leaking between the VRFs and the global table, but looking back at listserv threads as well as Juniper docs, I realize it's not possible to export MP-BGP learned routes into the global table using Juniper rib groups. I'm currently looking into using BGP between logical tunnel interfaces on the global table and a vrf to accomplish the route sharing, and that seems like a good possibility, but I’m curious about a few things: 1) Does anyone run production traffic through logical tunnel interfaces between the global table and routing instances? (we’re using fairly lightly-loaded MX480s) 2) Does any one have a smarter strategy that I could borrow to accomplish this transition? It all feels so kludge-y and brittle. -Dan

1 0

another cogent oddity
by ryanL 09 Oct '14

09 Oct '14

you may remember me from the weird cogent route retention / loop problem i brought up last week. it remains unsolved by cogent to date. also remembering i'm a relatively new cogent customer, i recently noticed some packets floating into my network that had cos and ipp markings on them. i figured i'd try to find where they were coming from, so i crafted up something like this and placed it inbound on my two transits (cogent and xo), excluding network control markings. from { dscp [ af11 af12 af13 af21 af22 af23 af31 af32 af33 af41 af42 af43 cs1 cs2 cs3 cs4 cs5 ef ]; precedence [ 1 2 3 4 5 ]; } all of it is coming in from cogent: COGENT-NOT-BE -> 4217788987 XO-NOT-BE -> 0 i shifted all traffic to XO just to make sure. the XO counter doesn't budge. seems like one transit is remarking everything to best effort before sending to me (which is preferred), and the other is not. am i odd to think that this is... odd? i also get a remarkable amount of hits against these destinations coming in on the cogent side, whereas i get none on the XO side. show policy-options prefix-list PUBLIC-BAD-NETS 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; 224.0.0.0/4; ryan

3 3

RE: NANOG Digest, Vol 81, Issue 7
by Ralph Wallace 09 Oct '14

09 Oct '14

<Message: 25 <Date: Mon, 6 Oct 2014 14:27:48 -0700 <From: Ca By <cb.list6(a)gmail.com> <To: "nanog(a)nanog.org" <nanog(a)nanog.org> <Subject: socialsecurity.gov ipv6 routing loop <Message-ID: < <CAD6AjGQHhRBZiFRNwH+_Dy1WoE8hXxHErNq0CT-pw+iQvVUqOA(a)mail.gmail.com> <Content-Type: text/plain; charset=UTF-8 <in case anyone can help resolve ~Attempting to work this through the Federal IPv6 Task Force and the SSA IPv6 Transition Manager~

2 1

Re: wifi blocking [was Re: Marriott wifi blocking]
by Larry Sheldon 09 Oct '14

09 Oct '14

On 10/9/2014 02:40, Owen DeLong wrote: >> What where the laws and practices in the Olde Days of over-the-air >> TV when somebody in a small town installed a translator to repeat >> Big-Cities-TV-Station into a small town? > > The translator had to be operated by a holder of an FCC license for > that translator. > > Operator and Owner are not necessarily linked in any way shape or > form, though they usually were one and the same. Was the translator operator obligated to carry everything from the source station, or could they turn the translator off if they wanted to? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

2 1

Paetech Routing Loop
by Nathaniel Wingard 09 Oct '14

09 Oct '14

Is there a Paetech/Windstream tech that could help me with a routing loop in New Hampshire? Thanks, Nathaniel -- <http://www.aciworldwide.com> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.

1 0

OT: A certain WISP operator puts Sir Tim in his place
by Jay Farrell 09 Oct '14

09 Oct '14

Noted, with some amusement, in the comments to a NY Times piece in which Sir Tim Berners-Lee speaks out for net neutrality: http://bits.blogs.nytimes.com/2014/10/08/tim-berners-lee-web-creator-defend… --quote-- Brett Glass Laramie, WY 16 hours ago <http://bits.blogs.nytimes.com/2014/10/08/tim-berners-lee-web-creator-defend…> Berners-Lee is an Internet application developer (he developed an early one that was never commercially successful -- in fact, no Web browser has been commercially successful -- but important nonetheless). He thus has the biases of one. He has never worked as an ISP, operated an ISP, or managed an Internet service. [snip] --end quote

1 0

Re: wifi blocking [was Re: Marriott wifi blocking]
by Larry Sheldon 09 Oct '14

09 Oct '14

On 10/9/2014 02:03, Owen DeLong wrote: > > On Oct 8, 2014, at 2:11 PM, William Herrin <bill(a)herrin.us> wrote: > >> On Wed, Oct 8, 2014 at 4:37 PM, joel jaeggli <joelja(a)bogus.com> wrote: >>> On 10/8/14 1:29 PM, Larry Sheldon wrote: >>>> On 10/8/2014 08:47, William Herrin wrote: >>>>> BART would not have had an FCC license. They'd have had contracts with >>>>> the various phone companies to co-locate equipment and provide wired >>>>> backhaul out of the tunnels. The only thing they'd be guilty of is >>>>> breach of contract, and that only if the cell phone companies decided >>>>> their behavior was inconsistent with the SLA.. >>>> >>>> OK that makes more sense than the private answer I got from Roy. I >>>> wondered why the FCC didn't take action if there was a license violation. >>> >>> http://www.nytimes.com/2012/03/03/technology/fcc-reviews-need-for-rules-to-… >> >>> From the article: "Among the issues on which the F.C.C. is seeking >> comment is whether it even has authority over the issue." >> >> Also: "The BART system owns the wireless transmitters and receivers >> that allow for cellphone reception within its network.” > > I’m not sure that statement is accurate. However, there is no prohibition against owning a Microcell or other cellular station which is operated by a third party under said third party’s license. > >> I'm not entirely clear how that works. > > If that were truly the case (and I don’t think it is, given BART statements that “...the cellular providers are basically tenants and are as such subject to…”), I’m pretty sure it would be operated by the cellular carrier under their license as a non-owner of the equipment. What where the laws and practices in the Olde Days of over-the-air TV when somebody in a small town installed a translator to repeat Big-Cities-TV-Station into a small town? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

2 1