November 2013 - Test - lists.nanog.org

[pfsinoz@gmail.com: [APRICOT-INFO] APRICOT 2014 call for papers]
by bmanning＠vacation.karoshi.com 05 Nov '13

05 Nov '13

of possible interest. /bill ----- Forwarded message from Philip Smith <pfsinoz(a)gmail.com> ----- X-Mailman-Approved-At: Tue, 05 Nov 2013 19:37:41 +1000 Subject: [APRICOT-INFO] APRICOT 2014 call for papers Hi everyone, We have just released the call for presentations for APRICOT 2014. Please consider presenting at APRICOT, or encourage a colleague or friend to do so. Also we'd really appreciate it if you would help inform members of your local operations community about this CfP. Many thanks! Philip, Mark, Dean APRICOT PC Chairs -- Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 18 - 28 February 2014, Bangkok, Thailand https://2014.apricot.net CALL FOR PAPERS =============== The APRICOT 2014 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2014. We are looking for presenters who would: - Offer a technical tutorial on an appropriate topic; - Participate in the technical conference sessions as a speaker; - Convene and chair panel sessions of relevant topics. Please submit on-line at: http://papers.apricot.net/user/login.php?event=6 CONFERENCE MILESTONES --------------------- Call for Papers Opens: 1 November 2013 First Draft Programme Published: 6 December 2013 Final Deadline for Submissions: 7 February 2014 Final Programme Published: 14 February 2014 Final Slides Received: 21 February 2014 PROGRAMME MATERIAL ------------------ The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. Topics for tutorials and the conference must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - Thai Internet - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, 3G/LTE, wireless, metro ethernet, fibre, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing CfP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Final slides are to be provided by the specified deadline for publication on the APRICOT website. Prospective presenters should note that the majority of speaking slots will be filled well before the final submission deadline. The PC will retain a limited number of slots up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://papers.apricot.net/user/login.php?event=6 Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Dean Pemberton, Mark Tinka & Philip Smith Co-Chairs, APRICOT Programme Committee pc-chairs(a)apricot.net -- _______________________________________________ Apricot-info mailing list Apricot-info(a)apricot.net http://mailman.apnic.net/mailman/listinfo/apricot-info ----- End forwarded message -----

1 0

Fwd: [apops] APRICOT 2014 call for papers is now open
by Mark Tinka 05 Nov '13

05 Nov '13

FYI. Cheers, Mark.

1 0

Fwd: Re: Some stats on IPv6 fragments and EH filtering on the Internet
by Fernando Gont 04 Nov '13

04 Nov '13

Folks, FYI. Thought this might be of interest. P.S.: Input/comments welcome Thanks! Cheers, Fernando -------- Original Message -------- Subject: Some stats on IPv6 fragments and EH filtering on the Internet Date: Mon, 04 Nov 2013 15:01:48 -0800 From: Fernando Gont <fernando(a)gont.com.ar> To: 6man(a)ietf.org <6man(a)ietf.org>, IPv6 Operations <v6ops(a)ietf.org> Folks, I did a presentation on the topic at the IEPG meeting earlier this week. It provides some concrete data regarding IPv6 fragmentation and Extension Header filtering on the Internet. The slideware is available at: <http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf> Certainly there's *much* more work to be done in this area, but I thought that this could be good food sfor some of the discussions that we were having on the topic. Thanks, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------- Original Message -------- Subject: Re: Some stats on IPv6 fragments and EH filtering on the Internet Date: Mon, 4 Nov 2013 23:27:12 +0000 From: Tim Chown <tjc(a)ecs.soton.ac.uk> To: 6man(a)ietf.org <6man(a)ietf.org>, IPv6 Operations <v6ops(a)ietf.org> Hi, Also as per the IEPG discussion, the results I had in conjunction with a summer MSc project student can be summarised as follows. The headline is that he saw a 37.7% failure rate for the Fragmentation Header (alone), a bit better than Fernandos results, but still not good. He tested the top 1,000 IPv6-enabled Alexa sites. He used the scapy toolkit which supports the four main extension header types (routing, fragmentation, destination and hop-by-hop) He tested a) valid combinations of those 4 extension headers as per RFC 2460 b) other non-valid combinations c) duplicated extension headers d) fragmentation header Primarily TCP tests, doing HTTP GET requests. For single extension headers, acceptance was Routing header 63.9% Frag header 62.3% Hop by hop header 60% Destination option header 15.8% When using no extension headers, success rate was 100% When using multiple headers, the rates fall markedly, not dissimilar with Fernandos numbers for longer headers. About 120 sites accept all four types of extension headers. A small number of sites accepted illegal combinations/ordering of extension headers. A more detailed set of results is being pushed to a conference paper. I now have another student taking this further, and validating the above results, so feel free to contact me off-list if youre interested. Tim On 4 Nov 2013, at 23:01, Fernando Gont <fernando(a)gont.com.ar> wrote: > Folks, > > I did a presentation on the topic at the IEPG meeting earlier this week. > It provides some concrete data regarding IPv6 fragmentation and > Extension Header filtering on the Internet. > > The slideware is available at: > <http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf> > > Certainly there's *much* more work to be done in this area, but I > thought that this could be good food sfor some of the discussions that > we were having on the topic. > > Thanks, > -- > Fernando Gont > e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6(a)ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6(a)ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0

BGP failure analysis and recommendations
by JRC NOC 04 Nov '13

04 Nov '13

Hello Nanog - On Saturday, October 19th at about 13:00 UTC we experienced an IP failure at one of our sites in the New York area. It was apparently a widespread outage on the East coast, but I haven't seen it discussed here. We are multihomed, using EBGP to three (diverse) upstream providers. One provider experienced a hardware failure in a core component at one POP. Regrettably, during the outage our BGP session remained active and we continued receiving full routes from the affected AS. And our prefixes continued to be advertised at their border. However basically none of the traffic between those prefixes over that provider was delivered. The bogus routes stayed up for hours. We shutdown the BGP peering session when the nature of the problem became clear. This was effective. I believe that all customer BGP routes were similarly affected, including those belonging to some large regional networks and corporations. I have raised the questions below with the provider but haven't received any information or advice. My question is why did our BGP configuration fail? I'm guessing the basic answer is that the IGP and route reflectors within that provider were still connected, but the forwarding paths were unavailable. My BGP session basically acted like a bunch of static routes, with no awareness of the failure(s) and no dynamic reconfiguration of the RIB. Is this just an unavoidable issue with scaling large networks? Is it perhaps a known side effect of MPLS? Have we/they lost something important in the changeover to converged mutiprotocol networks? Is there a better way for us edge networks to achieve IP resiliency in the current environment? This is an operational issue. Thanks in advance for any hints about what happened or better practices to reduce the impact of a routine hardware fault in an upstream network. - Eric Jensen >Date: Wed, 23 Oct 2013 21:26:43 -0400 >To: cj(a)chrisjensen.org >From: JRC NetOps <noc(a)jensenresearch.com> >Subject: Fwd: BGP failure analysis and recommendations > > >>Date: Mon, 21 Oct 2013 23:19:28 -0400 >>To: christopher.smith(a)level3.com >>From: Eric Jensen <ejensen(a)jensenresearch.com> >>Subject: BGP failure analysis and recommendations >>Cc: "Joe Budelis Fast-E.com" <Joe(a)Fast-E.com> >>Bcc: noc(a)jensenresearch.com >> >>Hello Christopher Smith - >> >>I left you a voicemail message today. The Customer Service folks also >>gave me your email address. >> >>We have a small, but high-value multi-homed corporate network. >>We operate using our AS number 17103. >> >>We have BGP transit circuits with Level 3, Lightpath, and at our colo >>center (AS8001) >>The Level 3 circuit ID is BBPM9946 >> >>On Saturday, October 19 2013 we had a large IP outage. I tracked it back >>to our Level 3 circuit and opened a ticket (7126634). >>I have copied (below) an email I sent our channel salesman with more >>details about our BGP problems during your outage. >>Briefly, I am very concerned that Level 3 presented routes to us that >>were not actually reachable through your network, and even worse Level 3 >>kept advertising our prefixes even though your network couldn't deliver >>the traffic to us for those prefixes. >> >>I believe that the BGP NLRI data should follow the same IP path as the >>forwarded data itself. Apparently this isn't the case at Level 3. >>I also believe that your MPLS backbone should have recovered >>automatically from the forwarding failure, but this didn't happen either. >>My only fix was to manually shutdown the BGP peering session with Level 3. >> >>Can you explain to me how Level 3 black-holed my routes? >>Can you suggest some change to our or your BGP configuration to eliminate >>this BGP failure mode? >> >>Just to be clear, I don't expect our circuit, or your network, to be up >>all the time. But I do expect that the routes you advertise to us and to >>your BGP peers actually be reachable through your network. On Saturday >>this didn't happen. The routes stayed up while the data transport was down. >> >>Our IPv4 BGP peering session with Level 3 remains down in the interim. >>Please get back to me as soon as possible. >> >>- Eric Jensen >>AS17103 >>201-741-9509 >> >> >> >>>Date: Mon, 21 Oct 2013 22:55:35 -0400 >>>To: "Joe Budelis Fast-E.com" <Joe(a)Fast-E.com> >>>From: Eric Jensen <ejensen(a)jensenresearch.com> >>>Subject: Re: Fwd: Level3 Interim Response >>>Bcc: noc(a)jensenresearch.com >>> >>>Hi Joe- >>> >>>Thanks for making the new inquiry. >>>This was a big outage. Apparently Time Warner Cable and Cablevision >>>were affected greatly. Plus many large corporate networks. And of course >>>all the single-homed Level 3 customers worldwide. My little network was >>>just one more casualty. >>> >>>See: >>> >>>http://www.dslreports.com/forum/r28749556-Internet-Level3-Outage- >>> >>>http://online.wsj.com/news/articles/SB1000142405270230486450457914581369858… >>> >>>For our site, the massive outage started at about 9:00 am Saturday and >>>lasted until after 2:00PM. I opened a ticket about 9:30 am but only >>>realized the routing issues and took down our BGP session about 12:00 to >>>try to minimize the problems for our traffic caused by their >>>misconfigured BGP. >>> >>>There can always be equipment failures and fiber cuts. That's not the >>>problem. >>> From my point of view the problem was/is that Level 3 kept >>> "advertising" our prefix but couldn't deliver the packets to us. They >>> did this for all their customer's prefixes, thereby sucking in about >>> half the NYC area internet traffic and dumping into the Hudson River, >>> for a huge period of time. >>>They also kept advertising all their BGP routes to me, thereby fooling >>>my routers into sending outbound traffic to Level 3 where they again >>>dumped my traffic into the Hudson. >>> >>>I called Level 3 customer service today and have the name of a network >>>engineer to discuss options for fixing the BGP failure. >>>If you get any response with an engineering contact please let me know. >>> >>>I shouldn't have to manually intervene to route around problems. Even >>>sadder is the response from Level 3 explaining that they spent hours >>>trying to find the problem and had to manually reconfigure their >>>network, leading to saturated links and more problems. Their network >>>only healed when the faulty line card was replaced. >>> >>>I had reactivated the BGP session later that night, but after reviewing >>>the actual damage that we incurred, and the widespread nature of the >>>failure, I have decided to leave our Level 3 BGP session down, at least >>>until the engineering situation improves. >>>There may not be any good way to use a Level 3 BGP session without >>>risking the same "black hole" problem going forward. It's that type of >>>failure that BGP is specifically designed to deal with, but it was >>>developed in the days of point-to-point circuits carrying IP traffic. >>> >>>Nowadays some networks have a new layer between the wires and IP, namely >>>MPLS, and this allowed BGP to stay up but deprived the routers of >>>functioning IP next-hops, which they (both the Level 3 IP routers and >>>the Level 3 personnel) were unaware of. Apparently the Level 3 IP-based >>>BGP routers all believed they had working circuits edge-to-edge, but in >>>fact their network was partitioned. >>> >>>MPLS must have some redundancy features, but they obviously weren't >>>working on Saturday. This is a huge engineering failure. No large ISP >>>could function this way for long. >>> >>>I can wait the 72 hours for their response. I expect it will be full of >>>mealy-mouth platitudes about how no system is foolproof and it will all >>>be fine now. >>> >>>It would be more interesting to me to be in the meeting room where some >>>engineer has to explain how they could lose so much traffic and not be >>>able to operate a functioning, if degraded, network after a single line >>>card failure. It wouldn't be the head of network design, because that >>>person would already have been fired. >>> >>>Let me know if your hear anything. I will do the same. >>> >>>- Eric Jensen >>>AS17103 >>>201-741-9509 >>> >>> >>>

6 7

Cogent IPV6 connectivity to fireball.acr.fi
by Clinton Work 04 Nov '13

04 Nov '13

IPV6 connectivity to fireball.acr.fi is failing inside Cogent AS174. I have already contacted the Cogent NOC, but I haven't heard anything back yet. I'm wondering if somebody else with Cogent IPV6 connectivity can run some tests. IPV4 connectivity is working fine. -- Clinton Work

5 6

abha ahuja
by Randy Bush 03 Nov '13

03 Nov '13

abha ahuja, researcher and operator, died this day in 2001 at a tragically early age. if you did not know her, search a bit. she did a lot, and with an open mind and heart. randy

7 6

Re: Email Server and Dm.
by Guillaume Parent 03 Nov '13

03 Nov '13

KNow On Nov 3, 2013 1:10 PM, "TR Shaw" <tshaw(a)oitc.com> wrote: > In addition to all the other reco's below, > > 1) only allow sending by your users from the submit port and only with > authentication. There should be no client sending through the SMTP port. > > 2) Implement SSL on POP & IMAP if at all possible Otherwise enforce > CRAM-MD5 > > 3) Review logs esp pop and imap login failures. > > 4) Turn off VRFY. > > On Nov 3, 2013, at 11:49 AM, Private Sender wrote: > > > Signed PGP part > > On 11/3/2013 8:39 AM, rwebb(a)ropeguru.com wrote: > > > So I figured a little break from the NSA was in order. > > > > > > I am looking for some info on current practice for an email server > > > and SMTP delivery. It has been a while since I have had to setup an > > > email server and I have been tasked with setting up a small one for > > > a friend. My question centers around the server sending outgoing > > > email and the current practices requirements for other servers to > > > accept email Things like rDNS, SPF records, etc... > > > > > > I am pretty much set on the issue of incoming spam and virus. > > > Probably overkill but it is checked at the Sophos UTM firewall and > > > at the email server itself. > > > > > > Thanks, > > > > > > Robert > > > > > > > MX, PTR, and SPF are really all you need. I would recommend you go a > > step further and use DKIM, ADSP, and DMARC. It will help keep asshat > > spammers from flaming your domain all over the internet. > > > > I use http://www.unlocktheinbox.com/ to verify my configuration. > > > > - -- > > - -Bret Taylor > > > > > >

1 0

RE: If you're on LinkedIn, and you use a smart phone...
by Phil Bedard 03 Nov '13

03 Nov '13

I had to answer the question of "Why is LinkedIn asking for my GMail account information" to one of my parents recently. "Oh it is so they can access your information and use it...". It is how some random guys I play tennis with in a league keep popping up as people I should add, since they likely succumbed to that prompt. Another practice of theirs I do not like. Phil From: Laszlo Hanyecz Sent: 10/26/2013 1:44 To: Chris Hartley Cc: Phil Bedard; Nanog Subject: Re: If you're on LinkedIn, and you use a smart phone... When a user signs up for a social media account they generally do so by providing an email address like victim(a)freewebmailsite.com and selecting a password. The social media site can obviously probe freewebmailsite.com and attempt to authenticate using the same password that you just provided to them (for the purpose of logging into their social media site). I guess offering an email proxy or asking if it's ok to worm through your email for contacts is merely a formality. How many social media users do you guess would use the same password on the social media site as they would for freewebmailsite.com (and likely their employer's organization's email)? It's kind of like when google asks their users with android phones to provide their mobile phone number for SMS password recovery. Laszlo On Oct 25, 2013, at 11:43 PM, Chris Hartley <hartleyc(a)gmail.com> wrote: > Anyone who has access to logs for their email infrastructure ought > probably to check for authentications to user accounts from linkedin's > servers. Likely, people in your organization are entering their > credentials into linkedin to add to their contact list. Is it a > problem if a social media company has your users' credentials? I > guess it depends on your definition of "is." The same advice might > apply to this perversion of trust as well, but I'm not sure how > linkedin is achieving this "feat." > > On Fri, Oct 25, 2013 at 7:25 PM, Phil Bedard <bedard.phil(a)gmail.com> wrote: >> I saw some antectdotal stuff on this yesterday but reading their >> engineering blog entry makes me feel all warm and fuzzy inside. Oh >> nevermind, that's just the alcohol. This is perhaps one of the worst >> ideas I've seen concocted by a social media company yet. >> >> >> -Phil >> >> On 10/25/13, 6:56 PM, "George Bakos" <gbakos(a)alpinista.org> wrote: >> >>> next thing you know, Google is going to be offering free email so they >>> can do the same thing. >>> >>> On Fri, 25 Oct 2013 08:45:40 -0700 >>> Shrdlu <shrdlu(a)deaddrop.org> wrote: >>> >>>> I hate to do this, but it's something that anyone managing email >>>> servers (or just using a smart phone to update LI) needs to know >>>> about. I just saw this on another list I'm on, and I know that there >>>> are folks on NANOG that are on LinkedIn. >>>> >>>> ++++++++++ >>>> http://www.bishopfox.com/blog/2013/10/linkedin-intro/ >>>> >>>> LinkedIn released a new product today called Intro. They call it >>>> ___doing the impossible___, but some might call it ___hijacking >>>> email___. >>>> Why do we say this? Consider the following: >>>> >>>> Intro reconfigures your iOS device (e.g. iPhone, iPad) so that all of >>>> your emails go through LinkedIn___s servers. You read that right. Once >>>> you install the Intro app, all of your emails, both sent and received, >>>> are transmitted via LinkedIn___s servers. LinkedIn is forcing all your >>>> IMAP and SMTP data through their own servers and then analyzing and >>>> scraping your emails for data pertaining to___whatever they feel like. >>>> >>>> ++++++++++ >>>> >>>> Read the full article. If you're using LI via your smart phone, and >>>> you have already installed this app, you probably need to save off >>>> your contacts and data, and wipe the phone. I wouldn't trust >>>> uninstalling as enough, myself. In the long run, I'll be deleting my >>>> account. >>>> >>>> No, I don't use a smart phone to update any social media. No, I >>>> especially do not trust LI (never have, never will). BTW, they're >>>> currently adding back any contacts you've deleted. Thanks for >>>> reminding me that Joe Barr, Len Sassaman, and Jay D Dyson are gone >>>> from this world. >>>> >>>> -- >>>> Life may not be the party we hoped for, but while we are here, >>>> we might as well dance. >>>> >>>> >>> >>> >>> -- >>> >> >> >> >

2 1

Changing Google Geodatabase information
by Bryan Socha 02 Nov '13

02 Nov '13

I've been searching for a way to submit updates to google for incorrect geodatabase information on our ip address assignments. does anyone have a contact or know how to do this? Thanks, Bryan Socha

2 1

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
by Harry Hoffman 02 Nov '13

02 Nov '13

That's with a recommendation of using RC4. Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 to be your preference when trying to defend against a adversary with the resources of a nation-state. Cheers, Harry Niels Bakker <niels=nanog(a)bakker.net> wrote: >* mikal(a)stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]: >>Its about the CPU cost of the crypto. I was once told the number of >>CPUs required to do SSL on web search (which I have now forgotten) >>and it was a bigger number than you'd expect -- certainly hundreds. > >False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html > >"On our production frontend machines, SSL/TLS accounts for less than >1% of the CPU load, less than 10KB of memory per connection and less >than 2% of network overhead. Many people believe that SSL takes a lot >of CPU time and we hope the above numbers (public for the first time) >will help to dispel that." > > > -- Niels. >

9 8