From jbfixurpc at gmail.com Tue Apr 1 02:51:05 2014 From: jbfixurpc at gmail.com (Joe) Date: Mon, 31 Mar 2014 21:51:05 -0500 Subject: Just wondering Message-ID: Pardon for the ignorance regarding this. If folks can point me to something I may have missed as a participant for over 14 years, to powering this Alzheimers. I received several reports today regarding some scans for udp items from shadowservers hosted out of H.E. Seems to claim to be checking for issues regarding udp issues, amp issues, which I am all fine for, but my issue is this. It trips several IDP/IPS traps pretty much causing issues that I have to resolve. I have one user that is a home user (outside one of my /16) that has seen this as well. Now with that said are these folks that do this going to pay for one of my users that pay per bit for this? Does garbage in to this really provide a garbage clean? I see they are planing on a bunch of other protocols too, so that's nice. I'm not sure where to go with this other than to advise my other folks to drop this traffic from their 184.105.139.64/26 networks and hope for the best regarding my FAP folks. Regards, -Joe From jared at puck.nether.net Tue Apr 1 03:03:26 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 31 Mar 2014 23:03:26 -0400 Subject: Just wondering In-Reply-To: References: Message-ID: On Mar 31, 2014, at 10:51 PM, Joe wrote: > Pardon for the ignorance regarding this. If folks can point me to something > I may have missed as a participant for over 14 years, to powering this > Alzheimers. > > I received several reports today regarding some scans for udp items from > shadowservers hosted out of H.E. Seems to claim to be checking for issues > regarding udp issues, amp issues, which I am all fine for, but my issue is > this. It trips several IDP/IPS traps pretty much causing issues that I have > to resolve. I have one user that is a home user (outside one of my /16) > that has seen this as well. Now with that said are these folks that do this > going to pay for one of my users that pay per bit for this? Does garbage in > to this really provide a garbage clean? I see they are planing on a bunch > of other protocols too, so that's nice. > > I'm not sure where to go with this other than to advise my other folks to > drop this traffic from their 184.105.139.64/26 networks and hope for the > best regarding my FAP folks. There are lots of people who think they need to monitor and respond to every packet that they didn't "expect". Sadly we are in a state of the world where these surveys have become necessary both as part of people getting their PHD, but also to provide operational data to network "first responders" in closing down Open Resolvers, NTP amplifiers and many other resources that can be abused. Many folks have automated tools that "complain" when these packets come at them but aren't actually accurate in their complaints, like claiming the UDP packets are an attempt to "log-in" to their service, or saying that UDP is TCP or something else. There are a few people (Cymru, Shadowserver, myself via Open*Project) that are doing work to enumerate and provide data on the problem to the community. For each person that complains there's about 100 thank-yous for the data they received. The R&E community have a number of criteria for their collection which is to have rDNS and a website on a name matching that rDNS so people can visit it. There are also lists of "do not probe" that exist: https://www.dns-oarc.net/oarc/services/dontprobe If your security posture can't accept unsolicited packets you perhaps need to move to a whitelist model vs blacklist one for traffic. (Or your policies about this need to be reviewed... I see every IP address I have control over either home or work get scanned by all sorts of malware and evil stuff, if you have to respond to each of them, that's an impractical task). Without S.A.V.E. (BCP-38/84) one can't tell if that origin IP is accurate in any event. - Jared From rdrake at direcpath.com Tue Apr 1 03:43:49 2014 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 31 Mar 2014 23:43:49 -0400 Subject: Just wondering In-Reply-To: References: Message-ID: <533A35F5.9070604@direcpath.com> On 3/31/2014 10:51 PM, Joe wrote: > > I received several reports today regarding some scans for udp items from > shadowservers hosted out of H.E. Seems to claim to be checking for issues > regarding udp issues, amp issues, which I am all fine for, but my issue is > this. It trips several IDP/IPS traps pretty much causing issues that I have > to resolve. I have one user that is a home user (outside one of my /16) > that has seen this as well. Now with that said are these folks that do this > going to pay for one of my users that pay per bit for this? Does garbage in > to this really provide a garbage clean? I see they are planing on a bunch > of other protocols too, so that's nice. If I was paying per bit I would probably want my ISP to rate limit and firewall lots of traffic before it ever reached my pay-per-bit line. Otherwise I would be paying for huge amounts of unsolicited traffic from everywhere. > I'm not sure where to go with this other than to advise my other folks to > drop this traffic from their 184.105.139.64/26 networks and hope for the > best regarding my FAP folks. > > Regards, > -Joe > If you're comfortable that your internal audits are accurate and what these people are doing won't provide you any value, I don't see what harm it would do to block them. Since they also have to worry about botnet authors blocking their traffic, I imagine they might change IP ranges after a while. You might complain to them directly and see if they can add you to a do not poll list. It looks like they have a couple of emails for issues listed here: https://www.shadowserver.org/wiki/pmwiki.php/Involve/GetReportsOnYourNetwork From frnkblk at iname.com Tue Apr 1 05:14:39 2014 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 1 Apr 2014 00:14:39 -0500 Subject: Just wondering In-Reply-To: References: Message-ID: <003801cf4d69$481d0540$d8570fc0$@iname.com> At the bottom of one of their pages it says this: If you would like us to not scan your network, please let us know and we will remove your networks from the scan. Likewise, if you have anymore questions please feel free to send us an email at: dnsscan [at] shadowserver [dot] org. They are quite responsive to questions. Frank -----Original Message----- From: Joe [mailto:jbfixurpc at gmail.com] Sent: Monday, March 31, 2014 9:51 PM To: NANOG Subject: Just wondering Pardon for the ignorance regarding this. If folks can point me to something I may have missed as a participant for over 14 years, to powering this Alzheimers. I received several reports today regarding some scans for udp items from shadowservers hosted out of H.E. Seems to claim to be checking for issues regarding udp issues, amp issues, which I am all fine for, but my issue is this. It trips several IDP/IPS traps pretty much causing issues that I have to resolve. I have one user that is a home user (outside one of my /16) that has seen this as well. Now with that said are these folks that do this going to pay for one of my users that pay per bit for this? Does garbage in to this really provide a garbage clean? I see they are planing on a bunch of other protocols too, so that's nice. I'm not sure where to go with this other than to advise my other folks to drop this traffic from their 184.105.139.64/26 networks and hope for the best regarding my FAP folks. Regards, -Joe From akaradag at NETAS.com.tr Tue Apr 1 06:33:12 2014 From: akaradag at NETAS.com.tr (Anil KARADAG) Date: Tue, 1 Apr 2014 06:33:12 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> <53395E31.7020002@edylie.net> Message-ID: Hi again, I continue to work on fixing the problem, but no success so far. Is there any way to use client port number without enabling "use source ip"?? -----Original Message----- From: Anil KARADAG [mailto:akaradag at NETAS.com.tr] Sent: Monday, March 31, 2014 3:51 PM To: Pui Edylie; Paul Bertain Cc: nanog at nanog.org Subject: RE: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi, Thanks for solution but I cannot use it, because backend servers must know netscaler snip ip for clients. So I need fixed proxy port to communication with backend servers. -----Original Message----- From: Pui Edylie [mailto:email at edylie.net] Sent: Monday, March 31, 2014 3:23 PM To: Anil KARADAG; Paul Bertain Cc: nanog at nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: > Hi Paul, > > Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? > > Thanks > > -----Original Message----- > From: Paul Bertain [mailto:paul at bertain.net] > Sent: Tuesday, March 25, 2014 10:47 PM > To: Anil KARADAG > Cc: nanog at nanog.org > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > Hi Anil, > > Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. > > Paul > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG > wrote: >> >> Hi, >> >> I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. >> >> I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. >> >> thanks >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. >> ------------------------------------------------------- >> This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From david at mailplus.nl Tue Apr 1 07:48:18 2014 From: david at mailplus.nl (David Hofstee) Date: Tue, 1 Apr 2014 09:48:18 +0200 Subject: [mailop] IPv6 DNSBL In-Reply-To: <20140331144638.10215.qmail@joyce.lan> References: <78C35D6C1A82D243B830523B4193CF5F75B25CEDB4@SBS1.blinker.local> <20140331144638.10215.qmail@joyce.lan> Message-ID: <78C35D6C1A82D243B830523B4193CF5F75B25CEF44@SBS1.blinker.local> Maybe you did not understand my message. I know what you say. However: I see a message from a list as a message-from-a-list , not as a forwarded-message-from-a-list-user. Because: How can a user authorize someone to send a message on behalf of his/her name (by sending an email). This should not ever happen. Example: A bank sends me an email which was authorized (in some way). I now forward this message. The message is genuinely not modified. But it still does not authorize me to send this email pretending to be the bank, even if it is the same message. Conclusion: If an email was sent by me, it should be authorized/authenticated by me. For mailing lists you might want to indicate that the message can be interpreted as being forwarded for a specific user. In that way the user-interface of the email client can reply to a user directly instead of the mailing list. If that is what one wants. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -----Oorspronkelijk bericht----- Van: John Levine [mailto:johnl at taugh.com] Verzonden: Monday, March 31, 2014 4:47 PM Aan: mailop at mailop.org CC: David Hofstee Onderwerp: Re: [mailop] IPv6 DNSBL >I don't see how forwarding should break authentication. This is SPF's famous limitation. It's been debated to death, no need to rerun the argument again. DKIM survives normal forwarding, which was one of its design goals, but mailing lists typically modify the message by adding subject tags or message footers, stripping attachments, and the like, which breaks the incoming signature. That's been debated to death, too. It always seemed to me that lists should sign their mail, publish SPF for the lists's bounce addresses, and recipients would use the list's reputation to filter, Some people apparently have a security model I don't understand that evaluates the spamminess of list messages by the presence of signatures from the individual contributors. R's, John From alexwr at gmail.com Tue Apr 1 07:59:44 2014 From: alexwr at gmail.com (Alex White-Robinson) Date: Tue, 1 Apr 2014 20:59:44 +1300 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> <53395E31.7020002@edylie.net> Message-ID: Have you configured RNAT yet? Might tidy up your SIP problem. Do you need the servers to see the client's source port, or is your issue that SIP response traffic is not on the port the client expects? Give the guide to setting up RNAT here a try - http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-1-map/ns-lb-commonprotocols-sip-con.html tl;dr though - set rnat set lb sipParameters -rnatSrcPort 5060 -rnatDstPort 5060 -retryDur 1000 -addRportVip ENABLED -sip503RateThreshold 1000 On Tue, Apr 1, 2014 at 7:33 PM, Anil KARADAG wrote: > Hi again, > > > > I continue to work on fixing the problem, but no success so far. Is there > any way to use client port number without enabling "use source ip"?? > > > > -----Original Message----- > From: Anil KARADAG [mailto:akaradag at NETAS.com.tr] > Sent: Monday, March 31, 2014 3:51 PM > To: Pui Edylie; Paul Bertain > Cc: nanog at nanog.org > Subject: RE: Outgoing traffic problem on Citrix Netscaler Load Balancer > > > > Hi,SIP source ports destination ports > SIP source ports destination ports > > > Thanks for solution but I cannot use it, because backend servers must know > netscaler snip ip for clients. So I need fixed proxy port to communication > with backend servers. > > > > -----Original Message----- > > From: Pui Edylie [mailto:email at edylie.net] > > Sent: Monday, March 31, 2014 3:23 PM > > To: Anil KARADAG; Paul Bertain > > Cc: nanog at nanog.org > > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > > > Hi Anil, > > > > Take a look at > > > http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html > > - use the client's port. > > > > We prefer F5 LTM much better than Netscaler :) > > > > Cheers, > > Edy > > > > On 3/31/2014 8:17 PM, Anil KARADAG wrote: > > > Hi Paul, > > > > > > Thanks for reply, it works :). But I have another problem; source port > is altered by the virtual service. However, we need the source port to be > the same on the destination servers. Is there a way to ensure this? > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Paul Bertain [mailto:paul at bertain.net] > > > Sent: Tuesday, March 25, 2014 10:47 PM > > > To: Anil KARADAG > > > Cc: nanog at nanog.org > > > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > > > > > Hi Anil, > > > > > > Have you setup MBF? I've seen that as an issue before. If you don't > have a default route set, than MBF might help you send the response out the > interface on which it was received. > > > > > > Paul > > > > > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG > wrote: > > >> > > >> Hi, > > >> > > >> I setup a netscaler load balancer for sip traffic on Amazon EC2. > Clients packets are arrived to the backend servers over to the load > balancer but any responses cannot be arrived to clients. I see the > responses on the load balancer. > > >> > > >> I think there is a config problem for that but I don't know and did not > find any solution for that. How can I fix the outbound traffic issue. > > >> > > >> thanks > > >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve > gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere > a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu > elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve > kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal > silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i > bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti > vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun > i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve > kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye > ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > > >> ------------------------------------------------------- > > >> This e-mail and its attachments are private and confidential and > intended for the exclusive use of the individual or entity to whom it is > addressed. It may also be legally confidential. Any disclosure, > distribution or other dissemination of this message to any third party is > strictly prohibited. If you are not the intended recipient you are hereby > notified that any dissemination, forwarding, copying or use of any of the > information is strictly prohibited, and the e-mail should immediately be > deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy > or completeness of any information contained in this message and hereby > excludes any liability of any kind for the information contained therein or > for the transmission, reception, storage or use of such information in any > way whatsoever. The opinions expressed in this message are those of the > sender and may not necessarily reflect the opinions of NETA? > TELEKOM?N?KASYON A.?. > > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve > gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere > a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu > elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve > kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal > silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i > bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti > vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun > i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve > kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye > ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > > > ------------------------------------------------------- > > > This e-mail and its attachments are private and confidential and > intended for the exclusive use of the individual or entity to whom it is > addressed. It may also be legally confidential. Any disclosure, > distribution or other dissemination of this message to any third party is > strictly prohibited. If you are not the intended recipient you are hereby > notified that any dissemination, forwarding, copying or use of any of the > information is strictly prohibited, and the e-mail should immediately be > deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy > or completeness of any information contained in this message and hereby > excludes any liability of any kind for the information contained therein or > for the transmission, reception, storage or use of such information in any > way whatsoever. The opinions expressed in this message are those of the > sender and may not necessarily reflect the opinions of NETA? > TELEKOM?N?KASYON A.?. > > > > > > > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve > gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere > a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu > elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve > kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal > silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i > bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti > vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun > i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve > kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye > ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > > ------------------------------------------------------- > > This e-mail and its attachments are private and confidential and intended > for the exclusive use of the individual or entity to whom it is addressed. > It may also be legally confidential. Any disclosure, distribution or other > dissemination of this message to any third party is strictly prohibited. If > you are not the intended recipient you are hereby notified that any > dissemination, forwarding, copying or use of any of the information is > strictly prohibited, and the e-mail should immediately be deleted. NETA? > TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness > of any information contained in this message and hereby excludes any > liability of any kind for the information contained therein or for the > transmission, reception, storage or use of such information in any way > whatsoever. The opinions expressed in this message are those of the sender > and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve > gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere > a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu > elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve > kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal > silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i > bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti > vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun > i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve > kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye > ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended > for the exclusive use of the individual or entity to whom it is addressed. > It may also be legally confidential. Any disclosure, distribution or other > dissemination of this message to any third party is strictly prohibited. If > you are not the intended recipient you are hereby notified that any > dissemination, forwarding, copying or use of any of the information is > strictly prohibited, and the e-mail should immediately be deleted. NETA? > TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness > of any information contained in this message and hereby excludes any > liability of any kind for the information contained therein or for the > transmission, reception, storage or use of such information in any way > whatsoever. The opinions expressed in this message are those of the sender > and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > From akaradag at NETAS.com.tr Tue Apr 1 08:38:18 2014 From: akaradag at NETAS.com.tr (Anil KARADAG) Date: Tue, 1 Apr 2014 08:38:18 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> <53395E31.7020002@edylie.net> Message-ID: My aim is forwarding all sip packages from netscaler snip:client port number to backend server ip: backend server port. I tried the following scenarios; - "use source ip" is enabled, "use proxy port" is set no o Result: we see client port as source port but no SNIP for source ip-address - In additional above configured also RNAT o Result: we see SNIP ip address as source ip address but source port again become random. Checked the citrix support link for rnat, but our sip packages include 'via header' option with SNIP: client port number; Via: SIP/2.0/UDP set lb sipParameters -rnatSrcPort 5060 -rnatDstPort 5060 -retryDur 1000 -addRportVip ENABLED -sip503RateThreshold 1000 On Tue, Apr 1, 2014 at 7:33 PM, Anil KARADAG > wrote: Hi again, I continue to work on fixing the problem, but no success so far. Is there any way to use client port number without enabling "use source ip"?? -----Original Message----- From: Anil KARADAG [mailto:akaradag at NETAS.com.tr] Sent: Monday, March 31, 2014 3:51 PM To: Pui Edylie; Paul Bertain Cc: nanog at nanog.org Subject: RE: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi,SIP source ports destination ports SIP source ports destination ports Thanks for solution but I cannot use it, because backend servers must know netscaler snip ip for clients. So I need fixed proxy port to communication with backend servers. -----Original Message----- From: Pui Edylie [mailto:email at edylie.net] Sent: Monday, March 31, 2014 3:23 PM To: Anil KARADAG; Paul Bertain Cc: nanog at nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: > Hi Paul, > > Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? > > Thanks > > -----Original Message----- > From: Paul Bertain [mailto:paul at bertain.net] > Sent: Tuesday, March 25, 2014 10:47 PM > To: Anil KARADAG > Cc: nanog at nanog.org > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > Hi Anil, > > Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. > > Paul > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG >> wrote: >> >> Hi, >> >> I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. >> >> I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. >> >> thanks >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. >> ------------------------------------------------------- >> This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From paul at bertain.net Tue Apr 1 13:58:16 2014 From: paul at bertain.net (Paul Bertain) Date: Tue, 1 Apr 2014 06:58:16 -0700 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> <53395E31.7020002@edylie.net> Message-ID: <3D3D1AA9-AF54-4508-971D-D4D1FBE1D422@bertain.net> Hi Anil, The command is for the service or servicegroup and it is: set service -useproxyport (NO|YES) Paul > On Apr 1, 2014, at 1:38, Anil KARADAG wrote: > > My aim is forwarding all sip packages from netscaler snip:client port number to backend server ip: backend server port. I tried the following scenarios; > > - ?use source ip? is enabled, ?use proxy port? is set no > o Result: we see client port as source port but no SNIP for source ip-address > - In additional above configured also RNAT > o Result: we see SNIP ip address as source ip address but source port again become random. > > Checked the citrix support link for rnat, but our sip packages include ?via header? option with SNIP: client port number; > > Via: SIP/2.0/UDP From: Alex White-Robinson [mailto:alexwr at gmail.com] > Sent: Tuesday, April 01, 2014 11:00 AM > To: Anil KARADAG > Cc: Pui Edylie; Paul Bertain; nanog at nanog.org > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > Have you configured RNAT yet? Might tidy up your SIP problem. Do you need the servers to see the client's source port, or is your issue that SIP response traffic is not on the port the client expects? > > Give the guide to setting up RNAT here a try - http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-1-map/ns-lb-commonprotocols-sip-con.html > > tl;dr though - > set rnat > set lb sipParameters -rnatSrcPort 5060 -rnatDstPort 5060 -retryDur 1000 -addRportVip ENABLED -sip503RateThreshold 1000 > > > > On Tue, Apr 1, 2014 at 7:33 PM, Anil KARADAG wrote: > Hi again, > > > > I continue to work on fixing the problem, but no success so far. Is there any way to use client port number without enabling "use source ip"?? > > > > -----Original Message----- > From: Anil KARADAG [mailto:akaradag at NETAS.com.tr] > Sent: Monday, March 31, 2014 3:51 PM > To: Pui Edylie; Paul Bertain > Cc: nanog at nanog.org > Subject: RE: Outgoing traffic problem on Citrix Netscaler Load Balancer > > > > Hi,SIP source ports destination ports > SIP source ports destination ports > > > Thanks for solution but I cannot use it, because backend servers must know netscaler snip ip for clients. So I need fixed proxy port to communication with backend servers. > > > > -----Original Message----- > > From: Pui Edylie [mailto:email at edylie.net] > > Sent: Monday, March 31, 2014 3:23 PM > > To: Anil KARADAG; Paul Bertain > > Cc: nanog at nanog.org > > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > > > Hi Anil, > > > > Take a look at > > http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html > > - use the client's port. > > > > We prefer F5 LTM much better than Netscaler :) > > > > Cheers, > > Edy > > > > On 3/31/2014 8:17 PM, Anil KARADAG wrote: > > > Hi Paul, > > > > > > Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? > > > > > > Thanks > > > > > > -----Original Message----- > > > From: Paul Bertain [mailto:paul at bertain.net] > > > Sent: Tuesday, March 25, 2014 10:47 PM > > > To: Anil KARADAG > > > Cc: nanog at nanog.org > > > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > > > > > Hi Anil, > > > > > > Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. > > > > > > Paul > > > > > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG > wrote: > > >> > > >> Hi, > > >> > > >> I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. > > >> > > >> I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. > > >> > > >> thanks > > >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. > > >> ------------------------------------------------------- > > >> This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > > > ------------------------------------------------------- > > > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > > > > > > > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > > ------------------------------------------------------- > > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From job at instituut.net Tue Apr 1 15:11:00 2014 From: job at instituut.net (Job Snijders) Date: Tue, 1 Apr 2014 17:11:00 +0200 Subject: Calculator written in route-map Message-ID: <20140401151100.GA33460@Eleanor.local> Hi all, Do you often find yourself in need of a simple calculator, and all you have available to you is a Brocade or Cisco IOS router? No longer will you experience the horror and dread of mental arithmetics. The route-map calculator is here! Brocade : http://instituut.net/~job/calculator-route-map.brocade.txt Cisco IOS : http://instituut.net/~job/calculator-route-map.ioscisco.txt (file size ~ 12 megabyte) In general I don't find route-maps useful to accomplish, well, anything. However, this is a striking example of re-usable configuration that has a measurable impact on daily operations! Calculations can be performed with integers between 1 and 256. The answer will be presented as a rounded positive integer. In case the calculation would result in a negative integer, larger than 2^16 (65536), an helpful error message is generated: 65000:7777. For divisions and substractions the order of the BGP communities is relevant, one must always place the operator first! arithmetic operators: 'add' operator community: 65000:1 'multiply' operator community: 65000:2 'substract' operator community: 65000:3 'divide' operator community: 65000:4 example output: telnet at input-router#show ip bgp routes detail 10.1.1.1 | i COMMUNITIES COMMUNITIES: 65000:2 0:63 0:113 ! calculate 63 * 113 telnet at input-router# telnet at calculator#show ip bgp routes detail 10.1.1.1 | i COMMUNITIES COMMUNITIES: 0:7119 ! result: 7119 telnet at calculator# Super convenient right?! WARNING: due to IOS/Ironware architecture this route-map consumes quite some memory. Always test in a lab before deploying in production! Kind regards, Job From swmike at swm.pp.se Tue Apr 1 15:23:43 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 1 Apr 2014 17:23:43 +0200 (CEST) Subject: Calculator written in route-map In-Reply-To: <20140401151100.GA33460@Eleanor.local> References: <20140401151100.GA33460@Eleanor.local> Message-ID: On Tue, 1 Apr 2014, Job Snijders wrote: > Do you often find yourself in need of a simple calculator, and all you > have available to you is a Brocade or Cisco IOS router? No longer will > you experience the horror and dread of mental arithmetics. The route-map > calculator is here! Is this meant as a proof that we need better operators for doing stuff based on contents of bgp communities? Because I concur that this is needed! Making it understand that "65000:65003" 65000:6500x" means take X and prepend your own ASn X times, and not have to do this explicitly. -- Mikael Abrahamsson email: swmike at swm.pp.se From casey at deccio.net Tue Apr 1 17:53:46 2014 From: casey at deccio.net (Casey Deccio) Date: Tue, 1 Apr 2014 13:53:46 -0400 Subject: Microsoft mail contact Message-ID: Hi all, I'm looking for a Microsoft mail contact, specifically for MTAs in 2a01:111:f400::/48 address space. Please contact me off-list. Thanks, Casey From mehmet at akcin.net Tue Apr 1 17:56:45 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 1 Apr 2014 10:56:45 -0700 Subject: Microsoft mail contact In-Reply-To: References: Message-ID: <1C7B6C12-6823-4EF4-AF2C-58C50E2FE4F9@akcin.net> Replied Off-list Mehmet > On Apr 1, 2014, at 10:53, Casey Deccio wrote: > > Hi all, > > I'm looking for a Microsoft mail contact, specifically for MTAs in > 2a01:111:f400::/48 address space. Please contact me off-list. > > Thanks, > Casey From ckossmey at cisco.com Tue Apr 1 18:44:06 2014 From: ckossmey at cisco.com (Clay Kossmeyer) Date: Tue, 1 Apr 2014 14:44:06 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Message-ID: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> Hi All - The Cisco PSIRT has been sending IOS Security Advisories to the NANOG mailing list for well over a decade. We started this process a long time ago at the request of the list?s then-membership and haven?t been asked to change since. Admittedly, vulnerability disclosure/discussion/reporting has changed a bit over the years and we may be a bit overdue on rethinking the need to send to NANOG. :) Given that there are a number of forums that more directly address either Cisco-specific issues or are specific to vulnerability announcements, we?re happy to discontinue sending to the NANOG list directly. Cisco maintains a mailing list and RSS feed to which we send our Security Advisories, and you?re welcome to join if interested: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html#rsvifc Thanks, Clay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 204 bytes Desc: Message signed with OpenPGP using GPGMail URL: From chuckchurch at gmail.com Tue Apr 1 19:24:32 2014 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 1 Apr 2014 15:24:32 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> References: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> Message-ID: <00cb01cf4de0$0339dad0$09ad9070$@gmail.com> Given that probably 80+% (a guess, but I'd be really surprised at a lower figure) of all internet traffic crosses at least one Cisco device somewhere, I think it would be a huge disservice to discontinue sending these emails. 10 to 15 emails per year isn't much overhead, compared to seemingly never-discussions on mandatory email legal signatures and other fluff. Chuck -----Original Message----- From: Clay Kossmeyer [mailto:ckossmey at cisco.com] Sent: Tuesday, April 01, 2014 2:44 PM To: nanog at nanog.org Cc: Clay Seaman-Kossmeyer (ckossmey) Subject: Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Hi All - The Cisco PSIRT has been sending IOS Security Advisories to the NANOG mailing list for well over a decade. We started this process a long time ago at the request of the list's then-membership and haven't been asked to change since. Admittedly, vulnerability disclosure/discussion/reporting has changed a bit over the years and we may be a bit overdue on rethinking the need to send to NANOG. :) Given that there are a number of forums that more directly address either Cisco-specific issues or are specific to vulnerability announcements, we're happy to discontinue sending to the NANOG list directly. Cisco maintains a mailing list and RSS feed to which we send our Security Advisories, and you're welcome to join if interested: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy. html#rsvifc Thanks, Clay From Valdis.Kletnieks at vt.edu Tue Apr 1 19:34:51 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 01 Apr 2014 15:34:51 -0400 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: Your message of "Tue, 01 Apr 2014 15:24:32 -0400." <00cb01cf4de0$0339dad0$09ad9070$@gmail.com> References: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> <00cb01cf4de0$0339dad0$09ad9070$@gmail.com> Message-ID: <16666.1396380891@turing-police.cc.vt.edu> On Tue, 01 Apr 2014 15:24:32 -0400, "Chuck Church" said: > Given that probably 80+% (a guess, but I'd be really surprised at a lower > figure) of all internet traffic crosses at least one Cisco device somewhere, > I think it would be a huge disservice to discontinue sending these emails. Actually, the *real* value here is for those of us who are *not* Cisco shops, but the box at the other end of the wire *is*, so that we can be aware of what possible problems the other end may encounter.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From surfer at mauigateway.com Tue Apr 1 19:36:52 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 1 Apr 2014 12:36:52 -0700 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Message-ID: <20140401123652.BE81339C@m0005299.ppops.net> --- ckossmey at cisco.com wrote: From: Clay Kossmeyer [...] we?re happy to discontinue sending to the NANOG list directly. -------------------------------------------------- Instead of discontinuing them how about one email that contains all the details, rather than one email per detail. Similar to what I sent to the list earlier. For example: ---------------------------------------------- The Semiannual Cisco IOS Software Security Advisory has been released. For information please goto this URL: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html Advisory titles: - Session Initiation Protocol Denial of Service Vulnerability - Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks Denial of Service Vulnerability - Internet Key Exchange Version 2 Denial of Service Vulnerability - Network Address Translation Vulnerabilities - SSL VPN Denial of Service Vulnerability - Crafted IPv6 Packet Denial of Service Vulnerability ----------------------------------------------- scott From brandon at rd.bbc.co.uk Tue Apr 1 21:03:01 2014 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 1 Apr 2014 22:03:01 +0100 (BST) Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Message-ID: <201404012103.WAA21487@sunf10.rd.bbc.co.uk> > The Cisco PSIRT has been sending IOS Security Advisories to > the NANOG mailing list for well over a decade Thank you, much appreciated > Given that there are a number of forums that more directly > address either Cisco-specific issues or are specific to > vulnerability announcements, we?re happy to discontinue > sending to the NANOG list directly. They are lost in the noise of some endless threads > Cisco maintains a mailing list and RSS feed to which we > send our Security Advisories NANOG having a filtered feed of ISP backbone risk level advisorises seems fair brandon From ted at io-tx.com Tue Apr 1 21:48:04 2014 From: ted at io-tx.com (Ted Hatfield) Date: Tue, 1 Apr 2014 16:48:04 -0500 (CDT) Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <201404012103.WAA21487@sunf10.rd.bbc.co.uk> References: <201404012103.WAA21487@sunf10.rd.bbc.co.uk> Message-ID: On Tue, 1 Apr 2014, Brandon Butterworth wrote: >> The Cisco PSIRT has been sending IOS Security Advisories to >> the NANOG mailing list for well over a decade > > Thank you, much appreciated > >> Given that there are a number of forums that more directly >> address either Cisco-specific issues or are specific to >> vulnerability announcements, we?re happy to discontinue >> sending to the NANOG list directly. > > They are lost in the noise of some endless threads > >> Cisco maintains a mailing list and RSS feed to which we >> send our Security Advisories > > NANOG having a filtered feed of ISP backbone risk level > advisorises seems fair > > brandon > > One of the reasons I subscribe to the NANOG list is to get these security advisories. I can always subscribe to another security list if necessary but I would would hope that CISCO would continue to send these notices, even if they are in a digest format. Ted Hatfield From mike-nanog at tiedyenetworks.com Wed Apr 2 01:44:01 2014 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 01 Apr 2014 18:44:01 -0700 Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> References: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> Message-ID: <533B6B61.4060107@tiedyenetworks.com> On 04/01/2014 11:44 AM, Clay Kossmeyer wrote: > Hi All - > > The Cisco PSIRT has been sending IOS Security Advisories to the NANOG mailing list for well over a decade. We started this process a long time ago at the request of the list?s then-membership and haven?t been asked to change since. > > Admittedly, vulnerability disclosure/discussion/reporting has changed a bit over the years and we may be a bit overdue on rethinking the need to send to NANOG. :) > > Given that there are a number of forums that more directly address either Cisco-specific issues or are specific to vulnerability announcements, we?re happy to discontinue sending to the NANOG list directly. > > Cisco maintains a mailing list and RSS feed to which we send our Security Advisories, and you?re welcome to join if interested: > > http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html#rsvifc > Its true this information is also available in other forums, but I don't have time to filter thru all of those. I *do* have time for nanog, however, because of the good cross section represented here and because it's worthwhile to be aware of what may be happening in other people's camps, because very frequently problems on one side of the wire can spill over and affect the other side as well. I think the advisories are highly relevent then and absolutely should be included here on nanog. Thanks. From jrex at CS.Princeton.EDU Tue Apr 1 15:22:08 2014 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Tue, 1 Apr 2014 11:22:08 -0400 Subject: Calculator written in route-map In-Reply-To: <20140401151100.GA33460@Eleanor.local> References: <20140401151100.GA33460@Eleanor.local> Message-ID: Job, Fun! More generally, BGP has the same computing power as a Turing Machine: Marco Chiesa, Luca Cittadini, Guiseppe Di Battista, Laurent Vanbever, and Stefano Vissicchio Using routers to build logic circuits: How powerful is BGP? (ICNP'13) http://vanbever.eu/pdfs/vanbever_turing_icnp_2013.pdf -- Jen On Apr 1, 2014, at 11:11 AM, Job Snijders wrote: > Hi all, > > Do you often find yourself in need of a simple calculator, and all you have > available to you is a Brocade or Cisco IOS router? No longer will you > experience the horror and dread of mental arithmetics. The route-map calculator > is here! > > Brocade : http://instituut.net/~job/calculator-route-map.brocade.txt > Cisco IOS : http://instituut.net/~job/calculator-route-map.ioscisco.txt > (file size ~ 12 megabyte) > > In general I don't find route-maps useful to accomplish, well, anything. > However, this is a striking example of re-usable configuration that has > a measurable impact on daily operations! > > Calculations can be performed with integers between 1 and 256. The > answer will be presented as a rounded positive integer. In case the > calculation would result in a negative integer, larger than 2^16 > (65536), an helpful error message is generated: 65000:7777. For > divisions and substractions the order of the BGP communities is > relevant, one must always place the operator first! > > arithmetic operators: > > 'add' operator community: 65000:1 > 'multiply' operator community: 65000:2 > 'substract' operator community: 65000:3 > 'divide' operator community: 65000:4 > > example output: > > telnet at input-router#show ip bgp routes detail 10.1.1.1 | i COMMUNITIES > COMMUNITIES: 65000:2 0:63 0:113 ! calculate 63 * 113 > telnet at input-router# > > telnet at calculator#show ip bgp routes detail 10.1.1.1 | i COMMUNITIES > COMMUNITIES: 0:7119 ! result: 7119 > telnet at calculator# > > Super convenient right?! > > WARNING: due to IOS/Ironware architecture this route-map consumes quite > some memory. Always test in a lab before deploying in production! > > Kind regards, > > Job > From randy_94108 at yahoo.com Wed Apr 2 05:23:42 2014 From: randy_94108 at yahoo.com (Randy) Date: Tue, 1 Apr 2014 22:23:42 -0700 (PDT) Subject: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability In-Reply-To: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> References: <73355C63-5D7F-420E-87FC-C3B7BFE9D199@cisco.com> Message-ID: <1396416222.16327.YahooMailNeo@web181706.mail.ne1.yahoo.com> From: Clay Kossmeyer To: nanog at nanog.org Cc: Clay Seaman-Kossmeyer (ckossmey) Sent: Tuesday, April 1, 2014 11:44 AM Subject: Re: Cisco Security Advisory: Cisco IOS Software SSL VPN Denial of Service Vulnerability Hi All - The Cisco PSIRT has been sending IOS Security Advisories to the NANOG mailing list for well over a decade.? We started this process a long time ago at the request of the list?s then-membership and haven?t been asked to change since. Admittedly, vulnerability disclosure/discussion/reporting has changed a bit over the years and we may be a bit overdue on rethinking the need to send to NANOG. :) Given that there are a number of forums that more directly address either Cisco-specific issues or are specific to vulnerability announcements, we?re happy to discontinue sending to the NANOG list directly. Cisco maintains a mailing list and RSS feed to which we send our Security Advisories, and you?re welcome to join if interested: http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html#rsvifc Thanks, Clay Touche'! ....such is NANOG...a few who post more frequently than most like to umm... Speak-UP. ./Randy From akaradag at NETAS.com.tr Wed Apr 2 05:51:28 2014 From: akaradag at NETAS.com.tr (Anil KARADAG) Date: Wed, 2 Apr 2014 05:51:28 +0000 Subject: Outgoing traffic problem on Citrix Netscaler Load Balancer In-Reply-To: <3D3D1AA9-AF54-4508-971D-D4D1FBE1D422@bertain.net> References: <33BB8CBA-7ED1-40BB-B27A-6A457C7D2419@bertain.net> <53395E31.7020002@edylie.net> <3D3D1AA9-AF54-4508-971D-D4D1FBE1D422@bertain.net> Message-ID: Hi Paul, I use Netscaler 10.1, and ?use proxy port? option depends on ?use source ip?. I don?t understand why I cannot set no for proxy port without enabling source ip. Its very bad solution for that. From: Paul Bertain [mailto:paul at bertain.net] Sent: Tuesday, April 01, 2014 4:58 PM To: Anil KARADAG Cc: Alex White-Robinson; Pui Edylie; Paul Bertain; nanog at nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, The command is for the service or servicegroup and it is: set service -useproxyport (NO|YES) Paul On Apr 1, 2014, at 1:38, Anil KARADAG > wrote: My aim is forwarding all sip packages from netscaler snip:client port number to backend server ip: backend server port. I tried the following scenarios; - ?use source ip? is enabled, ?use proxy port? is set no o Result: we see client port as source port but no SNIP for source ip-address - In additional above configured also RNAT o Result: we see SNIP ip address as source ip address but source port again become random. Checked the citrix support link for rnat, but our sip packages include ?via header? option with SNIP: client port number; Via: SIP/2.0/UDP Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Have you configured RNAT yet? Might tidy up your SIP problem. Do you need the servers to see the client's source port, or is your issue that SIP response traffic is not on the port the client expects? Give the guide to setting up RNAT here a try - http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-1-map/ns-lb-commonprotocols-sip-con.html tl;dr though - set rnat set lb sipParameters -rnatSrcPort 5060 -rnatDstPort 5060 -retryDur 1000 -addRportVip ENABLED -sip503RateThreshold 1000 On Tue, Apr 1, 2014 at 7:33 PM, Anil KARADAG > wrote: Hi again, I continue to work on fixing the problem, but no success so far. Is there any way to use client port number without enabling "use source ip"?? -----Original Message----- From: Anil KARADAG [mailto:akaradag at NETAS.com.tr] Sent: Monday, March 31, 2014 3:51 PM To: Pui Edylie; Paul Bertain Cc: nanog at nanog.org Subject: RE: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi,SIP source ports destination ports SIP source ports destination ports Thanks for solution but I cannot use it, because backend servers must know netscaler snip ip for clients. So I need fixed proxy port to communication with backend servers. -----Original Message----- From: Pui Edylie [mailto:email at edylie.net] Sent: Monday, March 31, 2014 3:23 PM To: Anil KARADAG; Paul Bertain Cc: nanog at nanog.org Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer Hi Anil, Take a look at http://support.citrix.com/proddocs/topic/ns-system-10-1-map/ns-nw-ipaddrssng-enabling-use-src-ip-mode-tsk.html - use the client's port. We prefer F5 LTM much better than Netscaler :) Cheers, Edy On 3/31/2014 8:17 PM, Anil KARADAG wrote: > Hi Paul, > > Thanks for reply, it works :). But I have another problem; source port is altered by the virtual service. However, we need the source port to be the same on the destination servers. Is there a way to ensure this? > > Thanks > > -----Original Message----- > From: Paul Bertain [mailto:paul at bertain.net] > Sent: Tuesday, March 25, 2014 10:47 PM > To: Anil KARADAG > Cc: nanog at nanog.org > Subject: Re: Outgoing traffic problem on Citrix Netscaler Load Balancer > > Hi Anil, > > Have you setup MBF? I've seen that as an issue before. If you don't have a default route set, than MBF might help you send the response out the interface on which it was received. > > Paul > >> On Mar 24, 2014, at 11:46 PM, Anil KARADAG >> wrote: >> >> Hi, >> >> I setup a netscaler load balancer for sip traffic on Amazon EC2. Clients packets are arrived to the backend servers over to the load balancer but any responses cannot be arrived to clients. I see the responses on the load balancer. >> >> I think there is a config problem for that but I don't know and did not find any solution for that. How can I fix the outbound traffic issue. >> >> thanks >> Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.'nin g?r??lerini yans?tmayabilir. >> ------------------------------------------------------- >> This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. > Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. > ------------------------------------------------------- > This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. Bu e-posta mesaj? ve ekleri g?nderildi?i ki?i ya da kuruma ?zeldir ve gizlidir. Ayr?ca hukuken de gizli olabilir. Hi?bir ?ekilde ???nc? ki?ilere a??klanamaz ve yay?nlanamaz. E?er mesaj?n g?nderildi?i al?c? de?ilseniz bu elektronik postan?n i?eri?ini a??klaman?z, kopyalaman?z, y?nlendirmeniz ve kullanman?z kesinlikle yasakt?r ve bu elektronik postay? ve eklerini derhal silmeniz gerekmektedir. NETA? TELEKOM?N?KASYON A.?. bu mesaj?n i?erdi?i bilgilerin do?rulu?u veya eksiksiz oldu?u konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne ?ekilde olursa olsun i?eri?inden, iletilmesinden, al?nmas?ndan, saklanmas?ndan ve kullan?lmas?ndan sorumlu de?ildir. Bu mesajdaki g?r??ler g?nderen ki?iye ait olup, NETA? TELEKOM?N?KASYON A.?.?nin g?r??lerini yans?tmayabilir. ------------------------------------------------------- This e-mail and its attachments are private and confidential and intended for the exclusive use of the individual or entity to whom it is addressed. It may also be legally confidential. Any disclosure, distribution or other dissemination of this message to any third party is strictly prohibited. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is strictly prohibited, and the e-mail should immediately be deleted. NETA? TELEKOM?N?KASYON A.?. makes no warranty as to the accuracy or completeness of any information contained in this message and hereby excludes any liability of any kind for the information contained therein or for the transmission, reception, storage or use of such information in any way whatsoever. The opinions expressed in this message are those of the sender and may not necessarily reflect the opinions of NETA? TELEKOM?N?KASYON A.?. From h.wahl at ifw-dresden.de Wed Apr 2 06:11:38 2014 From: h.wahl at ifw-dresden.de (Henri Wahl) Date: Wed, 02 Apr 2014 08:11:38 +0200 Subject: Microsoft security contact Message-ID: <533BAA1A.8040005@ifw-dresden.de> Hello, can someone from Microsoft responsible for security contact me off-list please? Thanks & regards -- Henri Wahl IT Department Leibniz-Institut fuer Festkoerper- u. Werkstoffforschung Dresden tel: (03 51) 46 59 - 797 email: h.wahl at ifw-dresden.de http://www.ifw-dresden.de Nagios status monitor Nagstamon: http://nagstamon.ifw-dresden.de DHCPv6 server dhcpy6d: http://dhcpy6d.ifw-dresden.de IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden VR Dresden Nr. 1369 Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From mehmet at akcin.net Wed Apr 2 06:33:42 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 1 Apr 2014 23:33:42 -0700 Subject: Microsoft security contact In-Reply-To: <533BAA1A.8040005@ifw-dresden.de> References: <533BAA1A.8040005@ifw-dresden.de> Message-ID: <6E130DEE-F52B-4BDD-B9C1-411AA4AC99B3@akcin.net> Replied offlist Mehmet > On Apr 1, 2014, at 23:11, Henri Wahl wrote: > > Hello, > can someone from Microsoft responsible for security contact me off-list > please? > Thanks & regards > > -- > Henri Wahl > > IT Department > Leibniz-Institut fuer Festkoerper- u. > Werkstoffforschung Dresden > > tel: (03 51) 46 59 - 797 > email: h.wahl at ifw-dresden.de > http://www.ifw-dresden.de > > Nagios status monitor Nagstamon: > http://nagstamon.ifw-dresden.de > > DHCPv6 server dhcpy6d: > http://dhcpy6d.ifw-dresden.de > > IFW Dresden e.V., Helmholtzstrasse 20, D-01069 Dresden > VR Dresden Nr. 1369 > Vorstand: Prof. Dr. Juergen Eckert, Dr. h.c. Dipl.-Finw. Rolf Pfrengle > From mallman at icir.org Wed Apr 2 12:38:09 2014 From: mallman at icir.org (Mark Allman) Date: Wed, 02 Apr 2014 08:38:09 -0400 Subject: new DNS forwarder vulnerability In-Reply-To: <53248184.7050404@mykolab.com> Message-ID: <20140402123809.1C6253C5B8FB@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jared at puck.nether.net Wed Apr 2 12:54:47 2014 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 2 Apr 2014 08:54:47 -0400 Subject: new DNS forwarder vulnerability In-Reply-To: <20140402123809.1C6253C5B8FB@lawyers.icir.org> References: <20140402123809.1C6253C5B8FB@lawyers.icir.org> Message-ID: On Apr 2, 2014, at 8:38 AM, Mark Allman wrote: > > [catching up] > >> That's a good question, but I know that during the ongoing survey >> within the Open Resolver Project [http://openresolverproject.org/], >> Jared found thousands of CPE devices which responded as resolvers. > > Not thousands, *tens of millions*. > > Our estimate from mid-2013 was 32M such devices (detailed in an IMC > paper last year; http://www.icir.org/mallman/pubs/SCRA13/). And, that > roughly agrees with both the openresolverproject.org numbers and another > (not public) study I know of. And, as if that isn't bad enough > ... there is a 2010 IMC paper that puts the number at 15M. I.e., the > instances of brokenness are getting worse---doubling in 3 years! UGH. One observation: The OpenResolverProject collects responses that come from ports that the query was not sent to (ie: device responds from UDP/12345 not from UDP/53, which obviously is broken and doesn't "work", but they actually return DNS payload which can be used for abuse). Some good news though: http://openresolverproject.org/breakdown-graph1.cgi Since the start of 2014 there seem to be new CPE devices out there that are resolving this issue. The linear nature of the line in the decrease doesn't seem to be something like "ISPs" started blocking udp/53 to customers, which would appear more like a step function. I'm aware of some other studies ongoing to fingerprint CPE and their behaviors/aggregated resolver dependencies. I expect to see some of that data presented at the upcoming DNS-OARC meeting in Warsaw. Getting everyone to update their firmware on devices would go a long way as well. Some vendors have no software QA on this front so add/remove the response on the WAN interface as their releases march forward. - Jared From jabley at hopcount.ca Wed Apr 2 18:14:22 2014 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 2 Apr 2014 14:14:22 -0400 Subject: real-world data about fragmentation Message-ID: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> Hi all, It's common wisdom that a datagram that needs to be fragmented between endpoints (because it is bigger than the path MTU) will demonstrate less reliable delivery and reassembly than a datagram that doesn't need to be fragmented, because math, firewall, other, take your pick. Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. What does the curve look like between 576 bytes and 10,000 bytes? I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. Anybody have any pointers? IPv4 and IPv6 are both interesting. Joe From bmanning at vacation.karoshi.com Wed Apr 2 18:50:53 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 2 Apr 2014 11:50:53 -0700 Subject: real-world data about fragmentation In-Reply-To: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> References: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> Message-ID: <20140402185053.GB23819@vacation.karoshi.com> I can send you a copy of an invited presentation at AINTEC from 2009. /bill On Wed, Apr 02, 2014 at 02:14:22PM -0400, Joe Abley wrote: > Hi all, > > It's common wisdom that a datagram that needs to be fragmented between endpoints (because it is bigger than the path MTU) will demonstrate less reliable delivery and reassembly than a datagram that doesn't need to be fragmented, because math, firewall, other, take your pick. > > Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? > > For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. > > What does the curve look like between 576 bytes and 10,000 bytes? > > I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. > > Anybody have any pointers? IPv4 and IPv6 are both interesting. > > > Joe From joe at breathe-underwater.com Wed Apr 2 18:51:58 2014 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Wed, 2 Apr 2014 11:51:58 -0700 Subject: BGPMON Alert Questions Message-ID: So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 From shawnl at up.net Wed Apr 2 18:57:01 2014 From: shawnl at up.net (Shawn L) Date: Wed, 2 Apr 2014 14:57:01 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: I just received the same exact notification -- same AS announcing one of my blocks. On Wed, Apr 2, 2014 at 2:51 PM, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From frnkblk at iname.com Wed Apr 2 18:59:12 2014 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Apr 2014 13:59:12 -0500 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> I received a similar notification about one of our prefixes also a few minutes ago. I couldn't find a looking glass for AS4761 or AS4651. But I also couldn't hit the websites for either AS, either. Frank -----Original Message----- From: Joseph Jenkins [mailto:joe at breathe-underwater.com] Sent: Wednesday, April 02, 2014 1:52 PM To: nanog at nanog.org Subject: BGPMON Alert Questions So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 From thorhallur.halfdanarson at advania.is Wed Apr 2 18:59:19 2014 From: thorhallur.halfdanarson at advania.is (=?iso-8859-1?Q?=DE=F3rhallur_H=E1lfd=E1narson?=) Date: Wed, 2 Apr 2014 18:59:19 +0000 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <5C0400DA-72BF-45D0-80D4-A2DA9BA1DBE0@advania.is> I have received those for two prefixes so far. Same origin+transit Br, Tolli > On 2.4.2014, at 18:57, "Joseph Jenkins" wrote: > > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 From kate at quadranet.com Wed Apr 2 18:59:39 2014 From: kate at quadranet.com (Kate Gerry) Date: Wed, 2 Apr 2014 11:59:39 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F60118F981BDC1@EXCH> I just got the same thing. ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 173.44.32.0/19: Prefix Description: AS8100 Update time: 2014-04-02 18:40 (UTC) Detected by #peers: 1 Detected prefix: 173.44.32.0/19 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 38794 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41639483 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41639483 ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 173.205.80.0/20: Prefix Description: AS8100 Update time: 2014-04-02 18:40 (UTC) Detected by #peers: 1 Detected prefix: 173.205.80.0/20 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 38794 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41639484 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41639484 -- Kate Gerry Network Manager kate at quadranet.com 1-888-5-QUADRA Ext 206?|?www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: ? -----Original Message----- From: Joseph Jenkins [mailto:joe at breathe-underwater.com] Sent: Wednesday, April 2, 2014 11:52 AM To: nanog at nanog.org Subject: BGPMON Alert Questions So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 From sethm at rollernet.us Wed Apr 2 19:02:47 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Apr 2014 12:02:47 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <533C5ED7.90100@rollernet.us> On 4/2/14, 11:51, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > Same here for one of my /21s. Origin of AS4761 through AS4651. ~Seth From dhubbard at dino.hostasaurus.com Wed Apr 2 19:02:30 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 2 Apr 2014 15:02:30 -0400 Subject: BGPMON Alert Questions References: Message-ID: If you contact bgpmon support you may be able to get some more in-depth information. I've contacted them before with alerts like those and they were able to give me specific date, time, ASN and interface information about the peering points that received the announcements; that might help make you present to the suspect party more likely to be acted upon. -----Original Message----- From: Joseph Jenkins [mailto:joe at breathe-underwater.com] Sent: Wednesday, April 02, 2014 2:52 PM To: nanog at nanog.org Subject: BGPMON Alert Questions So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 From vristevs at ramapo.edu Wed Apr 2 19:05:08 2014 From: vristevs at ramapo.edu (Vlade Ristevski) Date: Wed, 02 Apr 2014 15:05:08 -0400 Subject: BGPMON Alert Questions In-Reply-To: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> Message-ID: <533C5F64.8020401@ramapo.edu> I just got the same alert for one of my prefixes one minute ago. On 4/2/2014 2:59 PM, Frank Bulk wrote: > I received a similar notification about one of our prefixes also a few > minutes ago. I couldn't find a looking glass for AS4761 or AS4651. But I > also couldn't hit the websites for either AS, either. > > Frank > > -----Original Message----- > From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > Sent: Wednesday, April 02, 2014 1:52 PM > To: nanog at nanog.org > Subject: BGPMON Alert Questions > > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > > > -- Vlad From dhubbard at dino.hostasaurus.com Wed Apr 2 19:05:02 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 2 Apr 2014 15:05:02 -0400 Subject: BGPMON Alert Questions References: Message-ID: Lol, and two minutes after I replied to you, I got the same alert about the same AS with two of my prefixes. -----Original Message----- From: Joseph Jenkins [mailto:joe at breathe-underwater.com] Sent: Wednesday, April 02, 2014 2:52 PM To: nanog at nanog.org Subject: BGPMON Alert Questions So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 From steve.rossen at gmail.com Wed Apr 2 19:06:45 2014 From: steve.rossen at gmail.com (Steve Rossen) Date: Wed, 2 Apr 2014 14:06:45 -0500 Subject: BGPMON Alert Questions In-Reply-To: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> Message-ID: Same alert for me on two of my prefixes. Still looking into it. On Wed, Apr 2, 2014 at 1:59 PM, Frank Bulk wrote: > I received a similar notification about one of our prefixes also a few > minutes ago. I couldn't find a looking glass for AS4761 or AS4651. But I > also couldn't hit the websites for either AS, either. > > Frank > > -----Original Message----- > From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > Sent: Wednesday, April 02, 2014 1:52 PM > To: nanog at nanog.org > Subject: BGPMON Alert Questions > > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > > > > From alvarezp at alvarezp.ods.org Wed Apr 2 19:08:33 2014 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Wed, 02 Apr 2014 12:08:33 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <533C6031.90400@alvarezp.ods.org> On 02/04/14 11:51, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > Same here. I got an alert for two prefixes. Same origin AS, same AS path for one of them: 18356 9931 4651 4761, but a different one for the other: 18356 38794 4651 4761. From eric-list at truenet.com Wed Apr 2 19:10:43 2014 From: eric-list at truenet.com (eric-list at truenet.com) Date: Wed, 2 Apr 2014 15:10:43 -0400 Subject: BGPMON Alert Questions In-Reply-To: <5C0400DA-72BF-45D0-80D4-A2DA9BA1DBE0@advania.is> References: <5C0400DA-72BF-45D0-80D4-A2DA9BA1DBE0@advania.is> Message-ID: <016001cf4ea7$3ead3f40$bc07bdc0$@truenet.com> Sadly, it doesn't look like this is the first for Indosat either: January 14th, 2011 http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/ Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 F: 610-429-3222 -----Original Message----- From: ??rhallur H?lfd?narson [mailto:thorhallur.halfdanarson at advania.is] Sent: Wednesday, April 02, 2014 2:59 PM To: Joseph Jenkins Cc: nanog at nanog.org Subject: Re: BGPMON Alert Questions I have received those for two prefixes so far. Same origin+transit Br, Tolli From sf at lists.esoteric.ca Wed Apr 2 19:10:41 2014 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Wed, 02 Apr 2014 15:10:41 -0400 Subject: Prefix hijack by AS4761 (was Re: BGPMON Alert Questions) In-Reply-To: References: Message-ID: <533C60B1.6080702@lists.esoteric.ca> I'm seeing the same hijack of prefixes by multiple networks under my watch, at 18:40 UTC and 19:06 UTC. -- Stephen On 2014-04-02 2:51 PM, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From wilhelm at ripe.net Wed Apr 2 19:12:40 2014 From: wilhelm at ripe.net (Rene Wilhelm) Date: Wed, 02 Apr 2014 21:12:40 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <533C6128.3000802@ripe.net> On 4/2/14, 8:51 PM, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? You can check RIPEstat's BGP looking-glass: https://stat.ripe.net/widget/looking-glass#w.resource=8.37.93.0%2F24 This combines the result of 13 RIPE RIS route collectors. A minute ago I saw the INDOSAT announcement at 2 locations (Amsterdam, Frankfurt) from 3 out of 101 peers, but it seems to have stopped just now. -- Rene > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From eric at roxanne.org Wed Apr 2 19:03:52 2014 From: eric at roxanne.org (Eric) Date: Wed, 2 Apr 2014 15:03:52 -0400 Subject: Cogent - ATT issue? Message-ID: Anyone know if there is a connectivity issue between Cogent and ATT in the northeast? We're seeing random timeouts to some systems we have in an ATT data center but only from sources on Cogent's network. Thanks... - Eric :) From chris.burton at speakeasy.net Wed Apr 2 19:17:27 2014 From: chris.burton at speakeasy.net (Chris Burton) Date: Wed, 2 Apr 2014 12:17:27 -0700 Subject: BGPMON Alert Questions In-Reply-To: <533C5ED7.90100@rollernet.us> References: <533C5ED7.90100@rollernet.us> Message-ID: <002701cf4ea8$3101d670$93058350$@speakeasy.net> This seems to be occurring to many, I have two of my prefixes being announced by the same AS's, and I have confirmation from several others who are seeing this as well. Chris -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Wednesday, April 02, 2014 12:03 PM To: nanog at nanog.org Subject: Re: BGPMON Alert Questions On 4/2/14, 11:51, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. > Any other recommendations? > Same here for one of my /21s. Origin of AS4761 through AS4651. ~Seth From frnkblk at iname.com Wed Apr 2 19:18:34 2014 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Apr 2014 14:18:34 -0500 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <000c01cf4ea8$57623580$0626a080$@iname.com> bgpmon has tweeted that "We're currently observing a large hijack event. Indosat AS4761 originating many prefixes not assigned to them." Let's hope that AS4651 can quickly apply filters. Frank -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Wednesday, April 02, 2014 2:03 PM To: Joseph Jenkins; nanog at nanog.org Subject: RE: BGPMON Alert Questions If you contact bgpmon support you may be able to get some more in-depth information. I've contacted them before with alerts like those and they were able to give me specific date, time, ASN and interface information about the peering points that received the announcements; that might help make you present to the suspect party more likely to be acted upon. -----Original Message----- From: Joseph Jenkins [mailto:joe at breathe-underwater.com] Sent: Wednesday, April 02, 2014 2:52 PM To: nanog at nanog.org Subject: BGPMON Alert Questions So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? Is there a way I can verify what they are announcing just to make sure they are still doing it? Here is the alert for reference: Your prefix: 8.37.93.0/24: Update time: 2014-04-02 18:26 (UTC) Detected by #peers: 2 Detected prefix: 8.37.93.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 From olivier.benghozi at wifirst.fr Wed Apr 2 19:18:32 2014 From: olivier.benghozi at wifirst.fr (Olivier Benghozi) Date: Wed, 2 Apr 2014 21:18:32 +0200 Subject: BGPMON Alert Questions In-Reply-To: <533C5ED7.90100@rollernet.us> References: <533C5ED7.90100@rollernet.us> Message-ID: <6AA47326-45F0-4816-AFCC-EF2151EF54B5@wifirst.fr> ... and same here. Indosat looks now to have developed a solid experience in BGP prefix hijack mess (last time was in 2011). Olivier > On 4/2/14, 11:51, Joseph Jenkins wrote: >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> > > > Same here for one of my /21s. Origin of AS4761 through AS4651. > > ~Seth > From andree+nanog at toonk.nl Wed Apr 2 19:21:21 2014 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 02 Apr 2014 12:21:21 -0700 Subject: BGPMON Alert Questions In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F60118F981BDC1@EXCH> References: <4B4120B1642DCF48ACA84E4F82C8E1F60118F981BDC1@EXCH> Message-ID: <533C6331.5080807@toonk.nl> I can confirm that indosat appears to be hijacking many prefixes. HE 6939 is one of the networks picking it up and distributing it further. Here's an example for a Syrian prefix: http://portal.bgpmon.net/data/indosat-hijack.png ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 5.0.0.0/18: Prefix Description: STE Public Data Network Backbone and LIR Update time: 2014-04-02 18:47 (UTC) Detected by #peers: 13 Detected prefix: 5.0.0.0/18 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS6939 (HURRICANE - Hurricane Electric, Inc.,US) ASpath: 271 6939 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41644877 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41644877 Andree (BGPMON.net) .-- My secret spy satellite informs me that at 2014-04-02 11:59 AM Kate Gerry wrote: > I just got the same thing. > > ==================================================================== > Possible Prefix Hijack (Code: 10) > ==================================================================== > Your prefix: 173.44.32.0/19: > Prefix Description: AS8100 > Update time: 2014-04-02 18:40 (UTC) > Detected by #peers: 1 > Detected prefix: 173.44.32.0/19 > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) > ASpath: 18356 38794 4651 4761 > Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41639483 > Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41639483 > > ==================================================================== > Possible Prefix Hijack (Code: 10) > ==================================================================== > Your prefix: 173.205.80.0/20: > Prefix Description: AS8100 > Update time: 2014-04-02 18:40 (UTC) > Detected by #peers: 1 > Detected prefix: 173.205.80.0/20 > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) > ASpath: 18356 38794 4651 4761 > Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41639484 > Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41639484 > > -- > Kate Gerry > Network Manager > kate at quadranet.com > > 1-888-5-QUADRA Ext 206 | www.QuadraNet.com > Dedicated Servers, Colocation, Cloud Services and more. > Datacenters in Los Angeles, Dallas and Miami. > > Follow us on: > > -----Original Message----- > From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > Sent: Wednesday, April 2, 2014 11:52 AM > To: nanog at nanog.org > Subject: BGPMON Alert Questions > > So I setup BGPMON for my prefixes and got an alert about someone in Thailand announcing my prefix. Everything looks fine to me and I've checked a bunch of different Looking Glasses and everything announcing correctly. > > I am assuming I should be contacting the provider about their misconfiguration and announcing my prefixes and get them to fix it. Any other recommendations? > > Is there a way I can verify what they are announcing just to make sure they are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From lee at wildcard.net.uk Wed Apr 2 19:27:54 2014 From: lee at wildcard.net.uk (Lee Johnston) Date: Wed, 2 Apr 2014 19:27:54 +0000 Subject: BGPMON Alert Questions In-Reply-To: <533C5F64.8020401@ramapo.edu> References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: <566E00374727EE428E61E2AF4529BF520A6AD372@INT-SERVER.WildcardNet.local> Snap, announcing a few of our /21s and a /23. Seems they did something similar a few year ago: http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/ I can't make any contact with Indosat (website non responsive / email queuing). This is what I have back from Aware Corp. AS18356 (first AS in the path): I can confirm that we are seeing your prefixes as advertised by AS4761, via one of our upstreams CAT AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) We (Aware Corporation - AS18356) operate a BGPMon PeerMon node which is probably why you are seeing this alert from our AS. It is likely that your highjacked prefixes are being advertised to all of CAT's customers. I suggest contacting AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) directly for resolution as there is little we can do as a stub AS. Regards, Lee. -----Original Message----- From: Vlade Ristevski [mailto:vristevs at ramapo.edu] Sent: 02 April 2014 20:05 To: nanog at nanog.org Subject: Re: BGPMON Alert Questions I just got the same alert for one of my prefixes one minute ago. On 4/2/2014 2:59 PM, Frank Bulk wrote: > I received a similar notification about one of our prefixes also a few > minutes ago. I couldn't find a looking glass for AS4761 or AS4651. > But I also couldn't hit the websites for either AS, either. > > Frank > > -----Original Message----- > From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > Sent: Wednesday, April 02, 2014 1:52 PM > To: nanog at nanog.org > Subject: BGPMON Alert Questions > > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. > Any other recommendations? > > Is there a way I can verify what they are announcing just to make sure > they are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > > > -- Vlad From joelja at bogus.com Wed Apr 2 19:41:14 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 02 Apr 2014 12:41:14 -0700 Subject: Prefix hijack by AS4761 (was Re: BGPMON Alert Questions) In-Reply-To: <533C60B1.6080702@lists.esoteric.ca> References: <533C60B1.6080702@lists.esoteric.ca> Message-ID: <533C67DA.50908@bogus.com> yeah you're seeing the impact of a pretty broad prefix injection indosat's upstream filters seem to be working for the most part. On 4/2/14, 12:10 PM, Stephen Fulton wrote: > I'm seeing the same hijack of prefixes by multiple networks under my > watch, at 18:40 UTC and 19:06 UTC. > > -- Stephen > > > On 2014-04-02 2:51 PM, Joseph Jenkins wrote: >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> >> Is there a way I can verify what they are announcing just to make sure >> they >> are still doing it? >> >> Here is the alert for reference: >> >> Your prefix: 8.37.93.0/24: >> >> Update time: 2014-04-02 18:26 (UTC) >> >> Detected by #peers: 2 >> >> Detected prefix: 8.37.93.0/24 >> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >> Provider,ID) >> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications >> Authority of >> Thailand(CAT),TH) >> >> ASpath: 18356 9931 4651 4761 >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From contact at nullivex.com Wed Apr 2 19:44:48 2014 From: contact at nullivex.com (Bryan Tong) Date: Wed, 2 Apr 2014 13:44:48 -0600 Subject: BGPMON Alert Questions In-Reply-To: <533C6128.3000802@ripe.net> References: <533C6128.3000802@ripe.net> Message-ID: Just got the same for 5 of my prefixes. ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 192.225.232.0/21: Prefix Description: ARIN direct allocation Update time: 2014-04-02 19:26 (UTC) Detected by #peers: 1 Detected prefix: 192.225.232.0/21 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41651791 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41651791 ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 199.87.232.0/21: Prefix Description: Direct ARIN allocation Update time: 2014-04-02 19:26 (UTC) Detected by #peers: 1 Detected prefix: 199.87.232.0/21 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41651792 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41651792 ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 162.245.228.0/24: Update time: 2014-04-02 19:26 (UTC) Detected by #peers: 1 Detected prefix: 162.245.228.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41651793 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41651793 ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 198.44.191.0/24: Prefix Description: ARIN direct allocation Update time: 2014-04-02 19:26 (UTC) Detected by #peers: 1 Detected prefix: 198.44.191.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41651794 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41651794 ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 23.249.176.0/20: Prefix Description: ARIN direct allocation Update time: 2014-04-02 19:26 (UTC) Detected by #peers: 1 Detected prefix: 23.249.176.0/20 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41651795 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41651795 On Wed, Apr 2, 2014 at 1:12 PM, Rene Wilhelm wrote: > > On 4/2/14, 8:51 PM, Joseph Jenkins wrote: > >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> >> Is there a way I can verify what they are announcing just to make sure >> they >> are still doing it? >> > You can check RIPEstat's BGP looking-glass: > > https://stat.ripe.net/widget/looking-glass#w.resource=8.37.93.0%2F24 > > This combines the result of 13 RIPE RIS route collectors. > > A minute ago I saw the INDOSAT announcement at 2 locations (Amsterdam, > Frankfurt) from 3 out of 101 peers, but it seems to have stopped just now. > > -- Rene > > > > >> Here is the alert for reference: >> >> Your prefix: 8.37.93.0/24: >> >> Update time: 2014-04-02 18:26 (UTC) >> >> Detected by #peers: 2 >> >> Detected prefix: 8.37.93.0/24 >> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >> Provider,ID) >> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of >> Thailand(CAT),TH) >> >> ASpath: 18356 9931 4651 4761 >> >> > > -- eSited LLC (701) 390-9638 From contact at nullivex.com Wed Apr 2 19:51:00 2014 From: contact at nullivex.com (Bryan Tong) Date: Wed, 2 Apr 2014 13:51:00 -0600 Subject: BGPMON Alert Questions In-Reply-To: <000c01cf4ea8$57623580$0626a080$@iname.com> References: <000c01cf4ea8$57623580$0626a080$@iname.com> Message-ID: Another 5 of ours just got hit. Anyone have any ideas on what will be done about it? On Wed, Apr 2, 2014 at 1:18 PM, Frank Bulk wrote: > bgpmon has tweeted that "We're currently observing a large hijack event. > Indosat AS4761 originating many prefixes not assigned to them." > > Let's hope that AS4651 can quickly apply filters. > > Frank > > -----Original Message----- > From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] > Sent: Wednesday, April 02, 2014 2:03 PM > To: Joseph Jenkins; nanog at nanog.org > Subject: RE: BGPMON Alert Questions > > If you contact bgpmon support you may be able to get some more in-depth > information. I've contacted them before with alerts like those and they > were able to give me specific date, time, ASN and interface information > about the peering points that received the announcements; that might > help make you present to the suspect party more likely to be acted upon. > > -----Original Message----- > From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > Sent: Wednesday, April 02, 2014 2:52 PM > To: nanog at nanog.org > Subject: BGPMON Alert Questions > > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure > they are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > > > > > > > -- eSited LLC (701) 390-9638 From rsnyder at toontown.erial.nj.us Wed Apr 2 20:11:54 2014 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Wed, 2 Apr 2014 16:11:54 -0400 Subject: Prefix hijack by AS4761 (was Re: BGPMON Alert Questions) In-Reply-To: <533C67DA.50908@bogus.com> References: <533C60B1.6080702@lists.esoteric.ca> <533C67DA.50908@bogus.com> Message-ID: On Wed, Apr 2, 2014 at 3:41 PM, joel jaeggli wrote: > yeah you're seeing the impact of a pretty broad prefix injection > > indosat's upstream filters seem to be working for the most part. Based on the image they tweeted, I don't think they are doing much filtering; the Syrian prefix was spread to a number of countries and AS. If you have good US connectivity the impact seems limited due to better AS Paths winning, but for less well connected prefixes I'm assuming it's more up in the air. Bob From bob at FiberInternetCenter.com Wed Apr 2 20:16:33 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 2 Apr 2014 13:16:33 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <94081c39f9a5d313228bb194643fe287.squirrel@66.201.44.180> Yes, I too have alerts for some of our prefixes from the same offending origin 4761 On Wednesday April 2nd 2014 at 19:59 UTC we detected a Origin AS Change event for your prefix (66.201.48.0/20 slash 20 bottom of nor cal) The detected prefix: 66.201.48.0/20, was announced by AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Alert description: Origin AS Change Detected Prefix: 66.201.48.0/20 Detected Origin AS: 4761 Expected Origin AS: 26803 Bob Evans CTO > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure > they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From jamesl at mythostech.com Wed Apr 2 20:16:35 2014 From: jamesl at mythostech.com (James Laszko) Date: Wed, 2 Apr 2014 20:16:35 +0000 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com>, Message-ID: <6F52F909-BDBE-4990-B63B-0945917DBD69@mythostech.com> I have someone from cat.net.th on the phone and he doesn't speak a lot of English and I don't speak any Thai..... He knew what indosat was and their AS number. He further stated he got my email (never told him who I was), but he said he would be replying ASAP. We only had one /24 announced by indosat. James Laszko Mythos Technology Inc Sent from my iPad > On Apr 2, 2014, at 1:08 PM, "Bryan Tong" wrote: > > Another 5 of ours just got hit. > > Anyone have any ideas on what will be done about it? > > >> On Wed, Apr 2, 2014 at 1:18 PM, Frank Bulk wrote: >> >> bgpmon has tweeted that "We're currently observing a large hijack event. >> Indosat AS4761 originating many prefixes not assigned to them." >> >> Let's hope that AS4651 can quickly apply filters. >> >> Frank >> >> -----Original Message----- >> From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] >> Sent: Wednesday, April 02, 2014 2:03 PM >> To: Joseph Jenkins; nanog at nanog.org >> Subject: RE: BGPMON Alert Questions >> >> If you contact bgpmon support you may be able to get some more in-depth >> information. I've contacted them before with alerts like those and they >> were able to give me specific date, time, ASN and interface information >> about the peering points that received the announcements; that might >> help make you present to the suspect party more likely to be acted upon. >> >> -----Original Message----- >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] >> Sent: Wednesday, April 02, 2014 2:52 PM >> To: nanog at nanog.org >> Subject: BGPMON Alert Questions >> >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> >> Is there a way I can verify what they are announcing just to make sure >> they are still doing it? >> >> Here is the alert for reference: >> >> Your prefix: 8.37.93.0/24: >> >> Update time: 2014-04-02 18:26 (UTC) >> >> Detected by #peers: 2 >> >> Detected prefix: 8.37.93.0/24 >> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >> Provider,ID) >> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >> of >> Thailand(CAT),TH) >> >> ASpath: 18356 9931 4651 4761 > > > -- > eSited LLC > (701) 390-9638 From jamesl at mythostech.com Wed Apr 2 20:17:23 2014 From: jamesl at mythostech.com (James Laszko) Date: Wed, 2 Apr 2014 20:17:23 +0000 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com>, Message-ID: <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> I called into +66 2104-2374 James Laszko Mythos Technology Inc Sent from my iPad > On Apr 2, 2014, at 1:08 PM, "Bryan Tong" wrote: > > Another 5 of ours just got hit. > > Anyone have any ideas on what will be done about it? > > >> On Wed, Apr 2, 2014 at 1:18 PM, Frank Bulk wrote: >> >> bgpmon has tweeted that "We're currently observing a large hijack event. >> Indosat AS4761 originating many prefixes not assigned to them." >> >> Let's hope that AS4651 can quickly apply filters. >> >> Frank >> >> -----Original Message----- >> From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] >> Sent: Wednesday, April 02, 2014 2:03 PM >> To: Joseph Jenkins; nanog at nanog.org >> Subject: RE: BGPMON Alert Questions >> >> If you contact bgpmon support you may be able to get some more in-depth >> information. I've contacted them before with alerts like those and they >> were able to give me specific date, time, ASN and interface information >> about the peering points that received the announcements; that might >> help make you present to the suspect party more likely to be acted upon. >> >> -----Original Message----- >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] >> Sent: Wednesday, April 02, 2014 2:52 PM >> To: nanog at nanog.org >> Subject: BGPMON Alert Questions >> >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> >> Is there a way I can verify what they are announcing just to make sure >> they are still doing it? >> >> Here is the alert for reference: >> >> Your prefix: 8.37.93.0/24: >> >> Update time: 2014-04-02 18:26 (UTC) >> >> Detected by #peers: 2 >> >> Detected prefix: 8.37.93.0/24 >> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >> Provider,ID) >> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >> of >> Thailand(CAT),TH) >> >> ASpath: 18356 9931 4651 4761 > > > -- > eSited LLC > (701) 390-9638 From andrew.a at aware.co.th Wed Apr 2 19:33:33 2014 From: andrew.a at aware.co.th (Andrew (Andy) Ashley) Date: Wed, 2 Apr 2014 19:33:33 +0000 Subject: BGPMON Alert Questions In-Reply-To: <533C5F64.8020401@ramapo.edu> References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: Hi All, I am a network admin for Aware Corporation AS18356 (Thailand), as mentioned in the alert. We operate a BGPMon PeerMon node on our network, which peers with the BGPMon service as a collector. It is likely that AS4761 (INDOSAT) has somehow managed to hijack these prefixes and CAT (Communications Authority of Thailand AS4651) is not filtering them, hence they are announced to us and are triggering these BGPMon alerts. I have had several mails to our NOC about this already and have responded directly to those. I suggest contacting Indosat directly to get this resolved. AS18356 is a stub AS, so we are not actually advertising these learned hijacked prefixes to anyone but BGPMon for data collection purposes. Thanks. Regards, Andrew Ashley Office: +27 21 673 6841 E-mail: andrew.a at aware.co.th Web: www.aware.co.th On 2014/04/02, 21:05, "Vlade Ristevski" wrote: >I just got the same alert for one of my prefixes one minute ago. > >On 4/2/2014 2:59 PM, Frank Bulk wrote: >> I received a similar notification about one of our prefixes also a few >> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. >>But I >> also couldn't hit the websites for either AS, either. >> >> Frank >> >> -----Original Message----- >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] >> Sent: Wednesday, April 02, 2014 1:52 PM >> To: nanog at nanog.org >> Subject: BGPMON Alert Questions >> >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> >> Is there a way I can verify what they are announcing just to make sure >>they >> are still doing it? >> >> Here is the alert for reference: >> >> Your prefix: 8.37.93.0/24: >> >> Update time: 2014-04-02 18:26 (UTC) >> >> Detected by #peers: 2 >> >> Detected prefix: 8.37.93.0/24 >> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >> Provider,ID) >> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >>of >> Thailand(CAT),TH) >> >> ASpath: 18356 9931 4651 4761 >> >> >> > >-- >Vlad > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5770 bytes Desc: not available URL: From felix at mrfriday.com Wed Apr 2 19:21:45 2014 From: felix at mrfriday.com (Felix Aronsson) Date: Wed, 2 Apr 2014 21:21:45 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: Seeing the same here for a /21. This seems to have happened before with AS4761? See http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/from january 2011. On Wed, Apr 2, 2014 at 8:51 PM, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From jrex at CS.Princeton.EDU Wed Apr 2 19:30:11 2014 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Wed, 2 Apr 2014 15:30:11 -0400 Subject: real-world data about fragmentation In-Reply-To: <20140402185053.GB23819@vacation.karoshi.com> References: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> <20140402185053.GB23819@vacation.karoshi.com> Message-ID: <404AF763-8F57-480A-9AFC-8A45F4930C61@cs.princeton.edu> This isn't a direct answer to the question, but I find this paper pretty useful (even though it is dated now): Beyond Folklore: Observations on Fragmented Traffic by Colleen Shannon, David Moore, and k claffy IEEE/ACM Transactions on Networking, December 2002 http://www.caida.org/publications/papers/2002/Frag/frag.pdf (Bill, I'd be curious to see your AINTEC slides, too.) -- Jen On Apr 2, 2014, at 2:50 PM, bmanning at vacation.karoshi.com wrote: > > I can send you a copy of an invited presentation at AINTEC from 2009. > > /bill > > > On Wed, Apr 02, 2014 at 02:14:22PM -0400, Joe Abley wrote: >> Hi all, >> >> It's common wisdom that a datagram that needs to be fragmented between endpoints (because it is bigger than the path MTU) will demonstrate less reliable delivery and reassembly than a datagram that doesn't need to be fragmented, because math, firewall, other, take your pick. >> >> Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? >> >> For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. >> >> What does the curve look like between 576 bytes and 10,000 bytes? >> >> I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. >> >> Anybody have any pointers? IPv4 and IPv6 are both interesting. >> >> >> Joe > From danielzhang0212 at gmail.com Wed Apr 2 19:40:48 2014 From: danielzhang0212 at gmail.com (Mingwei Zhang) Date: Wed, 2 Apr 2014 12:40:48 -0700 Subject: BGPMON Alert Questions In-Reply-To: <533C6031.90400@alvarezp.ods.org> References: <533C6031.90400@alvarezp.ods.org> Message-ID: route-views4 /64.25.208.71 has seen updates that contains large amount of prefixes at time 1396464452 (04 / 02 / 14 @ 6:47:32pm UTC) with path [20225, 6939, 4761] full prefixes list: http://pastebin.com/Eu4ePgp4 is it normal for single update to contain such large amount NLRI info? On Wed, Apr 2, 2014 at 12:08 PM, Octavio Alvarez wrote: > On 02/04/14 11:51, Joseph Jenkins wrote: > > So I setup BGPMON for my prefixes and got an alert about someone in > > Thailand announcing my prefix. Everything looks fine to me and I've > > checked a bunch of different Looking Glasses and everything announcing > > correctly. > > > > I am assuming I should be contacting the provider about their > > misconfiguration and announcing my prefixes and get them to fix it. Any > > other recommendations? > > > > Is there a way I can verify what they are announcing just to make sure > they > > are still doing it? > > > > Here is the alert for reference: > > > > Your prefix: 8.37.93.0/24: > > > > Update time: 2014-04-02 18:26 (UTC) > > > > Detected by #peers: 2 > > > > Detected prefix: 8.37.93.0/24 > > > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > > Provider,ID) > > > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > of > > Thailand(CAT),TH) > > > > ASpath: 18356 9931 4651 4761 > > > > Same here. I got an alert for two prefixes. Same origin AS, same AS path > for one of them: 18356 9931 4651 4761, but a different one for the > other: 18356 38794 4651 4761. > > > From contact at nullivex.com Wed Apr 2 20:21:29 2014 From: contact at nullivex.com (Bryan Tong) Date: Wed, 2 Apr 2014 14:21:29 -0600 Subject: BGPMON Alert Questions In-Reply-To: <94081c39f9a5d313228bb194643fe287.squirrel@66.201.44.180> References: <94081c39f9a5d313228bb194643fe287.squirrel@66.201.44.180> Message-ID: They have advertised all of ours now. On Wed, Apr 2, 2014 at 2:16 PM, Bob Evans wrote: > Yes, I too have alerts for some of our prefixes from the same offending > origin 4761 > > On Wednesday April 2nd 2014 at 19:59 UTC we detected a Origin AS Change > event for your prefix (66.201.48.0/20 slash 20 bottom of nor cal) > The detected prefix: 66.201.48.0/20, was announced by AS4761 > (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) > Alert description: Origin AS Change > Detected Prefix: 66.201.48.0/20 > Detected Origin AS: 4761 > Expected Origin AS: 26803 > > Bob Evans > CTO > > > > > > So I setup BGPMON for my prefixes and got an alert about someone in > > Thailand announcing my prefix. Everything looks fine to me and I've > > checked a bunch of different Looking Glasses and everything announcing > > correctly. > > > > I am assuming I should be contacting the provider about their > > misconfiguration and announcing my prefixes and get them to fix it. Any > > other recommendations? > > > > Is there a way I can verify what they are announcing just to make sure > > they > > are still doing it? > > > > Here is the alert for reference: > > > > Your prefix: 8.37.93.0/24: > > > > Update time: 2014-04-02 18:26 (UTC) > > > > Detected by #peers: 2 > > > > Detected prefix: 8.37.93.0/24 > > > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > > Provider,ID) > > > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > of > > Thailand(CAT),TH) > > > > ASpath: 18356 9931 4651 4761 > > > > > > -- eSited LLC (701) 390-9638 From ikiris at gmail.com Wed Apr 2 20:24:44 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 2 Apr 2014 15:24:44 -0500 Subject: BGPMON Alert Questions In-Reply-To: <6F52F909-BDBE-4990-B63B-0945917DBD69@mythostech.com> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <6F52F909-BDBE-4990-B63B-0945917DBD69@mythostech.com> Message-ID: Saw this as well on my blocks. Is this malicious or did someone redistribute all of bgp with bad upstream filtering? On Wed, Apr 2, 2014 at 3:16 PM, James Laszko wrote: > I have someone from cat.net.th on the phone and he doesn't speak a lot of > English and I don't speak any Thai..... He knew what indosat was and their > AS number. He further stated he got my email (never told him who I was), > but he said he would be replying ASAP. We only had one /24 announced by > indosat. > > > James Laszko > Mythos Technology Inc > > > Sent from my iPad > > > On Apr 2, 2014, at 1:08 PM, "Bryan Tong" wrote: > > > > Another 5 of ours just got hit. > > > > Anyone have any ideas on what will be done about it? > > > > > >> On Wed, Apr 2, 2014 at 1:18 PM, Frank Bulk wrote: > >> > >> bgpmon has tweeted that "We're currently observing a large hijack event. > >> Indosat AS4761 originating many prefixes not assigned to them." > >> > >> Let's hope that AS4651 can quickly apply filters. > >> > >> Frank > >> > >> -----Original Message----- > >> From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] > >> Sent: Wednesday, April 02, 2014 2:03 PM > >> To: Joseph Jenkins; nanog at nanog.org > >> Subject: RE: BGPMON Alert Questions > >> > >> If you contact bgpmon support you may be able to get some more in-depth > >> information. I've contacted them before with alerts like those and they > >> were able to give me specific date, time, ASN and interface information > >> about the peering points that received the announcements; that might > >> help make you present to the suspect party more likely to be acted upon. > >> > >> -----Original Message----- > >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > >> Sent: Wednesday, April 02, 2014 2:52 PM > >> To: nanog at nanog.org > >> Subject: BGPMON Alert Questions > >> > >> So I setup BGPMON for my prefixes and got an alert about someone in > >> Thailand announcing my prefix. Everything looks fine to me and I've > >> checked a bunch of different Looking Glasses and everything announcing > >> correctly. > >> > >> I am assuming I should be contacting the provider about their > >> misconfiguration and announcing my prefixes and get them to fix it. Any > >> other recommendations? > >> > >> Is there a way I can verify what they are announcing just to make sure > >> they are still doing it? > >> > >> Here is the alert for reference: > >> > >> Your prefix: 8.37.93.0/24: > >> > >> Update time: 2014-04-02 18:26 (UTC) > >> > >> Detected by #peers: 2 > >> > >> Detected prefix: 8.37.93.0/24 > >> > >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > >> Provider,ID) > >> > >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > >> of > >> Thailand(CAT),TH) > >> > >> ASpath: 18356 9931 4651 4761 > > > > > > -- > > eSited LLC > > (701) 390-9638 > > From marka at isc.org Wed Apr 2 20:28:58 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 03 Apr 2014 07:28:58 +1100 Subject: new DNS forwarder vulnerability In-Reply-To: Your message of "Wed, 02 Apr 2014 08:54:47 -0400." References: <20140402123809.1C6253C5B8FB@lawyers.icir.org> Message-ID: <20140402202858.60AA712336CA@rock.dv.isc.org> In message , Jared Mauch writes: > > On Apr 2, 2014, at 8:38 AM, Mark Allman wrote: > > > > > [catching up] > > > >> That's a good question, but I know that during the ongoing survey > >> within the Open Resolver Project [http://openresolverproject.org/], > >> Jared found thousands of CPE devices which responded as resolvers. > > > > Not thousands, *tens of millions*. > > > > Our estimate from mid-2013 was 32M such devices (detailed in an IMC > > paper last year; http://www.icir.org/mallman/pubs/SCRA13/). And, that > > roughly agrees with both the openresolverproject.org numbers and another > > (not public) study I know of. And, as if that isn't bad enough > > ... there is a 2010 IMC paper that puts the number at 15M. I.e., the > > instances of brokenness are getting worse---doubling in 3 years! UGH. > > One observation: The OpenResolverProject collects responses that come from > ports that the query was not sent to (ie: device responds from UDP/12345 > not > from UDP/53, which obviously is broken and doesn't "work", but they > actually > return DNS payload which can be used for abuse). > > Some good news though: > > http://openresolverproject.org/breakdown-graph1.cgi I see axes, legend but no data points. If I hover over various spots on the graph I see data values pop up. > Since the start of 2014 there seem to be new CPE devices out there that > are resolving this issue. The linear nature of the line in the decrease > doesn't seem to be something like "ISPs" started blocking udp/53 to > customers, which would appear more like a step function. > > I'm aware of some other studies ongoing to fingerprint CPE and their > behaviors/aggregated resolver dependencies. I expect to see some of that > data presented at the upcoming DNS-OARC meeting in Warsaw. > > Getting everyone to update their firmware on devices would go a long way > as well. Some vendors have no software QA on this front so add/remove > the response on the WAN interface as their releases march forward. > > - Jared -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bob at FiberInternetCenter.com Wed Apr 2 20:31:12 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 2 Apr 2014 13:31:12 -0700 Subject: BGPMON Alert Questions In-Reply-To: <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> References: <000c01cf4ea8$57623580$0626a080$@iname.com>, <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> Message-ID: <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> where did you get that number ? aut-num: AS4761 as-name: INDOSAT-INP-AP descr: INDOSAT Internet Network Provider descr: Internet Network Access Point in INDONESIA country: ID admin-c: IH151-AP tech-c: DA205-AP mnt-by: MAINT-ID-INDOSAT-INP changed: hostmaster at indosat.com 20081006 source: APNIC person: Dewi Amalia nic-hdl: DA205-AP e-mail: dewi.amalia at indosat.com address: PT INDOSAT address: JL. Medan Merdeka Barat 21 address: Jakarta Pusat phone: +62-21-30444066 fax-no: +62-21-30001073 country: ID changed: dewi.amalia at indosat.com 20080117 mnt-by: MAINT-ID-INDOSAT-INP source: APNIC person: INDOSAT INP Hostmaster nic-hdl: IH151-AP e-mail: hostmaster at indosat.com address: PT Indosat address: Jl. Medan Merdeka Barat 21 address: Jakarta Pusat phone: +62-21-30444066 fax-no: +62-21-30001073 country: ID changed: hostmaster at indosat.com 20120104 mnt-by: MAINT-ID-INDOSAT-INP source: APNIC Bob Evans CTO > I called into +66 2104-2374 > > > James Laszko > Mythos Technology Inc > > > Sent from my iPad > >> On Apr 2, 2014, at 1:08 PM, "Bryan Tong" wrote: >> >> Another 5 of ours just got hit. >> >> Anyone have any ideas on what will be done about it? >> >> >>> On Wed, Apr 2, 2014 at 1:18 PM, Frank Bulk wrote: >>> >>> bgpmon has tweeted that "We're currently observing a large hijack >>> event. >>> Indosat AS4761 originating many prefixes not assigned to them." >>> >>> Let's hope that AS4651 can quickly apply filters. >>> >>> Frank >>> >>> -----Original Message----- >>> From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] >>> Sent: Wednesday, April 02, 2014 2:03 PM >>> To: Joseph Jenkins; nanog at nanog.org >>> Subject: RE: BGPMON Alert Questions >>> >>> If you contact bgpmon support you may be able to get some more in-depth >>> information. I've contacted them before with alerts like those and >>> they >>> were able to give me specific date, time, ASN and interface information >>> about the peering points that received the announcements; that might >>> help make you present to the suspect party more likely to be acted >>> upon. >>> >>> -----Original Message----- >>> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] >>> Sent: Wednesday, April 02, 2014 2:52 PM >>> To: nanog at nanog.org >>> Subject: BGPMON Alert Questions >>> >>> So I setup BGPMON for my prefixes and got an alert about someone in >>> Thailand announcing my prefix. Everything looks fine to me and I've >>> checked a bunch of different Looking Glasses and everything announcing >>> correctly. >>> >>> I am assuming I should be contacting the provider about their >>> misconfiguration and announcing my prefixes and get them to fix it. >>> Any >>> other recommendations? >>> >>> Is there a way I can verify what they are announcing just to make sure >>> they are still doing it? >>> >>> Here is the alert for reference: >>> >>> Your prefix: 8.37.93.0/24: >>> >>> Update time: 2014-04-02 18:26 (UTC) >>> >>> Detected by #peers: 2 >>> >>> Detected prefix: 8.37.93.0/24 >>> >>> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >>> Provider,ID) >>> >>> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >>> of >>> Thailand(CAT),TH) >>> >>> ASpath: 18356 9931 4651 4761 >> >> >> -- >> eSited LLC >> (701) 390-9638 > > From mwalter at 3z.net Wed Apr 2 20:33:39 2014 From: mwalter at 3z.net (Mike Walter) Date: Wed, 2 Apr 2014 20:33:39 +0000 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: Three of ours just got jacked. I have tried to contact via email for update / fix of their end. -Mike -----Original Message----- From: Felix Aronsson [mailto:felix at mrfriday.com] Sent: Wednesday, April 02, 2014 3:22 PM To: Joseph Jenkins Cc: nanog at nanog.org Subject: Re: BGPMON Alert Questions Seeing the same here for a /21. This seems to have happened before with AS4761? See http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/from january 2011. On Wed, Apr 2, 2014 at 8:51 PM, Joseph Jenkins wrote: > So I setup BGPMON for my prefixes and got an alert about someone in > Thailand announcing my prefix. Everything looks fine to me and I've > checked a bunch of different Looking Glasses and everything announcing > correctly. > > I am assuming I should be contacting the provider about their > misconfiguration and announcing my prefixes and get them to fix it. Any > other recommendations? > > Is there a way I can verify what they are announcing just to make sure they > are still doing it? > > Here is the alert for reference: > > Your prefix: 8.37.93.0/24: > > Update time: 2014-04-02 18:26 (UTC) > > Detected by #peers: 2 > > Detected prefix: 8.37.93.0/24 > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > > ASpath: 18356 9931 4651 4761 > From zachary.mcgibbon+nanog at gmail.com Wed Apr 2 20:34:50 2014 From: zachary.mcgibbon+nanog at gmail.com (Zachary McGibbon) Date: Wed, 2 Apr 2014 16:34:50 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: Same here: ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 132.206.0.0/16: Prefix Description: MCGILL-NET-132-206 Update time: 2014-04-02 20:11 (UTC) Detected by #peers: 1 Detected prefix: 132.206.0.0/16 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 38794 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41664976 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41664976 ==================================================================== Possible Prefix Hijack (Code: 10) ==================================================================== Your prefix: 142.157.128.0/18: Prefix Description: McGill Update time: 2014-04-02 20:11 (UTC) Detected by #peers: 1 Detected prefix: 142.157.128.0/18 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 Alert details: https://portal.bgpmon.net/alerts.php?details&alert_id=41664977 Mark as false alert: https://portal.bgpmon.net/fp.php?aid=41664977 On Wed, Apr 2, 2014 at 3:21 PM, Felix Aronsson wrote: > Seeing the same here for a /21. This seems to have happened before with > AS4761? See > http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/from > january 2011. > > > On Wed, Apr 2, 2014 at 8:51 PM, Joseph Jenkins > wrote: > > > So I setup BGPMON for my prefixes and got an alert about someone in > > Thailand announcing my prefix. Everything looks fine to me and I've > > checked a bunch of different Looking Glasses and everything announcing > > correctly. > > > > I am assuming I should be contacting the provider about their > > misconfiguration and announcing my prefixes and get them to fix it. Any > > other recommendations? > > > > Is there a way I can verify what they are announcing just to make sure > they > > are still doing it? > > > > Here is the alert for reference: > > > > Your prefix: 8.37.93.0/24: > > > > Update time: 2014-04-02 18:26 (UTC) > > > > Detected by #peers: 2 > > > > Detected prefix: 8.37.93.0/24 > > > > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > > Provider,ID) > > > > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > of > > Thailand(CAT),TH) > > > > ASpath: 18356 9931 4651 4761 > > > From jason at thebaughers.com Wed Apr 2 20:39:48 2014 From: jason at thebaughers.com (Jason Baugher) Date: Wed, 2 Apr 2014 15:39:48 -0500 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: I emailed hostmaster at indosat.com a little over an hour ago, and no response as yet. Anyone having luck making contact with Indosat themselves? On Wed, Apr 2, 2014 at 2:33 PM, Andrew (Andy) Ashley wrote: > Hi All, > > I am a network admin for Aware Corporation AS18356 (Thailand), as > mentioned in the alert. > We operate a BGPMon PeerMon node on our network, which peers with the > BGPMon service as a collector. > > It is likely that AS4761 (INDOSAT) has somehow managed to hijack these > prefixes and CAT (Communications Authority of Thailand AS4651) is not > filtering them, > hence they are announced to us and are triggering these BGPMon alerts. > > I have had several mails to our NOC about this already and have responded > directly to those. > I suggest contacting Indosat directly to get this resolved. > AS18356 is a stub AS, so we are not actually advertising these learned > hijacked prefixes to anyone but BGPMon for data collection purposes. > > Thanks. > > Regards, > > Andrew Ashley > > Office: +27 21 673 6841 > E-mail: andrew.a at aware.co.th > Web: www.aware.co.th > > > > On 2014/04/02, 21:05, "Vlade Ristevski" wrote: > > >I just got the same alert for one of my prefixes one minute ago. > > > >On 4/2/2014 2:59 PM, Frank Bulk wrote: > >> I received a similar notification about one of our prefixes also a few > >> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. > >>But I > >> also couldn't hit the websites for either AS, either. > >> > >> Frank > >> > >> -----Original Message----- > >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > >> Sent: Wednesday, April 02, 2014 1:52 PM > >> To: nanog at nanog.org > >> Subject: BGPMON Alert Questions > >> > >> So I setup BGPMON for my prefixes and got an alert about someone in > >> Thailand announcing my prefix. Everything looks fine to me and I've > >> checked a bunch of different Looking Glasses and everything announcing > >> correctly. > >> > >> I am assuming I should be contacting the provider about their > >> misconfiguration and announcing my prefixes and get them to fix it. Any > >> other recommendations? > >> > >> Is there a way I can verify what they are announcing just to make sure > >>they > >> are still doing it? > >> > >> Here is the alert for reference: > >> > >> Your prefix: 8.37.93.0/24: > >> > >> Update time: 2014-04-02 18:26 (UTC) > >> > >> Detected by #peers: 2 > >> > >> Detected prefix: 8.37.93.0/24 > >> > >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > >> Provider,ID) > >> > >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > >>of > >> Thailand(CAT),TH) > >> > >> ASpath: 18356 9931 4651 4761 > >> > >> > >> > > > >-- > >Vlad > > > > > From effulgence at gmail.com Wed Apr 2 20:40:17 2014 From: effulgence at gmail.com (Aris Lambrianidis) Date: Wed, 2 Apr 2014 22:40:17 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: Contacted ip.tac at indosat.com about this, I urge others to do the same. --Aris On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley wrote: > Hi All, > > I am a network admin for Aware Corporation AS18356 (Thailand), as > mentioned in the alert. > We operate a BGPMon PeerMon node on our network, which peers with the > BGPMon service as a collector. > > It is likely that AS4761 (INDOSAT) has somehow managed to hijack these > prefixes and CAT (Communications Authority of Thailand AS4651) is not > filtering them, > hence they are announced to us and are triggering these BGPMon alerts. > > I have had several mails to our NOC about this already and have responded > directly to those. > I suggest contacting Indosat directly to get this resolved. > AS18356 is a stub AS, so we are not actually advertising these learned > hijacked prefixes to anyone but BGPMon for data collection purposes. > > Thanks. > > Regards, > > Andrew Ashley > > Office: +27 21 673 6841 > E-mail: andrew.a at aware.co.th > Web: www.aware.co.th > > > > On 2014/04/02, 21:05, "Vlade Ristevski" wrote: > > >I just got the same alert for one of my prefixes one minute ago. > > > >On 4/2/2014 2:59 PM, Frank Bulk wrote: > >> I received a similar notification about one of our prefixes also a few > >> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. > >>But I > >> also couldn't hit the websites for either AS, either. > >> > >> Frank > >> > >> -----Original Message----- > >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > >> Sent: Wednesday, April 02, 2014 1:52 PM > >> To: nanog at nanog.org > >> Subject: BGPMON Alert Questions > >> > >> So I setup BGPMON for my prefixes and got an alert about someone in > >> Thailand announcing my prefix. Everything looks fine to me and I've > >> checked a bunch of different Looking Glasses and everything announcing > >> correctly. > >> > >> I am assuming I should be contacting the provider about their > >> misconfiguration and announcing my prefixes and get them to fix it. Any > >> other recommendations? > >> > >> Is there a way I can verify what they are announcing just to make sure > >>they > >> are still doing it? > >> > >> Here is the alert for reference: > >> > >> Your prefix: 8.37.93.0/24: > >> > >> Update time: 2014-04-02 18:26 (UTC) > >> > >> Detected by #peers: 2 > >> > >> Detected prefix: 8.37.93.0/24 > >> > >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > >> Provider,ID) > >> > >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > >>of > >> Thailand(CAT),TH) > >> > >> ASpath: 18356 9931 4651 4761 > >> > >> > >> > > > >-- > >Vlad > > > > > From ebais at a2b-internet.com Wed Apr 2 20:41:31 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 2 Apr 2014 22:41:31 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <40BF5902-2383-4ADF-8330-E3ABC9F972E7@a2b-internet.com> We are getting multiple alerts for a mix of our and customers prefixes. Could someone from HE tell if they started filtering yet ? Erik Bais Verstuurd vanaf mijn iPad Op 2 apr. 2014 om 21:21 heeft Felix Aronsson het volgende geschreven: > Seeing the same here for a /21. This seems to have happened before with > AS4761? See http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/from > january 2011. > > > On Wed, Apr 2, 2014 at 8:51 PM, Joseph Jenkins > wrote: > >> So I setup BGPMON for my prefixes and got an alert about someone in >> Thailand announcing my prefix. Everything looks fine to me and I've >> checked a bunch of different Looking Glasses and everything announcing >> correctly. >> >> I am assuming I should be contacting the provider about their >> misconfiguration and announcing my prefixes and get them to fix it. Any >> other recommendations? >> >> Is there a way I can verify what they are announcing just to make sure they >> are still doing it? >> >> Here is the alert for reference: >> >> Your prefix: 8.37.93.0/24: >> >> Update time: 2014-04-02 18:26 (UTC) >> >> Detected by #peers: 2 >> >> Detected prefix: 8.37.93.0/24 >> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >> Provider,ID) >> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of >> Thailand(CAT),TH) >> >> ASpath: 18356 9931 4651 4761 >> From sethm at rollernet.us Wed Apr 2 20:51:42 2014 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 02 Apr 2014 13:51:42 -0700 Subject: BGPMON Alert Questions In-Reply-To: <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> References: <000c01cf4ea8$57623580$0626a080$@iname.com>, <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> Message-ID: <533C785E.5060106@rollernet.us> On 4/2/14, 13:31, Bob Evans wrote: > where did you get that number ? I think that was a number for CAT, AS4651. ~Seth From Curtis at GreenKey.net Wed Apr 2 20:57:08 2014 From: Curtis at GreenKey.net (Curtis Doty) Date: Wed, 2 Apr 2014 13:57:08 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> <6F52F909-BDBE-4990-B63B-0945917DBD69@mythostech.com> Message-ID: On Wed, Apr 2, 2014 at 1:24 PM, Blake Dunlap wrote: > Is this malicious or did someone redistribute all of bgp with bad upstream > filtering? > They perfectly re-advertized all mine. Loos like a huge mistake. And still ongoing. Although this was nice to see: ==================================================================== RPKI Validation Failed (Code: 9) ==================================================================== Your prefix: 199.47.80.0/21: Prefix Description: NET-199-47-80-0-1 Update time: 2014-04-02 20:29 (UTC) Detected by #peers: 1 Detected prefix: 199.47.80.0/21 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 38794 4651 4761 RPKI Status: ROA validation failed: Invalid Origin ASN, expected 46851 Albeit ineffective. ../C From andrew.a at aware.co.th Wed Apr 2 21:05:47 2014 From: andrew.a at aware.co.th (Andrew (Andy) Ashley) Date: Wed, 2 Apr 2014 21:05:47 +0000 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: I got a bounce from Indosat saying: "Dear Senders, Thank you for your email, started March,1st 2012 email address for correspondence with Indosat IP Support & All Support INP will be change and not active with detail information as follows : 1. Correspondence and complain handling for Indosat Corporate customers (INP, IDIA and INIX services) please kindly address to : corporatesolution at indosat.com (Service Desk MIDI Indosat Corporate Solution) 2. Correspondence and coordination for upstream and peering purpose please kindly address to : SNOCIPSurv at indosat.com (SNOC IP Surveillance) Thank you for your kind cooperation and understanding. Indosat IP Support" Perhaps the ?SNOC IP Surveillance? address is better? For CAT Thailand, the contact details I have are: NOC call center CAT Telecom Tel: 66 2 104 2382 FAX: 66 2 104 2281 e-mail: cusserv at cattelecom.com As someone mentioned, English may be an issue, especially at this time of the morning over there. Regards, Andrew Ashley Office: +27 21 673 6841 E-mail: andrew.a at aware.co.th Web: www.aware.co.th From: Aris Lambrianidis Date: Wednesday 02 April 2014 at 22:40 To: Andrew Ashley Cc: "nanog at nanog.org" Subject: Re: BGPMON Alert Questions Contacted ip.tac at indosat.com about this, I urge others to do the same. --Aris On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley wrote: > Hi All, > > I am a network admin for Aware Corporation AS18356 (Thailand), as > mentioned in the alert. > We operate a BGPMon PeerMon node on our network, which peers with the > BGPMon service as a collector. > > It is likely that AS4761 (INDOSAT) has somehow managed to hijack these > prefixes and CAT (Communications Authority of Thailand AS4651) is not > filtering them, > hence they are announced to us and are triggering these BGPMon alerts. > > I have had several mails to our NOC about this already and have responded > directly to those. > I suggest contacting Indosat directly to get this resolved. > AS18356 is a stub AS, so we are not actually advertising these learned > hijacked prefixes to anyone but BGPMon for data collection purposes. > > Thanks. > > Regards, > > Andrew Ashley > > Office: +27 21 673 6841 > E-mail: andrew.a at aware.co.th > Web: www.aware.co.th > > > > On 2014/04/02, 21:05, "Vlade Ristevski" wrote: > >> >I just got the same alert for one of my prefixes one minute ago. >> > >> >On 4/2/2014 2:59 PM, Frank Bulk wrote: >>> >> I received a similar notification about one of our prefixes also a few >>> >> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. >>> >>But I >>> >> also couldn't hit the websites for either AS, either. >>> >> >>> >> Frank >>> >> >>> >> -----Original Message----- >>> >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] >>> >> Sent: Wednesday, April 02, 2014 1:52 PM >>> >> To: nanog at nanog.org >>> >> Subject: BGPMON Alert Questions >>> >> >>> >> So I setup BGPMON for my prefixes and got an alert about someone in >>> >> Thailand announcing my prefix. Everything looks fine to me and I've >>> >> checked a bunch of different Looking Glasses and everything announcing >>> >> correctly. >>> >> >>> >> I am assuming I should be contacting the provider about their >>> >> misconfiguration and announcing my prefixes and get them to fix it. Any >>> >> other recommendations? >>> >> >>> >> Is there a way I can verify what they are announcing just to make sure >>> >>they >>> >> are still doing it? >>> >> >>> >> Here is the alert for reference: >>> >> >>> >> Your prefix: 8.37.93.0/24 : >>> >> >>> >> Update time: 2014-04-02 18:26 (UTC) >>> >> >>> >> Detected by #peers: 2 >>> >> >>> >> Detected prefix: 8.37.93.0/24 >>> >> >>> >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >>> >> Provider,ID) >>> >> >>> >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >>> >>of >>> >> Thailand(CAT),TH) >>> >> >>> >> ASpath: 18356 9931 4651 4761 >>> >> >>> >> >>> >> >> > >> >-- >> >Vlad >> > >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5770 bytes Desc: not available URL: From bclark at spectraaccess.com Wed Apr 2 21:08:06 2014 From: bclark at spectraaccess.com (Bret Clark) Date: Wed, 02 Apr 2014 17:08:06 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: <94081c39f9a5d313228bb194643fe287.squirrel@66.201.44.180> Message-ID: <533C7C36.1050701@spectraaccess.com> They are advertising one of /22 right now as well, Bret On 04/02/2014 04:21 PM, Bryan Tong wrote: > They have advertised all of ours now. > > > On Wed, Apr 2, 2014 at 2:16 PM, Bob Evans wrote: > >> Yes, I too have alerts for some of our prefixes from the same offending >> origin 4761 >> >> On Wednesday April 2nd 2014 at 19:59 UTC we detected a Origin AS Change >> event for your prefix (66.201.48.0/20 slash 20 bottom of nor cal) >> The detected prefix: 66.201.48.0/20, was announced by AS4761 >> (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) >> Alert description: Origin AS Change >> Detected Prefix: 66.201.48.0/20 >> Detected Origin AS: 4761 >> Expected Origin AS: 26803 >> >> Bob Evans >> CTO >> >> >> >> >>> So I setup BGPMON for my prefixes and got an alert about someone in >>> Thailand announcing my prefix. Everything looks fine to me and I've >>> checked a bunch of different Looking Glasses and everything announcing >>> correctly. >>> >>> I am assuming I should be contacting the provider about their >>> misconfiguration and announcing my prefixes and get them to fix it. Any >>> other recommendations? >>> >>> Is there a way I can verify what they are announcing just to make sure >>> they >>> are still doing it? >>> >>> Here is the alert for reference: >>> >>> Your prefix: 8.37.93.0/24: >>> >>> Update time: 2014-04-02 18:26 (UTC) >>> >>> Detected by #peers: 2 >>> >>> Detected prefix: 8.37.93.0/24 >>> >>> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >>> Provider,ID) >>> >>> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >> of >>> Thailand(CAT),TH) >>> >>> ASpath: 18356 9931 4651 4761 >>> >> >> >> > -- Spectra Access 25 Lowell Street Manchester, NH 03042 603-296-0760 www.spectraaccess.net From luca.simonetti at enginenetworks.net Wed Apr 2 21:10:54 2014 From: luca.simonetti at enginenetworks.net (Luca Simonetti) Date: Wed, 2 Apr 2014 23:10:54 +0200 (CEST) Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: <1980121955.567748.1396473054113.JavaMail.zimbra@enginenetworks.net> Same here : Your prefix: 178.212.137.0/24: Prefix Description: Engine Networks EU Update time: 2014-04-02 20:54 (UTC) Detected by #peers: 1 Detected prefix: 178.212.137.0/24 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network Provider,ID) Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of Thailand(CAT),TH) ASpath: 18356 9931 4651 4761 and many others -- Luca Simonetti ________ Engine Networks http://www.enginenetworks.net http://www.facebook.com/enginenetworks http://twitter.com/enginenetworks Datacenter GENEVA 1: Rue de la Conf?d?ration, 6 1204 Geneve - CH Datacenter ZURICH 1: Josefstrasse, 225 - 8005 Z?rich - CH Datacenter MILAN 1: Via Caldera, 21 - 20100 Milan - IT Datacenter TURIN 1: C.so Svizzera, 185 - 10149 Turin - IT From mark at viviotech.net Wed Apr 2 21:12:57 2014 From: mark at viviotech.net (Mark Keymer) Date: Wed, 02 Apr 2014 14:12:57 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: <533C7D59.7090506@viviotech.net> So, Just tired e-mailing to that address. "*Delivery has failed to these recipients or groups:* indriana.triyunianingtyas at indosat.com The recipient's mailbox is full and can't accept messages now. Please try resending this message later, or contact the recipient directly." Sincerely, Mark Keymer CFO/COO Vivio Technologies On 4/2/2014 1:40 PM, Aris Lambrianidis wrote: > Contacted ip.tac at indosat.com about this, I urge others to do the same. > > --Aris > > > On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley > wrote: > >> Hi All, >> >> I am a network admin for Aware Corporation AS18356 (Thailand), as >> mentioned in the alert. >> We operate a BGPMon PeerMon node on our network, which peers with the >> BGPMon service as a collector. >> >> It is likely that AS4761 (INDOSAT) has somehow managed to hijack these >> prefixes and CAT (Communications Authority of Thailand AS4651) is not >> filtering them, >> hence they are announced to us and are triggering these BGPMon alerts. >> >> I have had several mails to our NOC about this already and have responded >> directly to those. >> I suggest contacting Indosat directly to get this resolved. >> AS18356 is a stub AS, so we are not actually advertising these learned >> hijacked prefixes to anyone but BGPMon for data collection purposes. >> >> Thanks. >> >> Regards, >> >> Andrew Ashley >> >> Office: +27 21 673 6841 >> E-mail: andrew.a at aware.co.th >> Web: www.aware.co.th >> >> >> >> On 2014/04/02, 21:05, "Vlade Ristevski" wrote: >> >>> I just got the same alert for one of my prefixes one minute ago. >>> >>> On 4/2/2014 2:59 PM, Frank Bulk wrote: >>>> I received a similar notification about one of our prefixes also a few >>>> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. >>>> But I >>>> also couldn't hit the websites for either AS, either. >>>> >>>> Frank >>>> >>>> -----Original Message----- >>>> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] >>>> Sent: Wednesday, April 02, 2014 1:52 PM >>>> To: nanog at nanog.org >>>> Subject: BGPMON Alert Questions >>>> >>>> So I setup BGPMON for my prefixes and got an alert about someone in >>>> Thailand announcing my prefix. Everything looks fine to me and I've >>>> checked a bunch of different Looking Glasses and everything announcing >>>> correctly. >>>> >>>> I am assuming I should be contacting the provider about their >>>> misconfiguration and announcing my prefixes and get them to fix it. Any >>>> other recommendations? >>>> >>>> Is there a way I can verify what they are announcing just to make sure >>>> they >>>> are still doing it? >>>> >>>> Here is the alert for reference: >>>> >>>> Your prefix: 8.37.93.0/24: >>>> >>>> Update time: 2014-04-02 18:26 (UTC) >>>> >>>> Detected by #peers: 2 >>>> >>>> Detected prefix: 8.37.93.0/24 >>>> >>>> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network >>>> Provider,ID) >>>> >>>> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority >>>> of >>>> Thailand(CAT),TH) >>>> >>>> ASpath: 18356 9931 4651 4761 >>>> >>>> >>>> >>> -- >>> Vlad >>> >>> From joe at breathe-underwater.com Wed Apr 2 21:13:21 2014 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Wed, 2 Apr 2014 14:13:21 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: Tried the recipients mailbox is full, but it looks like all of the bgpmon alerts have cleared. On Wed, Apr 2, 2014 at 1:40 PM, Aris Lambrianidis wrote: > Contacted ip.tac at indosat.com about this, I urge others to do the same. > > --Aris > > > On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley > wrote: > > > Hi All, > > > > I am a network admin for Aware Corporation AS18356 (Thailand), as > > mentioned in the alert. > > We operate a BGPMon PeerMon node on our network, which peers with the > > BGPMon service as a collector. > > > > It is likely that AS4761 (INDOSAT) has somehow managed to hijack these > > prefixes and CAT (Communications Authority of Thailand AS4651) is not > > filtering them, > > hence they are announced to us and are triggering these BGPMon alerts. > > > > I have had several mails to our NOC about this already and have responded > > directly to those. > > I suggest contacting Indosat directly to get this resolved. > > AS18356 is a stub AS, so we are not actually advertising these learned > > hijacked prefixes to anyone but BGPMon for data collection purposes. > > > > Thanks. > > > > Regards, > > > > Andrew Ashley > > > > Office: +27 21 673 6841 > > E-mail: andrew.a at aware.co.th > > Web: www.aware.co.th > > > > > > > > On 2014/04/02, 21:05, "Vlade Ristevski" wrote: > > > > >I just got the same alert for one of my prefixes one minute ago. > > > > > >On 4/2/2014 2:59 PM, Frank Bulk wrote: > > >> I received a similar notification about one of our prefixes also a few > > >> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. > > >>But I > > >> also couldn't hit the websites for either AS, either. > > >> > > >> Frank > > >> > > >> -----Original Message----- > > >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > > >> Sent: Wednesday, April 02, 2014 1:52 PM > > >> To: nanog at nanog.org > > >> Subject: BGPMON Alert Questions > > >> > > >> So I setup BGPMON for my prefixes and got an alert about someone in > > >> Thailand announcing my prefix. Everything looks fine to me and I've > > >> checked a bunch of different Looking Glasses and everything announcing > > >> correctly. > > >> > > >> I am assuming I should be contacting the provider about their > > >> misconfiguration and announcing my prefixes and get them to fix it. > Any > > >> other recommendations? > > >> > > >> Is there a way I can verify what they are announcing just to make sure > > >>they > > >> are still doing it? > > >> > > >> Here is the alert for reference: > > >> > > >> Your prefix: 8.37.93.0/24: > > >> > > >> Update time: 2014-04-02 18:26 (UTC) > > >> > > >> Detected by #peers: 2 > > >> > > >> Detected prefix: 8.37.93.0/24 > > >> > > >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > > >> Provider,ID) > > >> > > >> Upstream AS: AS4651 (THAI-GATEWAY The Communications > Authority > > >>of > > >> Thailand(CAT),TH) > > >> > > >> ASpath: 18356 9931 4651 4761 > > >> > > >> > > >> > > > > > >-- > > >Vlad > > > > > > > > > From EDugas at zerofail.com Wed Apr 2 21:12:56 2014 From: EDugas at zerofail.com (Eric Dugas) Date: Wed, 2 Apr 2014 21:12:56 +0000 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> , Message-ID: <656AAF5E8566DF47835F38F66FA8213A15EE2FFA@ZF-EXC1.Pre2Post.local> Thanks, also emailed support@ noc at . Didn't receive any bounce emails.. eric at zerofail.com AS40191 On Apr 2, 2014 5:06 PM, Aris Lambrianidis wrote: Contacted ip.tac at indosat.com about this, I urge others to do the same. --Aris On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley wrote: > Hi All, > > I am a network admin for Aware Corporation AS18356 (Thailand), as > mentioned in the alert. > We operate a BGPMon PeerMon node on our network, which peers with the > BGPMon service as a collector. > > It is likely that AS4761 (INDOSAT) has somehow managed to hijack these > prefixes and CAT (Communications Authority of Thailand AS4651) is not > filtering them, > hence they are announced to us and are triggering these BGPMon alerts. > > I have had several mails to our NOC about this already and have responded > directly to those. > I suggest contacting Indosat directly to get this resolved. > AS18356 is a stub AS, so we are not actually advertising these learned > hijacked prefixes to anyone but BGPMon for data collection purposes. > > Thanks. > > Regards, > > Andrew Ashley > > Office: +27 21 673 6841 > E-mail: andrew.a at aware.co.th > Web: www.aware.co.th > > > > On 2014/04/02, 21:05, "Vlade Ristevski" wrote: > > >I just got the same alert for one of my prefixes one minute ago. > > > >On 4/2/2014 2:59 PM, Frank Bulk wrote: > >> I received a similar notification about one of our prefixes also a few > >> minutes ago. I couldn't find a looking glass for AS4761 or AS4651. > >>But I > >> also couldn't hit the websites for either AS, either. > >> > >> Frank > >> > >> -----Original Message----- > >> From: Joseph Jenkins [mailto:joe at breathe-underwater.com] > >> Sent: Wednesday, April 02, 2014 1:52 PM > >> To: nanog at nanog.org > >> Subject: BGPMON Alert Questions > >> > >> So I setup BGPMON for my prefixes and got an alert about someone in > >> Thailand announcing my prefix. Everything looks fine to me and I've > >> checked a bunch of different Looking Glasses and everything announcing > >> correctly. > >> > >> I am assuming I should be contacting the provider about their > >> misconfiguration and announcing my prefixes and get them to fix it. Any > >> other recommendations? > >> > >> Is there a way I can verify what they are announcing just to make sure > >>they > >> are still doing it? > >> > >> Here is the alert for reference: > >> > >> Your prefix: 8.37.93.0/24: > >> > >> Update time: 2014-04-02 18:26 (UTC) > >> > >> Detected by #peers: 2 > >> > >> Detected prefix: 8.37.93.0/24 > >> > >> Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > >> Provider,ID) > >> > >> Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority > >>of > >> Thailand(CAT),TH) > >> > >> ASpath: 18356 9931 4651 4761 > >> > >> > >> > > > >-- > >Vlad > > > > > From contact at nullivex.com Wed Apr 2 21:19:49 2014 From: contact at nullivex.com (Bryan Tong) Date: Wed, 2 Apr 2014 15:19:49 -0600 Subject: BGPMON Alert Questions In-Reply-To: <533C785E.5060106@rollernet.us> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> Message-ID: Got this response from HE We are not in the as-path of the routes listed below. It seems we accepted some of them from a route server. I'm not seeing them in the table at this time. -- Rob Mosher Senior Network and Software Engineer Hurricane Electric / AS6939 On Wed, Apr 2, 2014 at 2:51 PM, Seth Mattinen wrote: > On 4/2/14, 13:31, Bob Evans wrote: > >> where did you get that number ? >> > > > I think that was a number for CAT, AS4651. > > ~Seth > > -- eSited LLC (701) 390-9638 From laszlo at heliacal.net Wed Apr 2 21:20:36 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 2 Apr 2014 21:20:36 +0000 Subject: BGPMON Alert Questions In-Reply-To: <533C785E.5060106@rollernet.us> References: <000c01cf4ea8$57623580$0626a080$@iname.com>, <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> Message-ID: They're just leaking every route right? Is it possible to poison the AS paths you announce with their own AS to get them to let go of your prefixes until it's fixed? Would that work, or some other trick that can be done without their cooperation? Thanks, Laszlo From petertavenier at gmail.com Wed Apr 2 21:23:18 2014 From: petertavenier at gmail.com (Peter Tavenier) Date: Wed, 2 Apr 2014 23:23:18 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> <6F52F909-BDBE-4990-B63B-0945917DBD69@mythostech.com> Message-ID: Same here. AS path is 18356 38794 4651 4761. Did anybody had any contact with AS 4761? Regards, Peter > Op 2 apr. 2014 om 22:57 heeft Curtis Doty het volgende geschreven: > >> On Wed, Apr 2, 2014 at 1:24 PM, Blake Dunlap wrote: >> >> Is this malicious or did someone redistribute all of bgp with bad upstream >> filtering? > > > They perfectly re-advertized all mine. Loos like a huge mistake. And still > ongoing. > > Although this was nice to see: > > ==================================================================== > RPKI Validation Failed (Code: 9) > ==================================================================== > Your prefix: 199.47.80.0/21: > Prefix Description: NET-199-47-80-0-1 > Update time: 2014-04-02 20:29 (UTC) > Detected by #peers: 1 > Detected prefix: 199.47.80.0/21 > Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network > Provider,ID) > Upstream AS: AS4651 (THAI-GATEWAY The Communications Authority of > Thailand(CAT),TH) > ASpath: 18356 38794 4651 4761 > RPKI Status: ROA validation failed: Invalid Origin ASN, expected > 46851 > > Albeit ineffective. > > ../C From adrian.minta at gmail.com Wed Apr 2 21:26:53 2014 From: adrian.minta at gmail.com (Adrian Minta) Date: Thu, 03 Apr 2014 00:26:53 +0300 Subject: BGPMON Alert Questions In-Reply-To: References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> Message-ID: <533C809D.7000303@gmail.com> Already too late :( *Delivery has failed to these recipients or groups:* indriana.triyunianingtyas at indosat.com The recipient's mailbox is full and can't accept messages now. Please try resending this message later, or contact the recipient directly. On 02.04.2014 23:40, Aris Lambrianidis wrote: > Contacted ip.tac at indosat.com about this, I urge others to do the same. > > --Aris > > > On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley > wrote: > >> Hi All, >> >> I am a network admin for Aware Corporation AS18356 (Thailand), as >> mentioned in the alert. >> We operate a BGPMon PeerMon node on our network, which peers with the >> BGPMon service as a collector. >> >> It is likely that AS4761 (INDOSAT) has somehow managed to hijack these >> prefixes and CAT (Communications Authority of Thailand AS4651) is not >> filtering them, >> hence they are announced to us and are triggering these BGPMon alerts. >> >> I have had several mails to our NOC about this already and have responded >> directly to those. >> I suggest contacting Indosat directly to get this resolved. >> AS18356 is a stub AS, so we are not actually advertising these learned >> hijacked prefixes to anyone but BGPMon for data collection purposes. >> >> -- Best regards, Adrian Minta From andrew.fried at gmail.com Wed Apr 2 21:54:13 2014 From: andrew.fried at gmail.com (Andrew Fried) Date: Wed, 02 Apr 2014 17:54:13 -0400 Subject: Cogent - ATT issue? In-Reply-To: References: Message-ID: <533C8705.7020109@gmail.com> My connectivity between Fios and Cogent in Washington DC has been mostly down for the past hour. Andrew Andrew Fried andrew.fried at gmail.com On 4/2/14, 3:03 PM, Eric wrote: > Anyone know if there is a connectivity issue between Cogent and ATT in the northeast? We're seeing random timeouts to some systems we have in an ATT data center but only from sources on Cogent's network. > > Thanks... > > - Eric :) > From streiner at cluebyfour.org Wed Apr 2 18:59:58 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 2 Apr 2014 14:59:58 -0400 (EDT) Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com>, <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> Message-ID: On Wed, 2 Apr 2014, Laszlo Hanyecz wrote: > They're just leaking every route right? > Is it possible to poison the AS paths you announce with their own AS to get them to let go of your prefixes until it's fixed? > Would that work, or some other trick that can be done without their cooperation? Keep in mind that the more AS hops there are between you and Indosat, the less effective that any hackery you do in your own BGP table will be. Two things need to happen: 1. Indosat needs to clean their mess up. 2. Indosat's upstreams need to apply some BGP clue to Indosat's announcements. It's pretty clear that both parties have dropped the ball in a big way, in terms of sane BGP filtering practices. jms From streiner at cluebyfour.org Wed Apr 2 19:01:58 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 2 Apr 2014 15:01:58 -0400 (EDT) Subject: BGPMON Alert Questions In-Reply-To: <533C809D.7000303@gmail.com> References: <000001cf4ea5$a2eaa210$e8bfe630$@iname.com> <533C5F64.8020401@ramapo.edu> <533C809D.7000303@gmail.com> Message-ID: On Thu, 3 Apr 2014, Adrian Minta wrote: > Already too late :( > > *Delivery has failed to these recipients or groups:* > > indriana.triyunianingtyas at indosat.com > > The recipient's mailbox is full and can't accept messages now. Please try > resending this message later, or contact the recipient directly. As long as that's not the only person behind the "ip.tac at indosat.com" mail alias, all hope is not lost. Still, I imagine their NOC is getting crushed with reports right now. jms > On 02.04.2014 23:40, Aris Lambrianidis wrote: >> Contacted ip.tac at indosat.com about this, I urge others to do the same. >> >> --Aris >> >> >> On Wed, Apr 2, 2014 at 9:33 PM, Andrew (Andy) Ashley >> wrote: >> >> > Hi All, >> > >> > I am a network admin for Aware Corporation AS18356 (Thailand), as >> > mentioned in the alert. >> > We operate a BGPMon PeerMon node on our network, which peers with the >> > BGPMon service as a collector. >> > >> > It is likely that AS4761 (INDOSAT) has somehow managed to hijack these >> > prefixes and CAT (Communications Authority of Thailand AS4651) is not >> > filtering them, >> > hence they are announced to us and are triggering these BGPMon alerts. >> > >> > I have had several mails to our NOC about this already and have >> > responded >> > directly to those. >> > I suggest contacting Indosat directly to get this resolved. >> > AS18356 is a stub AS, so we are not actually advertising these learned >> > hijacked prefixes to anyone but BGPMon for data collection purposes. >> > >> > > > > -- > Best regards, > Adrian Minta > > > From joelja at bogus.com Wed Apr 2 22:21:23 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 02 Apr 2014 15:21:23 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com>, <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> Message-ID: <533C8D63.5030307@bogus.com> On 4/2/14, 11:59 AM, Justin M. Streiner wrote: > Two things need to happen: > 1. Indosat needs to clean their mess up. > 2. Indosat's upstreams need to apply some BGP clue to Indosat's > announcements. > > It's pretty clear that both parties have dropped the ball in a big way, > in terms of sane BGP filtering practices. actually that's no at all clear. https://twitter.com/renesys/status/451456391656796161 it looked like the filtering worked rather well. certainly as a customer of many of 4761s transit providers I did not see any of them pick up this advertisement in asia. the impact was limited even when it began, and it should be largely over. One of the things it says as that this sort of announcement is highly visible to the monitoring infrastructure, which is rather good to know. > jms > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From andree+nanog at toonk.nl Wed Apr 2 23:16:23 2014 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 02 Apr 2014 16:16:23 -0700 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> Message-ID: <533C9A47.8070602@toonk.nl> Quick update from BGPmon: We've detected 415,652 prefixes being hijacked by Indosat today. 8,233 of those were seen by more than 10 of our BGP collectors. When receiving a BGPmon alerts, one of the metrics to look at that will help with determining the scope and impact is the 'Detected by #peers' value. Many of the alerts where only seen by one or two peers in Thailand. This indicates that communications for those prefixes would likely have been affected for some in Thailand. 8,233 of the hijacked prefixes were seen by more than 10 of our peers. For those the impact would have been more severe. Since we're on Nanog, here's al list of US based networks affected by Indosat hijack that were seen by more than 10 unique ASns: http://portal.bgpmon.net/data/indosat-us.txt it includes apple, telia, ntt, level3, comcast, cableone, akamai, Joyent Same for Canadian prefixes (keep in mind there were more hijacked prefixes, this is just the list for which the hijack was seen by more than 10 of our peers) http://portal.bgpmon.net/data/indosat-ca.txt Cheers, Andree .-- My secret spy satellite informs me that at 2014-04-02 2:20 PM Laszlo Hanyecz wrote: > They're just leaking every route right? > Is it possible to poison the AS paths you announce with their own AS to get them to let go of your prefixes until it's fixed? > Would that work, or some other trick that can be done without their cooperation? > > Thanks, > Laszlo > > From randy at psg.com Thu Apr 3 00:22:44 2014 From: randy at psg.com (Randy Bush) Date: Thu, 03 Apr 2014 09:22:44 +0900 Subject: BGPMON Alert Questions In-Reply-To: <533C9A47.8070602@toonk.nl> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> Message-ID: note joels careful use of 'injected'. imiho, 'hijacked' is perjorative implying evil intent. i very much doubt that is the case here. it looks much more like an accident. could we try to be less accusatory with our language. 'injected', 'mis-originated', ... would seem to descrive the situation. and, btw, how many of those whose prefixes were mis-originated had registered those prefixes in the rpki? randy From Valdis.Kletnieks at vt.edu Thu Apr 3 00:39:27 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Apr 2014 20:39:27 -0400 Subject: BGPMON Alert Questions In-Reply-To: Your message of "Wed, 02 Apr 2014 16:16:23 -0700." <533C9A47.8070602@toonk.nl> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> Message-ID: <70676.1396485567@turing-police.cc.vt.edu> On Wed, 02 Apr 2014 16:16:23 -0700, Andree Toonk said: > Quick update from BGPmon: > We've detected 415,652 prefixes being hijacked by Indosat today. Those who do not understand AS7007 are doomed to repeat it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bgreene at senki.org Thu Apr 3 01:11:56 2014 From: bgreene at senki.org (Barry Greene) Date: Thu, 3 Apr 2014 08:11:56 +0700 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> Message-ID: <6EFA9DE3-9C6F-4286-ACA0-7EF2E9DFAF79@senki.org> Agreed - focus on the fix. Then take a deep breath and figure out what happened. BTW - Indosat is down hard. Cannot call into their network (cell phone). I've got my team reaching in to their buddies to help. On Apr 3, 2014, at 7:22 AM, Randy Bush wrote: > note joels careful use of 'injected'. imiho, 'hijacked' is perjorative > implying evil intent. i very much doubt that is the case here. it > looks much more like an accident. could we try to be less accusatory > with our language. 'injected', 'mis-originated', ... would seem to > descrive the situation. > > and, btw, how many of those whose prefixes were mis-originated had > registered those prefixes in the rpki? > > randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bgreene at senki.org Thu Apr 3 03:30:33 2014 From: bgreene at senki.org (Barry Greene) Date: Thu, 3 Apr 2014 10:30:33 +0700 Subject: BGPMON Alert Questions In-Reply-To: <6EFA9DE3-9C6F-4286-ACA0-7EF2E9DFAF79@senki.org> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> <6EFA9DE3-9C6F-4286-ACA0-7EF2E9DFAF79@senki.org> Message-ID: <9831065B-DAF3-40A9-ACD5-1E39EC4EC163@senki.org> Hi Team, Confirmation from my team talking directly to Indosat - self inflected with a bad update during a maintenance window. Nothing malicious or intentional. Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Thu Apr 3 03:43:53 2014 From: randy at psg.com (Randy Bush) Date: Thu, 03 Apr 2014 12:43:53 +0900 Subject: BGPMON Alert Questions In-Reply-To: <70676.1396485567@turing-police.cc.vt.edu> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> <70676.1396485567@turing-police.cc.vt.edu> Message-ID: > > We've detected 415,652 prefixes being hijacked by Indosat today. > Those who do not understand AS7007 are doomed to repeat it? i very much doubt this is a 7007, where bgp was redistributed into rip, which sliced it into a jillion /24s, and then redistributed from rip back into bgp. of course the lack of filtering or origin validation is an endemic disease. randy From jeff-kell at utc.edu Thu Apr 3 03:54:17 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 2 Apr 2014 23:54:17 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> Message-ID: <533CDB69.7000105@utc.edu> So we're somewhat safe until the fast food burger grills and fries cookers advance to level-3 routing? Or Daquiri blenders get their own ASNs? Bad enough that "professional" folks can goof to this extent, but scarier still that the "Internet of Everything" seems to progress without bounds... Jeff On 4/2/2014 11:43 PM, Randy Bush wrote: >>> We've detected 415,652 prefixes being hijacked by Indosat today. >> Those who do not understand AS7007 are doomed to repeat it? > i very much doubt this is a 7007, where bgp was redistributed into rip, > which sliced it into a jillion /24s, and then redistributed from rip > back into bgp. > > of course the lack of filtering or origin validation is an endemic > disease. > > randy > > From randy at psg.com Thu Apr 3 06:00:41 2014 From: randy at psg.com (Randy Bush) Date: Thu, 03 Apr 2014 15:00:41 +0900 Subject: BGPMON Alert Questions In-Reply-To: <533CDB69.7000105@utc.edu> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <533CDB69.7000105@utc.edu> Message-ID: > So we're somewhat safe until the fast food burger grills and fries > cookers advance to level-3 routing? Or Daquiri blenders get their own > ASNs? that happened in the late '90s > Bad enough that "professional" folks can goof to this extent luckily, you, valdis, and i never make mistakes :) the point it to engineer the network so we are not affected by the inevitable mistakes as chris and i were noting privately, this seems not to have damaged a lot of traffic, more than compensated for by the traffic on nanog :) randy From Valdis.Kletnieks at vt.edu Thu Apr 3 09:11:51 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Apr 2014 05:11:51 -0400 Subject: BGPMON Alert Questions In-Reply-To: Your message of "Thu, 03 Apr 2014 15:00:41 +0900." References: <000c01cf4ea8$57623580$0626a080$@iname.com> <533CDB69.7000105@utc.edu> Message-ID: <52955.1396516311@turing-police.cc.vt.edu> On Thu, 03 Apr 2014 15:00:41 +0900, Randy Bush said: > > Bad enough that "professional" folks can goof to this extent > > luckily, you, valdis, and i never make mistakes :) You must have me confused with somebody else. I wouldn't have a world-wide reputation for getting myself out of holes I've dug if I wasn't incredible at hole digging in the first place. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From matthew at walster.org Thu Apr 3 11:02:59 2014 From: matthew at walster.org (Matthew Walster) Date: Thu, 3 Apr 2014 12:02:59 +0100 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> <70676.1396485567@turing-police.cc.vt.edu> Message-ID: On 3 April 2014 04:43, Randy Bush wrote: > i very much doubt this is a 7007, where bgp was redistributed into rip, > which sliced it into a jillion /24s, and then redistributed from rip > back into bgp. ?I could be wrong, but I thought AS7007 was nothing to do with RIP? http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html M? From mark.tinka at seacom.mu Thu Apr 3 12:04:44 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 14:04:44 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <201404031404.44935.mark.tinka@seacom.mu> On Wednesday, April 02, 2014 08:59:58 PM Justin M. Streiner wrote: > It's pretty clear that both parties have dropped the ball > in a big way, in terms of sane BGP filtering practices. It's amazing, isn't it? I have a customer of one my upstreams (Upstream A), at the moment, who are leaking my routes to another one of their upstreams (Upstream B). The problem is that Upstream B is re-announcing my leaked routes from their customer to the rest of the Internet. So both Upstream B's customer as well as Upstream B are at fault. That Upstream B is simply "accepting everything" their customer is sending to them without applying proper filters, or checking to confirm that what their customer needs to send them should come from them is absolutely and unacceptably shocking! A lot of people seem to have forgotten 2008. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ml at kenweb.org Thu Apr 3 12:09:35 2014 From: ml at kenweb.org (ML) Date: Thu, 03 Apr 2014 08:09:35 -0400 Subject: BGPMON Alert Questions In-Reply-To: <9831065B-DAF3-40A9-ACD5-1E39EC4EC163@senki.org> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> <6EFA9DE3-9C6F-4286-ACA0-7EF2E9DFAF79@senki.org> <9831065B-DAF3-40A9-ACD5-1E39EC4EC163@senki.org> Message-ID: <533D4F7F.2070206@kenweb.org> On 4/2/2014 11:30 PM, Barry Greene wrote: > Hi Team, > > Confirmation from my team talking directly to Indosat - self inflected with a bad update during a maintenance window. Nothing malicious or intentional. > > Barry > > Did you get any details on what specifically went wrong? I don't recall any switch in my routing gear to "re-originate every prefix on the planet as my own". From nick at foobar.org Thu Apr 3 12:17:07 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 03 Apr 2014 13:17:07 +0100 Subject: BGPMON Alert Questions In-Reply-To: <533D4F7F.2070206@kenweb.org> References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> <6EFA9DE3-9C6F-4286-ACA0-7EF2E9DFAF79@senki.org> <9831065B-DAF3-40A9-ACD5-1E39EC4EC163@senki.org> <533D4F7F.2070206@kenweb.org> Message-ID: <533D5143.5060806@foobar.org> On 03/04/2014 13:09, ML wrote: > Did you get any details on what specifically went wrong? I don't recall > any switch in my routing gear to "re-originate every prefix on the planet > as my own". Easy enough to do by e.g. redistributing your ebgp into your IGP and then back again, or by a variety of other means. It happened between 05:00 and 06:00 local time, so it's reasonable to assume that it was maintenance gone wrong. Horribly wrong. Nick From mark.tinka at seacom.mu Thu Apr 3 12:31:51 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 14:31:51 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <533C9A47.8070602@toonk.nl> Message-ID: <201404031431.55306.mark.tinka@seacom.mu> On Thursday, April 03, 2014 02:22:44 AM Randy Bush wrote: > and, btw, how many of those whose prefixes were > mis-originated had registered those prefixes in the > rpki? It is probably a bit of a hammer at this stage, but we are in limited deployment of dropping all Invalids using RPKI. We shall be rolling out, network-wide, in 2014, where all Invalids are dropped. At this stage, short of a mis- origination, it's mostly longer prefixes of an aggregate that are not ROA'd. I was asleep when Indosat was mis-originating, but it'd have been nice to see what our test-bed was doing to any Indosat- injected prefixes that have ROA's. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Apr 3 12:41:39 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 14:41:39 +0200 Subject: BGPMON Alert Questions In-Reply-To: <533D5143.5060806@foobar.org> References: <533D4F7F.2070206@kenweb.org> <533D5143.5060806@foobar.org> Message-ID: <201404031441.39569.mark.tinka@seacom.mu> On Thursday, April 03, 2014 02:17:07 PM Nick Hilliard wrote: > Easy enough to do by e.g. redistributing your ebgp into > your IGP and then back again, or by a variety of other > means. It happened between 05:00 and 06:00 local time, > so it's reasonable to assume that it was maintenance > gone wrong. Horribly wrong. I wonder who we should be going after here? Indosat or their upstream? Probably both, since if this happened with an ISP deeper in the Internet core, chances are they don't have what our concept of an "upstream" is. "max-prefix" could have come in handy here. But this is an old song (let alone prefix filtering or RPKI). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From randy at psg.com Thu Apr 3 12:45:04 2014 From: randy at psg.com (Randy Bush) Date: Thu, 03 Apr 2014 21:45:04 +0900 Subject: BGPMON Alert Questions In-Reply-To: <201404031431.55306.mark.tinka@seacom.mu> References: <533C9A47.8070602@toonk.nl> <201404031431.55306.mark.tinka@seacom.mu> Message-ID: > It is probably a bit of a hammer at this stage, but we are > in limited deployment of dropping all Invalids using RPKI. > > We shall be rolling out, network-wide, in 2014, where all > Invalids are dropped. At this stage, short of a mis- > origination, it's mostly longer prefixes of an aggregate > that are not ROA'd. sadly, my (legacy) address space is in the arin region. and arin does not see allowing me to protect my prefixes from mis-origination as a serious goal. randy From randy at psg.com Thu Apr 3 12:51:20 2014 From: randy at psg.com (Randy Bush) Date: Thu, 03 Apr 2014 21:51:20 +0900 Subject: BGPMON Alert Questions In-Reply-To: <201404031441.39569.mark.tinka@seacom.mu> References: <533D4F7F.2070206@kenweb.org> <533D5143.5060806@foobar.org> <201404031441.39569.mark.tinka@seacom.mu> Message-ID: > I wonder who we should be going after here? Indosat or their > upstream? Probably both, since if this happened with an ISP > deeper in the Internet core, chances are they don't have > what our concept of an "upstream" is. you want revenge or to prevent the effects of recurrence? one nice thing about origin validation is that anyone who validates anywhere on the internet can reject the mis-origination(s). randy From alby.williams at verizon.com Thu Apr 3 12:52:16 2014 From: alby.williams at verizon.com (Anthony Williams) Date: Thu, 03 Apr 2014 08:52:16 -0400 Subject: BGPMON Alert Questions In-Reply-To: <201404031441.39569.mark.tinka@seacom.mu> References: <533D4F7F.2070206@kenweb.org> <533D5143.5060806@foobar.org> <201404031441.39569.mark.tinka@seacom.mu> Message-ID: <533D5980.3060109@one.verizon.com> Was a specific Upstream at fault or several upstream providers? It appears they have 9 upstream links -- http://www.cidr-report.org/cgi-bin/as-report?as=4761 On 4/3/2014 8:41 AM, Mark Tinka wrote: > I wonder who we should be going after here? Indosat or their > upstream? From nick at foobar.org Thu Apr 3 12:57:31 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 03 Apr 2014 13:57:31 +0100 Subject: BGPMON Alert Questions In-Reply-To: <201404031441.39569.mark.tinka@seacom.mu> References: <533D4F7F.2070206@kenweb.org> <533D5143.5060806@foobar.org> <201404031441.39569.mark.tinka@seacom.mu> Message-ID: <533D5ABB.7080601@foobar.org> On 03/04/2014 13:41, Mark Tinka wrote: > "max-prefix" could have come in handy here. But this is an > old song (let alone prefix filtering or RPKI). I'm currently seeing ~100 prefixes originating from 4761, and an additional 725 transited through 4761. This would not be difficult to handle with prefix lists, assuming some level of automation. Nick From mark.tinka at seacom.mu Thu Apr 3 13:15:14 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 15:15:14 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031441.39569.mark.tinka@seacom.mu> Message-ID: <201404031515.17889.mark.tinka@seacom.mu> On Thursday, April 03, 2014 02:51:20 PM Randy Bush wrote: > you want revenge or to prevent the effects of recurrence? I'd like to consider targeted suggestions for fixes that address the specific challenges affecting "seasoned" upstreams vs. their downstream customers. I can understand how an ISP with relatively little experience can mess this up (and glad to help here to educate wherever possible). But if an "established" provider is still struggling with this, why is that? > one nice thing about origin validation is that anyone who > validates anywhere on the internet can reject the > mis-origination(s). +1. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From johny at griffintechnology.com Thu Apr 3 13:30:16 2014 From: johny at griffintechnology.com (John York) Date: Thu, 3 Apr 2014 08:30:16 -0500 Subject: BGPMON Alert Questions In-Reply-To: References: <000c01cf4ea8$57623580$0626a080$@iname.com> <5AC5ADBA-EAFB-4312-9CB2-D5227C219463@mythostech.com> <2a65ae2ab7b5e2be72cb829d57acf438.squirrel@66.201.44.180> <533C785E.5060106@rollernet.us> <533C9A47.8070602@toonk.nl> Message-ID: <6b7153ac7fef20b55005f6ba8342c34b@mail.gmail.com> We have a registered prefix that was affected. The RPKI may have helped though; only one BGPMON peer saw the mis-originated route. Much better than being on the 10+ list. -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Wednesday, April 02, 2014 7:23 PM To: North American Network Operators' Group Subject: Re: BGPMON Alert Questions note joels careful use of 'injected'. imiho, 'hijacked' is perjorative implying evil intent. i very much doubt that is the case here. it looks much more like an accident. could we try to be less accusatory with our language. 'injected', 'mis-originated', ... would seem to descrive the situation. and, btw, how many of those whose prefixes were mis-originated had registered those prefixes in the rpki? randy This message and any attachments should be treated as confidential information of Griffin Technology, Inc. From morrowc.lists at gmail.com Thu Apr 3 13:55:11 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Apr 2014 09:55:11 -0400 Subject: BGPMON Alert Questions In-Reply-To: <201404031515.17889.mark.tinka@seacom.mu> References: <201404031441.39569.mark.tinka@seacom.mu> <201404031515.17889.mark.tinka@seacom.mu> Message-ID: On Thu, Apr 3, 2014 at 9:15 AM, Mark Tinka wrote: > On Thursday, April 03, 2014 02:51:20 PM Randy Bush wrote: > >> you want revenge or to prevent the effects of recurrence? > > I'd like to consider targeted suggestions for fixes that > address the specific challenges affecting "seasoned" > upstreams vs. their downstream customers. at this point it's hard to come up with a suggestion aside from: "stop being negligent" :( if after so many incidents and so many years, and seeing so many of your friends trip on the stairs and break an arm, you'd think providers would route-filter their customers just to avoid going to the hospital. > I can understand how an ISP with relatively little > experience can mess this up (and glad to help here to > educate wherever possible). But if an "established" provider > is still struggling with this, why is that? I'm going to guess: 1) who's going to pay for the filtering setup work? 2) we have always done it this way... why change? 3) adrenaline rush? >> one nice thing about origin validation is that anyone who >> validates anywhere on the internet can reject the >> mis-origination(s). > > +1. > > Mark. From mark.tinka at seacom.mu Thu Apr 3 14:12:29 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 16:12:29 +0200 Subject: BGPMON Alert Questions In-Reply-To: <533D5ABB.7080601@foobar.org> References: <201404031441.39569.mark.tinka@seacom.mu> <533D5ABB.7080601@foobar.org> Message-ID: <201404031612.32994.mark.tinka@seacom.mu> On Thursday, April 03, 2014 02:57:31 PM Nick Hilliard wrote: > I'm currently seeing ~100 prefixes originating from 4761, > and an additional 725 transited through 4761. This > would not be difficult to handle with prefix lists, > assuming some level of automation. Indeed. I, for example, have an upstream that filters only on AS_PATH. Naturally, we are quite aggressive and insistent about filtering both on AS_PATH and prefix list across interconnects to our downstreams, but if things were to blow up on our side, the upstream in question would not be protected (unless, of course, they are relying on "max- prefix" as well). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Apr 3 14:12:38 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 16:12:38 +0200 Subject: BGPMON Alert Questions In-Reply-To: <533D5980.3060109@one.verizon.com> References: <201404031441.39569.mark.tinka@seacom.mu> <533D5980.3060109@one.verizon.com> Message-ID: <201404031612.39048.mark.tinka@seacom.mu> On Thursday, April 03, 2014 02:52:16 PM Anthony Williams wrote: > Was a specific Upstream at fault or several upstream > providers? It appears they have 9 upstream links -- > http://www.cidr-report.org/cgi-bin/as-report?as=4761 There probably won't be only one provider at fault. It could be all an ISP's providers are at fault, or it could be that two providers along a single AS_PATH are simultaneously at fault. It's a big weakness of our Internet, but we still need to figure out the best way to fix it, until, at least, RPKI is more widely adopted. At this stage, it appears education, and implementation of that education, is our only recourse. But how do we do this at scale? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Thu Apr 3 15:05:05 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 17:05:05 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031515.17889.mark.tinka@seacom.mu> Message-ID: <201404031705.11205.mark.tinka@seacom.mu> On Thursday, April 03, 2014 03:55:11 PM Christopher Morrow wrote: > I'm going to guess: > 1) who's going to pay for the filtering setup work? Well, your customers are paying you to ensure they don't get cut off due to your negligence. You also don't want to become a "watch-out-for-that-one" peer within the community. But, perhaps those two ideals are not significant motivation for change :-\. > 2) we have always done it this way... why change? This is probably a more endemic issue of our industry, where operators find it hard to keep up with the times (there is no shortage of "-bis" or BCP documents) through actual useful implementation (BCP-38) vs. talk (SDN hype). In the case of nailing routing filters for customers, one thought that comes to mind is if your organization is large enough, throw a warm body at the issue. There are lots of interns or folk you can hire on a temporary basis to focus on cleaning all this up, and getting the NOC trained and clued up on the new strategy. The new strategy is not just shiny, it could actually save you loss of customers and community respect. But that's just me... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From morrowc.lists at gmail.com Thu Apr 3 15:13:40 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Apr 2014 11:13:40 -0400 Subject: BGPMON Alert Questions In-Reply-To: <201404031705.11205.mark.tinka@seacom.mu> References: <201404031515.17889.mark.tinka@seacom.mu> <201404031705.11205.mark.tinka@seacom.mu> Message-ID: On Thu, Apr 3, 2014 at 11:05 AM, Mark Tinka wrote: > On Thursday, April 03, 2014 03:55:11 PM Christopher Morrow > wrote: > >> I'm going to guess: >> 1) who's going to pay for the filtering setup work? > > Well, your customers are paying you to ensure they don't get > cut off due to your negligence. I think you mean they are paying me to carry their bits across the network... and they are paying me to do it with minimal hassle to THEM... telling me prefixes to add to their list is hassle. > You also don't want to become a "watch-out-for-that-one" > peer within the community. > sure... not sure how much that matters to higher-ups? there's no such thing as bad PR, right? > But, perhaps those two ideals are not significant motivation > for change :-\. apparently they are not. >> 2) we have always done it this way... why change? > > This is probably a more endemic issue of our industry, where > operators find it hard to keep up with the times (there is > no shortage of "-bis" or BCP documents) through actual > useful implementation (BCP-38) vs. talk (SDN hype). > > In the case of nailing routing filters for customers, one > thought that comes to mind is if your organization is large > enough, throw a warm body at the issue. There are lots of > interns or folk you can hire on a temporary basis to focus > on cleaning all this up, and getting the NOC trained and there's a salient point about training time and internal systems complexity to keep in mind here as well :( > clued up on the new strategy. The new strategy is not just > shiny, it could actually save you loss of customers and > community respect. agreed. > > But that's just me... it's not just you. From mark.tinka at seacom.mu Thu Apr 3 15:31:50 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 3 Apr 2014 17:31:50 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031705.11205.mark.tinka@seacom.mu> Message-ID: <201404031731.51367.mark.tinka@seacom.mu> On Thursday, April 03, 2014 05:13:40 PM Christopher Morrow wrote: > I think you mean they are paying me to carry their bits > across the network... and they are paying me to do it > with minimal hassle to THEM... telling me prefixes to > add to their list is hassle. Agree - but, as an operator, that is my problem. Not my customer's problem. > there's a salient point about training time and internal > systems complexity to keep in mind here as well :( The ground is littered with pot holes. They are everywhere you turn. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From lcaron at unix-scripts.info Thu Apr 3 16:44:58 2014 From: lcaron at unix-scripts.info (Laurent CARON) Date: Thu, 03 Apr 2014 18:44:58 +0200 Subject: Cisco warranty Message-ID: <533D900A.2010605@unix-scripts.info> Hi, I bought a C3750G-12S which is now end of sale on cisco website. This device is now defective. Since I bought it from a reseller and not directly from cisco, cisco is refusing to take it under warranty and tells me to have the reseller take care of it. The reseller doesnt wan't to hear about this device since it is end of sale. According to cisco website, end of sale means the device is still covered for 5 years. My question is: Is it normal for my supplier to refuse to take it under warranty ? Is there (from your experience) a chance I might get cisco to deal with it ? Thanks Laurent From michael at supermathie.net Thu Apr 3 17:26:58 2014 From: michael at supermathie.net (Michael Brown) Date: Thu, 03 Apr 2014 13:26:58 -0400 Subject: Cisco warranty In-Reply-To: <533D900A.2010605@unix-scripts.info> References: <533D900A.2010605@unix-scripts.info> Message-ID: <533D99E2.9090004@supermathie.net> On 14-04-03 12:44 PM, Laurent CARON wrote: > I bought a C3750G-12S which is now end of sale on cisco website. This > device is now defective. > > Since I bought it from a reseller and not directly from cisco, cisco > is refusing to take it under warranty and tells me to have the > reseller take care of it. > > The reseller doesnt wan't to hear about this device since it is end of > sale. Did you purchase SMARTnet when you bought the device? If you didn't, you're probably SOL. > According to cisco website, end of sale means the device is still > covered for 5 years. This is not base warranty - this is potential coverage. Base warranty is 90 days: http://www.cisco.com/go/warranty > My question is: Is it normal for my supplier to refuse to take it > under warranty? See above. > Is there (from your experience) a chance I might get cisco to deal > with it ? Not likely. Specific information for this product's EOL is here: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/eol_c51-696372.html You'll need to have a service contract associated with the device (SMARTnet). Unfortunately for you, from that page: End of New Service Attachment Date: January 30, 2014 "For equipment and software that is not covered by a service-and-support contract, this is the last date to order a new service-and-support contract or add the equipment and/or software to an existing service-and-support contract." So if you don't already have SMARTnet, you're probably out of luck. M. -- Michael Brown | The true sysadmin does not adjust his behaviour Systems Administrator | to fit the machine. He adjusts the machine michael at supermathie.net | until it behaves properly. With a hammer, | if necessary. - Brian From sfischer1967 at gmail.com Thu Apr 3 17:46:04 2014 From: sfischer1967 at gmail.com (Steven Fischer) Date: Thu, 3 Apr 2014 13:46:04 -0400 Subject: Cisco warranty In-Reply-To: <533D99E2.9090004@supermathie.net> References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> Message-ID: Another point to consider when purchasing Cisco gear - there is a difference between a "reseller", and an "Authorized Reseller". Without going into specifics, I had experience with a previous customer that purchased Cisco gear from a "reseller" - all On Thu, Apr 3, 2014 at 1:26 PM, Michael Brown wrote: > On 14-04-03 12:44 PM, Laurent CARON wrote: > > I bought a C3750G-12S which is now end of sale on cisco website. This > > device is now defective. > > > > Since I bought it from a reseller and not directly from cisco, cisco > > is refusing to take it under warranty and tells me to have the > > reseller take care of it. > > > > The reseller doesnt wan't to hear about this device since it is end of > > sale. > Did you purchase SMARTnet when you bought the device? If you didn't, > you're probably SOL. > > According to cisco website, end of sale means the device is still > > covered for 5 years. > This is not base warranty - this is potential coverage. Base warranty is > 90 days: http://www.cisco.com/go/warranty > > My question is: Is it normal for my supplier to refuse to take it > > under warranty? > See above. > > Is there (from your experience) a chance I might get cisco to deal > > with it ? > Not likely. > > Specific information for this product's EOL is here: > > http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/eol_c51-696372.html > > You'll need to have a service contract associated with the device > (SMARTnet). > > Unfortunately for you, from that page: > > End of New Service Attachment Date: January 30, 2014 > "For equipment and software that is not covered by a service-and-support > contract, this is the last date to order a new service-and-support > contract or add the equipment and/or software to an existing > service-and-support contract." > > So if you don't already have SMARTnet, you're probably out of luck. > > M. > > -- > Michael Brown | The true sysadmin does not adjust his behaviour > Systems Administrator | to fit the machine. He adjusts the machine > michael at supermathie.net | until it behaves properly. With a hammer, > | if necessary. - Brian > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From sfischer1967 at gmail.com Thu Apr 3 17:51:32 2014 From: sfischer1967 at gmail.com (Steven Fischer) Date: Thu, 3 Apr 2014 13:51:32 -0400 Subject: Cisco warranty In-Reply-To: References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> Message-ID: Another point to consider when purchasing Cisco gear - there is a HUGE difference between a "reseller", and an "Authorized Reseller". Without going into specifics, I had experience with a previous customer that purchased Cisco gear from a "reseller" - all refurbished/grey-market that Cisco had as located over in Europe. When the time came, Cisco didn't honor the warranty on the gear. A good "authorized reseller" should help you - not necessarily exchange the unit if you haven't purchased SmartNet, but give you something more than "go call Cisco". Cisco generally takes a dim view of resellers treating it's customers that way. Again, first hand experience... On Thu, Apr 3, 2014 at 1:46 PM, Steven Fischer wrote: > Another point to consider when purchasing Cisco gear - there is a > difference between a "reseller", and an "Authorized Reseller". Without > going into specifics, I had experience with a previous customer that > purchased Cisco gear from a "reseller" - all > > On Thu, Apr 3, 2014 at 1:26 PM, Michael Brown wrote: > >> On 14-04-03 12:44 PM, Laurent CARON wrote: >> > I bought a C3750G-12S which is now end of sale on cisco website. This >> > device is now defective. >> > >> > Since I bought it from a reseller and not directly from cisco, cisco >> > is refusing to take it under warranty and tells me to have the >> > reseller take care of it. >> > >> > The reseller doesnt wan't to hear about this device since it is end of >> > sale. >> Did you purchase SMARTnet when you bought the device? If you didn't, >> you're probably SOL. >> > According to cisco website, end of sale means the device is still >> > covered for 5 years. >> This is not base warranty - this is potential coverage. Base warranty is >> 90 days: http://www.cisco.com/go/warranty >> > My question is: Is it normal for my supplier to refuse to take it >> > under warranty? >> See above. >> > Is there (from your experience) a chance I might get cisco to deal >> > with it ? >> Not likely. >> >> Specific information for this product's EOL is here: >> >> http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/eol_c51-696372.html >> >> You'll need to have a service contract associated with the device >> (SMARTnet). >> >> Unfortunately for you, from that page: >> >> End of New Service Attachment Date: January 30, 2014 >> "For equipment and software that is not covered by a service-and-support >> contract, this is the last date to order a new service-and-support >> contract or add the equipment and/or software to an existing >> service-and-support contract." >> >> So if you don't already have SMARTnet, you're probably out of luck. >> >> M. >> >> -- >> Michael Brown | The true sysadmin does not adjust his behaviour >> Systems Administrator | to fit the machine. He adjusts the machine >> michael at supermathie.net | until it behaves properly. With a hammer, >> | if necessary. - Brian >> >> > > > -- > To him who is able to keep you from falling and to present you before his > glorious presence without fault and with great joy -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From Joshua_Sholes at cable.comcast.com Thu Apr 3 17:52:17 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Thu, 3 Apr 2014 17:52:17 +0000 Subject: Cisco warranty In-Reply-To: References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> Message-ID: Back about ten years and three companies ago when I was a baby System Administrator, I made that mistake. Suffice it to say that I HIGHLY recommend looking for the "authorized reseller" (and getting SMARTNet up-front--if nothing else, that process will generally reliably inform you as to Cisco's opinion of your reseller and/or the gear they're selling) -- Josh Sholes On 4/3/14, 1:46 PM, "Steven Fischer" wrote: >Another point to consider when purchasing Cisco gear - there is a >difference between a "reseller", and an "Authorized Reseller". Without >going into specifics, I had experience with a previous customer that >purchased Cisco gear from a "reseller" - all > >On Thu, Apr 3, 2014 at 1:26 PM, Michael Brown >wrote: > >> On 14-04-03 12:44 PM, Laurent CARON wrote: >> > I bought a C3750G-12S which is now end of sale on cisco website. This >> > device is now defective. >> > >> > Since I bought it from a reseller and not directly from cisco, cisco >> > is refusing to take it under warranty and tells me to have the >> > reseller take care of it. >> > >> > The reseller doesnt wan't to hear about this device since it is end of >> > sale. >> Did you purchase SMARTnet when you bought the device? If you didn't, >> you're probably SOL. >> > According to cisco website, end of sale means the device is still >> > covered for 5 years. >> This is not base warranty - this is potential coverage. Base warranty is >> 90 days: http://www.cisco.com/go/warranty >> > My question is: Is it normal for my supplier to refuse to take it >> > under warranty? >> See above. >> > Is there (from your experience) a chance I might get cisco to deal >> > with it ? >> Not likely. >> >> Specific information for this product's EOL is here: >> >> >>http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-s >>eries-switches/eol_c51-696372.html >> >> You'll need to have a service contract associated with the device >> (SMARTnet). >> >> Unfortunately for you, from that page: >> >> End of New Service Attachment Date: January 30, 2014 >> "For equipment and software that is not covered by a service-and-support >> contract, this is the last date to order a new service-and-support >> contract or add the equipment and/or software to an existing >> service-and-support contract." >> >> So if you don't already have SMARTnet, you're probably out of luck. >> >> M. >> >> -- >> Michael Brown | The true sysadmin does not adjust his >>behaviour >> Systems Administrator | to fit the machine. He adjusts the machine >> michael at supermathie.net | until it behaves properly. With a hammer, >> | if necessary. - Brian >> >> > > >-- >To him who is able to keep you from falling and to present you before his >glorious presence without fault and with great joy From ttauber at 1-4-5.net Thu Apr 3 18:31:08 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 3 Apr 2014 14:31:08 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031515.17889.mark.tinka@seacom.mu> <201404031705.11205.mark.tinka@seacom.mu> Message-ID: On Thu, Apr 3, 2014 at 11:13 AM, Christopher Morrow wrote: > On Thu, Apr 3, 2014 at 11:05 AM, Mark Tinka wrote: > > On Thursday, April 03, 2014 03:55:11 PM Christopher Morrow > > wrote: > > > >> I'm going to guess: > >> 1) who's going to pay for the filtering setup work? > > > > Well, your customers are paying you to ensure they don't get > > cut off due to your negligence. > > I think you mean they are paying me to carry their bits across the > network... > and they are paying me to do it with minimal hassle to THEM... telling > me prefixes to add to their list is hassle. > I know this old saw and sales people will apply pressure to Ops if their customers balk at the extra overhead. The time is now to push back, hard, against that practice. I realize you know this, Chris but are trying to characterize the mindset. > > The new strategy is not just > > shiny, it could actually save you loss of customers and > > community respect. > > agreed. > > > > > But that's just me... > > it's not just you Yes, let's seize the bull by the horns. Tony From nicotine at warningg.com Thu Apr 3 18:46:37 2014 From: nicotine at warningg.com (Brandon Ewing) Date: Thu, 3 Apr 2014 13:46:37 -0500 Subject: Cisco warranty In-Reply-To: <533D99E2.9090004@supermathie.net> References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> Message-ID: <20140403184637.GB14530@radiological.warningg.com> On Thu, Apr 03, 2014 at 01:26:58PM -0400, Michael Brown wrote: > Did you purchase SMARTnet when you bought the device? If you didn't, > you're probably SOL. This is not true. Cisco provides a limited lifetime warranty on hardware purchased from them or an authorized reseller, with our without SmartNet. For an example, browse to http://www.cisco-servicefinder.com/warrantyfinder.aspx and look up specific products. I looked up an WS-C3750G-48TS-S, and while the warranty does not cover support (TAC contracts do), there is a lifetime warranty good for 5 years from EoS with a 10 business day turnaround. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From morrowc.lists at gmail.com Thu Apr 3 18:58:23 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Apr 2014 14:58:23 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031515.17889.mark.tinka@seacom.mu> <201404031705.11205.mark.tinka@seacom.mu> Message-ID: On Thu, Apr 3, 2014 at 2:31 PM, Tony Tauber wrote: > On Thu, Apr 3, 2014 at 11:13 AM, Christopher Morrow > wrote: > I know this old saw and sales people will apply pressure to Ops if their > customers balk at the extra overhead. > The time is now to push back, hard, against that practice. > I realize you know this, Chris but are trying to characterize the mindset. > I agree with you (both tony and mark)... the mindset was the point, and getting over that is certainly something we all should do. -chris From charles at thefnf.org Thu Apr 3 20:52:40 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Thu, 03 Apr 2014 15:52:40 -0500 Subject: Starting a greenfield carrier backbone network that can scale to national and international service. What would you =?UTF-8?Q?do=3F?= Message-ID: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> Hello everyone, It's been some time since I've been subscribed/replied/posted here (or on WISPA for that matter). I've been pretty busy running a non profit startup (protip: don't do that. It's really really terrible) :) I'm cofounder and CTO of the Free Networking Foundation. Our goal is to bring broadband (5 mbps symmetric to start) bandwidth to the 2/3 of Americans who currently can't get it (rural, urban core, undeserved, "$ILEC stops on otherside of street" etc). Efforts so far primarily have consisted of WiFI last (square) mile delivery using Ubiquiti hardware and the qmp.cat firmware (also meraki access points that were donated, for some reason this seems to happen quite a bit). We've helped numerous networks get started, grow and (soon we hope) become self sustaining in Austin, Kansas City, Los Angeles, Detroit, New York and a few other places throughout the US. The networks are in various stages of maturity of course, but a number of them are fully operational and passing real traffic. Especially the one in Kansas City (it spans both states). These are (point to point, routed) access/distribution networks which connect into colocation providers blended networks. So that's the background and current state of affairs. Not really NANOG material. The next step is to secure our v6 space and AS number. Now that's not horribly difficult or really worthy of NANOG (though I do greatly appreciate folks on the list who helped me through the theory/practice of that process sometime ago). It appears to be fairly straightforward if you are not an LIR. Simply go through the paperwork (LOA, submit to ARIN, get out the credit card, textbook BGP config and done). And if FNF was operating the networks (we don't, we just help with organizing/consulting/software guidance/hardware spend optimization/logistics etc) and if there was just one POP (and associated administrative body), then again it wouldn't be that interesting or worth cluttering up NANOG. FNF goal is to serve as an LIR, SWIPing out /48 chunks to neighborhood level operators. They would then peer with whatever upstream ISPs are regionally close and announce out the space. This of course would be associated with a training program, registration in an IPAM tool etc. Regarding the above? What do the operators on this list wish they could of been trained in starting out? I mean obviously they should have good mastery and working experience of CCNA level material, along with exposure to higher level concepts of WAN networking. What are the tricks, the gotchas, the "man that would of saved my company a million bucks in transit costs". Yes I realize these sort of things are usually closely held. I also am striving to create an entirely new breed of operators running BGP enabled sites with ipv6. The more I can do to help ease those folks integration into the internet, the better. In short, the often debated issue on this list of v6 endpoint explosion is going to be very very very real. What IPAM tools out there can scale to a multi hundred million node, distributed, "eventual consistency" national level? (I've been working closely with guifi.net, and we are attempting to relaunch that as a very slick Apple like experience with a libremap (couchdb based) system. I'd love to hear from folks across the spectrum of experience and network size. From folks who have been dual homed for <~1 year at a single site, to tier1 operators who were there when it all started. So what would you like to see done in a greenfield, open source, open governance carrier backbone network? What would a dream TIER1 (and I use that in the default free zone sense of the word) look like to you? Also how the heck would one get this bootstrapped at a sustainable pace? Would one create numerous tier2 regional carriers, and they would feed into an over arching tier1? I'm thinking something like a 501c8 type structure ( http://www.irs.gov/Charities-&-Non-Profits/Other-Non-Profits/Fraternal-Societies[1] ) As far as I know, this is the first time that an intentional community type approach is taken and a tier1 is the end goal. Not evolving into one, buying ones way into it, but a manifest destiny type approach to building a backbone. Please feel free to reach out to me directly (charles at thefnf.org[2] ) if you wish to have a one on one discussion. In particular I'm interested in legal expertise in these sort of areas (law/compliance/contracting/negotiations for right of way etc etc etc). Thanks for reading. I look forward to the discussion! PS: Yes, I'm young and idealistic. I'm also grounded/practical/focused. I'm currently working on making the access portion of the network as smooth and turnkey as possible. (That basically means packaging up zeroshell/observium/powerdns/libremap/trigger and other bits/bobs into a nice livecd/ova/openvz package). I also like to think about the next wave of issues while working on the current one. It will take another year or so before we need to really be building out the backbone (if nothing else, to link up the rapidly growing regional networks). This is about physical, layer 1 infrastructure. This isn't yet another overlay network (CJDNS/GNu FreeNet etc). Yes it's messy, yes it's all about non technical end users, yes it's about taking a rather complex stack (auth/network awareness/routing platform) and making it accessible to power users/"IT professionals". It's also a whole lot of fun! Please feel free to visit us at https://www.thefnf.org for more information. From dhubbard at dino.hostasaurus.com Thu Apr 3 22:55:02 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 3 Apr 2014 18:55:02 -0400 Subject: Recommendation on NTP appliances/devices Message-ID: Anyone have recommendations on NTP appliances; i.e. make, model, gps vs cell, etc.? Roof/outdoor/window access not available. Would ideally need to be able to handle bursts of up to a few thousand simultaneous queries. Needs IPv6 support. Thanks! From jason at lixfeld.ca Thu Apr 3 23:12:31 2014 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 3 Apr 2014 19:12:31 -0400 Subject: Anyone from AS577 and AS852 in the house? Message-ID: <2519F648-CFBF-4317-863D-2904A290FBE4@lixfeld.ca> Bell and Telus, if you're listening - I need to inquire about BGP community support on your respective networks that cannot be addressed by info published in RADB, by our assigned AM, SE, your NOC or any support documentation on your respective websites on the subject. Please hit me up off-list. Thanks in advance! From msa at latt.net Thu Apr 3 23:16:08 2014 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 3 Apr 2014 19:16:08 -0400 Subject: Recommendation on NTP appliances/devices In-Reply-To: References: Message-ID: <20140403231608.GC14529@puck.nether.net> On Thu, Apr 03, 2014 at 06:55:02PM -0400, David Hubbard wrote: > Anyone have recommendations on NTP appliances; i.e. make, model, gps vs > cell, etc.? Roof/outdoor/window access not available. Would ideally > need to be able to handle bursts of up to a few thousand simultaneous > queries. Needs IPv6 support. Without roof access I'd suggest CDMA instead of GPS: http://www.endruntechnologies.com/ntp-server.htm Appears to fit your requirements. --msa From randy at psg.com Thu Apr 3 23:28:15 2014 From: randy at psg.com (Randy Bush) Date: Fri, 04 Apr 2014 08:28:15 +0900 Subject: BGPMON Alert Questions In-Reply-To: <201404031515.17889.mark.tinka@seacom.mu> References: <201404031441.39569.mark.tinka@seacom.mu> <201404031515.17889.mark.tinka@seacom.mu> Message-ID: >> one nice thing about origin validation is that anyone who validates >> anywhere on the internet can reject the mis-origination(s). > +1. a non-op sec person who follows nanog in read-only mode pointed out in private email that this is a subtle difference from prefix filtering. in general, i can not prefix filter N hops away. randy From mysidia at gmail.com Thu Apr 3 23:51:48 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 3 Apr 2014 18:51:48 -0500 Subject: Cisco warranty In-Reply-To: <20140403184637.GB14530@radiological.warningg.com> References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> <20140403184637.GB14530@radiological.warningg.com> Message-ID: On Thu, Apr 3, 2014 at 1:46 PM, Brandon Ewing wrote: > On Thu, Apr 03, 2014 at 01:26:58PM -0400, Michael Brown wrote: > > Did you purchase SMARTnet when you bought the device? If you didn't, > > you're probably SOL. > This is not true. Cisco provides a limited lifetime warranty on hardware > purchased from them or an authorized reseller, with our without SmartNet. > On some: not all their hardware, they offer limited lifetime warranty. Lifetime is the exception to the rule: many of their components are 90 days or 1 year. The "limited" bit is also important --- they have restrictions in fine print. It's strongly recommended you buy their SmartNet, if you want their reps to treat you reasonably and make efforts to fulfill your paper warranty. Getting the manufacturer rep to actually honor the paper warranty and allow you an RMA, when there is no paid support.... is another thing altogether. May require a great deal of persistence on your part, As in continuing to contact Cisco and refusing to take "NO" as an acceptable answer to your RMA request. Or it may just not happen.... > > For an example, browse to > http://www.cisco-servicefinder.com/warrantyfinder.aspx and look up > specific > products. I looked up an WS-C3750G-48TS-S, and while the warranty does not > cover support (TAC contracts do), there is a lifetime warranty good for 5 > years from EoS with a 10 business day turnaround. > > -- > Brandon Ewing ( > nicotine at warningg.com) > -- -JH From berry at gadsdenst.org Fri Apr 4 00:02:59 2014 From: berry at gadsdenst.org (Berry Mobley) Date: Thu, 03 Apr 2014 20:02:59 -0400 Subject: Recommendation on NTP appliances/devices Message-ID: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> We have symmetricom (now microsemi) and are very happy with them, but we use the roof mounted gps antennas. They will peer with public ntp severs if that would work for you. David Hubbard wrote: >Anyone have recommendations on NTP appliances; i.e. make, model, gps vs >cell, etc.? Roof/outdoor/window access not available. Would ideally >need to be able to handle bursts of up to a few thousand simultaneous >queries. Needs IPv6 support. > >Thanks! > From randy at psg.com Fri Apr 4 00:50:28 2014 From: randy at psg.com (Randy Bush) Date: Fri, 04 Apr 2014 09:50:28 +0900 Subject: BGPMON Alert Questions In-Reply-To: <8B9D122A1836AF4BB23B7966A4EABEC20887AA7B@pcscmail001.MUTUALTEL.MTCNET.NET> References: <201404031441.39569.mark.tinka@seacom.mu> <201404031515.17889.mark.tinka@seacom.mu> <8B9D122A1836AF4BB23B7966A4EABEC20887AA7B@pcscmail001.MUTUALTEL.MTCNET.NET> Message-ID: > Good point, which makes me ask: So which 5 to 10 networks, > implementing source validation, could result in the greatest > "coverage" or "protection" for the largest part of the Internet to the best of my knowledge, no one has looked at this for origin validation. sharon goldberg and co-conspirators have done a lot of work in the area, see her pubs at https://www.cs.bu.edu/~goldbe/. but the concentration seems to be on bgpsec which deploys quite differently randy From bross at pobox.com Fri Apr 4 01:50:19 2014 From: bross at pobox.com (Brandon Ross) Date: Thu, 3 Apr 2014 21:50:19 -0400 (EDT) Subject: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do? In-Reply-To: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> References: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> Message-ID: Let's start with your basic assumption here. Why would you build a backbone at all if your goal is to solve last mile problems? It seems to me that the expense and distraction of building a large backbone network doesn't contribute to your goals at all, given that there are many high quality, nationwide backbone networks in North America today available at reasonable cost. On Thu, 3 Apr 2014, charles at thefnf.org wrote: > Hello everyone, > > It's been some time since I've been subscribed/replied/posted here (or on > WISPA for that matter). I've been pretty busy running a non profit startup > (protip: don't do that. It's really really terrible) :) I'm cofounder and CTO > of the Free Networking Foundation. Our goal is to bring broadband (5 mbps > symmetric to start) bandwidth to the 2/3 of Americans who currently can't get > it (rural, urban core, undeserved, "$ILEC stops on otherside of street" etc). > > Efforts so far primarily have consisted of WiFI last (square) mile delivery > using Ubiquiti hardware and the qmp.cat firmware (also meraki access points > that were donated, for some reason this seems to happen quite a bit). We've > helped numerous networks get started, grow and (soon we hope) become self > sustaining in Austin, Kansas City, Los Angeles, Detroit, New York and a few > other places throughout the US. The networks are in various stages of > maturity of course, but a number of them are fully operational and passing > real traffic. Especially the one in Kansas City (it spans both states). > > These are (point to point, routed) access/distribution networks which connect > into colocation providers blended networks. > > So that's the background and current state of affairs. Not really NANOG > material. > > The next step is to secure our v6 space and AS number. Now that's not > horribly difficult or really worthy of NANOG (though I do greatly appreciate > folks on the list who helped me through the theory/practice of that process > sometime ago). It appears to be fairly straightforward if you are not an LIR. > Simply go through the paperwork (LOA, submit to ARIN, get out the credit > card, textbook BGP config and done). And if FNF was operating the networks > (we don't, we just help with organizing/consulting/software guidance/hardware > spend optimization/logistics etc) and if there was just one POP (and > associated administrative body), then again it wouldn't be that interesting > or worth cluttering up NANOG. > > FNF goal is to serve as an LIR, SWIPing out /48 chunks to neighborhood level > operators. They would then peer with whatever upstream ISPs are regionally > close and announce out the space. This of course would be associated with a > training program, registration in an IPAM tool etc. > > Regarding the above? > > What do the operators on this list wish they could of been trained in > starting out? I mean obviously they should have good mastery and working > experience of CCNA level material, along with exposure to higher level > concepts of WAN networking. What are the tricks, the gotchas, the "man that > would of saved my company a million bucks in transit costs". Yes I realize > these sort of things are usually closely held. I also am striving to create > an entirely new breed of operators running BGP enabled sites with ipv6. The > more I can do to help ease those folks integration into the internet, the > better. In short, the often debated issue on this list of v6 endpoint > explosion is going to be very very very real. > > What IPAM tools out there can scale to a multi hundred million node, > distributed, "eventual consistency" national level? (I've been working > closely with guifi.net, and we are attempting to relaunch that as a very > slick Apple like experience with a libremap (couchdb based) system. > > I'd love to hear from folks across the spectrum of experience and network > size. From folks who have been dual homed for <~1 year at a single site, to > tier1 operators who were there when it all started. > > So what would you like to see done in a greenfield, open source, open > governance carrier backbone network? What would a dream TIER1 (and I use that > in the default free zone sense of the word) look like to you? > > Also how the heck would one get this bootstrapped at a sustainable pace? > Would one create numerous tier2 regional carriers, and they would feed into > an over arching tier1? I'm thinking something like a 501c8 type structure ( > http://www.irs.gov/Charities-&-Non-Profits/Other-Non-Profits/Fraternal-Societies[1] > ) > > As far as I know, this is the first time that an intentional community type > approach is taken and a tier1 is the end goal. Not evolving into one, buying > ones way into it, but a manifest destiny type approach to building a > backbone. > > Please feel free to reach out to me directly (charles at thefnf.org[2] ) if you > wish to have a one on one discussion. In particular I'm interested in legal > expertise in these sort of areas (law/compliance/contracting/negotiations for > right of way etc etc etc). > > Thanks for reading. I look forward to the discussion! > > PS: Yes, I'm young and idealistic. I'm also grounded/practical/focused. I'm > currently working on making the access portion of the network as smooth and > turnkey as possible. (That basically means packaging up > zeroshell/observium/powerdns/libremap/trigger and other bits/bobs into a nice > livecd/ova/openvz package). I also like to think about the next wave of > issues while working on the current one. It will take another year or so > before we need to really be building out the backbone (if nothing else, to > link up the rapidly growing regional networks). > > This is about physical, layer 1 infrastructure. This isn't yet another > overlay network (CJDNS/GNu FreeNet etc). Yes it's messy, yes it's all about > non technical end users, yes it's about taking a rather complex stack > (auth/network awareness/routing platform) and making it accessible to power > users/"IT professionals". It's also a whole lot of fun! > > > Please feel free to visit us at https://www.thefnf.org for more information. > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From rs at seastrom.com Fri Apr 4 02:25:07 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 03 Apr 2014 22:25:07 -0400 Subject: Recommendation on NTP appliances/devices In-Reply-To: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> (Berry Mobley's message of "Thu, 03 Apr 2014 20:02:59 -0400") References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> Message-ID: <868url96gs.fsf@valhalla.seastrom.com> On a tangential note, it's all very nice to say "We have brand X and like them", but I'd be curious to hear from folks who have deployed at least four divergent brands with non-overlapping GPS chip sets and software [*] to keep a conspiracy of errors from causing the time to suddenly be massively incorrect. Not that this has ever happened in the past in a single vendor configuration [cough]. Along the same lines I'm troubled by the lack of divergent sources these days - everything seems slaved to GPS either directly or indirectly (might be nice to have stuff out there that got its time exclusively via Galileo or Glonass). The sole exception that I can think of offhand is that I have an office within ground wave of WWVB, which would be a tasty ingredient. GOES is gone. LORAN is defunded. And so it goes; all our eggs are in one basket. I've thought about posting this request to the NTP developers list, but maybe someone who's an operator and actually cares about keeping the byzantine generals sequestered from each other has solved this problem recently. Clues? -r [*] to the extent possible; I'm sure that there's a lot of reference implementation DNA floating around out there) Berry Mobley writes: > We have symmetricom (now microsemi) and are very happy with them, but we use the roof mounted gps antennas. They will peer with public ntp severs if that would work for you. > > David Hubbard wrote: > >>Anyone have recommendations on NTP appliances; i.e. make, model, gps vs >>cell, etc.? Roof/outdoor/window access not available. Would ideally >>need to be able to handle bursts of up to a few thousand simultaneous >>queries. Needs IPv6 support. >> >>Thanks! >> From cma at cmadams.net Fri Apr 4 02:32:26 2014 From: cma at cmadams.net (Chris Adams) Date: Thu, 3 Apr 2014 21:32:26 -0500 Subject: Recommendation on NTP appliances/devices In-Reply-To: <868url96gs.fsf@valhalla.seastrom.com> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> Message-ID: <20140404023226.GA4063@cmadams.net> Once upon a time, Rob Seastrom said: > Along the same lines I'm troubled by the lack of divergent sources > these days - everything seems slaved to GPS either directly or > indirectly (might be nice to have stuff out there that got its time > exclusively via Galileo or Glonass). Since you mentioned GLONASS: it had a 10+ hour outage yesterday, apparently due to a bad ephemeris upload. Did anybody have a GLONASS-using NTP server experience problems? -- Chris Adams From goldbe at cs.bu.edu Fri Apr 4 03:06:22 2014 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Thu, 3 Apr 2014 23:06:22 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031441.39569.mark.tinka@seacom.mu> <201404031515.17889.mark.tinka@seacom.mu> <8B9D122A1836AF4BB23B7966A4EABEC20887AA7B@pcscmail001.MUTUALTEL.MTCNET.NET> Message-ID: On Thu, Apr 3, 2014 at 8:50 PM, Randy Bush wrote: > > > Good point, which makes me ask: So which 5 to 10 networks, > > implementing source validation, could result in the greatest > > "coverage" or "protection" for the largest part of the Internet > > to the best of my knowledge, no one has looked at this for origin > validation. sharon goldberg and co-conspirators have done a lot > of work in the area, see her pubs at https://www.cs.bu.edu/~goldbe/. > but the concentration seems to be on bgpsec which deploys quite > differently Right, we (and others) have not looked at the efficacy of a partial deployment of origin validation (using the RPKI) yet. But, we did look at partial deployments of BGPSEC. We found that a large number of networks (around 50% of ASes) need to deploy BGPSEC before its security benefits really kick in. The reasons for this include (1) routing policies during partial deployment might not prioritize the BGPSEC validity over its AS path or local pref, (2) you need every node on an AS path to deploy BGPSEC before it works. Full paper here: https://www.cs.bu.edu/~goldbe/papers/partialSec.pdf We also looked at prefix filtering and found that it has better partial deployment characteristics. Our analysis assumed that ISPs only filter routes from their *stub* customers. (We defined a stub an AS that does not have its own customers.) Then we looked at the fraction of attacks that would be eliminated, if the X largest ISPs correctly implemented prefix filtering. ("Large" was measured in terms of the number of customers ASes the ISP had.) See Figure 18 on pg 15 of this paper, and the text explaining it in the middle of the right column on pg 15: http://research.microsoft.com/pubs/120428/BGPAttack-full.pdf Finally, like Randy says, RPKI deploys quite different from BGPSEC. My intuition says that (1) once the RPKI is fully populated with ROAs for all originated prefixes, then (2) a partial deployment of origin validation at a few large ISPs should be fairly effective. But I would have to validate this with experiments before I can be sure, or say exactly how many ISPs, etc. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe From rs at seastrom.com Fri Apr 4 03:46:57 2014 From: rs at seastrom.com (Rob Seastrom) Date: Thu, 03 Apr 2014 23:46:57 -0400 Subject: Recommendation on NTP appliances/devices In-Reply-To: <20140404023226.GA4063@cmadams.net> (Chris Adams's message of "Thu, 3 Apr 2014 21:32:26 -0500") References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> Message-ID: <86d2gx21u6.fsf@valhalla.seastrom.com> Chris Adams writes: > Once upon a time, Rob Seastrom said: >> Along the same lines I'm troubled by the lack of divergent sources >> these days - everything seems slaved to GPS either directly or >> indirectly (might be nice to have stuff out there that got its time >> exclusively via Galileo or Glonass). > > Since you mentioned GLONASS: it had a 10+ hour outage yesterday, > apparently due to a bad ephemeris upload. Did anybody have a > GLONASS-using NTP server experience problems? It would be the height of arrogance to think that this couldn't happen to GPS. I want redundancy. -r From george.herbert at gmail.com Fri Apr 4 04:06:57 2014 From: george.herbert at gmail.com (George Herbert) Date: Thu, 3 Apr 2014 21:06:57 -0700 Subject: Recommendation on NTP appliances/devices In-Reply-To: <86d2gx21u6.fsf@valhalla.seastrom.com> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> Message-ID: On Thu, Apr 3, 2014 at 8:46 PM, Rob Seastrom wrote: > > Chris Adams writes: > > > Once upon a time, Rob Seastrom said: > >> Along the same lines I'm troubled by the lack of divergent sources > >> these days - everything seems slaved to GPS either directly or > >> indirectly (might be nice to have stuff out there that got its time > >> exclusively via Galileo or Glonass). > > > > Since you mentioned GLONASS: it had a 10+ hour outage yesterday, > > apparently due to a bad ephemeris upload. Did anybody have a > > GLONASS-using NTP server experience problems? > > It would be the height of arrogance to think that this couldn't happen to > GPS. > > I want redundancy. > Sadly, right now that either means your own real clock, or WWV. The cellphone time is (as far as I know, for the networks I saw data on) all coming off GPS. Fortunately real clocks are coming way down in cost. So the question is, if you want redundancy, what do your failure modes look like. Is some low level drift if GPS goes away and stays away for an extended period OK? In that case, redundancy probably would be a single local high grade clock. Do you want multi-vendor-common-mode-failure-resistant low drift if GPS goes away? In that case, you probably need 3 local clocks. Possibly 4, if you want to be able to down one for maintenance and still have 3 operating when the fit hits the shan, so that if one of the remaining ones drifts you know which of the 3 is out of whack and to exclude from the "live source". Just two operating and you're SOL on figuring out which one is off. This is why spacecraft and aircraft often have 3 or 4 of each critical thing; 3 gets you "only fly with all 3 working" and the ability to detect the bad instrument; 4 lets you fly with one down for maintenance and still have safe redundant operation, increasing dispatch reliability. -- -george william herbert george.herbert at gmail.com From bmanning at vacation.karoshi.com Fri Apr 4 04:24:01 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 3 Apr 2014 21:24:01 -0700 Subject: Recommendation on NTP appliances/devices In-Reply-To: <868url96gs.fsf@valhalla.seastrom.com> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> Message-ID: <20140404042401.GA2224@vacation.karoshi.com> Loves my old Heathkit WWVB unit. Keeps drift in check most days. Pairs nicely with the Spectracom 9383. Looking at the Microsemi TP-5000 w/ rubidium oscillator. /bill On Thu, Apr 03, 2014 at 10:25:07PM -0400, Rob Seastrom wrote: > > On a tangential note, it's all very nice to say "We have brand X and > like them", but I'd be curious to hear from folks who have deployed at > least four divergent brands with non-overlapping GPS chip sets and > software [*] to keep a conspiracy of errors from causing the time to > suddenly be massively incorrect. Not that this has ever happened in > the past in a single vendor configuration [cough]. > > Along the same lines I'm troubled by the lack of divergent sources > these days - everything seems slaved to GPS either directly or > indirectly (might be nice to have stuff out there that got its time > exclusively via Galileo or Glonass). The sole exception that I can > think of offhand is that I have an office within ground wave of WWVB, > which would be a tasty ingredient. GOES is gone. LORAN is defunded. > And so it goes; all our eggs are in one basket. > > I've thought about posting this request to the NTP developers list, > but maybe someone who's an operator and actually cares about keeping > the byzantine generals sequestered from each other has solved this > problem recently. > > Clues? > > -r > > > [*] to the extent possible; I'm sure that there's a lot of reference > implementation DNA floating around out there) > > > Berry Mobley writes: > > > We have symmetricom (now microsemi) and are very happy with them, but we use the roof mounted gps antennas. They will peer with public ntp severs if that would work for you. > > > > David Hubbard wrote: > > > >>Anyone have recommendations on NTP appliances; i.e. make, model, gps vs > >>cell, etc.? Roof/outdoor/window access not available. Would ideally > >>need to be able to handle bursts of up to a few thousand simultaneous > >>queries. Needs IPv6 support. > >> > >>Thanks! > >> From will at loopfree.net Fri Apr 4 04:25:27 2014 From: will at loopfree.net (Will Orton) Date: Thu, 3 Apr 2014 21:25:27 -0700 Subject: Recommendation on NTP appliances/devices In-Reply-To: References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> Message-ID: <20140404042527.GA11474@loopfree.net> On Thu, Apr 03, 2014 at 09:06:57PM -0700, George Herbert wrote: > Sadly, right now that either means your own real clock, or WWV. The > cellphone time is (as far as I know, for the networks I saw data on) all > coming off GPS. > > Fortunately real clocks are coming way down in cost. There are commercially available NTP servers with GPS + Rb oscillators... for NTP use you could basically let it sync up a couple days, disconnect the GPS and let it freerun. You'd still be within a millisecond of GPS even after a couple years most likely. Reconnect it to GPS for a couple days every 1-2 years to resync it. More fun and cheaper to build your own I'd bet, if you had the time. With clocks/oscillators designed to provide hold-over for synchronous networks and microwave RF systems (parts per million or billion) the demands of NTP for general use in an IP network are pretty modest. You lose more accuracy in NTP stratum 1->2 across a (relaively) jittery WAN link than a cheap atomic clock does in a long time. -Will From mark.tinka at seacom.mu Fri Apr 4 05:15:25 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 4 Apr 2014 07:15:25 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <201404040715.25878.mark.tinka@seacom.mu> On Friday, April 04, 2014 05:06:22 AM Sharon Goldberg wrote: > We also looked at prefix filtering and found that it has > better partial deployment characteristics. Our analysis > assumed that ISPs only filter routes from their *stub* > customers. (We defined a stub an AS that does not have > its own customers.) Just curious; in your considerations, how would/did you treat cases where ISP's filter their downstreams, to include their downstream's downstreams? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From saku at ytti.fi Fri Apr 4 06:29:22 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 4 Apr 2014 09:29:22 +0300 Subject: Recommendation on NTP appliances/devices In-Reply-To: <20140404042527.GA11474@loopfree.net> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> <20140404042527.GA11474@loopfree.net> Message-ID: <20140404062922.GA24655@pob.ytti.fi> On (2014-04-03 21:25 -0700), Will Orton wrote: > There are commercially available NTP servers with GPS + Rb oscillators... for NTP > use you could basically let it sync up a couple days, disconnect the GPS and let > it freerun. You'd still be within a millisecond of GPS even after a couple years > most likely. Reconnect it to GPS for a couple days every 1-2 years to resync it. > More fun and cheaper to build your own I'd bet, if you had the time. Meinberg[0] pegs rubidium at ?8ms per year, if you need NTP to do say single direction backbone SLA measurement you want to have microsecond precision. I think most GPS chipsets today do Glonass also, maybe it's partly because Russia has import sanctions for those who don't do, or maybe simply because it gives better user experience as sync is found earlier. But is there NTP product which you can configure to GPS-only mode or Glonass-only mode, which I think might be closer to Rob's idea of redundancy. As if you use both, 'poisoned' source would break all of your kit. But that is probably not easy to solve with two sources, if half is GPS and half is Glonass, and Glonass starts sending bad timing information, what do your NTP clients do, average to the middle? [0] http://www.meinbergglobal.com/english/specs/gpsopt.htm -- ++ytti From lcaron at unix-scripts.info Fri Apr 4 07:42:29 2014 From: lcaron at unix-scripts.info (Laurent CARON) Date: Fri, 04 Apr 2014 09:42:29 +0200 Subject: Cisco warranty In-Reply-To: References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> <20140403184637.GB14530@radiological.warningg.com> Message-ID: <533E6265.9050101@unix-scripts.info> On 04/04/2014 01:51, Jimmy Hess wrote: > On Thu, Apr 3, 2014 at 1:46 PM, Brandon Ewing wrote: > >> On Thu, Apr 03, 2014 at 01:26:58PM -0400, Michael Brown wrote: >>> Did you purchase SMARTnet when you bought the device? If you didn't, >>> you're probably SOL. >> This is not true. Cisco provides a limited lifetime warranty on hardware >> purchased from them or an authorized reseller, with our without SmartNet. >> > > On some: not all their hardware, they offer limited lifetime warranty. > Lifetime is the exception to the rule: many of their components are 90 days > or 1 year. > The "limited" bit is also important --- they have restrictions in fine > print. > > It's strongly recommended you buy their SmartNet, if you want their reps to > treat you reasonably and make efforts to fulfill your paper warranty. > Getting the manufacturer rep to actually honor the paper warranty and allow > you an RMA, when there is no paid support.... is another thing altogether. > > May require a great deal of persistence on your part, > As in continuing to contact Cisco and refusing to take "NO" as an > acceptable answer to your RMA request. > > Or it may just not happen.... My device is indeed supposedly covered by a lifetime warranty. Since I'm still in the timeframe of less than 5 years after EOS...it should be good...should. Never experienced such a bad service from Juniper or 3COM/H3C/HP From adam.vitkovsky at swan.sk Fri Apr 4 07:58:42 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Fri, 4 Apr 2014 07:58:42 +0000 Subject: BGPMON Alert Questions In-Reply-To: <201404031404.44935.mark.tinka@seacom.mu> References: <201404031404.44935.mark.tinka@seacom.mu> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011D70D4@EX01.swan.local> > That Upstream B is simply "accepting everything" > their customer is sending to them without applying proper filters, or checking > to confirm that what their customer needs to send them should come from > them is absolutely and unacceptably shocking! I wonder when (or if ever) we'll have such a discussion about data packets, i.e. finding that someone is not doing packet-filtering based on BGP updates is absolutely and unacceptably shocking! adam From simon at slimey.org Fri Apr 4 08:09:27 2014 From: simon at slimey.org (Simon Lockhart) Date: Fri, 4 Apr 2014 09:09:27 +0100 Subject: Cisco warranty In-Reply-To: <533E6265.9050101@unix-scripts.info> References: <533D900A.2010605@unix-scripts.info> <533D99E2.9090004@supermathie.net> <20140403184637.GB14530@radiological.warningg.com> <533E6265.9050101@unix-scripts.info> Message-ID: <20140404080926.GX5282@virtual.bogons.net> On Fri Apr 04, 2014 at 09:42:29AM +0200, Laurent CARON wrote: > My device is indeed supposedly covered by a lifetime warranty. Since I'm > still in the timeframe of less than 5 years after EOS...it should be > good...should. The *Limited* Lifetime Warranty is only offered to the original purchaser of the equipment from Cisco. If you're registered with Cisco as the purchaser, there's no reason they wouldn't honour it. If you're not, because the person you bought it off is registered as the original purchaser, then you'd need to go through that person/company to get the warranty from Cisco. Simon From nanog at studio442.com.au Fri Apr 4 09:37:54 2014 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 04 Apr 2014 20:37:54 +1100 Subject: Recommendation on NTP appliances/devices In-Reply-To: <20140404062922.GA24655@pob.ytti.fi> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> <20140404042527.GA11474@loopfree.net> <20140404062922.GA24655@pob.ytti.fi> Message-ID: <533E7D72.2010408@studio442.com.au> On 04/04/14 17:29, Saku Ytti wrote: > On (2014-04-03 21:25 -0700), Will Orton wrote: > >> There are commercially available NTP servers with GPS + Rb oscillators... for NTP >> use you could basically let it sync up a couple days, disconnect the GPS and let >> it freerun. You'd still be within a millisecond of GPS even after a couple years >> most likely. Reconnect it to GPS for a couple days every 1-2 years to resync it. >> More fun and cheaper to build your own I'd bet, if you had the time. > > Meinberg[0] pegs rubidium at ?8ms per year, if you need NTP to do say single > direction backbone SLA measurement you want to have microsecond precision. Those two statements don't go together. Also outside the HFTers most of us don't care about a few milliseconds (sure an extra 50ms can be a pain, but is trivial to measure). It's one thing to be a time-nut (I'm certainly one), but recognise that straight NTP, well deployed, even syncing from the pool is sufficient for nearly all use cases not needing sub-millisecond precision. > I think most GPS chipsets today do Glonass also, maybe it's partly because > Russia has import sanctions for those who don't do, or maybe simply because it > gives better user experience as sync is found earlier. > > But is there NTP product which you can configure to GPS-only mode or > Glonass-only mode, which I think might be closer to Rob's idea of redundancy. > As if you use both, 'poisoned' source would break all of your kit. > But that is probably not easy to solve with two sources, if half is GPS and > half is Glonass, and Glonass starts sending bad timing information, what do > your NTP clients do, average to the middle? > > [0] http://www.meinbergglobal.com/english/specs/gpsopt.htm > From nanog at studio442.com.au Fri Apr 4 09:38:21 2014 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 04 Apr 2014 20:38:21 +1100 Subject: Recommendation on NTP appliances/devices In-Reply-To: <20140403231608.GC14529@puck.nether.net> References: <20140403231608.GC14529@puck.nether.net> Message-ID: <533E7D8D.5090602@studio442.com.au> On 04/04/14 10:16, Majdi S. Abbas wrote: > On Thu, Apr 03, 2014 at 06:55:02PM -0400, David Hubbard wrote: >> Anyone have recommendations on NTP appliances; i.e. make, model, gps vs >> cell, etc.? Roof/outdoor/window access not available. Would ideally >> need to be able to handle bursts of up to a few thousand simultaneous >> queries. Needs IPv6 support. > > Without roof access I'd suggest CDMA instead of GPS: > > http://www.endruntechnologies.com/ntp-server.htm > > Appears to fit your requirements. > > --msa > The downside of CDMA is it's going to live until Verizon & Sprint can get enough of their customers migrated to LTE. It really depends on how accurate you need to be. If you only want <10ms accuracy but stable (It's trivial to get all clients better than 1ms) then grab three to five old servers (or new low-power ones), and just put ntpd on them, pointing at some nearby upstreams. If it *must* be an appliance the Symmetricom units are nice, and support IPv6 (have done for years). From wmaton at ottix.net Fri Apr 4 10:18:25 2014 From: wmaton at ottix.net (William F. Maton Sotomayor) Date: Fri, 4 Apr 2014 06:18:25 -0400 (EDT) Subject: Recommendation on NTP appliances/devices In-Reply-To: References: Message-ID: On Thu, 3 Apr 2014, David Hubbard wrote: > Anyone have recommendations on NTP appliances; i.e. make, model, gps vs > cell, etc.? Roof/outdoor/window access not available. Would ideally > need to be able to handle bursts of up to a few thousand simultaneous > queries. Needs IPv6 support. For some diversity you could try: - WWVB/CHU radio with a good indoor antenna into an appliance - CDMA, which yes is based on GPS, but tied with Rb oscillator can carry over any reception outages (CDMA or GPS) - Of course just setup an NTP server that peers to pool.ntp.org (but perphaps the least desirable) I've seen good results using the Endrun CDMA units as well as the WWVB units, both appliances and IPv6-enabled. Symmetricom does this too. wfms From benno at NLnetLabs.nl Fri Apr 4 10:31:35 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 04 Apr 2014 12:31:35 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031441.39569.mark.tinka@seacom.mu> <201404031515.17889.mark.tinka@seacom.mu> <8B9D122A1836AF4BB23B7966A4EABEC20887AA7B@pcscmail001.MUTUALTEL.MTCNET.NET> Message-ID: <533E8A07.30704@NLnetLabs.nl> On 04/04/2014 05:06 AM, Sharon Goldberg wrote: > Finally, like Randy says, RPKI deploys quite different from BGPSEC. My > intuition says that (1) once the RPKI is fully populated with ROAs for all > originated prefixes, then (2) a partial deployment of origin validation at > a few large ISPs should be fairly effective. But I would have to validate > this with experiments before I can be sure, or say exactly how many ISPs, > etc. Indeed. A MSc. project did a (limited) evaluation measuring the effects of RPKI route origin validation of a Dutch ISP xs4all which prefixes where incorrectly injected by another (larger according to CAIDA cone ranking) European ISP. With ROAs published and a small percentage (order of 5%) of the largest ISPs doing route origin validation, this would filter the incorrect announcement and result in about ~98% globally correct routes in the 35000 ASes (this work is done a couple years ago). With no route origin validation (or any other filtering) the percentage of correct routes at the ASes would be ~25% globally. Again, this was a specific scenario. See for results and figures the slides at http://www.caida.org/workshops/bgp-traceroute/slides/bgp-traceroute1108_rpki_deployment_study.pdf (slide 18). Best, -- Benno -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From saku at ytti.fi Fri Apr 4 10:48:52 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 4 Apr 2014 13:48:52 +0300 Subject: Recommendation on NTP appliances/devices In-Reply-To: <533E7D72.2010408@studio442.com.au> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> <20140404042527.GA11474@loopfree.net> <20140404062922.GA24655@pob.ytti.fi> <533E7D72.2010408@studio442.com.au> Message-ID: <20140404104852.GA26950@pob.ytti.fi> On (2014-04-04 20:37 +1100), Julien Goodwin wrote: > > Meinberg[0] pegs rubidium at ?8ms per year, if you need NTP to do say single > > direction backbone SLA measurement you want to have microsecond precision. > > Those two statements don't go together. Point I was making is that free-running rubidium is not accurate enough for QoS measurements of IP core. > Also outside the HFTers most of us don't care about a few milliseconds > (sure an extra 50ms can be a pain, but is trivial to measure). Jitter in backbone is low tens of microseconds, if you want to measure how that changes over time, free-running rubidium is not going to cut it. -- ++ytti From daniel.crompton at gmail.com Fri Apr 4 11:54:55 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Fri, 4 Apr 2014 13:54:55 +0200 Subject: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do? In-Reply-To: References: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> Message-ID: I recently saw an interesting talk about this at 30c3, this is the way some French ISPs are solving this: http://media.ccc.de/browse/congress/2013/30C3_-_5391_-_en_-_saal_6_-_201312291130_-_y_u_no_isp_taking_back_the_net_-_taziden.html D. Oplerno is built upon empowering faculty and students -- Dani?l W. Crompton http://specialbrands.net/ On 4 April 2014 03:50, Brandon Ross wrote: > Let's start with your basic assumption here. Why would you build a > backbone at all if your goal is to solve last mile problems? > > It seems to me that the expense and distraction of building a large > backbone network doesn't contribute to your goals at all, given that there > are many high quality, nationwide backbone networks in North America today > available at reasonable cost. > > > On Thu, 3 Apr 2014, charles at thefnf.org wrote: > > Hello everyone, >> >> It's been some time since I've been subscribed/replied/posted here (or on >> WISPA for that matter). I've been pretty busy running a non profit startup >> (protip: don't do that. It's really really terrible) :) I'm cofounder and >> CTO of the Free Networking Foundation. Our goal is to bring broadband (5 >> mbps symmetric to start) bandwidth to the 2/3 of Americans who currently >> can't get it (rural, urban core, undeserved, "$ILEC stops on otherside of >> street" etc). >> >> Efforts so far primarily have consisted of WiFI last (square) mile >> delivery using Ubiquiti hardware and the qmp.cat firmware (also meraki >> access points that were donated, for some reason this seems to happen quite >> a bit). We've helped numerous networks get started, grow and (soon we hope) >> become self sustaining in Austin, Kansas City, Los Angeles, Detroit, New >> York and a few other places throughout the US. The networks are in various >> stages of maturity of course, but a number of them are fully operational >> and passing real traffic. Especially the one in Kansas City (it spans both >> states). >> >> These are (point to point, routed) access/distribution networks which >> connect into colocation providers blended networks. >> >> So that's the background and current state of affairs. Not really NANOG >> material. >> >> The next step is to secure our v6 space and AS number. Now that's not >> horribly difficult or really worthy of NANOG (though I do greatly >> appreciate folks on the list who helped me through the theory/practice of >> that process sometime ago). It appears to be fairly straightforward if you >> are not an LIR. Simply go through the paperwork (LOA, submit to ARIN, get >> out the credit card, textbook BGP config and done). And if FNF was >> operating the networks (we don't, we just help with >> organizing/consulting/software guidance/hardware spend >> optimization/logistics etc) and if there was just one POP (and associated >> administrative body), then again it wouldn't be that interesting or worth >> cluttering up NANOG. >> >> FNF goal is to serve as an LIR, SWIPing out /48 chunks to neighborhood >> level operators. They would then peer with whatever upstream ISPs are >> regionally close and announce out the space. This of course would be >> associated with a training program, registration in an IPAM tool etc. >> >> Regarding the above? >> >> What do the operators on this list wish they could of been trained in >> starting out? I mean obviously they should have good mastery and working >> experience of CCNA level material, along with exposure to higher level >> concepts of WAN networking. What are the tricks, the gotchas, the "man that >> would of saved my company a million bucks in transit costs". Yes I realize >> these sort of things are usually closely held. I also am striving to create >> an entirely new breed of operators running BGP enabled sites with ipv6. The >> more I can do to help ease those folks integration into the internet, the >> better. In short, the often debated issue on this list of v6 endpoint >> explosion is going to be very very very real. >> >> What IPAM tools out there can scale to a multi hundred million node, >> distributed, "eventual consistency" national level? (I've been working >> closely with guifi.net, and we are attempting to relaunch that as a very >> slick Apple like experience with a libremap (couchdb based) system. >> >> I'd love to hear from folks across the spectrum of experience and network >> size. From folks who have been dual homed for <~1 year at a single site, to >> tier1 operators who were there when it all started. >> >> So what would you like to see done in a greenfield, open source, open >> governance carrier backbone network? What would a dream TIER1 (and I use >> that in the default free zone sense of the word) look like to you? >> >> Also how the heck would one get this bootstrapped at a sustainable pace? >> Would one create numerous tier2 regional carriers, and they would feed into >> an over arching tier1? I'm thinking something like a 501c8 type structure ( >> http://www.irs.gov/Charities-&-Non-Profits/Other-Non- >> Profits/Fraternal-Societies[1] ) >> >> As far as I know, this is the first time that an intentional community >> type approach is taken and a tier1 is the end goal. Not evolving into one, >> buying ones way into it, but a manifest destiny type approach to building a >> backbone. >> >> Please feel free to reach out to me directly (charles at thefnf.org[2] ) if >> you wish to have a one on one discussion. In particular I'm interested in >> legal expertise in these sort of areas (law/compliance/contracting/negotiations >> for right of way etc etc etc). >> >> Thanks for reading. I look forward to the discussion! >> >> PS: Yes, I'm young and idealistic. I'm also grounded/practical/focused. >> I'm currently working on making the access portion of the network as smooth >> and turnkey as possible. (That basically means packaging up >> zeroshell/observium/powerdns/libremap/trigger and other bits/bobs into a >> nice livecd/ova/openvz package). I also like to think about the next wave >> of issues while working on the current one. It will take another year or so >> before we need to really be building out the backbone (if nothing else, to >> link up the rapidly growing regional networks). >> >> This is about physical, layer 1 infrastructure. This isn't yet another >> overlay network (CJDNS/GNu FreeNet etc). Yes it's messy, yes it's all about >> non technical end users, yes it's about taking a rather complex stack >> (auth/network awareness/routing platform) and making it accessible to power >> users/"IT professionals". It's also a whole lot of fun! >> >> >> Please feel free to visit us at https://www.thefnf.org for more >> information. >> >> > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Skype: > brandonross > Schedule a meeting: http://www.doodle.com/bross > > From nanog at studio442.com.au Fri Apr 4 13:03:29 2014 From: nanog at studio442.com.au (Julien Goodwin) Date: Sat, 05 Apr 2014 00:03:29 +1100 Subject: Recommendation on NTP appliances/devices In-Reply-To: <20140404104852.GA26950@pob.ytti.fi> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> <20140404042527.GA11474@loopfree.net> <20140404062922.GA24655@pob.ytti.fi> <533E7D72.2010408@studio442.com.au> <20140404104852.GA26950@pob.ytti.fi> Message-ID: <533EADA1.9060001@studio442.com.au> On 04/04/14 21:48, Saku Ytti wrote: > On (2014-04-04 20:37 +1100), Julien Goodwin wrote: > >>> Meinberg[0] pegs rubidium at ?8ms per year, if you need NTP to do say single >>> direction backbone SLA measurement you want to have microsecond precision. >> >> Those two statements don't go together. > > Point I was making is that free-running rubidium is not accurate enough for > QoS measurements of IP core. Free running oscillators are fine as long as you know what the actual specs are (and have the unit measured to that). >> Also outside the HFTers most of us don't care about a few milliseconds >> (sure an extra 50ms can be a pain, but is trivial to measure). > > Jitter in backbone is low tens of microseconds, if you want to measure how > that changes over time, free-running rubidium is not going to cut it. What you'd actually measure is a side affect of buffer depth at any point. Show my anything short of a classic SONET transmission system (or perhaps sync-E) where you actually have something with jitter that low. So what, that sends IP packets, are you using to *measure* it. I can imagine using an FPGA hard clocked to a reference oscillator (and even a TCXO is good enough) doing it, but I'm not aware of any actual implementation of this. Again, short of the HFT world I just can't imagine how this could actually matter. From saku at ytti.fi Fri Apr 4 13:24:57 2014 From: saku at ytti.fi (Saku Ytti) Date: Fri, 4 Apr 2014 16:24:57 +0300 Subject: Recommendation on NTP appliances/devices In-Reply-To: <533EADA1.9060001@studio442.com.au> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> <20140404042527.GA11474@loopfree.net> <20140404062922.GA24655@pob.ytti.fi> <533E7D72.2010408@studio442.com.au> <20140404104852.GA26950@pob.ytti.fi> <533EADA1.9060001@studio442.com.au> Message-ID: <20140404132457.GA15957@pob.ytti.fi> > So what, that sends IP packets, are you using to *measure* it. I can Agilent if we need unidir. Normal run-of-the-mill 10GE SP router will give you low single digit microsecond jitter when not congested. (You can run 99.99% no problem, as long as you don't try >100% (i.e. >1 interface sending)). We only do bidir for constant measurements of network, unidir is unfortunately only for troubleshooting case-by-case. It would be very nice to always have unidir view to the network, but cost/benefit is not there if you have lot of pops. -- ++ytti From mark at amplex.net Fri Apr 4 14:08:32 2014 From: mark at amplex.net (Mark Radabaugh) Date: Fri, 04 Apr 2014 10:08:32 -0400 Subject: Starting a greenfield carrier backbone network that can scale to national and international service. What would you do? In-Reply-To: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> References: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> Message-ID: <533EBCE0.5000804@amplex.net> On 4/3/14, 4:52 PM, charles at thefnf.org wrote: > Hello everyone, > > It's been some time since I've been subscribed/replied/posted here (or > on WISPA for that matter). I've been pretty busy running a non profit > startup (protip: don't do that. It's really really terrible) :) I'm > cofounder and CTO of the Free Networking Foundation. Our goal is to > bring broadband (5 mbps symmetric to start) bandwidth to the 2/3 of > Americans who currently can't get it (rural, urban core, undeserved, > "$ILEC stops on otherside of street" etc). > > > Please feel free to visit us at https://www.thefnf.org for more > information. > I'm equally confused. Last mile is much more of a problem than backbone. I run a (for a WISP) mid size end user network. Raw bandwidth cost is <8% of our expenses. Last mile delivery and transport around our own network is the expensive part. Nearly all of the action in new last mile networks is wireless or small provider FTTx deployments. I would look at what WISPA (www.wispa.org) is doing, as well at the FTTH council (www.ftthcouncil.com) to see what is being done in last mile. The FCC and Agriculture departments is also heavily involved in rural and last mile deployments and is (depending on your view) either funding these deployments, distorting the markets by discouraging private investment, or wasting lots of money. Mark -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 x 1021 From charles at thefnf.org Fri Apr 4 14:29:52 2014 From: charles at thefnf.org (charles at thefnf.org) Date: Fri, 04 Apr 2014 09:29:52 -0500 Subject: Starting a greenfield carrier backbone network that can scale to national and international service. What would you =?UTF-8?Q?do=3F?= In-Reply-To: <533EBCE0.5000804@amplex.net> References: <719da7aea55abbbbc310c6482c80a0ce@thefnf.org> <533EBCE0.5000804@amplex.net> Message-ID: On 2014-04-04 09:08, Mark Radabaugh wrote: > On 4/3/14, 4:52 PM, charles at thefnf.org wrote: >> Hello everyone, >> >> It's been some time since I've been subscribed/replied/posted here (or >> on WISPA for that matter). I've been pretty busy running a non profit >> startup (protip: don't do that. It's really really terrible) :) I'm >> cofounder and CTO of the Free Networking Foundation. Our goal is to >> bring broadband (5 mbps symmetric to start) bandwidth to the 2/3 of >> Americans who currently can't get it (rural, urban core, undeserved, >> "$ILEC stops on otherside of street" etc). >> >> >> Please feel free to visit us at https://www.thefnf.org for more >> information. >> > I'm equally confused. Last mile is much more of a problem than > backbone. Quite true. This is why we've started there, and it's been our primary focus. We have more work to do of course. However efforts are promising and ongoing. I run a (for a WISP) mid size end user network. Raw > bandwidth cost is <8% of our expenses. Nice. That's not horrible. You have an AS/ip space? Or buying blended? Last mile delivery and > transport around our own network is the expensive part. Yes. It certainly is. Gear, end user support, truck rolls etc. > > Nearly all of the action in new last mile networks is wireless or > small provider FTTx deployments. I would look at what WISPA > (www.wispa.org) is doing, Yes. I'm quite connected with the WISPA folks, especially the principals. as well at the FTTH council > (www.ftthcouncil.com) Wasn't familiar with them. Thanks! to see what is being done in last mile. The > FCC and Agriculture departments is also heavily involved in rural and > last mile deployments and is (depending on your view) either funding > these deployments, distorting the markets by discouraging private > investment, or wasting lots of money. Yeah. I've been keeping an eye on that. We've helped several network builds happen via grants. Usually from local economic development councils. From goldbe at cs.bu.edu Fri Apr 4 15:17:36 2014 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Fri, 4 Apr 2014 11:17:36 -0400 Subject: BGPMON Alert Questions In-Reply-To: <201404040715.25878.mark.tinka@seacom.mu> References: <201404040715.25878.mark.tinka@seacom.mu> Message-ID: On Fri, Apr 4, 2014 at 1:15 AM, Mark Tinka wrote: > On Friday, April 04, 2014 05:06:22 AM Sharon Goldberg wrote: > > > We also looked at prefix filtering and found that it has > > better partial deployment characteristics. Our analysis > > assumed that ISPs only filter routes from their *stub* > > customers. (We defined a stub an AS that does not have > > its own customers.) > > Just curious; in your considerations, how would/did you > treat cases where ISP's filter their downstreams, to include > their downstream's downstreams? > Right, we didn't include that in our analysis because we didn't have a good sense for how many ISPs actually do filter their downstream downstreams. So we chose to give a conservative estimate of the impact of prefix filtering in partial deployment: we assumed that no one filters their downstreams downstreams. I'm honestly not sure exactly what including this assumption would do to our results, except to say that it would make them better (ie. that more attacks would be stopped). Might be a good experiment for one of my summer interns. Actually, since this is NANOG, might as well ask: Do you all view filtering your downstream's downstreams as much more difficult than filtering only downstreams, or only stub ASes? Do you have a sense for how many networks filter only their direct downstreams but no further, versus those that also filter downstreams downstreams? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe From nick at foobar.org Fri Apr 4 15:31:42 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 04 Apr 2014 16:31:42 +0100 Subject: BGPMON Alert Questions In-Reply-To: References: <201404040715.25878.mark.tinka@seacom.mu> Message-ID: <533ED05E.2050500@foobar.org> On 04/04/2014 16:17, Sharon Goldberg wrote: > we assumed that no one filters their downstreams downstreams. plenty of organisations do this. it can easily be done with irrdb AS sets. Nick From goldbe at cs.bu.edu Fri Apr 4 15:51:45 2014 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Fri, 4 Apr 2014 11:51:45 -0400 Subject: BGPMON Alert Questions In-Reply-To: References: <201404040715.25878.mark.tinka@seacom.mu> Message-ID: On Fri, Apr 4, 2014 at 11:17 AM, Sharon Goldberg wrote> > > > Actually, since this is NANOG, might as well ask: > > Do you all view filtering your downstream's downstreams as much more > difficult than filtering only downstreams, or only stub ASes? Do you have > a sense for how many networks filter only their direct downstreams but no > further, versus those that also filter downstreams downstreams? > I set up a quick anonymous survey (2 questions) to gather some info on this. If you have a minute, go here: https://docs.google.com/forms/d/1x6Bbe7OYvuWeOzO8xpxbIZzW3N14wI1SVVbQer4FSa4/viewform We will share our anonymized results on NANOG. Thanks, Sharon From dan-nanog at drown.org Fri Apr 4 15:57:24 2014 From: dan-nanog at drown.org (Dan Drown) Date: Fri, 04 Apr 2014 10:57:24 -0500 Subject: Recommendation on NTP appliances/devices In-Reply-To: <533EADA1.9060001@studio442.com.au> References: <1nt31ig431jvce5ivy7lf5uw.1396569779378@email.android.com> <868url96gs.fsf@valhalla.seastrom.com> <20140404023226.GA4063@cmadams.net> <86d2gx21u6.fsf@valhalla.seastrom.com> <20140404042527.GA11474@loopfree.net> <20140404062922.GA24655@pob.ytti.fi> <533E7D72.2010408@studio442.com.au> <20140404104852.GA26950@pob.ytti.fi> <533EADA1.9060001@studio442.com.au> Message-ID: <20140404105724.39565oaouac0kxgc@mail.drown.org> Quoting Julien Goodwin : > Show my anything short of a classic SONET transmission system (or > perhaps sync-E) where you actually have something with jitter that > low [tens of microseconds]. Since you asked, here you go: http://i.imgur.com/DvMJd5y.png Two EndRun Unison GPS NTP servers, one in New York metro and one in London metro. They're connected via 10G over dark fiber (along with a bunch of networking gear doing more than just measuring time). Measurements taken from ntp running on the New York server, the blue line is the offset between the two clocks (in ms, left labels) and the pink line is the rtt (in ms, right labels). 90th percentile of the offsets is 34 microseconds, and 10th percentile is 5 microseconds. You can see a spike in one-way latency near sample "590". Most likely culprit is of one of the firewalls being busy (there's two in this path). From cscora at apnic.net Fri Apr 4 18:14:02 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Apr 2014 04:14:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201404041814.s34IE2G4020974@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Apr, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 491178 Prefixes after maximum aggregation: 192805 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 242078 Total ASes present in the Internet Routing Table: 46547 Prefixes per ASN: 10.55 Origin-only ASes present in the Internet Routing Table: 35729 Origin ASes announcing only one prefix: 16379 Transit ASes present in the Internet Routing Table: 6052 Transit-only ASes present in the Internet Routing Table: 172 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1892 Unregistered ASNs in the Routing Table: 474 Number of 32-bit ASNs allocated by the RIRs: 6323 Number of 32-bit ASNs visible in the Routing Table: 4766 Prefixes from 32-bit ASNs in the Routing Table: 15525 Number of bogon 32-bit ASNs visible in the Routing Table: 78 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 446 Number of addresses announced to Internet: 2665473028 Equivalent to 158 /8s, 223 /16s and 228 /24s Percentage of available address space announced: 72.0 Percentage of allocated address space announced: 72.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.0 Total number of prefixes smaller than registry allocations: 171352 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 116725 Total APNIC prefixes after maximum aggregation: 34817 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 119479 Unique aggregates announced from the APNIC address blocks: 49894 APNIC Region origin ASes present in the Internet Routing Table: 4915 APNIC Prefixes per ASN: 24.31 APNIC Region origin ASes announcing only one prefix: 1229 APNIC Region transit ASes present in the Internet Routing Table: 850 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 891 Number of APNIC addresses announced to Internet: 730414720 Equivalent to 43 /8s, 137 /16s and 62 /24s Percentage of available APNIC address space announced: 85.4 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 167494 Total ARIN prefixes after maximum aggregation: 83096 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 168900 Unique aggregates announced from the ARIN address blocks: 78489 ARIN Region origin ASes present in the Internet Routing Table: 16209 ARIN Prefixes per ASN: 10.42 ARIN Region origin ASes announcing only one prefix: 6112 ARIN Region transit ASes present in the Internet Routing Table: 1671 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 80 Number of ARIN addresses announced to Internet: 1069441152 Equivalent to 63 /8s, 190 /16s and 96 /24s Percentage of available ARIN address space announced: 56.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 123273 Total RIPE prefixes after maximum aggregation: 62194 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 127488 Unique aggregates announced from the RIPE address blocks: 80791 RIPE Region origin ASes present in the Internet Routing Table: 17658 RIPE Prefixes per ASN: 7.22 RIPE Region origin ASes announcing only one prefix: 8283 RIPE Region transit ASes present in the Internet Routing Table: 2873 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2686 Number of RIPE addresses announced to Internet: 657873284 Equivalent to 39 /8s, 54 /16s and 89 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 55600 Total LACNIC prefixes after maximum aggregation: 10002 LACNIC Deaggregation factor: 5.56 Prefixes being announced from the LACNIC address blocks: 61721 Unique aggregates announced from the LACNIC address blocks: 28279 LACNIC Region origin ASes present in the Internet Routing Table: 2085 LACNIC Prefixes per ASN: 29.60 LACNIC Region origin ASes announcing only one prefix: 550 LACNIC Region transit ASes present in the Internet Routing Table: 427 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1089 Number of LACNIC addresses announced to Internet: 154294400 Equivalent to 9 /8s, 50 /16s and 88 /24s Percentage of available LACNIC address space announced: 92.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12458 Total AfriNIC prefixes after maximum aggregation: 2659 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 13144 Unique aggregates announced from the AfriNIC address blocks: 4247 AfriNIC Region origin ASes present in the Internet Routing Table: 717 AfriNIC Prefixes per ASN: 18.33 AfriNIC Region origin ASes announcing only one prefix: 205 AfriNIC Region transit ASes present in the Internet Routing Table: 152 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 20 Number of AfriNIC addresses announced to Internet: 53136640 Equivalent to 3 /8s, 42 /16s and 205 /24s Percentage of available AfriNIC address space announced: 52.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2963 11582 897 Korea Telecom 17974 2780 903 78 PT Telekomunikasi Indonesia 7545 2230 320 116 TPG Telecom Limited 4755 1844 396 197 TATA Communications formerly 9829 1618 1288 35 National Internet Backbone 4808 1365 2226 386 CNCGROUP IP network China169 9583 1317 102 534 Sify Limited 9498 1252 313 82 BHARTI Airtel Ltd. 7552 1223 1082 13 Viettel Corporation 24560 1123 384 177 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3005 3688 53 BellSouth.net Inc. 22773 2412 2938 140 Cox Communications Inc. 1785 2188 696 126 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1699 1679 576 Charter Communications 4323 1636 1074 415 tw telecom holdings, inc. 701 1482 11156 753 MCI Communications Services, 30036 1395 301 545 Mediacom Communications Corp 6983 1327 800 307 ITC^Deltacom 22561 1304 402 232 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1674 544 16 OJSC "Vimpelcom" 34984 1556 263 279 TELLCOM ILETISIM HIZMETLERI A 20940 1278 486 963 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1017 45 21 Freenet Ltd. 8551 965 370 41 Bezeq International-Ltd 6849 830 360 30 JSC "Ukrtelecom" 6830 763 2329 426 Liberty Global Operations B.V 12479 714 797 56 France Telecom Espana SA 35228 554 246 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3672 1948 97 NET Servi?os de Comunica??o S 10620 2817 451 205 Telmex Colombia S.A. 18881 1923 972 21 Global Village Telecom 7303 1753 1173 229 Telecom Argentina S.A. 8151 1395 2922 405 Uninet S.A. de C.V. 6503 1154 434 61 Axtel, S.A.B. de C.V. 7738 914 1754 40 Telemar Norte Leste S.A. 27947 864 114 50 Telconet S.A 11830 844 364 15 Instituto Costarricense de El 3816 792 320 129 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1637 240 6 Sudanese Mobile Telephone (ZA 24863 948 280 26 Link Egypt (Link.NET) 6713 612 721 27 Office National des Postes et 8452 567 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 284 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt 29571 218 22 18 Cote d'Ivoire Telecom 37054 215 23 11 Data Telecom Service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3672 1948 97 NET Servi?os de Comunica??o S 6389 3005 3688 53 BellSouth.net Inc. 4766 2963 11582 897 Korea Telecom 10620 2817 451 205 Telmex Colombia S.A. 17974 2780 903 78 PT Telekomunikasi Indonesia 22773 2412 2938 140 Cox Communications Inc. 7545 2230 320 116 TPG Telecom Limited 1785 2188 696 126 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1923 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3005 2952 BellSouth.net Inc. 17974 2780 2702 PT Telekomunikasi Indonesia 10620 2817 2612 Telmex Colombia S.A. 22773 2412 2272 Cox Communications Inc. 7545 2230 2114 TPG Telecom Limited 4766 2963 2066 Korea Telecom 1785 2188 2062 PaeTec Communications, Inc. 18881 1923 1902 Global Village Telecom 18566 2047 1869 MegaPath Corporation 8402 1674 1658 OJSC "Vimpelcom" Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:30 /11:90 /12:257 /13:478 /14:954 /15:1660 /16:12904 /17:6802 /18:11542 /19:24042 /20:33931 /21:36636 /22:52400 /23:45878 /24:261200 /25:846 /26:1001 /27:420 /28:13 /29:19 /30:8 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1695 3005 BellSouth.net Inc. 22773 1650 2412 Cox Communications Inc. 36998 1599 1637 Sudanese Mobile Telephone (ZA 8402 1349 1674 OJSC "Vimpelcom" 30036 1233 1395 Mediacom Communications Corp 11492 1182 1230 CABLE ONE, INC. 1785 1166 2188 PaeTec Communications, Inc. 6983 1044 1327 ITC^Deltacom 34984 1023 1556 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1020 2:704 3:3 4:15 5:925 6:19 8:721 12:1858 13:4 14:971 15:13 16:2 17:31 18:21 20:35 23:775 24:1736 25:1 27:1779 31:1524 32:40 33:2 34:5 36:128 37:1830 38:942 39:4 40:197 41:3249 42:245 44:15 46:2184 47:18 49:682 50:918 52:12 54:46 55:6 57:27 58:1169 59:604 60:390 61:1530 62:1247 63:1989 64:4350 65:2271 66:4167 67:2057 68:1033 69:3319 70:843 71:452 72:1988 74:2646 75:314 76:426 77:1467 78:1031 79:718 80:1309 81:1142 82:733 83:742 84:706 85:1235 86:438 87:1194 88:521 89:1793 90:140 91:5753 92:663 93:1699 94:2066 95:1524 96:540 97:350 98:1074 99:46 100:50 101:835 103:4566 105:536 106:169 107:583 108:561 109:2053 110:981 111:1285 112:656 113:846 114:880 115:1109 116:1065 117:875 118:1389 119:1333 120:372 121:802 122:1909 123:1290 124:1466 125:1460 128:660 129:322 130:352 131:652 132:386 133:163 134:318 135:74 136:249 137:321 138:353 139:167 140:211 141:356 142:569 143:427 144:500 145:103 146:614 147:440 148:923 149:349 150:161 151:599 152:423 153:219 154:243 155:471 156:336 157:339 158:239 159:881 160:344 161:478 162:1301 163:222 164:682 165:613 166:281 167:605 168:1025 169:124 170:1313 171:191 172:21 173:1650 174:688 175:616 176:1474 177:2863 178:1977 179:653 180:1680 181:1091 182:1529 183:510 184:705 185:1472 186:2790 187:1489 188:1914 189:1452 190:7415 191:165 192:7187 193:5471 194:4025 195:3372 196:1399 197:1137 198:5008 199:5621 200:6074 201:2641 202:9041 203:8911 204:4679 205:2694 206:2960 207:2981 208:4004 209:3729 210:3101 211:1707 212:2225 213:2074 214:900 215:85 216:5525 217:1694 218:582 219:319 220:1282 221:594 222:351 223:617 End of report From cidr-report at potaroo.net Fri Apr 4 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Apr 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201404042200.s34M00w3007474@wattle.apnic.net> This report has been generated at Fri Apr 4 21:13:45 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 28-03-14 492834 278076 29-03-14 492942 278137 30-03-14 493047 278044 31-03-14 493219 278056 01-04-14 493216 278233 02-04-14 493055 278223 03-04-14 493267 278669 04-04-14 494011 279075 AS Summary 46697 Number of ASes in routing system 19082 Number of ASes announcing only one prefix 3673 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 119829504 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 04Apr14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 494763 279040 215723 43.6% All ASes AS28573 3673 360 3313 90.2% NET Servi?os de Comunica??o S.A.,BR AS6389 3004 56 2948 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2781 235 2546 91.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2963 906 2057 69.4% KIXS-AS-KR Korea Telecom,KR AS18881 1923 35 1888 98.2% Global Village Telecom,BR AS1785 2188 473 1715 78.4% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS36998 1637 166 1471 89.9% SDN-MOBITEL,SD AS4323 2944 1522 1422 48.3% TWTC - tw telecom holdings, inc.,US AS10620 2817 1497 1320 46.9% Telmex Colombia S.A.,CO AS7303 1753 458 1295 73.9% Telecom Argentina S.A.,AR AS4755 1844 616 1228 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2231 1087 1144 51.3% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1224 125 1099 89.8% VIETEL-AS-AP Viettel Corporation,VN AS22561 1304 241 1063 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1327 314 1013 76.3% ITCDELTA - Earthlink, Inc.,US AS22773 2413 1427 986 40.9% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4808 1365 424 941 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS9829 1618 708 910 56.2% BSNL-NIB National Internet Backbone,IN AS24560 1123 297 826 73.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS18101 920 165 755 82.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1405 658 747 53.2% Uninet S.A. de C.V.,MX AS7738 914 182 732 80.1% Telemar Norte Leste S.A.,BR AS701 1482 753 729 49.2% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 762 57 705 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4788 1014 315 699 68.9% TMNET-AS-AP TM Net, Internet Service Provider,MY AS6147 782 113 669 85.5% Telefonica del Peru S.A.A.,PE AS4780 1031 367 664 64.4% SEEDNET Digital United Inc.,TW AS31148 1017 367 650 63.9% FREENET-AS Freenet Ltd.,UA AS8551 965 321 644 66.7% BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone,IL Total 52471 14810 37661 71.8% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/23 AS37451 CongoTelecom,CG 41.190.74.0/23 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.217.208.0/22 AS37158 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.119.240.0/22 AS26072 -Reserved AS-,ZZ 64.119.240.0/23 AS26072 -Reserved AS-,ZZ 64.119.242.0/23 AS26072 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.202.48.0/22 AS23380 -Reserved AS-,ZZ 64.202.52.0/23 AS23380 -Reserved AS-,ZZ 64.202.54.0/24 AS23380 -Reserved AS-,ZZ 64.202.55.0/24 AS23380 -Reserved AS-,ZZ 64.202.56.0/22 AS23380 -Reserved AS-,ZZ 64.202.60.0/24 AS23380 -Reserved AS-,ZZ 64.202.61.0/24 AS23380 -Reserved AS-,ZZ 64.202.62.0/24 AS23380 -Reserved AS-,ZZ 64.202.63.0/24 AS23380 -Reserved AS-,ZZ 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.206.208.0/22 AS23380 -Reserved AS-,ZZ 66.206.211.0/24 AS14288 MPINET - MPInet,US 66.206.212.0/24 AS23380 -Reserved AS-,ZZ 66.206.213.0/24 AS14288 MPINET - MPInet,US 66.206.214.0/24 AS23380 -Reserved AS-,ZZ 66.206.215.0/24 AS23380 -Reserved AS-,ZZ 66.206.216.0/23 AS14288 MPINET - MPInet,US 66.206.218.0/23 AS23380 -Reserved AS-,ZZ 66.206.220.0/22 AS23380 -Reserved AS-,ZZ 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc,US 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 154.75.25.0/24 AS32774 SOMALI-WIRELESS,SO 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 167.88.144.0/20 AS23352 SERVERCENTRAL - Server Central Network,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 185.53.8.0/22 AS19988 DEDICOLO-AS A.M. Bayhan is trading as "DediColo Services",NL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 -Reserved AS-,ZZ 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.106.0/23 AS42444 -Reserved AS-,ZZ 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.142.249.0/24 AS12389 ROSTELECOM-AS OJSC Rostelecom,RU 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.59.46.0/24 AS9145 EWETEL EWE TEL GmbH,DE 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.69.100.0/24 AS29174 -Reserved AS-,ZZ 195.69.101.0/24 AS29174 -Reserved AS-,ZZ 195.69.102.0/24 AS29174 -Reserved AS-,ZZ 195.69.103.0/24 AS29174 -Reserved AS-,ZZ 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 196.216.129.0/24 AS36886 -Reserved AS-,ZZ 196.216.130.0/24 AS36886 -Reserved AS-,ZZ 196.216.131.0/24 AS36886 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.188.28.0/22 AS46802 ASN-BACKCOUNTRY - Backcountry.com, Inc.,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.59.1.0/24 AS24032 AC3-AS ac3, Australian Centre for Advanced Computing and,AU 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.0.0.0/16 AS7545 TPG-INTERNET-AP TPG Telecom Limited,AU 203.83.16.0/21 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.91.164.0/22 AS46099 -Reserved AS-,ZZ 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 4 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Apr 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201404042200.s34M01KZ007492@wattle.apnic.net> BGP Update Report Interval: 27-Mar-14 -to- 03-Apr-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 69594 2.8% 42.5 -- SDN-MOBITEL,SD 2 - AS9829 64062 2.6% 63.1 -- BSNL-NIB National Internet Backbone,IN 3 - AS50710 44782 1.8% 199.0 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services,IQ 4 - AS29571 39069 1.6% 229.8 -- CITelecom-AS,CI 5 - AS4761 29840 1.2% 18.7 -- INDOSAT-INP-AP INDOSAT Internet Network Provider,ID 6 - AS8402 27088 1.1% 34.9 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS56115 25702 1.0% 428.4 -- NGGL-BD Road 27 House 13 Block C2,BD 8 - AS13118 23248 0.9% 645.8 -- ASN-YARTELECOM OJSC Rostelecom,RU 9 - AS45899 21807 0.9% 59.9 -- VNPT-AS-VN VNPT Corp,VN 10 - AS25184 20942 0.8% 163.6 -- AFRANET AFRANET Co. Tehran, Iran,IR 11 - AS41691 20534 0.8% 622.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 12 - AS17557 18014 0.7% 173.2 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 13 - AS48159 15904 0.6% 88.4 -- TIC-AS Telecommunication Infrastructure Company,IR 14 - AS23893 15699 0.6% 402.5 -- BPL-BD House No:03, Road no: 23/A,BD 15 - AS20450 15632 0.6% 7816.0 -- THL16-ASN - Trojan Hosting, LLC.,US 16 - AS28573 14381 0.6% 6.1 -- NET Servi?os de Comunica??o S.A.,BR 17 - AS7552 14172 0.6% 13.3 -- VIETEL-AS-AP Viettel Corporation,VN 18 - AS22561 13077 0.5% 108.1 -- AS22561 - CenturyTel Internet Holdings, Inc.,US 19 - AS53062 12618 0.5% 332.1 -- G G NET - Telecomunica??es LTDA EPP,BR 20 - AS58947 12073 0.5% 4024.3 -- SOFTWARE-AS-AP Software Shop Limited,BD TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6629 10353 0.4% 10353.0 -- NOAA-AS - NOAA,US 2 - AS20450 15632 0.6% 7816.0 -- THL16-ASN - Trojan Hosting, LLC.,US 3 - AS18135 7519 0.3% 7519.0 -- BTV BTV Cable television,JP 4 - AS58947 12073 0.5% 4024.3 -- SOFTWARE-AS-AP Software Shop Limited,BD 5 - AS54465 8600 0.3% 2866.7 -- QPM-AS-1 - QuickPlay Media Inc.,US 6 - AS17494 2585 0.1% 2585.0 -- BTTB-AS-AP Telecom Operator & Internet Service Provider as well,BD 7 - AS23466 2430 0.1% 2430.0 -- -Reserved AS-,ZZ 8 - AS56042 2711 0.1% 1355.5 -- CMNET-SHANXI-AP China Mobile communications corporation,CN 9 - AS3 1311 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 10 - AS16561 1977 0.1% 988.5 -- ARIBANETWORK - Ariba Technologies, Inc,US 11 - AS22688 896 0.0% 896.0 -- DOLGENCORP - Dollar General Corporation,US 12 - AS47714 847 0.0% 847.0 -- DRIESSEN-AS Driessen Aerospace Group NV,IT 13 - AS23295 1677 0.1% 838.5 -- EA-01 - Extend America,US 14 - AS37367 834 0.0% 834.0 -- CALLKEY,KE 15 - AS60345 823 0.0% 823.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 16 - AS48068 807 0.0% 807.0 -- VISONIC Visonic Ltd,IL 17 - AS14436 11050 0.4% 789.3 -- INTUIT-QDC - Intuit Inc.,US 18 - AS3235 1542 0.1% 771.0 -- GOLDENISP-AS OJSC "Vimpelcom",RU 19 - AS53841 730 0.0% 730.0 -- RAMHOST - RAM Host,US 20 - AS32244 4269 0.2% 711.5 -- LIQUID-WEB-INC - Liquid Web, Inc.,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22953 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 2 - 89.221.206.0/24 20402 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 3 - 121.52.144.0/24 18023 0.7% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 4 - 192.58.232.0/24 10353 0.4% AS6629 -- NOAA-AS - NOAA,US 5 - 78.109.192.0/20 9893 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 6 - 66.210.60.0/24 8988 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC.,US 7 - 206.152.15.0/24 8596 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 8 - 205.247.12.0/24 7574 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 9 - 42.83.48.0/20 7519 0.3% AS18135 -- BTV BTV Cable television,JP 10 - 65.90.49.0/24 7151 0.3% AS3356 -- LEVEL3 - Level 3 Communications, Inc.,US 11 - 74.231.237.0/24 6644 0.2% AS20450 -- THL16-ASN - Trojan Hosting, LLC.,US 12 - 103.26.138.0/24 6210 0.2% AS58947 -- SOFTWARE-AS-AP Software Shop Limited,BD 13 - 199.187.118.0/24 6029 0.2% AS11054 -- LIVEPERSON - LivePerson, Inc.,US 14 - 210.90.39.0/24 6020 0.2% AS4766 -- KIXS-AS-KR Korea Telecom,KR 15 - 103.26.139.0/24 5762 0.2% AS58947 -- SOFTWARE-AS-AP Software Shop Limited,BD 16 - 186.211.97.0/24 4964 0.2% AS53062 -- G G NET - Telecomunica??es LTDA EPP,BR 17 - 186.211.109.0/24 4864 0.2% AS53062 -- G G NET - Telecomunica??es LTDA EPP,BR 18 - 146.83.239.0/24 4368 0.2% AS11340 -- Red Universitaria Nacional,CL 19 - 216.109.107.0/24 3952 0.1% AS11486 -- COLO-PREM-VZB - Verizon Online LLC,US AS16561 -- ARIBANETWORK - Ariba Technologies, Inc,US 20 - 177.23.187.0/24 3255 0.1% AS52935 -- Infobarra Solucoes em Informatica Ltda,BR Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From hannigan at gmail.com Sat Apr 5 01:18:56 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 4 Apr 2014 21:18:56 -0400 Subject: 165 Halsey and Perimeter Security Message-ID: Folks, Anyone have a contact at Tishman that can help me with perimeter security concerns at 165 Halsey? The situation in the neighborhood is currently unsatisfactory (and unsafe) and I'd like to engage the landlord directly. Currently a tenant of a colo provider, not the landlord directly. Ping me offline. Very much appreciated. Best, -M< From LarrySheldon at cox.net Sat Apr 5 05:44:05 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 05 Apr 2014 00:44:05 -0500 Subject: Anternet Message-ID: <533F9825.3090300@cox.net> Offered for your amusement--no followup. http://kottke.org/14/04/the-anternet -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From trelane at trelane.net Sat Apr 5 06:32:13 2014 From: trelane at trelane.net (Andrew D Kirch) Date: Sat, 05 Apr 2014 02:32:13 -0400 Subject: Anternet In-Reply-To: <533F9825.3090300@cox.net> References: <533F9825.3090300@cox.net> Message-ID: <533FA36D.3090709@trelane.net> So, if there's more than 4 billion ants... what are they going to do? Andrew On 4/5/2014 1:44 AM, Larry Sheldon wrote: > > Offered for your amusement--no followup. > > http://kottke.org/14/04/the-anternet From morrowc.lists at gmail.com Sat Apr 5 06:50:59 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 5 Apr 2014 02:50:59 -0400 Subject: Anternet In-Reply-To: <533FA36D.3090709@trelane.net> References: <533F9825.3090300@cox.net> <533FA36D.3090709@trelane.net> Message-ID: On Sat, Apr 5, 2014 at 2:32 AM, Andrew D Kirch wrote: > So, if there's more than 4 billion ants... what are they going to do? there will never be more than 4 billion ants. > On 4/5/2014 1:44 AM, Larry Sheldon wrote: >> >> >> Offered for your amusement--no followup. >> >> http://kottke.org/14/04/the-anternet > > > From mark.tinka at seacom.mu Sat Apr 5 11:10:12 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 5 Apr 2014 13:10:12 +0200 Subject: BGPMON Alert Questions In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011D70D4@EX01.swan.local> References: <201404031404.44935.mark.tinka@seacom.mu> <61DC6BC4ABA10E4489D4A73EBABAC18B011D70D4@EX01.swan.local> Message-ID: <201404051310.16060.mark.tinka@seacom.mu> On Friday, April 04, 2014 09:58:42 AM Vitkovsk? Adam wrote: > I wonder when (or if ever) we'll have such a discussion > about data packets, i.e. finding that someone is not > doing packet-filtering based on BGP updates is > absolutely and unacceptably shocking! Well, filtering in the data plane is slightly easier because a single subnet can cover all traffic coming from individual sources or going to individual destinations. In the control plane, the industry like to filter on specific prefixes agreed between customer and provider, especially when using automated tools such as RPSL. This can get hairy as configurations become large, where a single entry with "le 24" or "le 48" could have sufficed. On the other hand, if you're not automating control plane filters to some extent, it becomes messy as you get bigger. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Apr 5 11:11:49 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 5 Apr 2014 13:11:49 +0200 Subject: BGPMON Alert Questions In-Reply-To: <533E8A07.30704@NLnetLabs.nl> References: <533E8A07.30704@NLnetLabs.nl> Message-ID: <201404051311.50033.mark.tinka@seacom.mu> On Friday, April 04, 2014 12:31:35 PM Benno Overeinder wrote: > With ROAs published and a small percentage (order of 5%) > of the largest ISPs doing route origin validation, this > would filter the incorrect announcement and result in > about ~98% globally correct routes in the 35000 ASes > (this work is done a couple years ago). With no route > origin validation (or any other filtering) the > percentage of correct routes at the ASes would be ~25% > globally. Again, this was a specific scenario. So do you know whether anyone has any idea about what the top 10 global carriers are doing re: RPKI? Thinking? Justifying? Testing? Ignoring? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mark.tinka at seacom.mu Sat Apr 5 11:21:20 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 5 Apr 2014 13:21:20 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404040715.25878.mark.tinka@seacom.mu> Message-ID: <201404051321.21299.mark.tinka@seacom.mu> On Friday, April 04, 2014 05:17:36 PM Sharon Goldberg wrote: > Right, we didn't include that in our analysis because we > didn't have a good sense for how many ISPs actually do > filter their downstream downstreams. So we chose to give > a conservative estimate of the impact of prefix > filtering in partial deployment: we assumed that no one > filters their downstreams downstreams. I'm honestly not > sure exactly what including this assumption would do to > our results, except to say that it would make them > better (ie. that more attacks would be stopped). Might > be a good experiment for one of my summer interns. I've typically been on the side where we filter just the downstream and apply AS_PATH filtering liberally for their downstreams. At $current_job, we're now filtering both downstream and downstream's downstreams on AS_PATH + prefix list, taking the prefix aggregate and suffixing "le 24" or "le 48". We are now thinking about how to scale this without using RPSL, as that creates lots and lots of clutter in the configuration, as well as sub-optimal forwarding when customers are sending routes you aren't accepting when they forget that RPSL-based filtering is prefix-specific. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From jeff-kell at utc.edu Sat Apr 5 13:03:46 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 5 Apr 2014 09:03:46 -0400 Subject: Anternet In-Reply-To: <533FA36D.3090709@trelane.net> References: <533F9825.3090300@cox.net> <533FA36D.3090709@trelane.net> Message-ID: <533FFF32.2030406@utc.edu> On 4/5/2014 2:32 AM, Andrew D Kirch wrote: > So, if there's more than 4 billion ants... what are they going to do? Who knows, but they'll definitely need IPv6 :) Jeff From tdurack at gmail.com Sat Apr 5 18:30:52 2014 From: tdurack at gmail.com (Tim Durack) Date: Sat, 5 Apr 2014 14:30:52 -0400 Subject: Anternet In-Reply-To: <533FFF32.2030406@utc.edu> References: <533F9825.3090300@cox.net> <533FA36D.3090709@trelane.net> <533FFF32.2030406@utc.edu> Message-ID: Large Scale aNt will be good enough. Plus this has security advantages. On Saturday, April 5, 2014, Jeff Kell wrote: > On 4/5/2014 2:32 AM, Andrew D Kirch wrote: > > So, if there's more than 4 billion ants... what are they going to do? > > Who knows, but they'll definitely need IPv6 :) > > Jeff > > > -- Tim:> From alter3d at alter3d.ca Sat Apr 5 18:43:08 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sat, 05 Apr 2014 14:43:08 -0400 Subject: Anternet In-Reply-To: <533FA36D.3090709@trelane.net> References: <533F9825.3090300@cox.net> <533FA36D.3090709@trelane.net> Message-ID: <53404EBC.4000403@alter3d.ca> This has been a solved problem for a long time. You just need to implement Virtual Local Ant Nest (VLAN) and use overlapping local address schemes. On 4/5/2014 2:32 AM, Andrew D Kirch wrote: > So, if there's more than 4 billion ants... what are they going to do? > > Andrew > > On 4/5/2014 1:44 AM, Larry Sheldon wrote: >> >> Offered for your amusement--no followup. >> >> http://kottke.org/14/04/the-anternet > > From surfer at mauigateway.com Sun Apr 6 02:55:04 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 5 Apr 2014 19:55:04 -0700 Subject: Anternet Message-ID: <20140405195504.BE964047@m0048140.ppops.net> --- jeff-kell at utc.edu wrote: On 4/5/2014 2:32 AM, Andrew D Kirch wrote: > So, if there's more than 4 billion ants... what are they going to do? :: Who knows, but they'll definitely need IPv6 :) ------------------------------------------------------- http://imgs.xkcd.com/comics/nanobots.png :-) scott From goldbe at cs.bu.edu Sun Apr 6 12:34:47 2014 From: goldbe at cs.bu.edu (Sharon Goldberg) Date: Sun, 6 Apr 2014 08:34:47 -0400 Subject: BGPMON Alert Questions In-Reply-To: <201404051321.21299.mark.tinka@seacom.mu> References: <201404040715.25878.mark.tinka@seacom.mu> <201404051321.21299.mark.tinka@seacom.mu> Message-ID: On Sat, Apr 5, 2014 at 7:11 AM, Mark Tinka wrote: > > So do you know whether anyone has any idea about what the > top 10 global carriers are doing re: RPKI? > > Thinking? Justifying? Testing? Ignoring? > These looking glasses are helpful: http://www.labs.lacnic.net/rpkitools/looking_glass/ http://www-x.antd.nist.gov/rpki-monitor/ http://certification-stats.ripe.net/ http://rpki.surfnet.nl/index.html But naturally it's harder to see who has turned on origin validation. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe From mark.tinka at seacom.mu Sun Apr 6 15:03:07 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 6 Apr 2014 17:03:07 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404051321.21299.mark.tinka@seacom.mu> Message-ID: <201404061703.07976.mark.tinka@seacom.mu> On Sunday, April 06, 2014 02:34:47 PM Sharon Goldberg wrote: > But naturally it's harder to see who has turned on origin > validation. Indeed, especially since there is no co-relation between providers issuing ROA's for their own allocations and turning on origin validation in their network. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From rdrake at direcpath.com Mon Apr 7 04:02:35 2014 From: rdrake at direcpath.com (Robert Drake) Date: Mon, 7 Apr 2014 00:02:35 -0400 Subject: Cisco warranty In-Reply-To: <533D900A.2010605@unix-scripts.info> References: <533D900A.2010605@unix-scripts.info> Message-ID: <5342235B.5050302@direcpath.com> On 4/3/2014 12:44 PM, Laurent CARON wrote: > Hi, > > I bought a C3750G-12S which is now end of sale on cisco website. This > device is now defective. > > Since I bought it from a reseller and not directly from cisco, cisco > is refusing to take it under warranty and tells me to have the > reseller take care of it. > > The reseller doesnt wan't to hear about this device since it is end of > sale. > > According to cisco website, end of sale means the device is still > covered for 5 years. > These have reached a price point where a used one will cost less than a smartnet contract for one, and you get better turnaround time too. > My question is: Is it normal for my supplier to refuse to take it > under warranty ? > Probably depends on the supplier. Most of them would have warranty terms of their own and if it's passed that time period then they won't take it back. > Is there (from your experience) a chance I might get cisco to deal > with it ? If you're a huge customer of Cisco and have multi-year contracts with them then sure. You could get them to RMA a toaster if they think they could make money in the long run on it. > > Thanks > > Laurent > From bortzmeyer at nic.fr Mon Apr 7 09:54:33 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 7 Apr 2014 11:54:33 +0200 Subject: Anternet In-Reply-To: <533F9825.3090300@cox.net> References: <533F9825.3090300@cox.net> Message-ID: <20140407095432.GA20999@nic.fr> On Sat, Apr 05, 2014 at 12:44:05AM -0500, Larry Sheldon wrote a message of 9 lines which said: > http://kottke.org/14/04/the-anternet But what is the equivalent of 3-way handshake? And of ECN (ants carrying back messages "I still bring food but it won't last")? And the security implications (what prevent bad ants to disrupt the mechanism: ants did not invent random ISNs)? Is there a source quench mechanism or did the ants deprecate it long before RFC 6633? And what is the size of the initial window? Should we cancel all patents related to TCP because there is prior ant art? Many questions unanswered. From marcus.sachs at verizon.com Mon Apr 7 13:26:11 2014 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Mon, 7 Apr 2014 09:26:11 -0400 Subject: Anternet In-Reply-To: <533F9825.3090300@cox.net> References: <533F9825.3090300@cox.net> Message-ID: Ant algorithms are currently part of the communications infrastructure. Here is a recent paper, and see the reference in the paper about the Ant Based Control (ABC) algorithm that is used for circuit switched networks. Marc http://www.ijarcsse.com/docs/papers/Volume_3/3_March2013/V3I3-0125.pdf -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Saturday, April 05, 2014 1:44 AM To: nanog at nanog.org Subject: Anternet Offered for your amusement--no followup. http://kottke.org/14/04/the-anternet -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From fergdawgster at mykolab.com Tue Apr 8 05:06:32 2014 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Mon, 07 Apr 2014 22:06:32 -0700 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <53436560.30002@internetidentity.com> References: <53436560.30002@internetidentity.com> Message-ID: <534383D8.8000006@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm really surprised no one has mentioned this here yet... FYI, - - ferg Begin forwarded message: > From: Rich Kulawiec Subject: Serious bug in > ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at > 9:27:40 PM EDT > > This reaches across many versions of Linux and BSD and, I'd > presume, into some versions of operating systems based on them. > OpenSSL is used in web servers, mail servers, VPNs, and many other > places. > > Writeup: Heartbleed: Serious OpenSSL zero day vulnerability > revealed > http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revealed-7000028166/ > > Technical details: Heartbleed Bug http://heartbleed.com/ > > OpenSSL versions affected (from link just above): OpenSSL 1.0.1 > through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT > vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is > NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e =aAzE -----END PGP SIGNATURE----- From dhubbard at dino.hostasaurus.com Tue Apr 8 05:13:24 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 8 Apr 2014 01:13:24 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: RHEL and CentOS both have patches out as of a couple hours ago, so run those updates! CentOS' mirrors do not all have it yet, so if you are updating, make sure you get the 1.0.1e-16.el6_5.7 version and not older. David -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at mykolab.com] Sent: Tuesday, April 08, 2014 1:07 AM To: NANOG Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm really surprised no one has mentioned this here yet... FYI, - - ferg Begin forwarded message: > From: Rich Kulawiec Subject: Serious bug in ubiquitous > OpenSSL library: "Heartbleed" Date: April 7, 2014 at 9:27:40 PM EDT > > This reaches across many versions of Linux and BSD and, I'd presume, > into some versions of operating systems based on them. > OpenSSL is used in web servers, mail servers, VPNs, and many other > places. > > Writeup: Heartbleed: Serious OpenSSL zero day vulnerability revealed > http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability > -revealed-7000028166/ > > Technical details: Heartbleed Bug http://heartbleed.com/ > > OpenSSL versions affected (from link just above): OpenSSL 1.0.1 > through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT > vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is NOT > vulnerable OpenSSL 0.9.8 branch is NOT vulnerable > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e =aAzE -----END PGP SIGNATURE----- From alter3d at alter3d.ca Tue Apr 8 05:17:30 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 08 Apr 2014 01:17:30 -0400 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <534383D8.8000006@mykolab.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: <5343866A.7090801@alter3d.ca> OK, now... it's far too late for April Fool's. :( That's scary as heck. :( Guess I know what the first order of business will be tomorrow... - Pete On 4/8/2014 1:06 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in >> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >> 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd >> presume, into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >> revealed >> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revealed-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- > From alter3d at alter3d.ca Tue Apr 8 05:18:52 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 08 Apr 2014 01:18:52 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: <534386BC.9000406@alter3d.ca> Not just run the updates -- all private keys should be changed too, on the assumption that they've been compromised already. THAT is going to be the crappy part of this. - Pete On 4/8/2014 1:13 AM, David Hubbard wrote: > RHEL and CentOS both have patches out as of a couple hours > ago, so run those updates! CentOS' mirrors do not all have > it yet, so if you are updating, make sure you get the > 1.0.1e-16.el6_5.7 version and not older. > > David > > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at mykolab.com] > Sent: Tuesday, April 08, 2014 1:07 AM > To: NANOG > Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in ubiquitous >> OpenSSL library: "Heartbleed" Date: April 7, 2014 at 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd presume, >> into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability revealed >> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability >> -revealed-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is NOT >> vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- > > > > From max at mxcrypt.com Tue Apr 8 06:05:23 2014 From: max at mxcrypt.com (Maxim Khitrov) Date: Tue, 8 Apr 2014 02:05:23 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <534383D8.8000006@mykolab.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: It's bad. I decided to test my servers after updating them. Took me about 3 hours to write a working implementation of this attack without any prior knowledge of TLS internals. It's easy to do, pretty much impossible to detect, and it's going to spread quickly. Shut down your https sites and any other TLS services until you've updated OpenSSL, then think about changing your private keys. - Max On Tue, Apr 8, 2014 at 1:06 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in >> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >> 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd >> presume, into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >> revealed >> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revealed-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- > From randy at psg.com Tue Apr 8 08:35:04 2014 From: randy at psg.com (Randy Bush) Date: Tue, 08 Apr 2014 16:35:04 +0800 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <534383D8.8000006@mykolab.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: > I'm really surprised no one has mentioned this here yet... we're all to damned busy updating and generating keys you might like (thanks smb, or was it sra) openssl s_client -connect google\.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe randy, who is almost through From Jac.Kloots at surfnet.nl Tue Apr 8 09:24:07 2014 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Tue, 8 Apr 2014 11:24:07 +0200 (CEST) Subject: BGPMON Alert Questions In-Reply-To: <201404031431.55306.mark.tinka@seacom.mu> References: <533C9A47.8070602@toonk.nl> <201404031431.55306.mark.tinka@seacom.mu> Message-ID: Hi Mark, On Thu, 3 Apr 2014, Mark Tinka wrote: > On Thursday, April 03, 2014 02:22:44 AM Randy Bush wrote: > >> and, btw, how many of those whose prefixes were >> mis-originated had registered those prefixes in the >> rpki? > > It is probably a bit of a hammer at this stage, but we are > in limited deployment of dropping all Invalids using RPKI. > > We shall be rolling out, network-wide, in 2014, where all > Invalids are dropped. At this stage, short of a mis- > origination, it's mostly longer prefixes of an aggregate > that are not ROA'd. Great to hear more people are planning on dropping all Invalids. We (SURFnet, AS1103) are in the same position and I wrote an article about the evaluation we did before deciding on dropping invalids (https://blog.surfnet.nl/?p=3159) I would encourage more people to do a similar analysis and start using a RPKI routing policy and start dropping invalids. Only when people start using RPKI the way it is proposted to (http://tools.ietf.org/html/rfc7115) we _all_ can benefit from this. Regards, Jac -- Jac Kloots Network Services SURFnet bv From fernando at gont.com.ar Tue Apr 8 10:28:25 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Tue, 08 Apr 2014 07:28:25 -0300 Subject: real-world data about fragmentation In-Reply-To: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> References: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> Message-ID: <5343CF49.6080208@gont.com.ar> Hi, Joe, On 04/02/2014 03:14 PM, Joe Abley wrote: > Is anybody aware of any wide-scale studies that examine the > probability of fragmentation of datagrams of different sizes? We're in the process of measuring some (kind of related stuff). If you're interested in this data, we might be able to provide something along these lines in 1 month or so... It seems to be mostly about measuring the MTU to as many destinations as possible, so to speak... > For example, I could reasonable expect an IPv4 packet of 576 bytes > not to be fragmented very often (to choose a size not at random). Note: there shouldn't be any special magic around this number (usualy mistakenly interpreted as the minimum IPv6 MTU, but rather being the minimum IPv4 reassembly buffer size). > The > probability of a 10,000 octet IPv4 packet getting fragmented seems > likely to be 100%, if we're talking about arbitrary paths across the > Internet. > > What does the curve look like between 576 bytes and 10,000 bytes? > > I might expect exciting curve action around 1500 bytes (because > ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in > actual data. > > Anybody have any pointers? IPv4 and IPv6 are both interesting. Probably off-topic, but since you mentioned reliability of IPv6 fragmentation: * * Thanks! Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mark.tinka at seacom.mu Tue Apr 8 10:49:10 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 8 Apr 2014 12:49:10 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031431.55306.mark.tinka@seacom.mu> Message-ID: <201404081249.13834.mark.tinka@seacom.mu> On Tuesday, April 08, 2014 11:24:07 AM Jac Kloots wrote: > We (SURFnet, AS1103) are in the same position and I wrote > an article about the evaluation we did before deciding > on dropping invalids (https://blog.surfnet.nl/?p=3159) Sounds great, Jac! In your report, you mention that you're not validating customer prefixes. Is this still the case? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From Jac.Kloots at surfnet.nl Tue Apr 8 11:20:23 2014 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Tue, 8 Apr 2014 13:20:23 +0200 (CEST) Subject: BGPMON Alert Questions In-Reply-To: <201404081249.13834.mark.tinka@seacom.mu> References: <201404031431.55306.mark.tinka@seacom.mu> <201404081249.13834.mark.tinka@seacom.mu> Message-ID: Mark, On Tue, 8 Apr 2014, Mark Tinka wrote: > On Tuesday, April 08, 2014 11:24:07 AM Jac Kloots wrote: > >> We (SURFnet, AS1103) are in the same position and I wrote >> an article about the evaluation we did before deciding >> on dropping invalids (https://blog.surfnet.nl/?p=3159) > > Sounds great, Jac! > > In your report, you mention that you're not validating > customer prefixes. Is this still the case? Yes, we don't validate those prefixes cause we filter them strict. We know from all our customers which prefixes they use so we have prefix-filters placed on all their connections. Jac -- Jac Kloots Network Services SURFnet bv From max at mxcrypt.com Tue Apr 8 12:14:33 2014 From: max at mxcrypt.com (Maxim Khitrov) Date: Tue, 8 Apr 2014 08:14:33 -0400 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: On Tue, Apr 8, 2014 at 4:35 AM, Randy Bush wrote: >> I'm really surprised no one has mentioned this here yet... > > we're all to damned busy updating and generating keys > > you might like (thanks smb, or was it sra) > > openssl s_client -connect google\.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe That just tells you whether the heartbeat extension is supported. Google servers are not vulnerable to this attack. - Max From dhubbard at dino.hostasaurus.com Tue Apr 8 12:18:04 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 8 Apr 2014 08:18:04 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <534386BC.9000406@alter3d.ca> Message-ID: Don't forget to restart every daemon that was using the old library as well, or just reboot. -----Original Message----- From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] Sent: Tuesday, April 08, 2014 1:19 AM To: nanog at nanog.org Subject: Re: Serious bug in ubiquitous OpenSSL library: "Heartbleed" Not just run the updates -- all private keys should be changed too, on the assumption that they've been compromised already. THAT is going to be the crappy part of this. - Pete On 4/8/2014 1:13 AM, David Hubbard wrote: > RHEL and CentOS both have patches out as of a couple hours ago, so run > those updates! CentOS' mirrors do not all have it yet, so if you are > updating, make sure you get the > 1.0.1e-16.el6_5.7 version and not older. > > David > > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at mykolab.com] > Sent: Tuesday, April 08, 2014 1:07 AM > To: NANOG > Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in ubiquitous >> OpenSSL library: "Heartbleed" Date: April 7, 2014 at 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd presume, >> into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability revealed >> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerabilit >> y >> -revealed-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- > > > > From contact at winterei.se Wed Apr 9 12:21:50 2014 From: contact at winterei.se (Paul S.) Date: Wed, 09 Apr 2014 21:21:50 +0900 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <534386BC.9000406@alter3d.ca> Message-ID: <53453B5E.1070507@winterei.se> If you built anything against the vulnerable library (esp static linked stuff), you'll need to rebuild those too. On 4/8/2014 ?? 09:18, David Hubbard wrote: > Don't forget to restart every daemon that was using the old library as > well, or just reboot. > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Tuesday, April 08, 2014 1:19 AM > To: nanog at nanog.org > Subject: Re: Serious bug in ubiquitous OpenSSL library: "Heartbleed" > > Not just run the updates -- all private keys should be changed too, on > the assumption that they've been compromised already. THAT is going to > be the crappy part of this. > > - Pete > > > On 4/8/2014 1:13 AM, David Hubbard wrote: >> RHEL and CentOS both have patches out as of a couple hours ago, so run >> those updates! CentOS' mirrors do not all have it yet, so if you are >> updating, make sure you get the >> 1.0.1e-16.el6_5.7 version and not older. >> >> David >> >> -----Original Message----- >> From: Paul Ferguson [mailto:fergdawgster at mykolab.com] >> Sent: Tuesday, April 08, 2014 1:07 AM >> To: NANOG >> Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I'm really surprised no one has mentioned this here yet... >> >> FYI, >> >> - - ferg >> >> >> >> Begin forwarded message: >> >>> From: Rich Kulawiec Subject: Serious bug in ubiquitous >>> OpenSSL library: "Heartbleed" Date: April 7, 2014 at 9:27:40 PM EDT >>> >>> This reaches across many versions of Linux and BSD and, I'd presume, >>> into some versions of operating systems based on them. >>> OpenSSL is used in web servers, mail servers, VPNs, and many other >>> places. >>> >>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability revealed >>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerabilit >>> y >>> -revealed-7000028166/ >>> >>> Technical details: Heartbleed Bug http://heartbleed.com/ >>> >>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >>> >> - -- >> Paul Ferguson >> VP Threat Intelligence, IID >> PGP Public Key ID: 0x54DC85B2 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf >> 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e >> =aAzE >> -----END PGP SIGNATURE----- >> >> >> >> > > > > From rs at seastrom.com Tue Apr 8 12:28:54 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 08 Apr 2014 08:28:54 -0400 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: (Randy Bush's message of "Tue, 08 Apr 2014 16:35:04 +0800") References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: <86sipogg3d.fsf@valhalla.seastrom.com> Randy Bush writes: > you might like (thanks smb, or was it sra) > > openssl s_client -connect google\.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe protip: you have to run this from a device that actually is running 1.0.x, i.e. supports the heartbeat extension. your desktop mac (running 0.9.8y if you're running mavericks and haven't stomped on it via ports; homebrew is a keg only install) WILL NOT SUFFICE and will just sit there quietly until the http server times out (60 seconds in my case) and then echo "safe" even when you're not. -r From mark.tinka at seacom.mu Tue Apr 8 12:29:48 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 8 Apr 2014 14:29:48 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404081249.13834.mark.tinka@seacom.mu> Message-ID: <201404081429.50983.mark.tinka@seacom.mu> On Tuesday, April 08, 2014 01:20:23 PM Jac Kloots wrote: > Yes, we don't validate those prefixes cause we filter > them strict. We know from all our customers which > prefixes they use so we have prefix-filters placed on > all their connections. Good point. We do both - prefix list + AS_PATH filtering as well as origin validation. At this point, you're likely to lose longer prefixes from customers if they forgot to ROA them, but the rationale is that if a customer has sufficient clue to ROA their aggregate, they can quickly ROA a de-aggregate or fix it in case they forgot. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From mike at mtcc.com Tue Apr 8 16:03:11 2014 From: mike at mtcc.com (Michael Thomas) Date: Tue, 08 Apr 2014 09:03:11 -0700 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <534383D8.8000006@mykolab.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: <53441DBF.9020200@mtcc.com> Just as a data point, I checked the servers I run and it's a good thing I didn't reflexively update them first. On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have the vulnerability, but the ones queued up for update do. I assume that redhat will get the patched version soon but be careful! Mike On 04/07/2014 10:06 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in >> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >> 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd >> presume, into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >> revealed >> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revealed-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- From richard.hesse at weebly.com Tue Apr 8 16:08:50 2014 From: richard.hesse at weebly.com (Richard Hesse) Date: Tue, 8 Apr 2014 09:08:50 -0700 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <53441DBF.9020200@mtcc.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: The updated CentOS openssl binaries haven't patched the underlying bug, but they have disabled the heartbeat functionality. By doing so, they've disabled the attack vector. Once upstream releases a fix, they will re-enable the heartbeat function with the working patch. And yes, don't forget to restart any linked services after updating. -richard On Tue, Apr 8, 2014 at 9:03 AM, Michael Thomas wrote: > Just as a data point, I checked the servers I run and it's a good thing I > didn't reflexively update them first. > On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have > the vulnerability, but the > ones queued up for update do. I assume that redhat will get the patched > version soon but be careful! > > Mike > > > On 04/07/2014 10:06 PM, Paul Ferguson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I'm really surprised no one has mentioned this here yet... >> >> FYI, >> >> - - ferg >> >> >> >> Begin forwarded message: >> >> From: Rich Kulawiec Subject: Serious bug in >>> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >>> 9:27:40 PM EDT >>> >>> This reaches across many versions of Linux and BSD and, I'd >>> presume, into some versions of operating systems based on them. >>> OpenSSL is used in web servers, mail servers, VPNs, and many other >>> places. >>> >>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >>> revealed >>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability- >>> revealed-7000028166/ >>> >>> Technical details: Heartbleed Bug http://heartbleed.com/ >>> >>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >>> >>> >> - -- Paul Ferguson >> VP Threat Intelligence, IID >> PGP Public Key ID: 0x54DC85B2 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf >> 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e >> =aAzE >> -----END PGP SIGNATURE----- >> > > > From jof at thejof.com Tue Apr 8 16:11:23 2014 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 8 Apr 2014 17:11:23 +0100 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <53441DBF.9020200@mtcc.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: For testing, I've had good luck with https://github.com/titanous/heartbleeder and https://gist.github.com/takeshixx/10107280 Both are mostly platform-independent, so they should be able to work even if you don't have a modern OpenSSL to test with. Cheers and good luck (you're going to need it), jof On Tue, Apr 8, 2014 at 5:03 PM, Michael Thomas wrote: > Just as a data point, I checked the servers I run and it's a good thing I > didn't reflexively update them first. > On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have > the vulnerability, but the > ones queued up for update do. I assume that redhat will get the patched > version soon but be careful! > > Mike > > > On 04/07/2014 10:06 PM, Paul Ferguson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I'm really surprised no one has mentioned this here yet... >> >> FYI, >> >> - - ferg >> >> >> >> Begin forwarded message: >> >> From: Rich Kulawiec Subject: Serious bug in >>> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >>> 9:27:40 PM EDT >>> >>> This reaches across many versions of Linux and BSD and, I'd >>> presume, into some versions of operating systems based on them. >>> OpenSSL is used in web servers, mail servers, VPNs, and many other >>> places. >>> >>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >>> revealed >>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability- >>> revealed-7000028166/ >>> >>> Technical details: Heartbleed Bug http://heartbleed.com/ >>> >>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >>> >>> >> - -- Paul Ferguson >> VP Threat Intelligence, IID >> PGP Public Key ID: 0x54DC85B2 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf >> 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e >> =aAzE >> -----END PGP SIGNATURE----- >> > > > From dhubbard at dino.hostasaurus.com Tue Apr 8 16:11:32 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 8 Apr 2014 12:11:32 -0400 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: 1.0.1 was not deployed until RHEL 6.5. RedHat released patches for RHEL last night, and CentOS followed suit a few minutes later. -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Tuesday, April 08, 2014 12:03 PM To: nanog at nanog.org Subject: Re: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" Just as a data point, I checked the servers I run and it's a good thing I didn't reflexively update them first. On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have the vulnerability, but the ones queued up for update do. I assume that redhat will get the patched version soon but be careful! Mike On 04/07/2014 10:06 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in ubiquitous >> OpenSSL library: "Heartbleed" Date: April 7, 2014 at 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd presume, >> into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability revealed >> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerabilit >> y-revealed-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- From patrick at ianai.net Tue Apr 8 16:16:12 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 8 Apr 2014 12:16:12 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: Lots of tools available. I'm with ferg, surprised more haven't been mentioned here. Tools to check for the bug: ? on your own box: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py ? online: http://filippo.io/Heartbleed/ (use carefully as they might log what you check) ? online: http://possible.lv/tools/hb/ ? offline: https://github.com/tdussa/heartbleed-masstest <--- Tobias Dussa, also Takes a CSV file with host names for input and ports as parameter ? offline: http://s3.jspenguin.org/ssltest.py ? offline: https://github.com/titanous/heartbleeder List of vulnerable Linux distributions: . Anyone have any more? -- TTFN, patrick On Apr 08, 2014, at 12:11 , Jonathan Lassoff wrote: > For testing, I've had good luck with > https://github.com/titanous/heartbleeder and > https://gist.github.com/takeshixx/10107280 > > Both are mostly platform-independent, so they should be able to work even > if you don't have a modern OpenSSL to test with. > > Cheers and good luck (you're going to need it), > jof > > On Tue, Apr 8, 2014 at 5:03 PM, Michael Thomas wrote: > >> Just as a data point, I checked the servers I run and it's a good thing I >> didn't reflexively update them first. >> On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have >> the vulnerability, but the >> ones queued up for update do. I assume that redhat will get the patched >> version soon but be careful! >> >> Mike >> >> >> On 04/07/2014 10:06 PM, Paul Ferguson wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> I'm really surprised no one has mentioned this here yet... >>> >>> FYI, >>> >>> - - ferg >>> >>> >>> >>> Begin forwarded message: >>> >>> From: Rich Kulawiec Subject: Serious bug in >>>> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >>>> 9:27:40 PM EDT >>>> >>>> This reaches across many versions of Linux and BSD and, I'd >>>> presume, into some versions of operating systems based on them. >>>> OpenSSL is used in web servers, mail servers, VPNs, and many other >>>> places. >>>> >>>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >>>> revealed >>>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability- >>>> revealed-7000028166/ >>>> >>>> Technical details: Heartbleed Bug http://heartbleed.com/ >>>> >>>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >>>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >>>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >>>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >>>> >>>> >>> - -- Paul Ferguson >>> VP Threat Intelligence, IID >>> PGP Public Key ID: 0x54DC85B2 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf >>> 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e >>> =aAzE >>> -----END PGP SIGNATURE----- >>> >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From sclark at netwolves.com Tue Apr 8 16:18:31 2014 From: sclark at netwolves.com (Steve Clark) Date: Tue, 08 Apr 2014 12:18:31 -0400 Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53442157.2030104@netwolves.com> <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: 1396973915190-016-00978972.sclark.netwolves.com@sclark66.netwolves.com According to the changelog it cvs is fixed now. $ rpm -qa|grep openssl openssl-1.0.1e-16.el6_5.7.x86_64 openssl-devel-1.0.1e-16.el6_5.7.x86_64 Tue Apr 8 12:17:25 EDT 2014 Z643357:~ $ rpm -q --changelog openssl | less * Mon Apr 07 2014 Tom?s( Mr?z 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension On 04/08/2014 12:11 PM, Jonathan Lassoff wrote: > For testing, I've had good luck with > https://github.com/titanous/heartbleeder and > https://gist.github.com/takeshixx/10107280 > > Both are mostly platform-independent, so they should be able to work even > if you don't have a modern OpenSSL to test with. > > Cheers and good luck (you're going to need it), > jof > > On Tue, Apr 8, 2014 at 5:03 PM, Michael Thomas wrote: > >> Just as a data point, I checked the servers I run and it's a good thing I >> didn't reflexively update them first. >> On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have >> the vulnerability, but the >> ones queued up for update do. I assume that redhat will get the patched >> version soon but be careful! >> >> Mike >> >> >> On 04/07/2014 10:06 PM, Paul Ferguson wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> I'm really surprised no one has mentioned this here yet... >>> >>> FYI, >>> >>> - - ferg >>> >>> >>> >>> Begin forwarded message: >>> >>> From: Rich Kulawiec Subject: Serious bug in >>>> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >>>> 9:27:40 PM EDT >>>> >>>> This reaches across many versions of Linux and BSD and, I'd >>>> presume, into some versions of operating systems based on them. >>>> OpenSSL is used in web servers, mail servers, VPNs, and many other >>>> places. >>>> >>>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >>>> revealed >>>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability- >>>> revealed-7000028166/ >>>> >>>> Technical details: Heartbleed Bug http://heartbleed.com/ >>>> >>>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >>>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >>>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >>>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >>>> >>>> >>> - -- Paul Ferguson >>> VP Threat Intelligence, IID >>> PGP Public Key ID: 0x54DC85B2 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.22 (MingW32) >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf >>> 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e >>> =aAzE >>> -----END PGP SIGNATURE----- >>> >> >> -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From ruben.roegels at jumping-frog.org Tue Apr 8 09:00:13 2014 From: ruben.roegels at jumping-frog.org (=?ISO-8859-15?Q?Ruben_R=F6gels?=) Date: Tue, 08 Apr 2014 11:00:13 +0200 Subject: web.de security contact Message-ID: <5343BA9D.8090101@jumping-frog.org> Hi, someone knowing a security contact for web.de, please contact me off list. Thanks! Regards, Ruben From max at mxcrypt.com Tue Apr 8 17:07:00 2014 From: max at mxcrypt.com (Maxim Khitrov) Date: Tue, 8 Apr 2014 13:07:00 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: Here's mine, written in Go: http://code.google.com/p/mxk/source/browse/go1/tlshb/ To build the binary, install Mercurial, install Go (golang.org), set GOPATH to some empty directory, then run: go get code.google.com/p/mxk/go1/tlshb - Max On Tue, Apr 8, 2014 at 12:16 PM, Patrick W. Gilmore wrote: > Lots of tools available. I'm with ferg, surprised more haven't been mentioned here. > > Tools to check for the bug: > ? on your own box: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py > ? online: http://filippo.io/Heartbleed/ (use carefully as they might log what you check) > ? online: http://possible.lv/tools/hb/ > ? offline: https://github.com/tdussa/heartbleed-masstest <--- Tobias Dussa, also Takes a CSV file with host names for input and ports as parameter > ? offline: http://s3.jspenguin.org/ssltest.py > ? offline: https://github.com/titanous/heartbleeder > > List of vulnerable Linux distributions: . > > Anyone have any more? > > -- > TTFN, > patrick > > > On Apr 08, 2014, at 12:11 , Jonathan Lassoff wrote: > >> For testing, I've had good luck with >> https://github.com/titanous/heartbleeder and >> https://gist.github.com/takeshixx/10107280 >> >> Both are mostly platform-independent, so they should be able to work even >> if you don't have a modern OpenSSL to test with. >> >> Cheers and good luck (you're going to need it), >> jof >> >> On Tue, Apr 8, 2014 at 5:03 PM, Michael Thomas wrote: >> >>> Just as a data point, I checked the servers I run and it's a good thing I >>> didn't reflexively update them first. >>> On Centos 6.0, the default openssl is 1.0.0 which supposedly doesn't have >>> the vulnerability, but the >>> ones queued up for update do. I assume that redhat will get the patched >>> version soon but be careful! >>> >>> Mike >>> >>> >>> On 04/07/2014 10:06 PM, Paul Ferguson wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> I'm really surprised no one has mentioned this here yet... >>>> >>>> FYI, >>>> >>>> - - ferg >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>> From: Rich Kulawiec Subject: Serious bug in >>>>> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >>>>> 9:27:40 PM EDT >>>>> >>>>> This reaches across many versions of Linux and BSD and, I'd >>>>> presume, into some versions of operating systems based on them. >>>>> OpenSSL is used in web servers, mail servers, VPNs, and many other >>>>> places. >>>>> >>>>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >>>>> revealed >>>>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability- >>>>> revealed-7000028166/ >>>>> >>>>> Technical details: Heartbleed Bug http://heartbleed.com/ >>>>> >>>>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >>>>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >>>>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >>>>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >>>>> >>>>> >>>> - -- Paul Ferguson >>>> VP Threat Intelligence, IID >>>> PGP Public Key ID: 0x54DC85B2 >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2.0.22 (MingW32) >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf >>>> 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e >>>> =aAzE >>>> -----END PGP SIGNATURE----- >>>> >>> >>> >>> > From betty at newnog.org Tue Apr 8 18:58:01 2014 From: betty at newnog.org (Betty Burke ) Date: Tue, 8 Apr 2014 14:58:01 -0400 Subject: [NANOG-announce] NANOG on THE ROAD - LA - May 20, 2014 Message-ID: The NANOG on the Road series will be coming to Los Angeleson May 20, 2014. Hosted by NANOG in partnership with Los Nettos at the USC campus, the program will include research and education presentations along with relevant NANOG meeting content. Topics to include security, IPv6, research and commercial network differences, along with network tools discussion. The meeting will be held at the Radisson Hotel Los Angeles- Midtown@ USC on Tuesday, May 20, 2014. Registration is required, however there is no fee to attend. Please visit the NOTR website and register today . The morning will include featured speakers. Lunch will be provided, followed by an afternoon of NANOG presentations. The day will conclude with a graduate student poster session during the Closing Reception. Please pass along this information to those who may not be able to attend a full NANOG meeting, and wish to learn more about NANOG and the topics discussed. Sincerely, Betty on behalf of the NOTR Programming Committee -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From frnkblk at iname.com Tue Apr 8 19:12:00 2014 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 8 Apr 2014 14:12:00 -0500 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <534383D8.8000006@mykolab.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> Message-ID: <008501cf535e$6b0e6350$412b29f0$@iname.com> If we would front our HTTPS services with a (OpenSSL vulnerable) load-balancer that does the SSL work and we just use HTTP to the service, will that mitigate information loss that's possible with this exploit? Or will the OpenSSL code on the load-balancer also store or "cache" content? Frank -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at mykolab.com] Sent: Tuesday, April 08, 2014 12:07 AM To: NANOG Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm really surprised no one has mentioned this here yet... FYI, - - ferg Begin forwarded message: > From: Rich Kulawiec Subject: Serious bug in > ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at > 9:27:40 PM EDT > > This reaches across many versions of Linux and BSD and, I'd > presume, into some versions of operating systems based on them. > OpenSSL is used in web servers, mail servers, VPNs, and many other > places. > > Writeup: Heartbleed: Serious OpenSSL zero day vulnerability > revealed > http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revea led-7000028166/ > > Technical details: Heartbleed Bug http://heartbleed.com/ > > OpenSSL versions affected (from link just above): OpenSSL 1.0.1 > through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT > vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is > NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e =aAzE -----END PGP SIGNATURE----- From laszlo at heliacal.net Tue Apr 8 19:14:57 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Tue, 8 Apr 2014 19:14:57 +0000 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <008501cf535e$6b0e6350$412b29f0$@iname.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <008501cf535e$6b0e6350$412b29f0$@iname.com> Message-ID: You can still potentially access all the same information since it all goes through the load balancer. Interesting bits of info are things like Cookie: headers being sent by clients and sitting in a buffer. Try one of the testing tools mentioned and see if you can see any info from other clients. It's almost like having remote tcpdump on the web server - you can copy down the in-memory process image. -Laszlo On Apr 8, 2014, at 7:12 PM, "Frank Bulk" wrote: > If we would front our HTTPS services with a (OpenSSL vulnerable) > load-balancer that does the SSL work and we just use HTTP to the service, > will that mitigate information loss that's possible with this exploit? Or > will the OpenSSL code on the load-balancer also store or "cache" content? > > Frank > > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster at mykolab.com] > Sent: Tuesday, April 08, 2014 12:07 AM > To: NANOG > Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm really surprised no one has mentioned this here yet... > > FYI, > > - - ferg > > > > Begin forwarded message: > >> From: Rich Kulawiec Subject: Serious bug in >> ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at >> 9:27:40 PM EDT >> >> This reaches across many versions of Linux and BSD and, I'd >> presume, into some versions of operating systems based on them. >> OpenSSL is used in web servers, mail servers, VPNs, and many other >> places. >> >> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability >> revealed >> > http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-revea > led-7000028166/ >> >> Technical details: Heartbleed Bug http://heartbleed.com/ >> >> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 >> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT >> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is >> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable >> > > > - -- > Paul Ferguson > VP Threat Intelligence, IID > PGP Public Key ID: 0x54DC85B2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf > 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e > =aAzE > -----END PGP SIGNATURE----- > > > > From cma at cmadams.net Tue Apr 8 19:15:36 2014 From: cma at cmadams.net (Chris Adams) Date: Tue, 8 Apr 2014 14:15:36 -0500 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <008501cf535e$6b0e6350$412b29f0$@iname.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <008501cf535e$6b0e6350$412b29f0$@iname.com> Message-ID: <20140408191536.GB32552@cmadams.net> Once upon a time, Frank Bulk said: > If we would front our HTTPS services with a (OpenSSL vulnerable) > load-balancer that does the SSL work and we just use HTTP to the service, > will that mitigate information loss that's possible with this exploit? Or > will the OpenSSL code on the load-balancer also store or "cache" content? One of the biggest risks that could be exposed in this particular case is the SSL private key. If your front end is handling SSL with OpenSSL, it'll have the key, and that is vulnerable. -- Chris Adams From ahebert at pubnix.net Tue Apr 8 19:37:38 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 08 Apr 2014 15:37:38 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <534386BC.9000406@alter3d.ca> Message-ID: <53445002.5010007@pubnix.net> Hi, I was wondering why most of my secure services didn't show up as vulnerable... ----- It do not seems to affect those services that require a valid user certificate. aka, in apache 2.2 SSLVerifyClient Require SSLVerifyDepth 1 (up to 10) I couldn't find a way to use the HB before satisfying the verify. I might be wrong. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 04/08/14 08:18, David Hubbard wrote: > Don't forget to restart every daemon that was using the old library as > well, or just reboot. > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Tuesday, April 08, 2014 1:19 AM > To: nanog at nanog.org > Subject: Re: Serious bug in ubiquitous OpenSSL library: "Heartbleed" > > Not just run the updates -- all private keys should be changed too, on > the assumption that they've been compromised already. THAT is going to > be the crappy part of this. > > - Pete > > > On 4/8/2014 1:13 AM, David Hubbard wrote: >> RHEL and CentOS both have patches out as of a couple hours ago, so run > >> those updates! CentOS' mirrors do not all have it yet, so if you are >> updating, make sure you get the >> 1.0.1e-16.el6_5.7 version and not older. >> >> David >> >> -----Original Message----- >> From: Paul Ferguson [mailto:fergdawgster at mykolab.com] >> Sent: Tuesday, April 08, 2014 1:07 AM >> To: NANOG >> Subject: Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed" >> > I'm really surprised no one has mentioned this here yet... > > FYI, > > - ferg > > > > Begin forwarded message: > > >>> From: Rich Kulawiec Subject: Serious bug in ubiquitous > >>> OpenSSL library: "Heartbleed" Date: April 7, 2014 at 9:27:40 PM EDT > >>> > >>> This reaches across many versions of Linux and BSD and, I'd presume, > >>> into some versions of operating systems based on them. > >>> OpenSSL is used in web servers, mail servers, VPNs, and many other > >>> places. > >>> > >>> Writeup: Heartbleed: Serious OpenSSL zero day vulnerability revealed > >>> http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerabilit > >>> y > >>> -revealed-7000028166/ > >>> > >>> Technical details: Heartbleed Bug http://heartbleed.com/ > >>> > >>> OpenSSL versions affected (from link just above): OpenSSL 1.0.1 > >>> through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT > >>> vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is > >>> NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable > >>> > >> >> >> >> > > > > > > > From davec at curado.org Tue Apr 8 22:15:36 2014 From: davec at curado.org (Dave Curado) Date: Tue, 08 Apr 2014 18:15:36 -0400 Subject: any network folks from github.com here? Message-ID: <53447508.7070403@curado.org> Please contact me off list? Thank you. From jschiel at flowtools.net Tue Apr 8 23:56:45 2014 From: jschiel at flowtools.net (Me) Date: Tue, 08 Apr 2014 17:56:45 -0600 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> Message-ID: <53448CBD.7060205@flowtools.net> On 04/08/2014 10:16 AM, Patrick W. Gilmore wrote: > Lots of tools available. I'm with ferg, surprised more haven't been mentioned here. > > Tools to check for the bug: > ? on your own box: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py > ? online: http://filippo.io/Heartbleed/ (use carefully as they might log what you check) > ? online: http://possible.lv/tools/hb/ > ? offline: https://github.com/tdussa/heartbleed-masstest <--- Tobias Dussa, also Takes a CSV file with host names for input and ports as parameter > ? offline: http://s3.jspenguin.org/ssltest.py > ? offline: https://github.com/titanous/heartbleeder > > List of vulnerable Linux distributions: . > > Anyone have any more? > Thanks for the expanded list, I had some of these already. I'm not comfortable in letting some online code that I can't see test my site though. --John From bmanning at vacation.karoshi.com Wed Apr 9 00:59:32 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Apr 2014 17:59:32 -0700 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <53448CBD.7060205@flowtools.net> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> Message-ID: <20140409005932.GA31139@vacation.karoshi.com> On Tue, Apr 08, 2014 at 05:56:45PM -0600, Me wrote: > > On 04/08/2014 10:16 AM, Patrick W. Gilmore wrote: > >Lots of tools available. I'm with ferg, surprised more haven't been mentioned here. > > > >Tools to check for the bug: > > ? on your own box: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py > > ? online: http://filippo.io/Heartbleed/ (use carefully as they might log what you check) > > ? online: http://possible.lv/tools/hb/ > > ? offline: https://github.com/tdussa/heartbleed-masstest <--- Tobias Dussa, also Takes a CSV file with host names for input and ports as parameter > > ? offline: http://s3.jspenguin.org/ssltest.py > > ? offline: https://github.com/titanous/heartbleeder > > > >List of vulnerable Linux distributions: . > > > >Anyone have any more? > > > Thanks for the expanded list, I had some of these already. I'm not > comfortable in letting some online code that I can't see test my > site though. > > --John or, there is this: http://git.openssl.org/gitweb/?p=openssl.git /bill From rs at seastrom.com Wed Apr 9 03:46:31 2014 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 08 Apr 2014 23:46:31 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <53448CBD.7060205@flowtools.net> (Me's message of "Tue, 08 Apr 2014 17:56:45 -0600") References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> Message-ID: <86bnwbnp0o.fsf@valhalla.seastrom.com> Me writes: > Thanks for the expanded list, I had some of these already. I'm not > comfortable in letting some online code that I can't see test my site > though. If that's true, you might want to consider immediately disconnecting your systems from the Internet and never re-connecting them. After all, theres a lot of online unseen code testing your site already whether you like it or not. -r From bmanning at vacation.karoshi.com Wed Apr 9 03:57:19 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Apr 2014 20:57:19 -0700 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <86bnwbnp0o.fsf@valhalla.seastrom.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> Message-ID: <20140409035719.GA31830@vacation.karoshi.com> On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote: > > Me writes: > > > Thanks for the expanded list, I had some of these already. I'm not > > comfortable in letting some online code that I can't see test my site > > though. > > If that's true, you might want to consider immediately disconnecting > your systems from the Internet and never re-connecting them. After > all, theres a lot of online unseen code testing your site already > whether you like it or not. > > -r > Diodes.... /bill From j at arpa.com Wed Apr 9 05:18:00 2014 From: j at arpa.com (jamie rishaw) Date: Wed, 9 Apr 2014 00:18:00 -0500 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <20140409035719.GA31830@vacation.karoshi.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <20140409035719.GA31830@vacation.karoshi.com> Message-ID: Here's the only way to keep a system safe from Internet hackers: http://goo.gl/ZvGrXw [google images] -j From mpalmer at hezmatt.org Wed Apr 9 05:28:09 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Wed, 9 Apr 2014 15:28:09 +1000 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <20140409035719.GA31830@vacation.karoshi.com> Message-ID: <20140409052809.GB15800@hezmatt.org> On Wed, Apr 09, 2014 at 12:18:00AM -0500, jamie rishaw wrote: > Here's the only way to keep a system safe from Internet hackers: > > http://goo.gl/ZvGrXw [google images] /me is disappointed that wasn't a pair of scissors - Matt -- Sure, it's possible to write C in an object-oriented way. But, in practice, getting an entire team to do that is like telling them to walk along a straight line painted on the floor, with the lights off. -- Tess Snider, slug-chat at slug.org.au From dougb at dougbarton.us Wed Apr 9 05:50:26 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 08 Apr 2014 22:50:26 -0700 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <20140409052809.GB15800@hezmatt.org> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <20140409035719.GA31830@vacation.karoshi.com> <20140409052809.GB15800@hezmatt.org> Message-ID: <5344DFA2.6040100@dougbarton.us> On 04/08/2014 10:28 PM, Matt Palmer wrote: > On Wed, Apr 09, 2014 at 12:18:00AM -0500, jamie rishaw wrote: >> Here's the only way to keep a system safe from Internet hackers: >> >> http://goo.gl/ZvGrXw [google images] > > /me is disappointed that wasn't a pair of scissors ... or a backhoe From Valdis.Kletnieks at vt.edu Wed Apr 9 14:00:11 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Apr 2014 10:00:11 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: Your message of "Tue, 08 Apr 2014 22:50:26 -0700." <5344DFA2.6040100@dougbarton.us> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <20140409035719.GA31830@vacation.karoshi.com> <20140409052809.GB15800@hezmatt.org> <5344DFA2.6040100@dougbarton.us> Message-ID: <39537.1397052011@turing-police.cc.vt.edu> On Tue, 08 Apr 2014 22:50:26 -0700, Doug Barton said: > On 04/08/2014 10:28 PM, Matt Palmer wrote: > > On Wed, Apr 09, 2014 at 12:18:00AM -0500, jamie rishaw wrote: > >> Here's the only way to keep a system safe from Internet hackers: > >> > >> http://goo.gl/ZvGrXw [google images] > > > > /me is disappointed that wasn't a pair of scissors > > ... or a backhoe Speaking of which, it's finally backhoe mating season across much of North America - anybody seeing an uptick in outages due to backhoe mating dances? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From royce at techsolvency.com Wed Apr 9 15:13:47 2014 From: royce at techsolvency.com (Royce Williams) Date: Wed, 9 Apr 2014 07:13:47 -0800 Subject: Yahoo DMARC breakage Message-ID: Am I interpreting this correctly -- that Yahoo's implementation of DMARC is broken, such that anyone using a Yahoo address to participate in a mailing list is dead in the water? http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html http://www.theregister.co.uk/2014/04/08/yahoo_breaks_every_mailing_list_in_the_world_says_email_guru/ My mailman bounce action notifications are going through the roof. Royce From jschiel at flowtools.net Wed Apr 9 15:26:04 2014 From: jschiel at flowtools.net (Me) Date: Wed, 09 Apr 2014 09:26:04 -0600 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <86bnwbnp0o.fsf@valhalla.seastrom.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> Message-ID: <5345668C.30807@flowtools.net> On 04/08/2014 09:46 PM, Rob Seastrom wrote: > If that's true, you might want to consider immediately disconnecting > your systems from the Internet and never re-connecting them. After > all, theres a lot of online unseen code testing your site already > whether you like it or not. > > -r > Sending someone to a site with obscure TLDs of .io or .lv doesn't help in these situations. This is a perfect opportunity for someone to set up a drive by site to drop malware on someone's computer. I'm not saying these sites did that but in order to see the code, someone would have to visit the site first. I personally would use wget instead of a browser for sites like these and did so in this situation. And yes, your point is not lost on me, there are tons of sites that have obfuscated code and malware running on them, I know that. --John From patrick at ianai.net Wed Apr 9 15:31:48 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 9 Apr 2014 11:31:48 -0400 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <5345668C.30807@flowtools.net> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <5345668C.30807@flowtools.net> Message-ID: <7644C8C8-A93F-498A-B883-DE69524ED058@ianai.net> On Apr 09, 2014, at 11:26 , Me wrote: > On 04/08/2014 09:46 PM, Rob Seastrom wrote: >> If that's true, you might want to consider immediately disconnecting >> your systems from the Internet and never re-connecting them. After >> all, theres a lot of online unseen code testing your site already >> whether you like it or not. >> >> -r >> > Sending someone to a site with obscure TLDs of .io or .lv doesn't help in these situations. This is a perfect opportunity for someone to set up a drive by site to drop malware on someone's computer. > > I'm not saying these sites did that but in order to see the code, someone would have to visit the site first. I personally would use wget instead of a browser for sites like these and did so in this situation. > > And yes, your point is not lost on me, there are tons of sites that have obfuscated code and malware running on them, I know that. In the list of tools were several sites with code you could download, review, and run locally on your machine to test against the bug. However, I trust some of the sites listed. My new favorite is , since it takes ports other than 443 and gives back a lot of info. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From niels=nanog at bakker.net Wed Apr 9 15:39:32 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 9 Apr 2014 17:39:32 +0200 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <5345668C.30807@flowtools.net> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <5345668C.30807@flowtools.net> Message-ID: <20140409153932.GE36211@burnout.tpb.net> * jschiel at flowtools.net (Me) [Wed 09 Apr 2014, 17:26 CEST]: >Sending someone to a site with obscure TLDs of .io or .lv doesn't >help in these situations. This is a perfect opportunity for someone >to set up a drive by site to drop malware on someone's computer. Yes, because obviously .com registrations are limited to good people only. *eyeroll* -- Niels. From jschiel at flowtools.net Wed Apr 9 15:51:07 2014 From: jschiel at flowtools.net (Me) Date: Wed, 09 Apr 2014 09:51:07 -0600 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <20140409153932.GE36211@burnout.tpb.net> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <5345668C.30807@flowtools.net> <20140409153932.GE36211@burnout.tpb.net> Message-ID: <53456C6B.8030002@flowtools.net> On 04/09/2014 09:39 AM, Niels Bakker wrote: > * jschiel at flowtools.net (Me) [Wed 09 Apr 2014, 17:26 CEST]: >> Sending someone to a site with obscure TLDs of .io or .lv doesn't >> help in these situations. This is a perfect opportunity for someone >> to set up a drive by site to drop malware on someone's computer. > > Yes, because obviously .com registrations are limited to good people > only. *eyeroll* > > > -- Niels. > Guess you didn't read my last sentence, I know the .coms and .orgs, and such don't all belong to the good folks. *sigh*. --John From niels=nanog at bakker.net Wed Apr 9 15:59:31 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 9 Apr 2014 17:59:31 +0200 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <53456C6B.8030002@flowtools.net> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <5345668C.30807@flowtools.net> <20140409153932.GE36211@burnout.tpb.net> <53456C6B.8030002@flowtools.net> Message-ID: <20140409155931.GF36211@burnout.tpb.net> * jschiel at flowtools.net (Me) [Wed 09 Apr 2014, 17:51 CEST]: >On 04/09/2014 09:39 AM, Niels Bakker wrote: >>* jschiel at flowtools.net (Me) [Wed 09 Apr 2014, 17:26 CEST]: >> >>>Sending someone to a site with obscure TLDs of .io or .lv >>>doesn't help in these situations. This is a perfect opportunity >>>for someone to set up a drive by site to drop malware on >>>someone's computer. >> >>Yes, because obviously .com registrations are limited to good >>people only. *eyeroll* > >Guess you didn't read my last sentence, I know the .coms and .orgs, and >such don't all belong to the good folks. > >*sigh*. Then why single out the .io and .lv's? Maybe you missed the trend (by now a few years old) to get domains in those and similar ccTLD's for startups? Why even try to portray them as less trusted, as you plainly did in the quoted paragraph? -- Niels. From rsk at gsp.org Wed Apr 9 16:26:22 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 9 Apr 2014 12:26:22 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: Message-ID: <20140409162622.GA31248@gsp.org> On Wed, Apr 09, 2014 at 07:13:47AM -0800, Royce Williams wrote: > Am I interpreting this correctly -- that Yahoo's implementation of > DMARC is broken, such that anyone using a Yahoo address to participate > in a mailing list is dead in the water? Yes. It seems that Yahoo wasn't content with just breaking Flickr [1] but decided to branch out into email as well. John Levine's comments (in the first link you provided) have been, I think, the most articulate on the subject. The worst part of this is (a) it creates massive problems for everyone running mailing lists and (b) it doesn't solve any problems for anybody, including Yahoo and its users. Mitigation tactics vary, but one is to put everyone using a yahoo.com address on moderation, using whatever mechanism the mailing list manager (e.g. Mailman, majordomo, etc.) provides. Another is to encourage people with Yahoo accounts to move elsewhere. (There's nothing "wrong" with DMARC, per se, although I remain somewhat skeptical about its widespread/long-term utility. What's "wrong" here is that it's been badly misapplied to a use case that it doesn't fit. To borrow a line from Zathras, "This...is wrong tool.") ---rsk [1] http://boingboing.net/2014/04/07/restoring-cc-attribution-to-fl.html From simestd at netexpress.com Wed Apr 9 16:52:42 2014 From: simestd at netexpress.com (Tom Simes) Date: Wed, 09 Apr 2014 08:52:42 -0800 Subject: Yahoo DMARC breakage In-Reply-To: References: Message-ID: <53457ADA.2080009@netexpress.com> On 04/09/14 07:13, Royce Williams wrote: > Am I interpreting this correctly -- that Yahoo's implementation of > DMARC is broken, such that anyone using a Yahoo address to participate > in a mailing list is dead in the water? > > http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html > http://www.theregister.co.uk/2014/04/08/yahoo_breaks_every_mailing_list_in_the_world_says_email_guru/ > > My mailman bounce action notifications are going through the roof. > > Royce > Ugly. Confirmed across a variety of Mailman lists I administer. Harvested addresses from the bounce logs, scripted up a notification to small batches of addresses and moderated all @yahoo! addresses on the lists. Can you say Collateral! Damage! Yahoo! -- Tom ====================================================================== "Z80 system stack overflow. Shut 'er down Scotty, she's sucking mud again!" - Error message on XENIX v3.0 Tom Simes simestd at netexpress.com ====================================================================== From dhc2 at dcrocker.net Wed Apr 9 17:27:55 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 09 Apr 2014 12:27:55 -0500 Subject: Yahoo DMARC breakage In-Reply-To: References: Message-ID: <5345831B.4030705@dcrocker.net> On 4/9/2014 10:13 AM, Royce Williams wrote: > Am I interpreting this correctly -- that Yahoo's implementation of > DMARC is broken, such that anyone using a Yahoo address to participate > in a mailing list is dead in the water? Their implementation is not 'broken'. Rather, Yahoo has made a very conscious policy decision. So the "such that" clause of your sentence is correct. That is, the effect really is what you describe. But it's the result of an informed corporate choice rather than software or operations error. From background exchanges and Yahoo participation in the development of DMARC, I believe they fully understood the technical and operations effects of the decision. Whether it is the 'right' choice is primarily a political debate, and I'm not commenting on that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jimpop at gmail.com Wed Apr 9 18:36:01 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 9 Apr 2014 14:36:01 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <53457ADA.2080009@netexpress.com> References: <53457ADA.2080009@netexpress.com> Message-ID: > Confirmed across a variety of Mailman lists I administer. Mailman can be patched to reject/discard posts from members with p=reject. https://code.launchpad.net/~jimpop/mailman/dmarc-reject I'm sort of glad that Yahoo did what they did, people are now seeing the dark side of DMARC. WooHoo!! Vindication! -Jim P. From jschiel at flowtools.net Wed Apr 9 18:49:45 2014 From: jschiel at flowtools.net (Me) Date: Wed, 09 Apr 2014 12:49:45 -0600 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <20140409155931.GF36211@burnout.tpb.net> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <5345668C.30807@flowtools.net> <20140409153932.GE36211@burnout.tpb.net> <53456C6B.8030002@flowtools.net> <20140409155931.GF36211@burnout.tpb.net> Message-ID: <53459649.3030205@flowtools.net> On 04/09/2014 09:59 AM, Niels Bakker wrote: > > > Then why single out the .io and .lv's? Maybe you missed the trend (by > now a few years old) to get domains in those and similar ccTLD's for > startups? Why even try to portray them as less trusted, as you > plainly did in the quoted paragraph? > > > -- Niels. > No, I didn't miss it, it's been a long time in coming. I happened to point .io and .lv because those are the ones that were shared on list and are not common, at least not to me. My concern mostly is with those that disregard what the link name is and just click blindly because it's a link into the issue that is affecting them that day. Instead of picking on a specific tld, I should have more clearly stated I'd rather folks do this type of checking with code that can run locally. This way we can validate the code once and run as many times as we want. Relying on a web page doesn't always work because that site may be overloaded or the site owner hits some limit and the page is not available so you have to go validate the code from yet another site. I did have some versions of the code that was shared and I thanked the OP for the other versions. --John From dwing at cisco.com Wed Apr 9 19:42:29 2014 From: dwing at cisco.com (Dan Wing) Date: Wed, 9 Apr 2014 12:42:29 -0700 Subject: real-world data about fragmentation In-Reply-To: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> References: <253521C4-EA53-4CF3-BC5F-EBC424989DFC@hopcount.ca> Message-ID: On Apr 2, 2014, at 11:14 AM, Joe Abley wrote: > Hi all, > > It's common wisdom that a datagram that needs to be fragmented between endpoints (because it is bigger than the path MTU) will demonstrate less reliable delivery and reassembly than a datagram that doesn't need to be fragmented, because math, firewall, other, take your pick. > > Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? > > For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. > > What does the curve look like between 576 bytes and 10,000 bytes? > > I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. > > Anybody have any pointers? IPv4 and IPv6 are both interesting. Seems a good thing for RIPE Atlas probes to measure. But they are probably not generally connected to representative networks (read: poor networks). -d From johnl at iecc.com Wed Apr 9 20:05:58 2014 From: johnl at iecc.com (John Levine) Date: 9 Apr 2014 20:05:58 -0000 Subject: Yahoo DMARC breakage In-Reply-To: <5345831B.4030705@dcrocker.net> Message-ID: <20140409200558.3314.qmail@joyce.lan> In article <5345831B.4030705 at dcrocker.net> you write: >On 4/9/2014 10:13 AM, Royce Williams wrote: >> Am I interpreting this correctly -- that Yahoo's implementation of >> DMARC is broken, such that anyone using a Yahoo address to participate >> in a mailing list is dead in the water? > > >Their implementation is not 'broken'. I'd say it's pretty badly broken if Yahoo intends for their web mail to continue to be a general purpose mail system for consumers. If they want to make it something else, that's certainly their right, but it would have been nice if they'd given us some advance warning so we could take the yahoo.com addresses off our lists. R's, John From bill at herrin.us Wed Apr 9 21:15:59 2014 From: bill at herrin.us (William Herrin) Date: Wed, 9 Apr 2014 17:15:59 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <20140409200558.3314.qmail@joyce.lan> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> Message-ID: On Wed, Apr 9, 2014 at 4:05 PM, John Levine wrote: > I'd say it's pretty badly broken if Yahoo intends for their web mail > to continue to be a general purpose mail system for consumers. If > they want to make it something else, that's certainly their right, but > it would have been nice if they'd given us some advance warning so we > could take the yahoo.com addresses off our lists. Meh. This just means list software will have to rewrite the From header to "From: John Levine " and rely on the Reply-To header for anybody who wants to send a message back to the originator. Maybe this is a good thing - we can stop getting all the "sorry I'm out of the office" emails when posting to a list. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Wed Apr 9 21:24:44 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Apr 2014 17:24:44 -0400 Subject: Yahoo DMARC breakage In-Reply-To: Your message of "Wed, 09 Apr 2014 17:15:59 -0400." References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> Message-ID: <19726.1397078684@turing-police.cc.vt.edu> On Wed, 09 Apr 2014 17:15:59 -0400, William Herrin said: > Meh. This just means list software will have to rewrite the From > header to "From: John Levine " and rely on the > Reply-To header for anybody who wants to send a message back to the > originator. > > Maybe this is a good thing - we can stop getting all the "sorry I'm > out of the office" emails when posting to a list. The sort of programmer that writes out-of-mind software that doesn't employ the long well-known heuristics for detecting mailing lists (starting with checking Return-Path: for "owner-" and similar) will also likely disregard the Reply-To: header. This Is Not A Good Thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jimpop at gmail.com Wed Apr 9 21:35:26 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 9 Apr 2014 17:35:26 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> Message-ID: On Wed, Apr 9, 2014 at 5:15 PM, William Herrin wrote: > On Wed, Apr 9, 2014 at 4:05 PM, John Levine wrote: >> I'd say it's pretty badly broken if Yahoo intends for their web mail >> to continue to be a general purpose mail system for consumers. If >> they want to make it something else, that's certainly their right, but >> it would have been nice if they'd given us some advance warning so we >> could take the yahoo.com addresses off our lists. > > Meh. This just means list software will have to rewrite the From > header to "From: John Levine " and rely on the > Reply-To header for anybody who wants to send a message back to the > originator. Or perhaps DMARC can go back to it's original goal. Go here: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Notice the early versions of the spec contained the word "transactional", notice the current version has it removed. Also notice that one of the authors is from Yahoo!. > Maybe this is a good thing - we can stop getting all the "sorry I'm > out of the office" emails when posting to a list. The OoO problem is a Client/MUA problem. Most (other than Lotus Notes, and some older copies of Outlook) properly tag OoO emails with well-defined headers (RFC 3834). -Jim P. From ted at io-tx.com Wed Apr 9 21:33:08 2014 From: ted at io-tx.com (Ted Hatfield) Date: Wed, 9 Apr 2014 16:33:08 -0500 (CDT) Subject: Yahoo DMARC breakage In-Reply-To: <19726.1397078684@turing-police.cc.vt.edu> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> Message-ID: On Wed, 9 Apr 2014, Valdis.Kletnieks at vt.edu wrote: > On Wed, 09 Apr 2014 17:15:59 -0400, William Herrin said: > >> Meh. This just means list software will have to rewrite the From >> header to "From: John Levine " and rely on the >> Reply-To header for anybody who wants to send a message back to the >> originator. >> >> Maybe this is a good thing - we can stop getting all the "sorry I'm >> out of the office" emails when posting to a list. > > The sort of programmer that writes out-of-mind software that doesn't > employ the long well-known heuristics for detecting mailing lists > (starting with checking Return-Path: for "owner-" and similar) will also > likely disregard the Reply-To: header. This Is Not A Good Thing. > According to the DMARC FAQ at http://dmarc.org/faq.html Q: I operate a mailing list and I want to interoperate with DMARC, what should I do? DMARC introduces the concept of aligned identifiers. It means the domain in the from header must match the d= in the DKIM signature and the domain in the mail from envelope. 1: operate as a strict forwarder, where the message is not changed and the validity of the DKIM signature is preserved 2: introduce an "Original Authentication Results" header to indicate you have performed the authentication and you are validating it 3: take ownership of the email, by removing the DKIM signature and putting your own as well as changing the from header in the email to contain an email address within your mailing list domain. Option 1 is out of the question. Option 3 is what a lot of people are starting to do. Can anybody tell me what exactly option 2 is. What exactly is an "Original Authentication Results" header? I'm already doing my own research but if someone can give a concise answer as to what it is that would be appreciated. Ted Hatfield From jeff-kell at utc.edu Wed Apr 9 21:49:27 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 9 Apr 2014 17:49:27 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <19726.1397078684@turing-police.cc.vt.edu> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> Message-ID: <5345C067.9040003@utc.edu> On 4/9/2014 5:24 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 09 Apr 2014 17:15:59 -0400, William Herrin said: > >> Meh. This just means list software will have to rewrite the From >> header to "From: John Levine " and rely on the >> Reply-To header for anybody who wants to send a message back to the >> originator. >> >> Maybe this is a good thing - we can stop getting all the "sorry I'm >> out of the office" emails when posting to a list. > > The sort of programmer that writes out-of-mind software that doesn't > employ the long well-known heuristics for detecting mailing lists > (starting with checking Return-Path: for "owner-" and similar) will also > likely disregard the Reply-To: header. This Is Not A Good Thing. The most "sane" out-of-mind response should only be sent *if* the out-of-mind person is named explicitly as a recipient in the RFC822 header. Anything To: somelist at somehost does not qualify :) Jeff From jimpop at gmail.com Wed Apr 9 21:56:06 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 9 Apr 2014 17:56:06 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5345C067.9040003@utc.edu> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> Message-ID: > The most "sane" out-of-mind response should only be sent *if* the > out-of-mind person is named explicitly as a recipient in the RFC822 > header. Anything To: somelist at somehost does not qualify :) Funny story: When I was at IBM I filed that as a bug with Lotus Notes. The Notes team rejected the bug. -Jim P. From dhc2 at dcrocker.net Wed Apr 9 22:05:54 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 09 Apr 2014 17:05:54 -0500 Subject: Yahoo DMARC breakage In-Reply-To: <20140409200558.3314.qmail@joyce.lan> References: <20140409200558.3314.qmail@joyce.lan> Message-ID: <5345C442.5000103@dcrocker.net> On 4/9/2014 3:05 PM, John Levine wrote: > In article <5345831B.4030705 at dcrocker.net> you write: >> Their implementation is not 'broken'. > > I'd say it's pretty badly broken if Yahoo intends for their web mail > to continue to be a general purpose mail system for consumers. If > they want to make it something else, that's certainly their right, but > it would have been nice if they'd given us some advance warning so we > could take the yahoo.com addresses off our lists. If I point a gun at you, and pull the trigger, but maybe shouldn't have done that, the gun is not broken. Management decisions that are subject to criticism does not represent erroneous performance by the folks tasked with doing the task mandated. Everything they are doing is "legal". Your (possibly entirely valid) assessment that their action is ill-advised or unpleasant does not equal broken. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From bmanning at vacation.karoshi.com Wed Apr 9 22:11:12 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 9 Apr 2014 15:11:12 -0700 Subject: Yahoo DMARC breakage In-Reply-To: <5345C067.9040003@utc.edu> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> Message-ID: <20140409221112.GA3069@vacation.karoshi.com> On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: > > The most "sane" out-of-mind response should only be sent *if* the > out-of-mind person is named explicitly as a recipient in the RFC822 > header. Anything To: somelist at somehost does not qualify :) > > Jeff and just how is an algorithm supposed to detect that is a single human and not a list? /bill From jeff-kell at utc.edu Wed Apr 9 22:20:26 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 9 Apr 2014 18:20:26 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <20140409221112.GA3069@vacation.karoshi.com> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> Message-ID: <5345C7AA.9000304@utc.edu> On 4/9/2014 6:11 PM, bmanning at vacation.karoshi.com wrote: > On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: >> The most "sane" out-of-mind response should only be sent *if* the >> out-of-mind person is named explicitly as a recipient in the RFC822 >> header. Anything To: somelist at somehost does not qualify :) >> >> Jeff > and just how is an algorithm supposed to detect that > is a single human and not a list? Because *I* set the out-of-office notification for my email address[es]. If I'm not in the recipient list, do not respond. This is a "per user" knob we are talking about here, so it knows darn well what address[es] are me. Jeff From johnl at iecc.com Wed Apr 9 22:27:14 2014 From: johnl at iecc.com (John R. Levine) Date: 9 Apr 2014 16:27:14 -0600 Subject: autoresponding to Yahoo DMARC breakage In-Reply-To: <5345C7AA.9000304@utc.edu> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> Message-ID: >> The most "sane" out-of-mind response should only be sent *if* the >> out-of-mind person is named explicitly as a recipient in the RFC822 >> To: header. Anything To: somelist at somehost does not qualify :) This highly effective trick was in the procmail example vacation script in 1991, and doubtless goes back much farther than that. It's a little dismaying to hear that there are still people writing autoresponders who don't know about it. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2314 bytes Desc: S/MIME Cryptographic Signature URL: From johnl at iecc.com Wed Apr 9 22:37:18 2014 From: johnl at iecc.com (John R. Levine) Date: 9 Apr 2014 16:37:18 -0600 Subject: hack #2 for Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> Message-ID: > 2: introduce an "Original Authentication Results" header to indicate > you have performed the authentication and you are validating it This was someone's hack that doesn't work. The idea is that you make an RFC5451 Authentication-Results header for the incoming message, change the name to original-authentication-results to circumvent some MTAs that strip incoming A-R headers, and send it as part of the signed outgoing message. The reason it doesn't work is that spammers can add fake o-a-r headers as easily as lists can add real ones, so you need to make a whitelist of well behaved senders who don't send faked mail so you know whether to believe them. But once you have the whitelist of well behaved senders, you can skip the o-a-r stuff and just deliver the mail. I gather somewhere there is a private non-standard bilateral implementation of this, but it still seems like an awfully complicated way to do your spam filtering. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2314 bytes Desc: S/MIME Cryptographic Signature URL: From morrowc.lists at gmail.com Wed Apr 9 22:42:45 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 9 Apr 2014 18:42:45 -0400 Subject: autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> Message-ID: On Wed, Apr 9, 2014 at 6:27 PM, John R. Levine wrote: >>> The most "sane" out-of-mind response should only be sent *if* the >>> out-of-mind person is named explicitly as a recipient in the RFC822 >>> To: header. Anything To: somelist at somehost does not qualify :) > > > This highly effective trick was in the procmail example vacation script in > 1991, and doubtless goes back much farther than that. It's a little > dismaying to hear that there are still people writing autoresponders who > don't know about it. what is procmail? From ggm at algebras.org Wed Apr 9 22:45:57 2014 From: ggm at algebras.org (George Michaelson) Date: Thu, 10 Apr 2014 08:45:57 +1000 Subject: autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> Message-ID: procmail is a rewrite of MMDF mailfilter. badly. On Thu, Apr 10, 2014 at 8:42 AM, Christopher Morrow wrote: > On Wed, Apr 9, 2014 at 6:27 PM, John R. Levine wrote: > >>> The most "sane" out-of-mind response should only be sent *if* the > >>> out-of-mind person is named explicitly as a recipient in the RFC822 > >>> To: header. Anything To: somelist at somehost does not qualify :) > > > > > > This highly effective trick was in the procmail example vacation script > in > > 1991, and doubtless goes back much farther than that. It's a little > > dismaying to hear that there are still people writing autoresponders who > > don't know about it. > > what is procmail? > > From johnl at iecc.com Wed Apr 9 22:47:47 2014 From: johnl at iecc.com (John R. Levine) Date: 9 Apr 2014 16:47:47 -0600 Subject: autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> Message-ID: >> This highly effective trick was in the procmail example vacation script in >> 1991, and doubtless goes back much farther than that. It's a little >> dismaying to hear that there are still people writing autoresponders who >> don't know about it. > > what is procmail? The scriptable mail delivery agent that most Unix-ish systems use to sort mail at delivery time. It's a marvel of robust programming, no updates since 2001 but still works great. http://lmgtfy.com/?q=procmail&l=1 Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From LarrySheldon at cox.net Wed Apr 9 23:22:51 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 09 Apr 2014 18:22:51 -0500 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> Message-ID: <5345D64B.3010307@cox.net> On 4/9/2014 5:11 PM, bmanning at vacation.karoshi.com wrote: > On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: >> >> The most "sane" out-of-mind response should only be sent *if* the >> out-of-mind person is named explicitly as a recipient in the RFC822 >> header. Anything To: somelist at somehost does not qualify :) >> >> Jeff > > and just how is an algorithm supposed to detect that > is a single human and not a list? It is really too bad that there is not place to put a "precedence" that the software could key on--with values like "bulk" or "junk" or "list". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From dhc2 at dcrocker.net Wed Apr 9 23:52:35 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 09 Apr 2014 18:52:35 -0500 Subject: autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> Message-ID: <5345DD43.9000905@dcrocker.net> On 4/9/2014 5:45 PM, George Michaelson wrote: > procmail is a rewrite of MMDF mailfilter. badly. Thanks, but I believe it slightly preceded MMDF's equivalent facility. On the average, Allman put comparable features into sendmail sooner than I did. Of course, my design's were sooo much better than his, but that seems to have hurt it's adoption... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jeff-kell at utc.edu Thu Apr 10 00:02:16 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 9 Apr 2014 20:02:16 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5345D64B.3010307@cox.net> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <5345D64B Message-ID: <5345DF88.5000101@utc.edu> On 4/9/2014 7:22 PM, Larry Sheldon wrote: > On 4/9/2014 5:11 PM, bmanning at vacation.karoshi.com wrote: >> On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: >>> >>> The most "sane" out-of-mind response should only be sent *if* the >>> out-of-mind person is named explicitly as a recipient in the RFC822 >>> header. Anything To: somelist at somehost does not qualify :) >>> >>> Jeff >> >> and just how is an algorithm supposed to detect that >> is a single human and not a list? > > It is really too bad that there is not place to put a "precedence" > that the software could key on--with values like "bulk" or "junk" or > "list". Headers of your message include: > Precedence: list > List-Id: North American Network Operators Group > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Errors-To: nanog-bounces+jeff-kell=utc.edu at nanog.org > Return-Path: nanog-bounces+jeff-kell=utc.edu at nanog.org Proper mail clients can provide "list links" based on the List- headers, but few if any actually do. So take your pick, but my point remains, it still retains: > Date: Wed, 9 Apr 2014 18:22:51 -0500 > From: Larry Sheldon > Organization: Maybe tomorrow > User-Agent: Mozilla/5.0 (Windows NT 5.1; > rv:24.0) Gecko/20100101 Thunderbird/24.4.0 > To: > Subject: Re: Yahoo DMARC breakage And I'm nowhere mentioned. I only appear in the "envelope RCPT TO:<> RFC821 header", nowhere in the RFC822 header. It's not rocket science if you have headers available (which even Outlook can see, although you have to jump through a few hoops to see them). Jeff Jeff From LarrySheldon at cox.net Thu Apr 10 00:12:23 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 09 Apr 2014 19:12:23 -0500 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <5345D64B Message-ID: <5345E1E7.3030205@cox.net> On 4/9/2014 7:02 PM, Jeff Kell wrote: > On 4/9/2014 7:22 PM, Larry Sheldon wrote: >> On 4/9/2014 5:11 PM, bmanning at vacation.karoshi.com wrote: >>> On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: >>>> >>>> The most "sane" out-of-mind response should only be sent *if* the >>>> out-of-mind person is named explicitly as a recipient in the RFC822 >>>> header. Anything To: somelist at somehost does not qualify :) >>>> >>>> Jeff >>> >>> and just how is an algorithm supposed to detect that >>> is a single human and not a list? >> >> It is really too bad that there is not place to put a "precedence" >> that the software could key on--with values like "bulk" or "junk" or >> "list". > > Headers of your message include: > >> Precedence: list [snip] I knew that. > Proper mail clients can provide "list links" based on the List- headers, > but few if any actually do. > > So take your pick, but my point remains, it still retains: > >> Date: Wed, 9 Apr 2014 18:22:51 -0500 >> From: Larry Sheldon >> Organization: Maybe tomorrow >> User-Agent: Mozilla/5.0 (Windows NT 5.1; >> rv:24.0) Gecko/20100101 Thunderbird/24.4.0 >> To: >> Subject: Re: Yahoo DMARC breakage > > And I'm nowhere mentioned. I only appear in the "envelope RCPT TO:<> > RFC821 header", nowhere in the RFC822 header. > > It's not rocket science if you have headers available (which even > Outlook can see, although you have to jump through a few hoops to see them). My point is, and was only that the ID10t's robot-responder needs only two rules (one of which is sortakinda off topic in a muchmorphed OT threadlet) are: If the Precedence is "list", "junk", or "bulk" DO NOTHING, else, if the address to which the proposed babblegram is to be sent has received a babblegram from us since the controlling file was created DO NOTHING, else, BABBLEON. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From bill at herrin.us Thu Apr 10 00:12:34 2014 From: bill at herrin.us (William Herrin) Date: Wed, 9 Apr 2014 20:12:34 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <20140409221112.GA3069@vacation.karoshi.com> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> Message-ID: On Wed, Apr 9, 2014 at 6:11 PM, wrote: > and just how is an algorithm supposed to detect that > is a single human and not a list? If the autoresponder is sane, it looks for: List-Id: North American Network Operators Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Precedence: list If the mailing list doesn't set those headers, that's the mailing list's fault. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jimpop at gmail.com Thu Apr 10 00:16:21 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 9 Apr 2014 20:16:21 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5345DF88.5000101@utc.edu> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <5345D64B.3010307@cox.net> <5345DF88.5000101@utc.edu> Message-ID: On Wed, Apr 9, 2014 at 8:02 PM, Jeff Kell wrote: >> Date: Wed, 9 Apr 2014 18:22:51 -0500 >> From: Larry Sheldon >> Organization: Maybe tomorrow >> User-Agent: Mozilla/5.0 (Windows NT 5.1; >> rv:24.0) Gecko/20100101 Thunderbird/24.4.0 >> To: >> Subject: Re: Yahoo DMARC breakage It's also worth mentioning that if someone else's previous advice is/was followed (about changing the MLM From: to a generic list address) there would be no way to killfile someone, filter by name, NOR any sense to long threaded discussions where MUAs do quoting and others copy+paste. In Mailinglists, rfc5322.From: is sacred (and according to RFC 5322 so are Sender and Reply-To, which DMARC conveniently disregard) -Jim P. From nanog at jima.us Thu Apr 10 00:18:59 2014 From: nanog at jima.us (Jima) Date: Wed, 09 Apr 2014 18:18:59 -0600 Subject: Serious bug in ubiquitous OpenSSL library: "Heartbleed" In-Reply-To: <20140409035719.GA31830@vacation.karoshi.com> References: <53436560.30002@internetidentity.com> <534383D8.8000006@mykolab.com> <53441DBF.9020200@mtcc.com> <53448CBD.7060205@flowtools.net> <86bnwbnp0o.fsf@valhalla.seastrom.com> <20140409035719.GA31830@vacation.karoshi.com> Message-ID: <5345E373.6000500@jima.us> On 2014-04-08 21:57, bmanning wrote: > On Tue, Apr 08, 2014 at 11:46:31PM -0400, Rob Seastrom wrote: >> If that's true, you might want to consider immediately disconnecting >> your systems from the Internet and never re-connecting them. After >> all, theres a lot of online unseen code testing your site already >> whether you like it or not. > > Diodes.... Is it wrong that I read that like this? http://jima.us/201404/diodes.jpg (Sorry.) Jima From jimpop at gmail.com Thu Apr 10 00:19:53 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Wed, 9 Apr 2014 20:19:53 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> Message-ID: On Wed, Apr 9, 2014 at 8:12 PM, William Herrin wrote: > On Wed, Apr 9, 2014 at 6:11 PM, wrote: >> and just how is an algorithm supposed to detect that >> is a single human and not a list? > > If the autoresponder is sane, it looks for: > > List-Id: North American Network Operators Group > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Precedence: list and if the autoresponder/MUA is smart it only autoresponds where To: is the target address. -Jim P. From mfidelman at meetinghouse.net Thu Apr 10 00:25:55 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 09 Apr 2014 20:25:55 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5345C442.5000103@dcrocker.net> References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> Message-ID: <5345E513.7030908@meetinghouse.net> Dave Crocker wrote: > On 4/9/2014 3:05 PM, John Levine wrote: >> In article <5345831B.4030705 at dcrocker.net> you write: >>> Their implementation is not 'broken'. >> >> I'd say it's pretty badly broken if Yahoo intends for their web mail >> to continue to be a general purpose mail system for consumers. If >> they want to make it something else, that's certainly their right, but >> it would have been nice if they'd given us some advance warning so we >> could take the yahoo.com addresses off our lists. > > > If I point a gun at you, and pull the trigger, but maybe shouldn't > have done that, the gun is not broken. > > Management decisions that are subject to criticism does not represent > erroneous performance by the folks tasked with doing the task mandated. > > Everything they are doing is "legal". > > Your (possibly entirely valid) assessment that their action is > ill-advised or unpleasant does not equal broken. Well, sort of - given that DMARC is still an Internet draft, not even an experimental standard. Maybe it's doing what the draft says it is - but it's an alpha-level protocol, that breaks a lot of things it touches. If not "broken" it's certainly "not ready for prime time" - and large scale deployment is akin to a DDoS attack - i.e., not "ill-advised" but verging on criminal. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From dhc2 at dcrocker.net Thu Apr 10 00:50:00 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 09 Apr 2014 19:50:00 -0500 Subject: Yahoo DMARC breakage In-Reply-To: <5345E513.7030908@meetinghouse.net> References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> Message-ID: <5345EAB8.10603@dcrocker.net> On 4/9/2014 7:25 PM, Miles Fidelman wrote: > Dave Crocker wrote: >> Everything they are doing is "legal". >> >> Your (possibly entirely valid) assessment that their action is >> ill-advised or unpleasant does not equal broken. > > Well, sort of - given that DMARC is still an Internet draft, not even an > experimental standard. Maybe it's doing what the draft says it is - but > it's an alpha-level protocol, that breaks a lot of things it touches. If > not "broken" it's certainly "not ready for prime time" - and large scale > deployment is akin to a DDoS attack - i.e., not "ill-advised" but > verging on criminal. While IETF "full" standards status does indicate real deployment and serious technical maturity, IETF Proposed Standard does not mean mature or immature, given the varied history of work leading to Proposed. SSL was quite mature, before the IETF did enhancements to produce TLS. The IETF's version of DKIM was essentially v4 for the technology. DMARC is estimated to currently cover roughly 60% of the world's email traffic. As "not ready for prime time" goes, that's quite a lot of prime time. Yahoo! is choosing to apply the technology for usage scenarios that have long been known to be problematic. Again, they've made an informed choice. Whether it's justified and whether it was the right choice is more of a political or management discussion than a technical one. In technical terms, DMARC is reasonably simple and reasonably well understood and extensively deployed. For most discussions, that qualifies as 'mature'... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mfidelman at meetinghouse.net Thu Apr 10 01:04:42 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 09 Apr 2014 21:04:42 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5345EAB8.10603@dcrocker.net> References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> Message-ID: <5345EE2A.9060609@meetinghouse.net> Dave Crocker wrote: > On 4/9/2014 7:25 PM, Miles Fidelman wrote: >> Dave Crocker wrote: >>> Everything they are doing is "legal". >>> >>> Your (possibly entirely valid) assessment that their action is >>> ill-advised or unpleasant does not equal broken. >> >> Well, sort of - given that DMARC is still an Internet draft, not even an >> experimental standard. Maybe it's doing what the draft says it is - but >> it's an alpha-level protocol, that breaks a lot of things it touches. If >> not "broken" it's certainly "not ready for prime time" - and large scale >> deployment is akin to a DDoS attack - i.e., not "ill-advised" but >> verging on criminal. > > > While IETF "full" standards status does indicate real deployment and > serious technical maturity, IETF Proposed Standard does not mean > mature or immature, given the varied history of work leading to Proposed. > > SSL was quite mature, before the IETF did enhancements to produce TLS. > > The IETF's version of DKIM was essentially v4 for the technology. > > DMARC is estimated to currently cover roughly 60% of the world's email > traffic. As "not ready for prime time" goes, that's quite a lot of > prime time. > > Yahoo! is choosing to apply the technology for usage scenarios that > have long been known to be problematic. Again, they've made an > informed choice. Whether it's justified and whether it was the right > choice is more of a political or management discussion than a > technical one. > > In technical terms, DMARC is reasonably simple and reasonably well > understood and extensively deployed. > > For most discussions, that qualifies as 'mature'... > Speaking as someone who runs a few dozen mailing lists, and based on discussions on mailops and admin lists for various listserver packages, I humbly suggest that, as John Levine put it: "Yahoo breaks every mailing list in the world including the IETF's" suggests something something other than "reasonably simple and reasonably well understood and extensively deployed" and "mature." Especially after reading some of the discussions on the DMARC mailing list where it's clear that issues of breaking mailing lists were explicitly ignored and dismissed. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From johnl at iecc.com Thu Apr 10 01:54:21 2014 From: johnl at iecc.com (John R. Levine) Date: 9 Apr 2014 19:54:21 -0600 Subject: autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> Message-ID: > On Wed, Apr 9, 2014 at 6:11 PM, wrote: >> and just how is an algorithm supposed to detect that >> is a single human and not a list? > > If the autoresponder is sane, it looks for: > > List-Id: North American Network Operators Group Yes, there are a lot of headers that give you a hint that a message is from a list. But the heuristic to look for the recipient's address on the To: line works so well, along with a little rate limiting, that you don't really need anything else. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2314 bytes Desc: S/MIME Cryptographic Signature URL: From johnl at iecc.com Thu Apr 10 01:58:46 2014 From: johnl at iecc.com (John R. Levine) Date: 9 Apr 2014 19:58:46 -0600 Subject: procmail, was autoresponding to Yahoo DMARC breakage In-Reply-To: <5345DD43.9000905@dcrocker.net> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> <5345DD43.9000905@dcrocker.net> Message-ID: > On 4/9/2014 5:45 PM, George Michaelson wrote: >> procmail is a rewrite of MMDF mailfilter. badly. > Thanks, but I believe it slightly preceded MMDF's equivalent facility. On the > average, Allman put comparable features into sendmail sooner than I did. Procmail's user interface, if you can call it that, is beyond awful and looks like line noise. But the code is great. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2314 bytes Desc: S/MIME Cryptographic Signature URL: From ggm at algebras.org Thu Apr 10 02:21:47 2014 From: ggm at algebras.org (George Michaelson) Date: Thu, 10 Apr 2014 12:21:47 +1000 Subject: procmail, was autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> <5345DD43.9000905@dcrocker.net> Message-ID: Aside from a horrid config notation. the main problem for me has always been getting sysadmins to include the changes which expose envelope-sender and envelope-recipient to procmail. Thats not procmail, its the way procmail is typically called. Without it, some stuff simply cannot be done because you don't know the values passed by protocol, only the values exposed in header. (this may have changed. I don't use it any more) On Thu, Apr 10, 2014 at 11:58 AM, John R. Levine wrote: > On 4/9/2014 5:45 PM, George Michaelson wrote: >> >>> procmail is a rewrite of MMDF mailfilter. badly. >>> >> > Thanks, but I believe it slightly preceded MMDF's equivalent facility. On >> the average, Allman put comparable features into sendmail sooner than I did. >> > > Procmail's user interface, if you can call it that, is beyond awful and > looks like line noise. But the code is great. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly From asullivan at dyn.com Thu Apr 10 03:00:57 2014 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 9 Apr 2014 23:00:57 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5345831B.4030705@dcrocker.net> References: <5345831B.4030705@dcrocker.net> Message-ID: <20140410030056.GB3886@dyn.com> Hi Dave, On Wed, Apr 09, 2014 at 12:27:55PM -0500, Dave Crocker wrote: > But it's the result of an informed > corporate choice rather than software or operations error. Why do you think (it seems to me you've said it more than once) that this was "informed" choice? If I go to http://dmarc.org/, and read the "who can use?" part, there is no big warning there that domains with a lot of random users from all over who might be posting to mailing lists will have a complicated problem. On the contrary, the only "who" in that section is "everyone". Also, the "why important" part says "DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse." And indeed, if I follow the link for the current specification from http://dmarc.org/, there is rather little discussion of what happens to users. This is as it should be. That's an Internet-Draft of the protocol. It might one day be published as an Independent Submission, partly because those who developed DMARC didn't want to give control to the IETF. I get that, but it's sort of hard to know what it means in terms of corporate "informed choice". There's no applicability statement I can see. So, I'm trying to imagine the presentation slide on which appears the advice to implement the controversial adopted policy. I imagine in big, giant print "Will reduce yahoo.com abuse effects" and in one of those secondary bullets "May have consequences" and even lower "for our users on mailing lists" and "for mailing list managers/non-company". We all know the Tufte observations about PowerPoint; that doesn't make them less true. I can even give the presentation I imagine, and I don't work at the company in question. I think DMARC is mostly useful when used correctly. There is no BCP yet, however, and that's partly because there's as yet no broad experience with DMARC in what we might call "mostly-user domains": there is no "CP" at all. There is quite good experience in the areas where DMARC was intended to be effective. Good. To pretend that there's any experience outside that realm, in my opinion, generalizing inappropriately. I think responsible Internet deployment ought to point that out. I'm sure there will be those who disagree. Best regards, A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From mysidia at gmail.com Thu Apr 10 04:54:00 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 9 Apr 2014 23:54:00 -0500 Subject: Yahoo DMARC breakage In-Reply-To: <5345EE2A.9060609@meetinghouse.net> References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: On Wed, Apr 9, 2014 at 8:04 PM, Miles Fidelman wrote: On 4/9/2014 7:25 PM, Miles Fidelman wrote: > Yahoo! is choosing to apply the technology for usage scenarios that have >> long been known to be problematic. Again, they've made an > > In fact... it is too generous to say "known to be problematic". Basic functionality is seriously and utterly broken --- that DMARC doesn't have a good answer for such situations, is a major indicator of its immaturity, in the sense that it is "Too specific" a solution and cannot apply to e-mail in general. If it were mature: a mechanism would be provided that would allow mailing lists to function without breaking changes such as substituting From:. An example of a solution would be the use of a DKIM alternative with not a single signature for the entire message, but only partial signing of parts of the message: specifically identified headers and/or specific body elements, to validate that the message was really sent and certain elements are genuine ---- and certain elements were modified by the mailing list. > informed choice. Whether it's justified and whether it was the right >> choice is more of a political or management discussion than a technical one. >> > The technical issue, is that the immaturity of the related specs. limits the decisions are available for a particular domain ---- so, essentially, if you have certain kind of user traffic: you have to incur technical issues with mailing lists, or forego using DMARC. In other words: much as you would like to dismiss as purely a managerial decision ---- the decisions available to be made are entangled with the limitations of the technical options that are available for mitigating spoofing, AND the public's understanding thereof. > >> In technical terms, DMARC is reasonably simple and reasonably well >> understood and extensively deployed. >> > I would say reasonably simple. Only well-understood by a very limited fraction of the population of mail operators. Not widely deployed; particularly on domains serving end user mailboxes. > >> For most discussions, that qualifies as 'mature'... >> >> > Especially after reading some of the discussions on the DMARC mailing list > where it's clear that issues of breaking mailing lists were explicitly > ignored and dismissed. +1. Common use case ignored and dismissed, is a pretty convincing indicator of a lack of maturity with regads to the spec. > Miles Fidelman > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > -- -Mysid From randy at psg.com Thu Apr 10 07:18:34 2014 From: randy at psg.com (Randy Bush) Date: Thu, 10 Apr 2014 16:18:34 +0900 Subject: BGPMON Alert Questions In-Reply-To: References: <201404031431.55306.mark.tinka@seacom.mu> <201404081249.13834.mark.tinka@seacom.mu> Message-ID: > Yes, we don't validate those prefixes cause we filter them strict. in our measurements, an rpki-based origin check is significantly faster than an acl of non-trivial length. randy From lists at ecsc.co.uk Wed Apr 9 10:07:36 2014 From: lists at ecsc.co.uk (Fabien Bourdaire) Date: Wed, 09 Apr 2014 11:07:36 +0100 Subject: CVE-2014-0160 mitigation using iptables Message-ID: <53451BE8.8060609@ecsc.co.uk> Following up on the CVE-2014-0160 vulnerability, heartbleed. We've created some iptables rules to block all heartbeat queries using the very powerful u32 module. The rules allow you to mitigate systems that can't yet be patched by blocking ALL the heartbeat handshakes. We also like the capability to log external scanners :) The rules have been specifically created for HTTPS traffic and may be adapted for other protocols; SMTPS/IMAPS/... # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j DROP # Wireshark rules $ tshark -i interface port 443 -R 'frame[68:1] == 18' $ tshark -i interface port 443 -R 'ssl.record.content_type == 24' We believe that this should only be used as a temporary fix to decrease the exposure window. The log rule should allow you to test the firewall rules before being used in production. It goes without saying that if you have any suggested improvements to these rules we would be grateful if you could share them with the security community. Clearly, use of these rules is at your own risk ;) ECSC SOC Team Researchers: Adam Shore Alex Innes Fabien Bourdaire -- ECSC Ltd - http://www.ecsc.co.uk From jbates at paradoxnetworks.net Thu Apr 10 02:35:27 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Wed, 09 Apr 2014 21:35:27 -0500 Subject: procmail, was autoresponding to Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> <5345DD43.9000905@dcrocker.net> Message-ID: <5346036F.7070109@paradoxnetworks.net> On 4/9/2014 9:21 PM, George Michaelson wrote: > Aside from a horrid config notation. the main problem for me has always > been getting sysadmins to include the changes which expose envelope-sender > and envelope-recipient to procmail. Thats not procmail, its the way > procmail is typically called. Without it, some stuff simply cannot be done > because you don't know the values passed by protocol, only the values > exposed in header. > > (this may have changed. I don't use it any more) > > > It can still be a problem, although I believe LMTP fixes this problem along with the others it was designed to fix. Jack From oscar.vives at gmail.com Thu Apr 10 10:05:17 2014 From: oscar.vives at gmail.com (Tei) Date: Thu, 10 Apr 2014 12:05:17 +0200 Subject: Yahoo DMARC breakage In-Reply-To: References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: Your post advocates a (*) technical ( ) legislative ( ) market-based ( ) vigilante approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.) ( ) Spammers can easily use it to harvest email addresses (*) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks (*) It will stop spam for two weeks and then we'll be stuck with it (*) Users of email will not put up with it ( ) Microsoft will not put up with it ( ) The police will not put up with it ( ) Requires too much cooperation from spammers (*) Requires immediate total cooperation from everybody at once (*) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business Specifically, your plan fails to account for ( ) Laws expressly prohibiting it (*) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email ( ) Armies of worm riddled broadband-connected Windows boxes ( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves ( ) Bandwidth costs that are unaffected by client filtering ( ) Outlook and the following philosophical objections may also apply: ( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck (*) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud (*) Countermeasures should not involve sabotage of public networks (*) Countermeasures must work if phased in gradually ( ) Sending email should be free (*) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses (*) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough Furthermore, this is what I think about you: (*) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down! From mark.tinka at seacom.mu Thu Apr 10 10:10:16 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Apr 2014 12:10:16 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: Message-ID: <201404101210.19987.mark.tinka@seacom.mu> On Thursday, April 10, 2014 09:18:34 AM Randy Bush wrote: > in our measurements, an rpki-based origin check is > significantly faster than an acl of non-trivial length. Ultimately, at some point in the future, it is not completely unreasonable to think that some operators could attempt control plane filtering based purely on RPKI-based origin and AS_PATH validation, without actually needing to configure prefix or AS_PATH lists :-). Wouldn't that be something... Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From nick at foobar.org Thu Apr 10 10:12:40 2014 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Apr 2014 11:12:40 +0100 Subject: CVE-2014-0160 mitigation using iptables In-Reply-To: <53451BE8.8060609@ecsc.co.uk> References: <53451BE8.8060609@ecsc.co.uk> Message-ID: <53466E98.4060406@foobar.org> On 09/04/2014 11:07, Fabien Bourdaire wrote: > Following up on the CVE-2014-0160 vulnerability, heartbleed. We've > created some iptables rules to block all heartbeat queries using the > very powerful u32 module. as someone pointed out on the UKNOF mailing list yesterday, you make a number of assumptions in this ruleset which are not necessarily valid. Please do not claim that this ruleset blocks all heartbeat queries because it does not. Nick From mfidelman at meetinghouse.net Thu Apr 10 10:13:51 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 10 Apr 2014 06:13:51 -0400 Subject: Yahoo DMARC breakage Message-ID: <53466EDF.1030606@meetinghouse.net> at some point, Dave Crocker wrote: > If I point a gun at you, and pull the trigger, but maybe shouldn't have > done that, the gun is not broken. It occurs to me that, if you point a gun at me, aim at me, pull the trigger, and hit someone standing 10 feet to my left - the gun IS broken (or at least very poorly designed). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra re From mfidelman at meetinghouse.net Thu Apr 10 10:19:57 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 10 Apr 2014 06:19:57 -0400 Subject: procmail, was autoresponding to Yahoo DMARC breakage In-Reply-To: <5346036F.7070109@paradoxnetworks.net> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <19726.1397078684@turing-police.cc.vt.edu> <5345C067.9040003@utc.edu> <20140409221112.GA3069@vacation.karoshi.com> <5345C7AA.9000304@utc.edu> <5345DD43.9000905@dcrocker.net> <5346036F.7070109@paradoxnetworks.net> Message-ID: <5346704D.6060908@meetinghouse.net> All this talk about procmail leads me to ask: - has anybody come up with a procmail recipe, or other mechanism to validate DKIM-signed mail and apply an Original-Authentication-Results header, at the MTA level? - if so, does it work with Yahoo mail directed to mailing lists? - if yes, can you share?! (So far, all the folks I know who are trying to react, have been doing so via hacks to their list management software. I'm hoping to attack the problem at a more accessible step in mail processing). -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Thu Apr 10 10:27:47 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 10 Apr 2014 06:27:47 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: <53467223.6080605@meetinghouse.net> Tei wrote: > Your post advocates a > > (*) technical ( ) legislative ( ) market-based ( ) vigilante > > approach to fighting spam. Your idea will not work. Here is why it > won't work. (One or more of the following may apply to your particular > > > (*) Sorry dude, but I don't think it would work. > ( ) This is a stupid idea, and you're a stupid person for suggesting it. > ( ) Nice try, assh0le! I'm going to find out where you live and burn your > house down! Right about now, I'm starting to lean toward: (*) Nice try, assh0le! I'm going to find out where you live and burn your house down! Foisting this on the world, particularly as tax day approaches - heads should roll. Sigh... Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From randy at psg.com Thu Apr 10 10:30:51 2014 From: randy at psg.com (Randy Bush) Date: Thu, 10 Apr 2014 19:30:51 +0900 Subject: BGPMON Alert Questions In-Reply-To: <201404101210.19987.mark.tinka@seacom.mu> References: <201404101210.19987.mark.tinka@seacom.mu> Message-ID: as folk start to roll out rejection of invalids, we might think about how we report problems with folk registering inadequate roas, covering their customers, covering their deaggs (maybe deaggs get what they deserve), etc. if they are not clued enough to generate prudent roas, they will not be clued enough to generate ghostbusters (and neither ripe's nor apnic's software supports gbrs today). if my customer can not reach foo's customer, will foo's rir be willing to help? if foo's customer can not reach mine, how to let foo know who to call/write? do we need conventions? randy From rsk at gsp.org Thu Apr 10 11:29:12 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 10 Apr 2014 07:29:12 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> Message-ID: <20140410112912.GA15874@gsp.org> An aside: On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote: > Maybe this is a good thing - we can stop getting all the "sorry I'm > out of the office" emails when posting to a list. I entirely support that goal, but my preferred solution is the complete eradication of the software (a lot of which makes mistakes that have been well-known as mistakes for decades) and thus the entire practice of setting up "out of office" messages. Out-of-office notices might have had some relevance 20 or 30 years ago when much of the population was new to email and had not yet grasped in *any* sense how it works. And when there was a large overlap between "people who use email" and "people who read/send email from their offices and only from their offices". But I think by now everyone who is capable of being educated has been educated and realizes that the one of the reasons for the absence of a response is that the recipient hasn't seen the relevant message yet. There's really no need to spin the roulette wheel and hope that the combination of MUAs and MTAs on both ends is functional enough to enable the out-of-office software (optimistically presuming it's halfway sane) to figure out what it should do. And that's before we even get to the security and privacy issues that are in play, which are substantial. So while there are numerous approaches to solving the problem of errant out-of-office messages, and some of those approaches work pretty well in the field, I would prefer to kill the problem by attacking the source: the *existence* of out-of-office autoresponders. ---rsk From rsk at gsp.org Thu Apr 10 11:42:00 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 10 Apr 2014 07:42:00 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <20140410030056.GB3886@dyn.com> References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> Message-ID: <20140410114200.GB15874@gsp.org> I agree to a large extent with your comments/observations, but I'd like to focus on one point in particular: On Wed, Apr 09, 2014 at 11:00:57PM -0400, Andrew Sullivan wrote: > So, I'm trying to imagine the presentation slide on which appears the > advice to implement the controversial adopted policy. I imagine in > big, giant print "Will reduce yahoo.com abuse effects" and in one of > those secondary bullets "May have consequences" and even lower "for > our users on mailing lists" and "for mailing list > managers/non-company". This decision by Yahoo will have no effect whatsoever on the largest abuse problem, which is outbound spam/phishing/malware/etc. *sourced* by Yahoo. Those messages are (and have been for a long time) dutifully marked as authentic and in one sense they are: they really do originate from Yahoo's operation. But of course in a much more important operational sense they're not: they're forgeries created by the new owners of hijacked Yahoo user accounts. And those accounts are being hijacked at will by the millions, as they have been for many years. Yahoo is not alone in permitting an enormous volume of such messages to leave their operation and attack the rest of the Internet: Hotmail, Gmail, and the rest do the same. (Of course the rates vary, as do the targets. My spamtraps see large rate fluctuations across networks, domains, ASNs, etc. as well as through time. I strongly suspect that individual measurements at any one are essentially meaningless and that aggregation over a sufficiently diverse set over a sufficiently long time is necessary to construct a coherent, useful statistical model of what's really happening.) In other words, this deployment might reduce abuse OF Yahoo, but it will do nothing about the far more important problem of abuse BY Yahoo. Which pretty much lives up to my expectations. ---rsk From dhc2 at dcrocker.net Thu Apr 10 11:45:41 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 10 Apr 2014 06:45:41 -0500 Subject: Yahoo DMARC breakage In-Reply-To: References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: <53468465.7080704@dcrocker.net> On 4/9/2014 11:54 PM, Jimmy Hess wrote: > Basic functionality is seriously and utterly broken --- that DMARC > doesn't have a good answer for such situations, is a major indicator > of its immaturity, in the sense that it is "Too specific" a solution > and cannot apply to e-mail in general. > > If it were mature: a mechanism would be provided that would allow > mailing lists to function without breaking changes such as > substituting From:. On 4/9/2014 11:54 PM, Jimmy Hess wrote:> Basic functionality is seriously and utterly broken --- that DMARC doesn't > have a good answer for such situations, is a major indicator of its > immaturity, in the sense that it is "Too specific" a solution and > cannot apply to e-mail in general. > > If it were mature: a mechanism would be provided that would allow > mailing lists to function without breaking changes such as > substituting From:. Every tool has limitations. An 18-wheeler truck is not broken or immature because it fails to corner like a Maserati. A Maserati is not broken or immature because it does not have the carrying capacity of an 18-wheeler. DMARC was designed to handle a particular usage scenario and its limitations have been carefully documented. Or perhaps we need to declare email broken and immature because it does not (yet) satisfy a long list of entirely reasonable functional requirements, such as, ummm, author authentication? Long deployment and use and deep knowledge don't matter; only satisfying someone's list of requirements does? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2 at dcrocker.net Thu Apr 10 11:48:27 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 10 Apr 2014 06:48:27 -0500 Subject: Yahoo DMARC breakage In-Reply-To: References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: <5346850B.7080804@dcrocker.net> On 4/10/2014 5:05 AM, Tei wrote: > Your post advocates a > > (*) technical ( ) legislative ( ) market-based ( ) vigilante Since the nanog list isn't devoted to anti-spam work, folk might not know that you were calling upon the stellar web page developed by Cory Doctorow: http://craphound.com/spamsolutions.txt As far as I know, he meant it strictly for humor. However he did such a good job, it is common to point folk to it (or, as we've seen here, even fill it out) when the they declare that they have the FUSSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mark.tinka at seacom.mu Thu Apr 10 13:26:50 2014 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 10 Apr 2014 15:26:50 +0200 Subject: BGPMON Alert Questions In-Reply-To: References: <201404101210.19987.mark.tinka@seacom.mu> Message-ID: <201404101526.54008.mark.tinka@seacom.mu> On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote: > as folk start to roll out rejection of invalids, we might > think about how we report problems with folk registering > inadequate roas, covering their customers, covering > their deaggs (maybe deaggs get what they deserve), etc. > if they are not clued enough to generate prudent roas, > they will not be clued enough to generate ghostbusters > (and neither ripe's nor apnic's software supports gbrs > today). Agree. If you are clued enough to generate ROA's, you are clued enough to generate ROA's for the de-aggregates (or, at least, respond to the errors that indicate that). But the reverse is also true. It would be useful to use BGPmon's free RPKI validation feature, which e-mails you, incessantly, about validation failures due to un-ROA'd de-aggregates. It will also help if the CA's run by the RIR's support prefix length definitions. For the Africa region, AFRINIC currently do not, meaning every de-aggregate needs to be ROA'd. It's planned, though... > if my customer can not reach foo's customer, will foo's > rir be willing to help? if foo's customer can not reach > mine, how to let foo know who to call/write? do we need > conventions? This was one of the questions I've always pondered, and if you recall, was part of our panel discussion on the subject in Xi'an last year. I think it would be helpful if CA delegation was supported by RIR's, and supported well, so that customers can deal with their ISP's CA instead of having to deal with the RIR instead (particularly for situations where RIR's aren't 24/7 shops). On the monitoring side, it will be critical for ISP's to provide looking glasses that customers can use to verify the delta between what has been ROA'd and what has been announced/rejected, particularly in the case of un-ROA'd de- aggregates. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From dhc2 at dcrocker.net Thu Apr 10 13:49:59 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Thu, 10 Apr 2014 08:49:59 -0500 Subject: Yahoo DMARC breakage In-Reply-To: <53466EDF.1030606@meetinghouse.net> References: <53466EDF.1030606@meetinghouse.net> Message-ID: <5346A187.50107@dcrocker.net> On 4/10/2014 5:13 AM, Miles Fidelman wrote: >> If I point a gun at you, and pull the trigger, but maybe shouldn't have >> done that, the gun is not broken. > > It occurs to me that, if you point a gun at me, aim at me, pull the > trigger, and hit someone standing 10 feet to my left - the gun IS broken > (or at least very poorly designed). Unfortunately, that has no relationship to do with the current situation. Again: Yahoo was fully aware of the implications of its choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Valdis.Kletnieks at vt.edu Thu Apr 10 13:52:53 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Apr 2014 09:52:53 -0400 Subject: CVE-2014-0160 mitigation using iptables In-Reply-To: Your message of "Wed, 09 Apr 2014 11:07:36 +0100." <53451BE8.8060609@ecsc.co.uk> References: <53451BE8.8060609@ecsc.co.uk> Message-ID: <86376.1397137973@turing-police.cc.vt.edu> On Wed, 09 Apr 2014 11:07:36 +0100, Fabien Bourdaire said: > # Log rules > iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ > "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" That 52= isn't going to work if it's an IPv4 packet with an unexpected number IP or TCP options, or an IPv6 connection.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From dhubbard at dino.hostasaurus.com Thu Apr 10 13:54:54 2014 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 10 Apr 2014 09:54:54 -0400 Subject: CVE-2014-0160 mitigation using iptables References: <53451BE8.8060609@ecsc.co.uk> <53466E98.4060406@foobar.org> Message-ID: He was also proven wrong on the Full Disclosure list but he seems to be pushing this everywhere he can find an audience for some reason. -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Thursday, April 10, 2014 6:13 AM To: Fabien Bourdaire; nanog at nanog.org Subject: Re: CVE-2014-0160 mitigation using iptables On 09/04/2014 11:07, Fabien Bourdaire wrote: > Following up on the CVE-2014-0160 vulnerability, heartbleed. We've > created some iptables rules to block all heartbeat queries using the > very powerful u32 module. as someone pointed out on the UKNOF mailing list yesterday, you make a number of assumptions in this ruleset which are not necessarily valid. Please do not claim that this ruleset blocks all heartbeat queries because it does not. Nick From mike at mtcc.com Thu Apr 10 14:56:16 2014 From: mike at mtcc.com (Michael Thomas) Date: Thu, 10 Apr 2014 07:56:16 -0700 Subject: Yahoo DMARC breakage In-Reply-To: References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: <5346B110.3080201@mtcc.com> On 04/09/2014 09:54 PM, Jimmy Hess wrote: > Basic functionality is seriously and utterly broken --- that DMARC doesn't > have a good answer for such situations, is a major indicator of its > immaturity, in the sense that it is "Too specific" a solution and cannot > apply to e-mail in general. DMARC is nothing more than warmed over ADSP which itself didn't have a pat answer for mailing list traversal. For transactional mail ADSP was just fine, but for regular mail the signing policy was meant to be a guide for other heuristics. It says nothing more than "i sign my mail outgoing", so what do you do if the signature is broken? If you want to take a hard line, then you are going to get all kinds of false positives... this has been known for 10 years at least. I'd be surprised to hear that Y! of all people was doing that, but it's their pissed off users' problem. Vote with your feet. > > If it were mature: a mechanism would be provided that would allow mailing > lists to function without breaking changes such as substituting From:. > > An example of a solution would be the use of a DKIM alternative with not > a single signature for the entire message, but only partial signing of > parts of the message: specifically identified headers and/or specific > body elements, to validate that the message was really sent and certain > elements are genuine ---- and certain elements were modified by the > mailing list. You can more or less do this with DKIM already, and get about 90% of mailing list traffic to pass verification. The question is whether that's enough. I have no idea whether Y! is doing the things I did to get that pass rate. > > The technical issue, is that the immaturity of the related specs. limits > the decisions are available for a particular domain ---- so, > essentially, if you have certain kind of user traffic: you have to incur > technical issues with mailing lists, or forego using DMARC. > > In other words: much as you would like to dismiss as purely a managerial > decision ---- the decisions available to be made are entangled with > the limitations of the technical options that are available for > mitigating spoofing, > > AND the public's understanding thereof. Crocker may have some further insight that we're not privy to, but using signing policy on the general population as a raw instrument is well known to be a bad idea for DKIM and SPF's policy mechanisms as well. SPF in particular had a huge amount of blowback by punitive mail operators who didn't understand the implications, at least in the early days. It may indeed be management idiocy, but I can't see what the point is in defending the idiocy as being some sort of sacred right. Mike From Valdis.Kletnieks at vt.edu Thu Apr 10 15:01:31 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Apr 2014 11:01:31 -0400 Subject: Yahoo DMARC breakage In-Reply-To: Your message of "Thu, 10 Apr 2014 07:56:16 -0700." <5346B110.3080201@mtcc.com> References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> <5346B110.3080201@mtcc.com> Message-ID: <90577.1397142091@turing-police.cc.vt.edu> On Thu, 10 Apr 2014 07:56:16 -0700, Michael Thomas said: > but I can't see what the point is in defending the idiocy as being some > sort of sacred right. I'm sure Randy Bush would defend his competitor's right to run their networks that way. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jcurran at arin.net Thu Apr 10 15:46:42 2014 From: jcurran at arin.net (John Curran) Date: Thu, 10 Apr 2014 15:46:42 +0000 Subject: ICANN issues call for public input on process to develop IANA stewardship transition plan References: <5345782E.5080902@arin.net> Message-ID: <1B3AE35E-FE58-41B1-918D-5EAC4824C5BD@corp.arin.net> NANOGers - As you may have heard, the United States National Telecommunications and Information Administration (US NTIA) has a contract with ICANN for administration of the Internet technical identifiers [e.g. DNS names, IP address spaces, and protocol parameters], and recently proposed transitioning stewardship of these tasks over to the Internet technical community. ICANN is facilitating the development of a plan to accomplish this, and their initial draft of a process for plan development has been released and is available for public comment. Comments on the proposed process are due by 8 May 2014, and as that is well before NANOG 61 in June, I'm drawing attention to this opportunity via the list. You can find more information regarding the proposed process and how to provide feedback attached. FYI (and thanks!) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] ICANN issues Call for Public Input on the IANA Functions Transition Date: April 9, 2014 at 12:41:18 PM EDT To: arin-announce at arin.net ICANN has issued a call for public input on a newly released Draft Proposal, based on initial community input, of the principles, mechanisms, and process to develop a proposal to transition NTIA's stewardship of the IANA functions. Details are available at: http://www.icann.org/en/about/agreements/iana/transition/draft-proposal-08apr14-en.htm Feedback can be submitted via the publicly archived mailing list: ianatransition at icann.org. We encourage ARIN community members to participate, and call to your attention that the deadline to contribute is 8 May 2014 (midnight UTC). Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From mike at mtcc.com Thu Apr 10 16:41:39 2014 From: mike at mtcc.com (Michael Thomas) Date: Thu, 10 Apr 2014 09:41:39 -0700 Subject: Yahoo DMARC breakage In-Reply-To: <5345EE2A.9060609@meetinghouse.net> References: <20140409200558.3314.qmail@joyce.lan> <5345C442.5000103@dcrocker.net> <5345E513.7030908@meetinghouse.net> <5345EAB8.10603@dcrocker.net> <5345EE2A.9060609@meetinghouse.net> Message-ID: <5346C9C3.3040805@mtcc.com> On 04/09/2014 06:04 PM, Miles Fidelman wrote: > > Especially after reading some of the discussions on the DMARC mailing > list where it's clear that issues of breaking mailing lists were > explicitly ignored and dismissed. There's been 10 years of ostrichism about policy and mailing lists, especially from the crowd who were against ADSP until they were for it. Mike From ag4ve.us at gmail.com Thu Apr 10 17:57:50 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 10 Apr 2014 13:57:50 -0400 Subject: CVE-2014-0160 mitigation using iptables In-Reply-To: <86376.1397137973@turing-police.cc.vt.edu> References: <53451BE8.8060609@ecsc.co.uk> <86376.1397137973@turing-police.cc.vt.edu> Message-ID: On Thu, Apr 10, 2014 at 9:52 AM, wrote: > On Wed, 09 Apr 2014 11:07:36 +0100, Fabien Bourdaire said: > >> # Log rules >> iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ >> "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" > > That 52= isn't going to work if it's an IPv4 packet with an unexpected > number IP or TCP options, or an IPv6 connection.... IPv6 wasn't mentioned here (that'd be ip6tables). But yeah, there might be some other shortcomings with the match. I think it's the right way to go - it just needs a bit of work (maybe a bm string match?). You're also going to deal with different versions (see ssl-heartbleed.nse for the breakdown). Though, I wonder if there are any other variations you might miss... From nanog.smitasin at gmail.com Thu Apr 10 16:28:47 2014 From: nanog.smitasin at gmail.com (Nanog Smitasin) Date: Thu, 10 Apr 2014 09:28:47 -0700 Subject: Akamai DNS for GoDaddy hosted servers? Message-ID: Anyone else hosting at GoDaddy seeing NXDOMAIN from some Akamai servers? Example: # dig +trace ip-redacted.ip.secureserver.net ; <<>> DiG 9.9.5 <<>> +trace ip-redacted.ip.secureserver.net ;; global options: +cmd secureserver.net. 172800 IN NS cns1.secureserver.net. secureserver.net. 172800 IN NS cns2.secureserver.net. secureserver.net. 172800 IN NS a9-67.akam.net. secureserver.net. 172800 IN NS a8-67.akam.net. secureserver.net. 172800 IN NS a1-245.akam.net. secureserver.net. 172800 IN NS a20-65.akam.net. secureserver.net. 172800 IN NS a11-64.akam.net. secureserver.net. 172800 IN NS a6-66.akam.net. # dig ip-redacted.ip.secureserver.net at cns1.secureserver.net ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28818 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; ANSWER SECTION: ip-redacted.ip.secureserver.net. 3600 IN A REDACTED ;; AUTHORITY SECTION: ip.secureserver.net. 3600 IN NS cns2.secureserver.net. ip.secureserver.net. 3600 IN NS cns1.secureserver.net. # dig ip-redacted.ip.secureserver.net @a9-67.akam.net ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56606 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip-redacted.ip.secureserver.net. IN A ;; AUTHORITY SECTION: secureserver.net. 3600 IN SOA cns1.secureserver.net. dns.jomax.net. 2014041000 300 600 2592000 3600 ;; Query time: 13 msec ;; SERVER: 184.85.248.67#53(184.85.248.67) ;; WHEN: Thu Apr 10 09:11:21 PDT 2014 ;; MSG SIZE rcvd: 115 From nazgul at marrowbones.com Thu Apr 10 19:22:24 2014 From: nazgul at marrowbones.com (Kee Hinckley) Date: Thu, 10 Apr 2014 15:22:24 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5346A187.50107@dcrocker.net> References: <53466EDF.1030606@meetinghouse.net> <5346A187.50107@dcrocker.net> Message-ID: <5B037999-DCE4-4095-AC95-09A5449C44C8@marrowbones.com> On 10 Apr 2014, at 9:49, Dave Crocker wrote: > Unfortunately, that has no relationship to do with the current > situation. Again: Yahoo was fully aware of the implications of its > choice. I suspect they looked at the amount of spam they could stop, the number of Yahoo email users, and the number of Yahoo users using mailing lists, and said "That's just noise, it doesn't matter." It happens to be very loud noise, but it's still tiny compared to the overall number of email users. From jcurran at arin.net Thu Apr 10 20:20:26 2014 From: jcurran at arin.net (John Curran) Date: Thu, 10 Apr 2014 20:20:26 +0000 Subject: ARIN 33 Chicago - 14 proposed changes to IP address policy (non-attendee options) Message-ID: <6DAB26F2-8AFF-4F40-80C7-018335162BB9@corp.arin.net> NANOGers - There are a particularly large number of proposed changes to Internet number resource policy that will be discussed next week at the ARIN 33 meeting in Chicago, and for those who will _not_ be attending, there are still two good options for providing input on these potential changes: 1) Express your support or opposition (and reasoning if possible) on any of the proposed changes on the ARIN Public Policy Mailing List (ppml) 2) Participate remotely in the discussion at the ARIN 33 meeting (remote participants can view the real-time feed, make statements, ask questions, and participate in polls on proposals just as those on-site) Participants must register to participate on-site or remotely in the meeting. You can find information on the proposals and posting comments to arin-ppml here - https://www.arin.net/policy/proposals/ For information on being a remote participant in the ARIN 33 meeting - https://www.arin.net/ARIN33_remote There is also an ARIN 33 discussion guide with all of the proposals, their associated staff/legal reviews, and the current policy manual and policy development process - https://www.arin.net/participate/meetings/reports/ARIN_33/materials/discussion-guide.pdf ARIN administers the number resources in the region in accordance with policy developed by community; participation is open to everyone and improves the quality of the resulting policy that we must follow. Thanks! /John John Curran President and CEO ARIN From ttauber at 1-4-5.net Thu Apr 10 21:25:51 2014 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 10 Apr 2014 17:25:51 -0400 Subject: BGPMON Alert Questions In-Reply-To: <201404101526.54008.mark.tinka@seacom.mu> References: <201404101210.19987.mark.tinka@seacom.mu> <201404101526.54008.mark.tinka@seacom.mu> Message-ID: On Thu, Apr 10, 2014 at 9:26 AM, Mark Tinka wrote: > On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote: > > > as folk start to roll out rejection of invalids, we might > > think about how we report problems with folk registering > > inadequate roas, covering their customers, covering > > their deaggs (maybe deaggs get what they deserve), etc. > > if they are not clued enough to generate prudent roas, > > they will not be clued enough to generate ghostbusters > > (and neither ripe's nor apnic's software supports gbrs > > today). > > > It would be useful to use BGPmon's free RPKI validation > feature, which e-mails you, incessantly, about validation > failures due to un-ROA'd de-aggregates. > This seems like good idea and would also be good to know how else to know "I've broken something.". There's a BGP Visibility Project http://visibility.it.uc3m.es/ which perhaps could be brought to bear. Other thoughts out there? Tony From geoffk at geoffk.org Thu Apr 10 21:40:36 2014 From: geoffk at geoffk.org (Geoffrey Keating) Date: 10 Apr 2014 14:40:36 -0700 Subject: Yahoo DMARC breakage In-Reply-To: <20140410030056.GB3886@dyn.com> References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> Message-ID: Andrew Sullivan writes: > I think DMARC is mostly useful when used correctly. There is no BCP > yet... There is, however, BCP167/RFC6377 covering DKIM and mailing lists. Some relevant sections are 4.1 and 5.3: 4.1: ... site administrators wishing to employ ADSP with a "discardable" setting SHOULD separate the controlled mail stream warranting this handling from other mail streams that are less controlled, such as personal mail that transits MLMs [Mailing List Managers]. 5.3: At subscription time, an ADSP-aware MLM SHOULD check for a published ADSP record for the new subscriber's domain. If the policy specifies "discardable", the MLM SHOULD disallow the subscription or present a warning... From LarrySheldon at cox.net Fri Apr 11 01:36:45 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 10 Apr 2014 20:36:45 -0500 Subject: ID10T out of office responders (was Re: Yahoo DMARC breakage) In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> Message-ID: <5347472D.4030804@cox.net> On 4/10/2014 6:29 AM, Rich Kulawiec wrote: > On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote: >> Maybe this is a good thing - we can stop getting all the "sorry I'm >> out of the office" emails when posting to a list. > > I entirely support that goal, but my preferred solution is the complete > eradication of the software (a lot of which makes mistakes that have > been well-known as mistakes for decades) and thus the entire practice > of setting up "out of office" messages. [relevant discussion] > But I think by now everyone who is capable of being educated has been > educated and realizes that the one of the reasons for the absence of a > response is that the recipient hasn't seen the relevant message yet. > There's really no need to spin the roulette wheel and hope that the > combination of MUAs and MTAs on both ends is functional enough to enable > the out-of-office software (optimistically presuming it's halfway sane) > to figure out what it should do. And the truly paranoid that are scared to death that nobody will miss them, have learned to forward the flow to a device that is never "out of the office". (I have filters on the two accounts whose mail I EVER read that forward mail from named sources to my BlackBerry. My Kindle gets copies af all mail sent to those two accounts (mostly since I have been to lazy to set up the filtered stream and I almost never look at it anyway). > And that's before we even get to the security and privacy issues > that are in play, which are substantial. And that is where I started. In every other part of my life the conventional wisdom has been "do NOT put a thing on the Sassiety page about your up-coming around-the-world cruise and the camera equipment you have bought for the trip", "Leave lights and a radio on timers", "stop the mil and the newspapers", "get somebody to mow the lawn and pick up the trash every few days", "have somebody down the street park their car in your driveway"and so on. Why on G*ds blue Earth would I want put up posters and flyers that say "need a stapler? I just got a new one.", "I won't be looking for my desk chair for a while.", and "If your keyboard fails,......"? > So while there are numerous approaches to solving the problem of > errant out-of-office messages, and some of those approaches work > pretty well in the field, I would prefer to kill the problem by > attacking the source: the *existence* of out-of-office autoresponders. Amen -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From oscar.vives at gmail.com Fri Apr 11 07:16:00 2014 From: oscar.vives at gmail.com (Tei) Date: Fri, 11 Apr 2014 09:16:00 +0200 Subject: ID10T out of office responders (was Re: Yahoo DMARC breakage) In-Reply-To: <5347472D.4030804@cox.net> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <5347472D.4030804@cox.net> Message-ID: So.... Suppose I configure my email to send a "Thanks, we have received your email, we will reply shortly in office hours.". Whats the Holy Headers so even poorly configured servers don't cause a AutoReply Storm? Googling, I found "Precedence", "X-Auto-Response-Suppress",..? For something like this, normally I would scan lots of opensource projects in www.google.com/codesearch (so I can learn from the projects with a large number of hours in production) , but seems down at the moment. -- -- ?in del ?ensaje. From LarrySheldon at cox.net Fri Apr 11 07:27:49 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 11 Apr 2014 02:27:49 -0500 Subject: ID10T out of office responders In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <5347472D.4030804@cox.net> Message-ID: <53479975.4070109@cox.net> On 4/11/2014 2:16 AM, Tei wrote: > So.... > > Suppose I configure my email to send a "Thanks, we have received your > email, we will reply shortly in office hours.". Whats the Holy Headers > so even poorly configured servers don't cause a AutoReply Storm? > Googling, I found "Precedence", "X-Auto-Response-Suppress",..? For > something like this, normally I would scan lots of opensource projects > in www.google.com/codesearch (so I can learn from the projects with > a large number of hours in production) , but seems down at the > moment. Any device or process that uses information from the infinitely forgeable email headers is a process or device that can be subverted. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From daniel.crompton at gmail.com Fri Apr 11 07:49:28 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Fri, 11 Apr 2014 09:49:28 +0200 Subject: ID10T out of office responders In-Reply-To: <53479975.4070109@cox.net> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <5347472D.4030804@cox.net> <53479975.4070109@cox.net> Message-ID: My experience shows that when things go wrong there is usually an amplified feedback loop between your mail server and the remote, so ensure that any header you set is one that you drop too. This is also why the mighty no-reply@ was thought up, which simply drops all mail. It might be crude, but it's effective. D. -- Excuse my brevity, I'm using a mobile device On Apr 11, 2014 9:30 AM, "Larry Sheldon" wrote: > On 4/11/2014 2:16 AM, Tei wrote: > >> So.... >> >> Suppose I configure my email to send a "Thanks, we have received your >> email, we will reply shortly in office hours.". Whats the Holy Headers >> so even poorly configured servers don't cause a AutoReply Storm? >> Googling, I found "Precedence", "X-Auto-Response-Suppress",..? For >> something like this, normally I would scan lots of opensource projects >> in www.google.com/codesearch (so I can learn from the projects with >> a large number of hours in production) , but seems down at the >> moment. >> > > > Any device or process that uses information from the infinitely forgeable > email headers is a process or device that can be subverted. > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > From jethro.binks at strath.ac.uk Fri Apr 11 08:05:48 2014 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Fri, 11 Apr 2014 09:05:48 +0100 (BST) Subject: ID10T out of office responders (was Re: Yahoo DMARC breakage) In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <5347472D.4030804@cox.net> Message-ID: On Fri, 11 Apr 2014, Tei wrote: > Suppose I configure my email to send a "Thanks, we have received your > email, we will reply shortly in office hours.". Whats the Holy Headers > so even poorly configured servers don't cause a AutoReply Storm? > Googling, I found "Precedence", "X-Auto-Response-Suppress",..? For > something like this, normally I would scan lots of opensource projects > in www.google.com/codesearch (so I can learn from the projects with > a large number of hours in production) , but seems down at the > moment. If that's what you want to do, then setting one or more of these may help: Auto-submitted: auto-generated X-Auto-Response-Suppress: OOF Precendence: bulk (Other values of the last two are possible). RFC3834 is background reading and references Auto-submitted:. X-Auto-Response-Suppress: is used by MS Exchange/Outlook. But if those servers really are "poorly configured", there's no guarantee they will honour any of those anyway. If you want more control for yourself, you need to filter the return messages out. I do this in Exim to identify "automatically generated email" to be thrown away in some circumstances: condition = ${if or { \ { match {$h_precedence:} {(?i)junk|bulk|list} } \ { eq {$sender_address} {} } \ { def:header_X-Cron-Env: } \ { def:header_Auto-Submitted: } \ { def:header_List-Id: } \ { def:header_List-Help: } \ { def:header_List-Unsubscribe: } \ { def:header_List-Subscribe: } \ { def:header_List-Owner: } \ { def:header_List-Post: } \ { def:header_List-Archive: } \ { def:header_Autorespond: } \ { def:header_X-Autoresponse: } \ { def:header_X-Autoreply-From: } \ { def:header_X-eBay-MailTracker: } \ { def:header_X-MaxCode-Template: } \ { match {$h_X-Auto-Response-Suppress: } {OOF} } \ { match {$h_X-OS:} {HP Onboard Administrator} } \ { match {$h_X-MimeOLE:} {\N^Produced By phpBB2$\N} } \ { match {$h_Subject:} {\N^Yahoo! Auto Response$\N} } \ { match {$h_Subject:} {\N^ezmlm warning$\N} } \ { match {$h_X-FC-MachineGenerated:} {true} } \ { match {$h_X-Spam-Flag:} {\N^yes\N} } \ { match {$message_body} {\N^Your \"cron\" job on\N} } \ { match {$h_Subject:} {\N^Out of Office\N} } \ { match {$h_Subject:} {\N^Auto-Reply:\N} } \ { match {$h_Subject:} {\N^Autoresponse:\N} } \ { match {$h_Subject:} {\N(Auto Reply)$\N} } \ { match {$h_Subject:} {\N(Out of Office)$\N} } \ { match {$h_Subject:} {\Nis out of the office.$\N} } \ { match {$h_From:} {\N(via the vacation program)\N } } \ { ! match {$header_To: $header_CC: $header_Bcc: \ $header_Resent-To: $header_Resent-Cc: $header_Resent-Bcc:} \ } \ } {no} {yes} \ } (I have not reviewed this for a very long time). Be careful. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From rsk at gsp.org Fri Apr 11 08:55:53 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 11 Apr 2014 04:55:53 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5B037999-DCE4-4095-AC95-09A5449C44C8@marrowbones.com> References: <53466EDF.1030606@meetinghouse.net> <5346A187.50107@dcrocker.net> <5B037999-DCE4-4095-AC95-09A5449C44C8@marrowbones.com> Message-ID: <20140411085528.GA12513@gsp.org> On Thu, Apr 10, 2014 at 03:22:24PM -0400, Kee Hinckley wrote: > I suspect they looked at the amount of spam they could stop [...] Which is, to a very good first approximation, zero. Nearly all (at least 99% and likely quite a bit more) of the spam [as observed by my numerous spamtraps] that purports to originate from Yahoo really *does* originate from Yahoo. All that I have to do to verify that is to look at the originating host -- that is, it's not necessary to check DMARC or anything else. There are several reasons for this. First, Yahoo has done an absolutely miserable job of outbound abuse control. For over a decade. Second, they've done a correspondingly miserable job of handling abuse reports, so even when one of their victims is kind and generous enough to do their work for them and tell them that they have a problem...they don't pay attention and they don't take any action. (Or they fire back a clueless boilerplate denial that it was their user on their host on their network...even though it was all three.) Also for over a decade. Third, why would any spammer forge a @yahoo.com address when it's easy enough to buy hijacked accounts by the bucketful -- or to use any of the usual exploits to go get some? Fourth, at least some spammers seem to have caught on that Yahoo isn't *worth* forging: it's a toxic cesspool because the people running it have allowed it to be become one. So let's not pretend that this has anything to do with stopping spam. If Yahoo actually wanted to do something about spam, they could have done that years and years ago simply by *paying attention* to what was going on inside their own operation. ---rsk From glen.kent at gmail.com Fri Apr 11 10:24:11 2014 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 11 Apr 2014 15:54:11 +0530 Subject: Heartbleed Bug Found in Cisco Routers, Juniper Gear Message-ID: http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 Glen From ruairi.carroll at gmail.com Fri Apr 11 10:34:11 2014 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Fri, 11 Apr 2014 12:34:11 +0200 Subject: Heartbleed Bug Found in Cisco Routers, Juniper Gear In-Reply-To: References: Message-ID: Slightly sensationalistic article, tends to imply that heartbleed will allow you to capture data-plane traffic on any piece of Cisco/Juniper kit. Either way, as I've said before, if you're exposing *any* management interfaces, be is ssh,netconf or https to the internet in general, you've got bigger issues than just heartbleed. VPN, on the other hand, is a totally different world of pain for this issue. /ruairi On 11 April 2014 12:24, Glen Kent wrote: > > http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 > > Glen > From glen.kent at gmail.com Fri Apr 11 11:16:03 2014 From: glen.kent at gmail.com (Glen Kent) Date: Fri, 11 Apr 2014 16:46:03 +0530 Subject: Heartbleed Bug Found in Cisco Routers, Juniper Gear In-Reply-To: References: Message-ID: > > Either way, as I've said before, if you're exposing *any* management > interfaces, be is ssh,netconf or https to the internet in general, you've > got bigger issues than just heartbleed. > Sure, i agree. > > VPN, on the other hand, is a totally different world of pain for this > issue. > What about VPNs? Glen > > /ruairi > > > > On 11 April 2014 12:24, Glen Kent wrote: > >> >> http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 >> >> Glen >> > > From Jack.Stonebraker at mygrande.com Fri Apr 11 16:13:26 2014 From: Jack.Stonebraker at mygrande.com (Jack Stonebraker) Date: Fri, 11 Apr 2014 16:13:26 +0000 Subject: Chronic Abnormal Traceroutes Traversing Level 3 Message-ID: <1C88157B8801CB448C108286C81ECB630DADE0@SRV-SAM-MBOX02.lan.thrifty.net> If there's anybody from Level 3 Transport available, I'd like to discuss some bizarre results when traversing through your network, namely in Dallas, TX over the past few months? I'm working this through your NOC as well, but figured I would cover all avenues as this issue is pretty chronic. Taken from your Looking Glass in Dallas to a destination of 195.110.36.136 1 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 120 msec vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 120 msec vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 120 msec 2 ae-93-93.ebr3.Dallas1.Level3.net (4.69.151.170) 120 msec ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 120 msec ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 120 msec 3 ae-7-7.ebr4.Atlanta2.Level3.net (4.69.134.22) 36 msec 20 msec 20 msec 4 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 120 msec 116 msec 120 msec 5 ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 120 msec ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec 6 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 120 msec 120 msec ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 124 msec 7 ae-44-44.ebr2.Paris1.Level3.net (4.69.137.61) 120 msec ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 116 msec 116 msec 8 ae-62-62.csw1.Paris1.Level3.net (4.69.161.94) 124 msec ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 120 msec 120 msec 9 ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 120 msec ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 124 msec ae-71-71.ebr1.Paris1.Level3.net (4.69.161.81) 120 msec 10 ae-41-41.ebr2.London2.Level3.net (4.69.159.81) 120 msec 120 msec ae-43-43.ebr2.London2.Level3.net (4.69.159.89) 120 msec 11 ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 116 msec 120 msec 120 msec 12 ae-26-26.car2.London2.Level3.net (4.69.200.98) 120 msec 120 msec 120 msec 13 BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 120 msec 120 msec 120 msec 14 * * * 15 * * * 16 * * * I'm confused how the first and last hops are showing equal latency, while being half way around the world. I'm also confused why it's 120ms to the first hop from a route server local to that market. While I wouldn't rely on a traceroute as a true measurement of end to end latency, I'm having problems explaining to customers experiencing tangible issues when their traceroute looks like this: traceroute source 24.155.144.226 195.110.36.136 traceroute to 195.110.36.136 (195.110.36.136) from 24.155.144.226, 30 hops max, 40 byte packets 1 lag-8-868.ear1.Dallas1.Level3.net (4.30.74.53) 924.705 ms 545.117 ms 512.992 ms 2 4.69.146.5 (4.69.146.5) 124.812 ms 4.69.146.21 (4.69.146.21) 125.686 ms 4.69.146.9 (4.69.146.9) 124.018 ms MPLS Label=1965 CoS=0 TTL=1 S=1 3 ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 125.012 ms ae-83-83.ebr3.Dallas1.Level3.net (4.69.151.158) 141.585 ms ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 125.005 ms MPLS Label=1810 CoS=0 TTL=1 S=1 4 * * * 5 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 126.085 ms 125.994 ms 127.148 ms MPLS Label=1692 CoS=0 TTL=1 S=1 6 ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 124.500 ms ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 125.369 ms ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 124.306 ms MPLS Label=1555 CoS=0 TTL=1 S=1 7 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 131.126 ms 128.607 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 123.955 ms MPLS Label=1636 CoS=0 TTL=1 S=1 8 ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 127.156 ms ae-41-41.ebr2.Paris1.Level3.net (4.69.137.49) 125.736 ms ae-43-43.ebr2.Paris1.Level3.net (4.69.137.57) 143.070 ms MPLS Label=1801 CoS=0 TTL=1 S=1 9 ae-82-82.csw3.Paris1.Level3.net (4.69.161.102) 122.998 ms 122.245 ms ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 124.499 ms MPLS Label=1564 CoS=0 TTL=1 S=1 10 ae-61-61.ebr1.Paris1.Level3.net (4.69.161.77) 129.705 ms ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 122.705 ms ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 126.454 ms MPLS Label=1322 CoS=0 TTL=1 S=1 11 ae-42-42.ebr2.London2.Level3.net (4.69.159.85) 126.019 ms 125.672 ms ae-44-44.ebr2.London2.Level3.net (4.69.159.93) 127.026 ms MPLS Label=1911 CoS=0 TTL=1 S=1 12 ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 122.058 ms 124.301 ms 123.397 ms MPLS Label=300112 CoS=0 TTL=1 S=1 13 ae-26-26.car2.London2.Level3.net (4.69.200.98) 124.003 ms 124.567 ms 130.346 ms 14 BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 125.316 ms 125.991 ms 124.968 ms 15 * * * This also doesn't seem to be circuit specific (Eliminating possible physical circuit errors, etc) as I have a secondary 10-Gig sourcing out of San Antonio, TX (Which ultimately terminates on your network in Dallas, same as the Austin Circuit) which demonstrates similar results (120+ ms at the second hop in Dallas when entering your MPLS cloud). Killing the BGP adjacency to both the Austin and San Antonio peers clears the issue up, but obviously that's not a long term viable option. Any help would be appreciated. JJ Stonebraker IP Network Engineering Grande Communications 512.878.5627 From Jack.Stonebraker at mygrande.com Fri Apr 11 16:25:25 2014 From: Jack.Stonebraker at mygrande.com (Jack Stonebraker) Date: Fri, 11 Apr 2014 16:25:25 +0000 Subject: Chronic Abnormal Traceroutes Traversing Level 3 In-Reply-To: References: <1C88157B8801CB448C108286C81ECB630DADE0@SRV-SAM-MBOX02.lan.thrifty.net> Message-ID: <1C88157B8801CB448C108286C81ECB630DAE1D@SRV-SAM-MBOX02.lan.thrifty.net> Ah Ha! Thanks Nick and Trent! Well that explains the path being even at the MPLS cloud. JJ Stonebraker IP Network Engineering Grande Communications 512.878.5627 ________________________________ From: Trent Farrell [mailto:tfarrell at riotgames.com] Sent: Friday, April 11, 2014 11:19 AM To: Jack Stonebraker Cc: nanog at nanog.org Subject: Re: Chronic Abnormal Traceroutes Traversing Level 3 RTT gets calculated before the packet enters a MPLS network. On Fri, Apr 11, 2014 at 5:13 PM, Jack Stonebraker > wrote: If there's anybody from Level 3 Transport available, I'd like to discuss some bizarre results when traversing through your network, namely in Dallas, TX over the past few months? I'm working this through your NOC as well, but figured I would cover all avenues as this issue is pretty chronic. Taken from your Looking Glass in Dallas to a destination of 195.110.36.136 1 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 120 msec vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 120 msec vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 120 msec 2 ae-93-93.ebr3.Dallas1.Level3.net (4.69.151.170) 120 msec ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 120 msec ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 120 msec 3 ae-7-7.ebr4.Atlanta2.Level3.net (4.69.134.22) 36 msec 20 msec 20 msec 4 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 120 msec 116 msec 120 msec 5 ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 120 msec ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec 6 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 120 msec 120 msec ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 124 msec 7 ae-44-44.ebr2.Paris1.Level3.net (4.69.137.61) 120 msec ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 116 msec 116 msec 8 ae-62-62.csw1.Paris1.Level3.net (4.69.161.94) 124 msec ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 120 msec 120 msec 9 ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 120 msec ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 124 msec ae-71-71.ebr1.Paris1.Level3.net (4.69.161.81) 120 msec 10 ae-41-41.ebr2.London2.Level3.net (4.69.159.81) 120 msec 120 msec ae-43-43.ebr2.London2.Level3.net (4.69.159.89) 120 msec 11 ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 116 msec 120 msec 120 msec 12 ae-26-26.car2.London2.Level3.net (4.69.200.98) 120 msec 120 msec 120 msec 13 BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 120 msec 120 msec 120 msec 14 * * * 15 * * * 16 * * * I'm confused how the first and last hops are showing equal latency, while being half way around the world. I'm also confused why it's 120ms to the first hop from a route server local to that market. While I wouldn't rely on a traceroute as a true measurement of end to end latency, I'm having problems explaining to customers experiencing tangible issues when their traceroute looks like this: traceroute source 24.155.144.226 195.110.36.136 traceroute to 195.110.36.136 (195.110.36.136) from 24.155.144.226, 30 hops max, 40 byte packets 1 lag-8-868.ear1.Dallas1.Level3.net (4.30.74.53) 924.705 ms 545.117 ms 512.992 ms 2 4.69.146.5 (4.69.146.5) 124.812 ms 4.69.146.21 (4.69.146.21) 125.686 ms 4.69.146.9 (4.69.146.9) 124.018 ms MPLS Label=1965 CoS=0 TTL=1 S=1 3 ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 125.012 ms ae-83-83.ebr3.Dallas1.Level3.net (4.69.151.158) 141.585 ms ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 125.005 ms MPLS Label=1810 CoS=0 TTL=1 S=1 4 * * * 5 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 126.085 ms 125.994 ms 127.148 ms MPLS Label=1692 CoS=0 TTL=1 S=1 6 ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 124.500 ms ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 125.369 ms ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 124.306 ms MPLS Label=1555 CoS=0 TTL=1 S=1 7 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 131.126 ms 128.607 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 123.955 ms MPLS Label=1636 CoS=0 TTL=1 S=1 8 ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 127.156 ms ae-41-41.ebr2.Paris1.Level3.net (4.69.137.49) 125.736 ms ae-43-43.ebr2.Paris1.Level3.net (4.69.137.57) 143.070 ms MPLS Label=1801 CoS=0 TTL=1 S=1 9 ae-82-82.csw3.Paris1.Level3.net (4.69.161.102) 122.998 ms 122.245 ms ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 124.499 ms MPLS Label=1564 CoS=0 TTL=1 S=1 10 ae-61-61.ebr1.Paris1.Level3.net (4.69.161.77) 129.705 ms ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 122.705 ms ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 126.454 ms MPLS Label=1322 CoS=0 TTL=1 S=1 11 ae-42-42.ebr2.London2.Level3.net (4.69.159.85) 126.019 ms 125.672 ms ae-44-44.ebr2.London2.Level3.net (4.69.159.93) 127.026 ms MPLS Label=1911 CoS=0 TTL=1 S=1 12 ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 122.058 ms 124.301 ms 123.397 ms MPLS Label=300112 CoS=0 TTL=1 S=1 13 ae-26-26.car2.London2.Level3.net (4.69.200.98) 124.003 ms 124.567 ms 130.346 ms 14 BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 125.316 ms 125.991 ms 124.968 ms 15 * * * This also doesn't seem to be circuit specific (Eliminating possible physical circuit errors, etc) as I have a secondary 10-Gig sourcing out of San Antonio, TX (Which ultimately terminates on your network in Dallas, same as the Austin Circuit) which demonstrates similar results (120+ ms at the second hop in Dallas when entering your MPLS cloud). Killing the BGP adjacency to both the Austin and San Antonio peers clears the issue up, but obviously that's not a long term viable option. Any help would be appreciated. JJ Stonebraker IP Network Engineering Grande Communications 512.878.5627 -- Trent Farrell Riot Games IP Network Engineer E: tfarrell at riotgames.com | IE: +353 86 845 7230 | US: +1 424 285 9825 Summoner name: Foro From dlr at bungi.com Fri Apr 11 17:01:59 2014 From: dlr at bungi.com (Dave Rand) Date: Fri, 11 Apr 2014 10:01:59 -0700 Subject: Gmail contact please? Message-ID: Is there a good contact at Gmail that can take care of a persistant issue for me? Thanks in advance, Dave Rand dlr at kelkea.com or dlr at bungi.com -- From cscora at apnic.net Fri Apr 11 18:11:52 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Apr 2014 04:11:52 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201404111811.s3BIBqG4013968@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 12 Apr, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 490753 Prefixes after maximum aggregation: 193016 Deaggregation factor: 2.54 Unique aggregates announced to Internet: 242489 Total ASes present in the Internet Routing Table: 46574 Prefixes per ASN: 10.54 Origin-only ASes present in the Internet Routing Table: 35707 Origin ASes announcing only one prefix: 16364 Transit ASes present in the Internet Routing Table: 6067 Transit-only ASes present in the Internet Routing Table: 173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1855 Unregistered ASNs in the Routing Table: 471 Number of 32-bit ASNs allocated by the RIRs: 6366 Number of 32-bit ASNs visible in the Routing Table: 4800 Prefixes from 32-bit ASNs in the Routing Table: 15763 Number of bogon 32-bit ASNs visible in the Routing Table: 95 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 493 Number of addresses announced to Internet: 2667159300 Equivalent to 158 /8s, 249 /16s and 159 /24s Percentage of available address space announced: 72.0 Percentage of allocated address space announced: 72.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.1 Total number of prefixes smaller than registry allocations: 171113 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 116260 Total APNIC prefixes after maximum aggregation: 34801 APNIC Deaggregation factor: 3.34 Prefixes being announced from the APNIC address blocks: 119063 Unique aggregates announced from the APNIC address blocks: 49824 APNIC Region origin ASes present in the Internet Routing Table: 4911 APNIC Prefixes per ASN: 24.24 APNIC Region origin ASes announcing only one prefix: 1222 APNIC Region transit ASes present in the Internet Routing Table: 859 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 906 Number of APNIC addresses announced to Internet: 729825408 Equivalent to 43 /8s, 128 /16s and 64 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 167314 Total ARIN prefixes after maximum aggregation: 82965 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 168705 Unique aggregates announced from the ARIN address blocks: 78477 ARIN Region origin ASes present in the Internet Routing Table: 16199 ARIN Prefixes per ASN: 10.41 ARIN Region origin ASes announcing only one prefix: 6096 ARIN Region transit ASes present in the Internet Routing Table: 1676 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 84 Number of ARIN addresses announced to Internet: 1068639616 Equivalent to 63 /8s, 178 /16s and 37 /24s Percentage of available ARIN address space announced: 56.5 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 123278 Total RIPE prefixes after maximum aggregation: 62465 RIPE Deaggregation factor: 1.97 Prefixes being announced from the RIPE address blocks: 127543 Unique aggregates announced from the RIPE address blocks: 81103 RIPE Region origin ASes present in the Internet Routing Table: 17665 RIPE Prefixes per ASN: 7.22 RIPE Region origin ASes announcing only one prefix: 8294 RIPE Region transit ASes present in the Internet Routing Table: 2864 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2686 Number of RIPE addresses announced to Internet: 657604740 Equivalent to 39 /8s, 50 /16s and 64 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 55643 Total LACNIC prefixes after maximum aggregation: 10081 LACNIC Deaggregation factor: 5.52 Prefixes being announced from the LACNIC address blocks: 61878 Unique aggregates announced from the LACNIC address blocks: 28388 LACNIC Region origin ASes present in the Internet Routing Table: 2085 LACNIC Prefixes per ASN: 29.68 LACNIC Region origin ASes announcing only one prefix: 551 LACNIC Region transit ASes present in the Internet Routing Table: 434 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1102 Number of LACNIC addresses announced to Internet: 157533312 Equivalent to 9 /8s, 99 /16s and 196 /24s Percentage of available LACNIC address space announced: 93.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12389 Total AfriNIC prefixes after maximum aggregation: 2666 AfriNIC Deaggregation factor: 4.65 Prefixes being announced from the AfriNIC address blocks: 13071 Unique aggregates announced from the AfriNIC address blocks: 4272 AfriNIC Region origin ASes present in the Internet Routing Table: 715 AfriNIC Prefixes per ASN: 18.28 AfriNIC Region origin ASes announcing only one prefix: 201 AfriNIC Region transit ASes present in the Internet Routing Table: 151 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 22 Number of AfriNIC addresses announced to Internet: 53141504 Equivalent to 3 /8s, 42 /16s and 224 /24s Percentage of available AfriNIC address space announced: 52.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2919 11589 898 Korea Telecom 17974 2780 903 78 PT Telekomunikasi Indonesia 7545 2216 320 115 TPG Telecom Limited 4755 1843 396 197 TATA Communications formerly 9829 1622 1288 35 National Internet Backbone 4808 1366 2226 386 CNCGROUP IP network China169 9583 1317 102 534 Sify Limited 9498 1245 310 75 BHARTI Airtel Ltd. 7552 1223 1082 13 Viettel Corporation 24560 1123 384 177 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2997 3688 53 BellSouth.net Inc. 22773 2411 2938 137 Cox Communications Inc. 1785 2192 697 130 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1702 1683 581 Charter Communications 4323 1635 1074 416 tw telecom holdings, inc. 701 1480 11156 751 MCI Communications Services, 30036 1395 301 545 Mediacom Communications Corp 22561 1309 402 232 CenturyTel Internet Holdings, 7018 1268 18243 831 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1649 544 16 OJSC "Vimpelcom" 34984 1555 263 278 TELLCOM ILETISIM HIZMETLERI A 20940 1294 495 981 Akamai International B.V. 31148 1017 45 21 Freenet Ltd. 13188 945 94 109 TOV "Bank-Inform" 8551 927 370 41 Bezeq International-Ltd 6849 830 360 30 JSC "Ukrtelecom" 6830 763 2329 426 Liberty Global Operations B.V 12479 718 797 56 France Telecom Espana SA 35228 553 245 17 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3662 1948 97 NET Servi?os de Comunica??o S 10620 2820 454 211 Telmex Colombia S.A. 18881 1922 972 21 Global Village Telecom 7303 1753 1173 229 Telecom Argentina S.A. 8151 1398 2940 404 Uninet S.A. de C.V. 6503 1154 434 60 Axtel, S.A.B. de C.V. 7738 914 1754 40 Telemar Norte Leste S.A. 27947 863 114 50 Telconet S.A 11830 845 364 15 Instituto Costarricense de El 3816 795 321 133 COLOMBIA TELECOMUNICACIONES S Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1637 240 6 Sudanese Mobile Telephone (ZA 24863 954 280 26 Link Egypt (Link.NET) 6713 614 722 28 Office National des Postes et 8452 568 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 295 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 37054 234 23 11 Data Telecom Service 29571 219 22 18 Cote d'Ivoire Telecom 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3662 1948 97 NET Servi?os de Comunica??o S 6389 2997 3688 53 BellSouth.net Inc. 4766 2919 11589 898 Korea Telecom 10620 2820 454 211 Telmex Colombia S.A. 17974 2780 903 78 PT Telekomunikasi Indonesia 22773 2411 2938 137 Cox Communications Inc. 7545 2216 320 115 TPG Telecom Limited 1785 2192 697 130 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1922 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2997 2944 BellSouth.net Inc. 17974 2780 2702 PT Telekomunikasi Indonesia 10620 2820 2609 Telmex Colombia S.A. 22773 2411 2274 Cox Communications Inc. 7545 2216 2101 TPG Telecom Limited 1785 2192 2062 PaeTec Communications, Inc. 4766 2919 2021 Korea Telecom 18881 1922 1901 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1843 1646 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.55.64.0/21 36423 San Juan Cable, LLC 24.55.72.0/21 36423 San Juan Cable, LLC 24.55.80.0/21 36423 San Juan Cable, LLC 24.55.88.0/21 36423 San Juan Cable, LLC 24.55.96.0/21 36423 San Juan Cable, LLC 24.55.104.0/21 36423 San Juan Cable, LLC 24.55.112.0/21 36423 San Juan Cable, LLC 24.55.120.0/21 36423 San Juan Cable, LLC 24.137.224.0/21 36423 San Juan Cable, LLC 24.137.232.0/21 36423 San Juan Cable, LLC Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:30 /11:90 /12:258 /13:477 /14:958 /15:1671 /16:12921 /17:6806 /18:11584 /19:23973 /20:33892 /21:36648 /22:52388 /23:45822 /24:260959 /25:816 /26:950 /27:403 /28:13 /29:19 /30:8 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1695 2997 BellSouth.net Inc. 22773 1650 2411 Cox Communications Inc. 36998 1599 1637 Sudanese Mobile Telephone (ZA 8402 1328 1649 OJSC "Vimpelcom" 30036 1233 1395 Mediacom Communications Corp 11492 1185 1233 CABLE ONE, INC. 1785 1165 2192 PaeTec Communications, Inc. 6983 1041 1228 ITC^Deltacom 34984 1023 1555 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1022 2:706 3:3 4:15 5:935 6:19 8:721 12:1854 13:4 14:972 15:13 16:2 17:30 18:21 20:35 23:811 24:1745 25:1 27:1752 31:1505 32:40 33:2 34:5 36:129 37:1819 38:946 39:5 40:197 41:3203 42:246 44:16 46:2193 47:18 49:686 50:910 52:12 54:46 55:6 57:29 58:1158 59:606 60:392 61:1529 62:1233 63:1981 64:4336 65:2246 66:4155 67:2063 68:1035 69:3296 70:843 71:450 72:1989 74:2642 75:312 76:412 77:1473 78:992 79:709 80:1310 81:1144 82:746 83:754 84:706 85:1264 86:451 87:1197 88:520 89:1823 90:140 91:5748 92:668 93:1717 94:2067 95:1522 96:544 97:350 98:1075 99:46 100:50 101:785 103:4626 105:534 106:168 107:552 108:564 109:2025 110:985 111:1273 112:650 113:848 114:882 115:1106 116:1047 117:882 118:1388 119:1330 120:375 121:802 122:1912 123:1291 124:1430 125:1400 128:657 129:324 130:345 131:653 132:395 133:162 134:319 135:73 136:251 137:323 138:356 139:168 140:211 141:360 142:571 143:418 144:501 145:104 146:606 147:434 148:924 149:361 150:161 151:625 152:422 153:218 154:251 155:477 156:332 157:339 158:239 159:874 160:343 161:479 162:1323 163:220 164:685 165:612 166:281 167:610 168:1028 169:124 170:1368 171:187 172:21 173:1633 174:694 175:617 176:1485 177:2903 178:1947 179:648 180:1710 181:1102 182:1533 183:516 184:710 185:1488 186:2800 187:1500 188:1930 189:1453 190:7424 191:191 192:7168 193:5481 194:4026 195:3382 196:1392 197:1143 198:5004 199:5620 200:6083 201:2644 202:8998 203:8904 204:4660 205:2703 206:2920 207:2927 208:4012 209:3712 210:3104 211:1698 212:2176 213:2072 214:900 215:85 216:5468 217:1691 218:584 219:321 220:1282 221:594 222:350 223:613 End of report From bzs at world.std.com Fri Apr 11 18:35:38 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 11 Apr 2014 14:35:38 -0400 (EDT) Subject: DNSSEC? Message-ID: <201404111835.s3BIZcqQ003034@world.std.com> So, DNSSEC is also compromised by this heartbleed bug, right? -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From dougb at dougbarton.us Fri Apr 11 18:44:45 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 11 Apr 2014 11:44:45 -0700 Subject: DNSSEC? In-Reply-To: <201404111835.s3BIZcqQ003034@world.std.com> References: <201404111835.s3BIZcqQ003034@world.std.com> Message-ID: <5348381D.2050705@dougbarton.us> On 04/11/2014 11:35 AM, Barry Shein wrote: > So, DNSSEC is also compromised by this heartbleed bug, right? There is nothing in the DNSSEC protocol that requires the Heartbeat functionality. However whether a specific implementation of DNS software is vulnerable or not depends on how it's compiled. I would expect that most would not be. ISC for example just released a statement that BIND is not: https://lists.isc.org/pipermail/bind-users/2014-April/092944.html hth, Doug From woody at pch.net Fri Apr 11 18:50:28 2014 From: woody at pch.net (Bill Woodcock) Date: Fri, 11 Apr 2014 11:50:28 -0700 Subject: DNSSEC? In-Reply-To: <201404111835.s3BIZcqQ003034@world.std.com> References: <201404111835.s3BIZcqQ003034@world.std.com> Message-ID: <0F470CFA-D3A5-49ED-8651-FD438AADF5D3@pch.net> On Apr 11, 2014, at 11:35 AM, Barry Shein wrote: > > So, DNSSEC is also compromised by this heartbleed bug, right? Nope, apples and oranges. http://www.afilias.info/webfm_send/32 The only point of intersection I can think of is an indirect one, and unfortunately not much used yet: DANE certificates for TLS/SSL connections. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From christopher.morrow at gmail.com Fri Apr 11 19:14:58 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 11 Apr 2014 15:14:58 -0400 Subject: Gmail contact please? In-Reply-To: References: Message-ID: ICMP 0/0 On Apr 11, 2014 1:02 PM, "Dave Rand" wrote: > Is there a good contact at Gmail that can take care of a persistant issue > for me? > > Thanks in advance, > > Dave Rand > dlr at kelkea.com or dlr at bungi.com > > -- > > From cma at cmadams.net Fri Apr 11 19:25:29 2014 From: cma at cmadams.net (Chris Adams) Date: Fri, 11 Apr 2014 14:25:29 -0500 Subject: DNSSEC? In-Reply-To: <201404111835.s3BIZcqQ003034@world.std.com> References: <201404111835.s3BIZcqQ003034@world.std.com> Message-ID: <20140411192529.GE21153@cmadams.net> Once upon a time, Barry Shein said: > So, DNSSEC is also compromised by this heartbleed bug, right? No, wrong. The OpenSSL bug involves an extension to the TLS protocol called "heartbeat" (basically like a TCP or PPP keepalive). DNSSEC does not use TLS (or any other kind of transport encryption). -- Chris Adams From rsk at gsp.org Fri Apr 11 19:30:39 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 11 Apr 2014 15:30:39 -0400 Subject: Fwd: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Message-ID: <20140411193039.GA2724@gsp.org> I'm not forwarding this to get into politics. I'm forwarding it because of the impact on operational security. Given the recent "I hunt sysadmins" leak, I think it's not unreasonable to suggest that everyone on this list has probably been targeted because of their privileged access to networks/servers/services/etc. ---rsk ----- Forwarded message from Richard Forno ----- > Date: Fri, 11 Apr 2014 15:05:03 -0400 > From: Richard Forno > To: Infowarrior List > Subject: [Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years > > NSA Said to Have Used Heartbleed Bug, Exposing Consumers > > By Michael Riley Apr 11, 2014 2:58 PM ET > > http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html > > The U.S. National Security Agency knew for at least two years about a flaw > in the way that many websites send sensitive information, now dubbed the > Heartbleed bug, and regularly used it to gather critical intelligence, > two people familiar with the matter said. > > The NSA's decision to keep the bug secret in pursuit of national security > interests threatens to renew the rancorous debate over the role of the > government's top computer experts. > > Heartbleed appears to be one of the biggest glitches in the Internet's > history, a flaw in the basic security of as many as two-thirds of the > world's websites. Its discovery and the creation of a fix by researchers > five days ago prompted consumers to change their passwords, the Canadian > government to suspend electronic tax filing and computer companies > including Cisco Systems Inc. to Juniper Networks Inc. to provide patches > for their systems. > > Putting the Heartbleed bug in its arsenal, the NSA was able to obtain > passwords and other basic data that are the building blocks of the > sophisticated hacking operations at the core of its mission, but at a > cost. Millions of ordinary users were left vulnerable to attack from > other nations' intelligence arms and criminal hackers. > > Controversial Practice > > "It flies in the face of the agency's comments that defense comes first," > said Jason Healey, director of the cyber statecraft initiative at the > Atlantic Council and a former Air Force cyber officer. "They are going > to be completely shredded by the computer security community for this." [snip] From bzs at world.std.com Fri Apr 11 19:27:43 2014 From: bzs at world.std.com (Barry Shein) Date: Fri, 11 Apr 2014 15:27:43 -0400 Subject: DNSSEC? In-Reply-To: <5348381D.2050705@dougbarton.us> References: <201404111835.s3BIZcqQ003034@world.std.com> <5348381D.2050705@dougbarton.us> Message-ID: <21320.16943.687126.697863@world.std.com> On April 11, 2014 at 11:44 dougb at dougbarton.us (Doug Barton) wrote: > On 04/11/2014 11:35 AM, Barry Shein wrote: > > So, DNSSEC is also compromised by this heartbleed bug, right? > > There is nothing in the DNSSEC protocol that requires the Heartbeat > functionality. However whether a specific implementation of DNS software > is vulnerable or not depends on how it's compiled. I would expect that > most would not be. ISC for example just released a statement that BIND > is not: > > https://lists.isc.org/pipermail/bind-users/2014-April/092944.html Cool, good news. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From christopher.morrow at gmail.com Fri Apr 11 19:37:43 2014 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 11 Apr 2014 15:37:43 -0400 Subject: DNSSEC? In-Reply-To: <21320.16943.687126.697863@world.std.com> References: <201404111835.s3BIZcqQ003034@world.std.com> <5348381D.2050705@dougbarton.us> <21320.16943.687126.697863@world.std.com> Message-ID: (But you should change your DNSSEC password) ;) /troll (so I don't get lots if mail like my procmail question caused) On Apr 11, 2014 3:35 PM, "Barry Shein" wrote: > > On April 11, 2014 at 11:44 dougb at dougbarton.us (Doug Barton) wrote: > > On 04/11/2014 11:35 AM, Barry Shein wrote: > > > So, DNSSEC is also compromised by this heartbleed bug, right? > > > > There is nothing in the DNSSEC protocol that requires the Heartbeat > > functionality. However whether a specific implementation of DNS software > > is vulnerable or not depends on how it's compiled. I would expect that > > most would not be. ISC for example just released a statement that BIND > > is not: > > > > https://lists.isc.org/pipermail/bind-users/2014-April/092944.html > > Cool, good news. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > > From cabo at tzi.org Fri Apr 11 19:37:38 2014 From: cabo at tzi.org (Carsten Bormann) Date: Fri, 11 Apr 2014 21:37:38 +0200 Subject: DNSSEC? In-Reply-To: <20140411192529.GE21153@cmadams.net> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> Message-ID: <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> On 11 Apr 2014, at 21:25, Chris Adams wrote: > DNSSEC does not use TLS (or any other kind of transport encryption). The administrative interfaces controlling the implementation might still do. Gr??e, Carsten From bill at herrin.us Fri Apr 11 20:03:36 2014 From: bill at herrin.us (William Herrin) Date: Fri, 11 Apr 2014 16:03:36 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411193039.GA2724@gsp.org> References: <20140411193039.GA2724@gsp.org> Message-ID: >> The U.S. National Security Agency knew for at least two years about a flaw >> in the way that many websites send sensitive information, now dubbed the >> Heartbleed bug, and regularly used it to gather critical intelligence, >> two people familiar with the matter said. >> >> The NSA's decision to keep the bug secret in pursuit of national security >> interests threatens to renew the rancorous debate over the role of the >> government's top computer experts. I call B.S. Do you have any idea how many thousands of impacted NSA servers run by contractors hung out on the Internet with sensitive NSA data? If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. These two unnamed sources are liars. Bet on it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From niels=nanog at bakker.net Fri Apr 11 20:10:44 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 11 Apr 2014 22:10:44 +0200 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> Message-ID: <20140411201044.GG36211@burnout.tpb.net> * bill at herrin.us (William Herrin) [Fri 11 Apr 2014, 22:04 CEST]: >I call B.S. Do you have any idea how many thousands of impacted NSA >servers run by contractors hung out on the Internet with sensitive NSA >data? If you told me they used it against the targets of the day while >putting out the word to patch I could buy it, but intentionally >leaving a certain bodily extension hanging in the breeze in the hopes >of gaining more valuable data than they lose would have been an >unusually gutsy move. Have you been paying attention at all. Please go read up on some recent and less recent history before making judgments on what would be unusually gutsy for that group of people. I'm not saying this has been happening but you will have to come up with a better defense than "it seems unlikely to me personally". -- Niels. From niels=nanog at bakker.net Fri Apr 11 20:14:42 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 11 Apr 2014 22:14:42 +0200 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411201044.GG36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> Message-ID: <20140411201442.GH36211@burnout.tpb.net> I wrote: >I'm not saying this has been happening ... but here's the same news from a much more credible source: http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html Still anonymously sourced but at least via people whose ability to vet sources you can usually trust. -- Niels. From sfrost at snowman.net Fri Apr 11 20:22:25 2014 From: sfrost at snowman.net (Stephen Frost) Date: Fri, 11 Apr 2014 16:22:25 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411201442.GH36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> <20140411201442.GH36211@burnout.tpb.net> Message-ID: <20140411202225.GD2556@tamriel.snowman.net> * Niels Bakker (niels=nanog at bakker.net) wrote: > but here's the same news from a much more credible source: > > http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html > > Still anonymously sourced but at least via people whose ability to > vet sources you can usually trust. hum. That was included in the original post... Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From cma at cmadams.net Fri Apr 11 20:45:35 2014 From: cma at cmadams.net (Chris Adams) Date: Fri, 11 Apr 2014 15:45:35 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411201442.GH36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> <20140411201442.GH36211@burnout.tpb.net> Message-ID: <20140411204535.GH21153@cmadams.net> Once upon a time, Niels Bakker said: > but here's the same news from a much more credible source: Actually, that's the same news _from the same source_ as originally posted. That article also has other wonderful bits like: The Heartbleed flaw, introduced in early 2012 in a minor adjustment to the OpenSSL protocol, highlights one of the failings of open source software development. While many Internet companies rely on the free code, its integrity depends on a small number of underfunded researchers who devote their energies to the projects. This is fairly typical big-business denigration of Open Source, ignoring the fact that (a) closed source software doesn't get reviewed for things like this, and (b) code like this isn't just written by "underfunded researchers". Red Hat (a billion-dollar company) got their package of OpenSSL through FIPS certification. Even the opening of the article: The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, The flaw has only existed for two years and a couple of weeks (and how many websites deployed a brand-new OpenSSL the day it came out?). So unless the patch was authored by the NSA (which the patch author claims is not the case), they'd have to have known about it before it existed. I don't even fully buy the "two-thirds of the world's websites". I'm not sure that 2/3 of the websites I visit even use SSL. Also, many versions of "enterprise" OSes like Red Hat Enterprise Linux weren't affected (RHEL 5 was not affected, and RHEL 6 was only affected starting with 6.5 from last November). There are a lot of web servers that aren't updated that often (or stay with more "stable" release trains). -- Chris Adams From rsk at gsp.org Fri Apr 11 20:48:02 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 11 Apr 2014 16:48:02 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> Message-ID: <20140411204802.GA4914@gsp.org> On Fri, Apr 11, 2014 at 04:03:36PM -0400, William Herrin wrote: > If you told me they used it against the targets of the day while > putting out the word to patch I could buy it, but intentionally > leaving a certain bodily extension hanging in the breeze in the hopes > of gaining more valuable data than they lose would have been an > unusually gutsy move. "unusually gutsy" compared to what, EXACTLY? Sources: NSA sucks in data from 50 companies http://theweek.com/article/index/245311/sources-nsa-sucks-in-data-from-50-companies Report: NSA Circumvented Encryption http://www.bankinfosecurity.com/report-nsa-circumvented-encryption-a-6045 [ That one is interesting, by the way. It's from September 6, 2013, and quotes reporting by the New York Times and Pro Publica the previous day. Here's an excerpt: Bruce Schneier, a widely followed cryptography expert, author and blogger, characterizes the revelation as explosive. "Basically, the NSA is able to decrypt most of the Internet," he writes in his blog. "They're doing it primarily by cheating, not by mathematics. ... Remember this: The math is good, but math has no agency. Code has agency, and the code has been subverted." According to the news report, some of NSA's most exhaustive efforts have concentrated on encryption widely used in the United States, including Secure Sockets Layer, virtual private networks and the protection used on fourth generation smart phones. Interesting that it mentions SSL, isn't it? ] NSA's pipe dream: Weakening crypto will only help the "good guys" http://arstechnica.com/security/2013/09/nsas-pipe-dream-weakening-crypto-will-only-help-the-good-guys/ Exclusive: NSA infiltrated RSA security more deeply than thought http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331?feedType=RSS&feedName=topNews&utm_source=dlvr.it&utm_medium=twitter&dlvrit=992637 NSA Aiming To Infect "Millions" Of Computers Worldwide With Its Malware; Targets Telco/ISP Systems Administrators http://www.techdirt.com/articles/20140312/07334826545/nsa-aiming-to-infect-millions-computers-worldwide-with-its-malware-targets-telcoisp-systems-administrators.shtml NSA hacker in residence dishes on how to "hunt" system admins http://arstechnica.com/security/2014/03/nsa-hacker-in-residence-dishes-on-how-to-hunt-system-admins/ Let me note in passing that the NSA is not the only intelligence agency on this planet that has demonstrated both willingness and ability to create and/or exploit large scale security breaches in order to acquire information. Surely nobody thinks that folks in Moscow and London and Berlin and Bejing were just sitting on their hands. ---rsk From bill at herrin.us Fri Apr 11 21:05:49 2014 From: bill at herrin.us (William Herrin) Date: Fri, 11 Apr 2014 17:05:49 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411201044.GG36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> Message-ID: On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker wrote: > Please go read up on some recent and less recent history before making > judgments on what would be unusually gutsy for that group of people. > > I'm not saying this has been happening but you will have to come up with a > better defense than "it seems unlikely to me personally". Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word "sensitive" does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpalmer at hezmatt.org Fri Apr 11 21:47:15 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 12 Apr 2014 07:47:15 +1000 Subject: DNSSEC? In-Reply-To: <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> Message-ID: <20140411214715.GV15800@hezmatt.org> On Fri, Apr 11, 2014 at 09:37:38PM +0200, Carsten Bormann wrote: > On 11 Apr 2014, at 21:25, Chris Adams wrote: > > > DNSSEC does not use TLS (or any other kind of transport encryption). > > The administrative interfaces controlling the implementation might still do. That's not DNSSEC that's broken, then. - Matt -- "Mr... Baggins. It seems you have been leading... two lives. In one... you are an ordinary hobbit... you organize your uncle's diary... give generous gifts to children. In the other... you are the Ring Bearer... charged to carry the One Ring to Mount Doom. One life has... a future, Mr... Baggins, and the other..." From mpalmer at hezmatt.org Fri Apr 11 21:56:01 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 12 Apr 2014 07:56:01 +1000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> Message-ID: <20140411215601.GW15800@hezmatt.org> On Fri, Apr 11, 2014 at 04:03:36PM -0400, William Herrin wrote: > >> The U.S. National Security Agency knew for at least two years about a flaw > >> in the way that many websites send sensitive information, now dubbed the > >> Heartbleed bug, and regularly used it to gather critical intelligence, > >> two people familiar with the matter said. > >> > >> The NSA's decision to keep the bug secret in pursuit of national security > >> interests threatens to renew the rancorous debate over the role of the > >> government's top computer experts. > > I call B.S. Do you have any idea how many thousands of impacted NSA > servers run by contractors hung out on the Internet with sensitive NSA > data? If you told me they used it against the targets of the day while > putting out the word to patch I could buy it, but intentionally > leaving a certain bodily extension hanging in the breeze in the hopes > of gaining more valuable data than they lose would have been an > unusually gutsy move. You're assuming that the NSA is a single monolithic entity. IIRC, the offense team and the defense team don't really talk much, and they *certainly* have very different motivations. It wouldn't surprise me at all if the offense got hold of a juicy bug, and since they're paid to capture data, and knowing that they wouldn't get in trouble if the defense lost data, their motivations to keep their little bug to themselves are entirely understandable. The interesting thing to me is that the article claims the NSA have been using this for "over two years", but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA put it in there (still a bridge too far for me to believe without further evidence, although I can certainly understand why people could believe it) and hence were using it from day 1; * The NSA found it *amazingly* quickly (they're very good at what they do, but I don't believe them have superhuman talents); or * The article has got at least one fact wrong, in which case it's entirely plausible they've got other things wrong, too. - Matt -- That's why I love VoIP. You don't get people phoning up to complain that the network is down. -- Peter Corlett, in the Monastery From cidr-report at potaroo.net Fri Apr 11 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Apr 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201404112200.s3BM00ou088156@wattle.apnic.net> This report has been generated at Fri Apr 11 21:13:53 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 04-04-14 494011 279041 05-04-14 494614 278808 06-04-14 494695 279258 07-04-14 494768 279209 08-04-14 494723 281417 09-04-14 497900 281706 10-04-14 498626 281966 11-04-14 498748 282193 AS Summary 46790 Number of ASes in routing system 19080 Number of ASes announcing only one prefix 3594 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 119829504 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 11Apr14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 498391 282236 216155 43.4% All ASes AS28573 3594 350 3244 90.3% NET Servi?os de Comunica??o S.A.,BR AS6389 2996 56 2940 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2781 237 2544 91.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2919 907 2012 68.9% KIXS-AS-KR Korea Telecom,KR AS18881 1922 35 1887 98.2% Global Village Telecom,BR AS1785 2192 479 1713 78.1% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS10620 2820 1339 1481 52.5% Telmex Colombia S.A.,CO AS4323 2940 1520 1420 48.3% TWTC - tw telecom holdings, inc.,US AS36998 1637 248 1389 84.9% SDN-MOBITEL,SD AS7303 1751 452 1299 74.2% Telecom Argentina S.A.,AR AS4755 1843 608 1235 67.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2231 1085 1146 51.4% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1224 119 1105 90.3% VIETEL-AS-AP Viettel Corporation,VN AS22561 1309 241 1068 81.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1228 217 1011 82.3% ITCDELTA - Earthlink, Inc.,US AS22773 2414 1467 947 39.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4808 1366 426 940 68.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS9829 1622 719 903 55.7% BSNL-NIB National Internet Backbone,IN AS24560 1123 297 826 73.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4788 1023 252 771 75.4% TMNET-AS-AP TM Net, Internet Service Provider,MY AS18101 943 183 760 80.6% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1407 661 746 53.0% Uninet S.A. de C.V.,MX AS7738 914 182 732 80.1% Telemar Norte Leste S.A.,BR AS701 1480 751 729 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS855 764 57 707 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1036 368 668 64.5% SEEDNET Digital United Inc.,TW AS6147 781 113 668 85.5% Telefonica del Peru S.A.A.,PE AS26615 756 105 651 86.1% Tim Celular S.A.,BR AS9808 966 330 636 65.8% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN Total 52029 14369 37660 72.4% Top 30 total Possible Bogus Routes 24.55.64.0/21 AS36423 -Reserved AS-,ZZ 24.55.72.0/21 AS36423 -Reserved AS-,ZZ 24.55.80.0/21 AS36423 -Reserved AS-,ZZ 24.55.88.0/21 AS36423 -Reserved AS-,ZZ 24.55.96.0/21 AS36423 -Reserved AS-,ZZ 24.55.104.0/21 AS36423 -Reserved AS-,ZZ 24.55.112.0/21 AS36423 -Reserved AS-,ZZ 24.55.120.0/21 AS36423 -Reserved AS-,ZZ 24.137.224.0/21 AS36423 -Reserved AS-,ZZ 24.137.232.0/21 AS36423 -Reserved AS-,ZZ 24.137.240.0/21 AS36423 -Reserved AS-,ZZ 24.137.248.0/21 AS36423 -Reserved AS-,ZZ 24.157.16.0/21 AS36423 -Reserved AS-,ZZ 24.157.24.0/21 AS36423 -Reserved AS-,ZZ 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 41.217.208.0/22 AS37158 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.119.240.0/22 AS26072 -Reserved AS-,ZZ 64.119.240.0/23 AS26072 -Reserved AS-,ZZ 64.119.242.0/23 AS26072 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 70.45.0.0/21 AS36423 -Reserved AS-,ZZ 70.45.8.0/21 AS36423 -Reserved AS-,ZZ 70.45.16.0/21 AS36423 -Reserved AS-,ZZ 70.45.24.0/21 AS36423 -Reserved AS-,ZZ 70.45.32.0/21 AS36423 -Reserved AS-,ZZ 70.45.40.0/21 AS36423 -Reserved AS-,ZZ 70.45.48.0/21 AS36423 -Reserved AS-,ZZ 70.45.56.0/21 AS36423 -Reserved AS-,ZZ 70.45.64.0/21 AS36423 -Reserved AS-,ZZ 70.45.72.0/21 AS36423 -Reserved AS-,ZZ 70.45.80.0/21 AS36423 -Reserved AS-,ZZ 70.45.88.0/21 AS36423 -Reserved AS-,ZZ 70.45.96.0/21 AS36423 -Reserved AS-,ZZ 70.45.104.0/21 AS36423 -Reserved AS-,ZZ 70.45.112.0/21 AS36423 -Reserved AS-,ZZ 70.45.120.0/21 AS36423 -Reserved AS-,ZZ 70.45.128.0/21 AS36423 -Reserved AS-,ZZ 70.45.136.0/21 AS36423 -Reserved AS-,ZZ 70.45.144.0/21 AS36423 -Reserved AS-,ZZ 70.45.152.0/21 AS36423 -Reserved AS-,ZZ 70.45.160.0/21 AS36423 -Reserved AS-,ZZ 70.45.168.0/21 AS36423 -Reserved AS-,ZZ 70.45.176.0/21 AS36423 -Reserved AS-,ZZ 70.45.184.0/21 AS36423 -Reserved AS-,ZZ 70.45.192.0/21 AS36423 -Reserved AS-,ZZ 70.45.200.0/21 AS36423 -Reserved AS-,ZZ 70.45.208.0/21 AS36423 -Reserved AS-,ZZ 70.45.216.0/21 AS36423 -Reserved AS-,ZZ 70.45.224.0/21 AS36423 -Reserved AS-,ZZ 70.45.232.0/21 AS36423 -Reserved AS-,ZZ 70.45.240.0/21 AS36423 -Reserved AS-,ZZ 70.45.248.0/21 AS36423 -Reserved AS-,ZZ 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.119.236.0/23 AS26368 -Reserved AS-,ZZ 74.119.239.0/24 AS26368 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 108.59.160.0/24 AS11049 -Reserved AS-,ZZ 108.59.161.0/24 AS11049 -Reserved AS-,ZZ 108.59.164.0/24 AS11049 -Reserved AS-,ZZ 108.59.165.0/24 AS11049 -Reserved AS-,ZZ 108.59.168.0/24 AS11049 -Reserved AS-,ZZ 108.59.169.0/24 AS11049 -Reserved AS-,ZZ 108.59.170.0/24 AS11049 -Reserved AS-,ZZ 108.59.171.0/24 AS11049 -Reserved AS-,ZZ 108.59.175.0/24 AS11049 -Reserved AS-,ZZ 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 154.75.25.0/24 AS32774 SOMALI-WIRELESS,SO 162.212.160.0/21 AS36423 -Reserved AS-,ZZ 162.220.96.0/21 AS36423 -Reserved AS-,ZZ 162.246.132.0/22 AS27288 DPCHICO-1 - Digital Path,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 185.53.140.0/22 AS61973 ROHDE-AS Rohde GmbH,DE 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 -Reserved AS-,ZZ 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.106.0/23 AS42444 -Reserved AS-,ZZ 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 196.216.129.0/24 AS36886 -Reserved AS-,ZZ 196.216.130.0/24 AS36886 -Reserved AS-,ZZ 196.216.131.0/24 AS36886 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.245.96.0/21 AS36423 -Reserved AS-,ZZ 198.245.104.0/21 AS36423 -Reserved AS-,ZZ 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.27.96.0/21 AS36423 -Reserved AS-,ZZ 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.87.166.0/24 AS26368 -Reserved AS-,ZZ 199.87.167.0/24 AS26368 -Reserved AS-,ZZ 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.102.73.0/24 AS26368 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.0.0.0/16 AS7545 TPG-INTERNET-AP TPG Telecom Limited,AU 203.83.16.0/21 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 -Reserved AS-,ZZ 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 11 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Apr 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201404112200.s3BM017D088174@wattle.apnic.net> BGP Update Report Interval: 03-Apr-14 -to- 10-Apr-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36998 73697 3.1% 46.4 -- SDN-MOBITEL,SD 2 - AS9829 72918 3.0% 78.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS27738 57295 2.4% 99.5 -- Ecuadortelecom S.A.,EC 4 - AS29571 41104 1.7% 384.1 -- CITelecom-AS,CI 5 - AS13188 28842 1.2% 27.4 -- BANKINFORM-AS TOV "Bank-Inform",UA 6 - AS8402 27938 1.2% 32.9 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS56115 24373 1.0% 369.3 -- NGGL-BD Road 27 House 13 Block C2,BD 8 - AS3816 23167 1.0% 65.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 9 - AS13118 22914 1.0% 11457.0 -- ASN-YARTELECOM OJSC Rostelecom,RU 10 - AS45899 20767 0.9% 66.1 -- VNPT-AS-VN VNPT Corp,VN 11 - AS14259 20688 0.9% 157.9 -- Gtd Internet S.A.,CL 12 - AS1659 20579 0.9% 78.2 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 13 - AS41691 20470 0.9% 1137.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 14 - AS25184 20123 0.8% 157.2 -- AFRANET AFRANET Co. Tehran, Iran,IR 15 - AS23893 15713 0.7% 402.9 -- BPL-BD House No:03, Road no: 23/A,BD 16 - AS1785 15604 0.7% 35.3 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 17 - AS7552 15254 0.6% 47.4 -- VIETEL-AS-AP Viettel Corporation,VN 18 - AS17557 14714 0.6% 216.4 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 19 - AS48159 14614 0.6% 74.6 -- TIC-AS Telecommunication Infrastructure Company,IR 20 - AS7029 14267 0.6% 81.1 -- WINDSTREAM - Windstream Communications Inc,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13118 22914 1.0% 11457.0 -- ASN-YARTELECOM OJSC Rostelecom,RU 2 - AS18135 8939 0.4% 8939.0 -- BTV BTV Cable television,JP 3 - AS6459 7711 0.3% 7711.0 -- TRANSBEAM - I-2000, Inc.,US 4 - AS20450 13280 0.6% 6640.0 -- THL16-ASN - Trojan Hosting, LLC.,US 5 - AS54465 8401 0.3% 2800.3 -- QPM-AS-1 - QuickPlay Media Inc.,US 6 - AS58822 7262 0.3% 2420.7 -- IDNIC-UNESA-AS-ID Universitas Negeri Surabaya,ID 7 - AS6629 10536 0.4% 2107.2 -- NOAA-AS - NOAA,US 8 - AS3 1490 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS41691 20470 0.9% 1137.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS60345 1064 0.0% 1064.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 11 - AS45636 972 0.0% 972.0 -- D2H-BBCL-IN Plot No. 1D, Udyog Vihar Industrial Estate,IN 12 - AS38909 2898 0.1% 966.0 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 13 - AS23466 828 0.0% 828.0 -- -Reserved AS-,ZZ 14 - AS23295 1623 0.1% 811.5 -- EA-01 - Extend America,US 15 - AS2 2294 0.1% 2024.0 -- UDEL-DCN - University of Delaware,US 16 - AS21973 648 0.0% 648.0 -- XPONET - Xponet,US 17 - AS33643 640 0.0% 640.0 -- JELLYBELLY - Jelly Belly Candy Company,US 18 - AS38730 3196 0.1% 639.2 -- VIETINBANK-AS-VN Vietnam Bank for Industry and Trade,VN 19 - AS57013 4455 0.2% 636.4 -- EURASIA-STAR-AS Eurasia Star Ltd.,KZ 20 - AS45900 632 0.0% 632.0 -- SBV-AS-VN The State Bank of Viet Nam,VN TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22906 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 2 - 89.221.206.0/24 20390 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 3 - 121.52.144.0/24 14696 0.6% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 4 - 187.188.205.0/24 10667 0.4% AS17072 -- Iusacell PCS de Mexico, S.A. de C.V.,MX 5 - 192.58.232.0/24 10531 0.4% AS6629 -- NOAA-AS - NOAA,US 6 - 78.109.192.0/20 9640 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 7 - 42.83.48.0/20 8939 0.3% AS18135 -- BTV BTV Cable television,JP 8 - 206.152.15.0/24 8395 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 9 - 205.247.12.0/24 7711 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 10 - 65.90.49.0/24 7069 0.3% AS3356 -- LEVEL3 - Level 3 Communications, Inc.,US 11 - 66.210.60.0/24 6685 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC.,US 12 - 74.231.237.0/24 6595 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC.,US 13 - 199.187.118.0/24 4365 0.2% AS11054 -- LIVEPERSON - LivePerson, Inc.,US 14 - 186.211.97.0/24 4302 0.2% AS53062 -- G G NET - Telecomunica??es LTDA EPP,BR 15 - 210.90.39.0/24 3625 0.1% AS4766 -- KIXS-AS-KR Korea Telecom,KR 16 - 103.242.124.0/24 3018 0.1% AS58822 -- IDNIC-UNESA-AS-ID Universitas Negeri Surabaya,ID 17 - 103.242.125.0/24 3016 0.1% AS58822 -- IDNIC-UNESA-AS-ID Universitas Negeri Surabaya,ID 18 - 2.93.235.0/24 2905 0.1% AS8402 -- CORBINA-AS OJSC "Vimpelcom",RU 19 - 210.4.14.0/24 2886 0.1% AS38909 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 20 - 120.28.62.0/24 2568 0.1% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From alter3d at alter3d.ca Fri Apr 11 22:27:16 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 11 Apr 2014 18:27:16 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> Message-ID: <53486C44.6080304@alter3d.ca> On 4/11/2014 4:03 PM, William Herrin wrote: >>> The U.S. National Security Agency knew for at least two years about a flaw >>> in the way that many websites send sensitive information, now dubbed the >>> Heartbleed bug, and regularly used it to gather critical intelligence, >>> two people familiar with the matter said. >>> >>> The NSA's decision to keep the bug secret in pursuit of national security >>> interests threatens to renew the rancorous debate over the role of the >>> government's top computer experts. > I call B.S. Do you have any idea how many thousands of impacted NSA > servers run by contractors hung out on the Internet with sensitive NSA > data? If you told me they used it against the targets of the day while > putting out the word to patch I could buy it, but intentionally > leaving a certain bodily extension hanging in the breeze in the hopes > of gaining more valuable data than they lose would have been an > unusually gutsy move. > > These two unnamed sources are liars. Bet on it. > > Regards, > Bill Herrin I would imagine that federal contractors have to adhere to FIPS 140-2 standards (or some similar requirement) for sensitive environments, and none of the affected OpenSSL versions were certified to any FIPS standard... the last version that WAS certified (0.9.8j) is only rated to Level 1, which, being the lowest possible rating, I suspect is not permitted for use by NSA contractors -- they're probably required to use level 3 or 4 for everything. From bill at herrin.us Fri Apr 11 22:31:19 2014 From: bill at herrin.us (William Herrin) Date: Fri, 11 Apr 2014 18:31:19 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411215601.GW15800@hezmatt.org> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> Message-ID: On Fri, Apr 11, 2014 at 5:56 PM, Matt Palmer wrote: > You're assuming that the NSA is a single monolithic entity. IIRC, the > offense team and the defense team don't really talk much, and they > *certainly* have very different motivations. It wouldn't surprise me at all > if the offense got hold of a juicy bug, and since they're paid to capture > data, and knowing that they wouldn't get in trouble if the defense lost > data, their motivations to keep their little bug to themselves are entirely > understandable. Hi Matt, I assume only individual motivations, like CYA. Folks at the bottom don't make bold decisions. A potentially career-making or career-ending decision like this would have been kicked up the chain until it reached someone who could, after consulting several other folks to cover his own posterior, authorize the risk. This and the high odds of a leak are how I know the NSA hasn't cracked the prime factoring problem either. And anyone surprised by Snowden's revelations either didn't read about or didn't understand Mark Klein's 2006 AT&T documents. There are things that folks at the NSA could plausibly be doing. Intentionally sitting on a massive security hole in their own systems for two years isn't one of them. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sotnickd-nanog at ddv.com Fri Apr 11 22:50:28 2014 From: sotnickd-nanog at ddv.com (David Sotnick) Date: Fri, 11 Apr 2014 15:50:28 -0700 Subject: Severe latency at both San Jose and Los Angeles Level3/AT&T peering Message-ID: Hi Nanog, I have a ticket open with Level 3, with whom I have 1gig pipes in Oakland, CA and Las Vegas, NV. One of our users noticed very slow file transfer/media delivery from the Bay Area to L.A., and on investigating it appears as though the peering point between Level3 and AT&T in SF was saturated and had 300ms avg. latency. 90 minutes later after receiving no call from Level3, I escalated to a P1 ticket, as the latency is now > 1000ms and we're seeing 20% packet loss. I decided to statically route to the destination via our DR cluster in Vegas, and interestingly I found the same situation where AT&T and Level3 peer in Tustin. mtr traceroutes, for those curious: Via Oakland: My traceroute [v0.71] hivemind (0.0.0.0) Fri Apr 11 15:36:08 2014 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 138.72.xxx.xxx 0.0% 0.3 0.2 0.1 0.3 0.1 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 0.4 0.4 0.5 0.0 3. verge-vlan66.pixar.com 0.0% 0.6 0.7 0.6 0.9 0.1 4. ge-6-24.car1.Oakland1.Level3.net 0.0% 0.7 105.5 0.7 307.3 110.9 5. ae-5-5.ebr2.SanJose1.Level3.net 0.0% 1.7 1.7 1.6 2.8 0.4 6. ae-92-92.csw4.SanJose1.Level3.net 0.0% 1.6 1.7 1.6 3.0 0.4 7. ae-4-90.edge2.SanJose1.Level3.net 0.0% 1.6 4.6 1.6 37.1 10.2 8. 192.205.32.209 41.7% 1042. 1048. 1038. 1059. 9.1 9. cr1.sffca.ip.att.net 25.0% 1052. 1059. 1046. 1072. 10.0 10. cr1.la2ca.ip.att.net 27.3% 1043. 1060. 1043. 1071. 10.7 11. cr83.la2ca.ip.att.net 16.7% 1058. 1060. 1045. 1073. 8.8 12. gar7.la2ca.ip.att.net 16.7% 1059. 1061. 1044. 1087. 13.3 13. 12.249.143.98 33.3% 1059. 1057. 1048. 1071. 7.8 14. ??? My traceroute [v0.71] hivemind (0.0.0.0) Fri Apr 11 15:36:43 2014 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 138.72.xxx.xxx 0.0% 0.2 0.1 0.1 0.2 0.0 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 0.4 0.3 0.6 0.1 3. cat-vegas-01-vlan66.pixar.com 0.0% 22.0 21.8 21.7 22.3 0.2 4. 205.129.21.101 0.0% 19.4 19.5 19.3 19.9 0.2 5. ae-2-5.bar1.LasVegas1.Level3.net 0.0% 19.3 21.8 19.3 40.7 5.9 6. ae-4-4.ebr1.LosAngeles1.Level3.net 0.0% 22.0 22.4 21.9 26.8 1.3 7. ae-6-6.ebr1.Tustin1.Level3.net 0.0% 20.0 20.2 19.9 21.8 0.5 8. ae-107-3507.bar2.Tustin1.Level3.net 0.0% 22.0 22.0 21.9 22.1 0.0 9. 192.205.37.145 30.8% 1052. 1063. 1048. 1072. 8.1 10. cr1.la2ca.ip.att.net 35.7% 1050. 1060. 1050. 1070. 7.3 11. cr83.la2ca.ip.att.net 28.6% 1049. 1064. 1049. 1072. 7.8 12. gar7.la2ca.ip.att.net 21.4% 1048. 1061. 1048. 1072. 6.7 13. 12.249.143.98 28.6% 1050. 1061. 1050. 1072. 7.9 14. ??? Just wanted to share in case anyone else is running into similar issues. I know, I should be on the outages list. I will add myself now. :) Regards, Dave Sotnick From rdrake at direcpath.com Fri Apr 11 23:03:52 2014 From: rdrake at direcpath.com (Robert Drake) Date: Fri, 11 Apr 2014 19:03:52 -0400 Subject: DNSSEC? In-Reply-To: <20140411214715.GV15800@hezmatt.org> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> Message-ID: <534874D8.3050205@direcpath.com> On 4/11/2014 5:47 PM, Matt Palmer wrote: > That's not DNSSEC that's broken, then. - Matt You're correct about that, but everything depends on your level of paranoia. The bug has a potential to show 64k of memory that may or may not be a part of the TLS/SSL connection*. In that 64k their may be ssh keys, dnssec keys, pictures of cats, or anything else that needs to be safely protected. If something is very important to keep secure and it was on a box that has a TLS/SSL connection then you should regenerate keys for it, but largely this effort would be just in case and not because it's compromised. * technically it is part of the connection, it's just malloc() and not zeroed so whatever data was in it before was not cleared. If you can be sure all your cat picture applications zero memory on exit and none of them exited uncleanly then this isn't a problem. At high levels of paranoia this isn't really something that you can be sure of though. I'm not even sure if it's done in most crypto apps aside from gpg. OpenSSL is double-faulted here for both not checking the length and not zeroing the memory on malloc**. ** probably making this all up since I haven't done a real look at the library, I'm just going by what I've read on the internet. I expect we may see more bugs revealed in openssl soon. It's getting lots of scrutiny from this so I expect the code is being audit by everyone and that's good. From wbailey at satelliteintelligencegroup.com Fri Apr 11 23:08:19 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 11 Apr 2014 23:08:19 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <53486C44.6080304@alter3d.ca> References: <20140411193039.GA2724@gsp.org> <53486C44.6080304@alter3d.ca> Message-ID: And their Level 3 to 4 accomplished what exactly?? They were owned the same way the own others, from the inside. On 4/11/14, 4:27 PM, "Peter Kristolaitis" wrote: > >On 4/11/2014 4:03 PM, William Herrin wrote: >>>> The U.S. National Security Agency knew for at least two years about a >>>>flaw >>>> in the way that many websites send sensitive information, now dubbed >>>>the >>>> Heartbleed bug, and regularly used it to gather critical intelligence, >>>> two people familiar with the matter said. >>>> >>>> The NSA's decision to keep the bug secret in pursuit of national >>>>security >>>> interests threatens to renew the rancorous debate over the role of the >>>> government's top computer experts. >> I call B.S. Do you have any idea how many thousands of impacted NSA >> servers run by contractors hung out on the Internet with sensitive NSA >> data? If you told me they used it against the targets of the day while >> putting out the word to patch I could buy it, but intentionally >> leaving a certain bodily extension hanging in the breeze in the hopes >> of gaining more valuable data than they lose would have been an >> unusually gutsy move. >> >> These two unnamed sources are liars. Bet on it. >> >> Regards, >> Bill Herrin > >I would imagine that federal contractors have to adhere to FIPS 140-2 >standards (or some similar requirement) for sensitive environments, and >none of the affected OpenSSL versions were certified to any FIPS >standard... the last version that WAS certified (0.9.8j) is only rated >to Level 1, which, being the lowest possible rating, I suspect is not >permitted for use by NSA contractors -- they're probably required to use >level 3 or 4 for everything. > From surfer at mauigateway.com Fri Apr 11 23:36:38 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Apr 2014 16:36:38 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Message-ID: <20140411163638.44618AD8@m0005296.ppops.net> --- mpalmer at hezmatt.org wrote: From: Matt Palmer The interesting thing to me is that the article claims the NSA have been using this for "over two years", but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA put it in there (still a bridge too far for me to believe without further evidence, although I can certainly understand why people could believe it) and hence were using it from day 1; ----------------------------------------------- Why is a mole in the IETF subverting things hard to believe? ;-) scott From marka at isc.org Fri Apr 11 23:39:56 2014 From: marka at isc.org (Mark Andrews) Date: Sat, 12 Apr 2014 09:39:56 +1000 Subject: DNSSEC? In-Reply-To: Your message of "Fri, 11 Apr 2014 19:03:52 -0400." <534874D8.3050205@direcpath.com> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> Message-ID: <20140411233957.20E4A13A1157@rock.dv.isc.org> In message <534874D8.3050205 at direcpath.com>, Robert Drake writes: > > On 4/11/2014 5:47 PM, Matt Palmer wrote: > > That's not DNSSEC that's broken, then. - Matt > > You're correct about that, but everything depends on your level of > paranoia. > > The bug has a potential to show 64k of memory that may or may not be a > part of the TLS/SSL connection*. In that 64k their may be ssh keys, > dnssec keys, pictures of cats, or anything else that needs to be safely > protected. If something is very important to keep secure and it was on > a box that has a TLS/SSL connection then you should regenerate keys for > it, but largely this effort would be just in case and not because it's > compromised. That bug has the potential to show what is in them memory of the process it is connecting to. Note I said process not machine. Now unless you are using SSL to take to a process that is signing DNSSEC keys there is no exposure of the private keys. Named doesn't use ssl. There are however nameservers that do use ssl to work around broken middle boxes. If they are also signing zones then there is potential to expose private keys. That said it also depends on how the process manages the memory it frees. Named for example overwrites freed memory with 0xde. It also initialises allocated memory with 0xbe. Doing so help detect use after free and use of uninitialised structure elements. We want to catch these sorts of bugs before they get to the internal review stage. > * technically it is part of the connection, it's just malloc() and not > zeroed so whatever data was in it before was not cleared. If you can be > sure all your cat picture applications zero memory on exit and none of > them exited uncleanly then this isn't a problem. At high levels of > paranoia this isn't really something that you can be sure of though. > I'm not even sure if it's done in most crypto apps aside from gpg. > OpenSSL is double-faulted here for both not checking the length and not > zeroing the memory on malloc**. > > ** probably making this all up since I haven't done a real look at the > library, I'm just going by what I've read on the internet. > > I expect we may see more bugs revealed in openssl soon. It's getting > lots of scrutiny from this so I expect the code is being audit by > everyone and that's good. I also expect to see more bugs revealed in MacOS, Windows, FreeBSD and any other program written by humans or written by programs written by humans. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Valdis.Kletnieks at vt.edu Sat Apr 12 00:49:47 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Apr 2014 20:49:47 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: Your message of "Sat, 12 Apr 2014 07:56:01 +1000." <20140411215601.GW15800@hezmatt.org> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> Message-ID: <80786.1397263787@turing-police.cc.vt.edu> On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: > The interesting thing to me is that the article claims the NSA have been > using this for "over two years", but 1.0.1 (the first vulnerable version) > was only released on 14 Mar 2012. That means that either: > * The NSA found it *amazingly* quickly (they're very good at what they do, > but I don't believe them have superhuman talents); or You seriously think the NSA *isn't* watching the commits to security-relevant open source? Remember - it was a bonehead bug, it's *not* unreasonable for somebody who was auditing the code to spot it. Heck, there's a good chance that automated tools could have spotted it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From bill at herrin.us Sat Apr 12 01:03:10 2014 From: bill at herrin.us (William Herrin) Date: Fri, 11 Apr 2014 21:03:10 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <53486C44.6080304@alter3d.ca> References: <20140411193039.GA2724@gsp.org> <53486C44.6080304@alter3d.ca> Message-ID: On Fri, Apr 11, 2014 at 6:27 PM, Peter Kristolaitis wrote: > I would imagine that federal contractors have to adhere to FIPS 140-2 > standards (or some similar requirement) for sensitive environments, and none > of the affected OpenSSL versions were certified to any FIPS standard... the > last version that WAS certified (0.9.8j) is only rated to Level 1, which, > being the lowest possible rating, I suspect is not permitted for use by NSA > contractors -- they're probably required to use level 3 or 4 for everything. Some of the time, sure. And some of the time they buy Red Hat Linux off the shelf like everybody else. They have budgets too. They can't do everything at the highest protection level. Or did you think they were above and immune to the ordinary business realities of the 21st century? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joly at punkcast.com Sat Apr 12 04:32:55 2014 From: joly at punkcast.com (Joly MacFie) Date: Sat, 12 Apr 2014 00:32:55 -0400 Subject: Fwd: [IP] Summary of what I know so far about the Linksys botnet and/or worm In-Reply-To: References: <201402120211.TAA05575@mail.lariat.net> Message-ID: Any comments? ---------- Forwarded message ---------- From: Dave Farber Date: Fri, Apr 11, 2014 at 8:13 PM Subject: [IP] Summary of what I know so far about the Linksys botnet and/or worm To: ip ---------- Forwarded message ---------- From: *Brett Glass* Date: Wednesday, February 12, 2014 Subject: Summary of what I know so far about the Linksys botnet and/or worm To: "Eugene H. Spafford" , "dave at farber.net" Cc: security at linksys.com Gene, Dave: Here is what I know so far about the Linksys router exploit that I've been observing in the wild today. * The exploit has affected Linksys E1000 and E1200 routers that have public IP addresses on our network. Those which we've shielded behind carrier-grade NAT (the majority) have not been compromised. * The routers are rapidly scanning blocks of IP addresses for Web servers on ports 80 and 8080. This choice of ports seems to indicate that they are looking for other routers of their ilk to infect. It's unclear whether, once they find a vulnerable router, they infect it themselves or report its IP address back to a botmaster for later infection. I suspect the latter, though, because infection would require flashing the router with a modified firmware image that would be model-specific and there is not room in a router for multiple images. It's also likely that a central server is coordinating the scans. * All of the E1000s that have been affected have the last version of firmware that was made for this now-discontinued model. The affected E1200s have firmware version 1.0.03 (the last one published for hardware version 1) or 2.0.04 (not the latest for hardware version 2, but close; there's now a 2.0.06. I do not know if 2.0.06 stops the exploit because we have no E1200s running it with public IPs). We have not seen any E900s infected, even though the E900 and the E1200 use the same hardware. * None of the infected routers had default or easily guessable passwords, suggesting that the backdoor or security hole through which the exploit was performed did not require guessing a password. * Re-flashing routers and resetting them to factory defaults SEEMS to clear the malware, but of course one cannot be 100% sure that it does not protect itself from re-flashing. * These routers use Broadcom chipsets and Wind River's RTOS operating system, and it wasn't swapped for a Linux-based one, so the creators of the malware must be skilled in development for this OS -- or at least sufficiently skilled to modify the firmware. At this point, it appears that those who implemented this exploit is still building an "army" and has not used it for anything yet. However, there are so many millions of these routers in the field, with so many private networks behind them, that there's no telling just how much havoc they could wreak if they were set to invasion of privacy, DoS attacks, etc. I haven't been able to get in touch with anyone at Linksys to talk about this. Their support techs are all in remote call centers in far-flung corners of the world, and I have not been able to get them to escalate. --Brett Glass Archives | ModifyYour Subscription | Unsubscribe Now -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From pauldotwall at gmail.com Sat Apr 12 04:40:50 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Sat, 12 Apr 2014 00:40:50 -0400 Subject: Severe latency at both San Jose and Los Angeles Level3/AT&T peering In-Reply-To: References: Message-ID: This should provide some background: http://apps.fcc.gov/ecfs/document/view?id=7022026095 Drive Slow, Paul On Fri, Apr 11, 2014 at 6:50 PM, David Sotnick wrote: > Hi Nanog, > > I have a ticket open with Level 3, with whom I have 1gig pipes in Oakland, > CA and Las Vegas, NV. > > One of our users noticed very slow file transfer/media delivery from the > Bay Area to L.A., and on investigating it appears as though the peering > point between Level3 and AT&T in SF was saturated and had 300ms avg. > latency. > > 90 minutes later after receiving no call from Level3, I escalated to a P1 > ticket, as the latency is now > 1000ms and we're seeing 20% packet loss. > > I decided to statically route to the destination via our DR cluster in > Vegas, and interestingly I found the same situation where AT&T and Level3 > peer in Tustin. > > mtr traceroutes, for those curious: > > Via Oakland: > > My traceroute [v0.71] > > hivemind (0.0.0.0) > Fri Apr 11 15:36:08 2014 > > Keys: Help Display mode Restart statistics Order of fields quit > > Packets > Pings > > Host Loss% Last > Avg Best Wrst StDev > > 1. 138.72.xxx.xxx 0.0% 0.3 > 0.2 0.1 0.3 0.1 > 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 > 0.4 0.4 0.5 0.0 > 3. verge-vlan66.pixar.com 0.0% 0.6 > 0.7 0.6 0.9 0.1 > 4. ge-6-24.car1.Oakland1.Level3.net 0.0% 0.7 > 105.5 0.7 307.3 110.9 > 5. ae-5-5.ebr2.SanJose1.Level3.net 0.0% 1.7 > 1.7 1.6 2.8 0.4 > 6. ae-92-92.csw4.SanJose1.Level3.net 0.0% 1.6 > 1.7 1.6 3.0 0.4 > 7. ae-4-90.edge2.SanJose1.Level3.net 0.0% 1.6 > 4.6 1.6 37.1 10.2 > 8. 192.205.32.209 41.7% 1042. > 1048. 1038. 1059. 9.1 > 9. cr1.sffca.ip.att.net 25.0% 1052. > 1059. 1046. 1072. 10.0 > 10. cr1.la2ca.ip.att.net 27.3% 1043. > 1060. 1043. 1071. 10.7 > 11. cr83.la2ca.ip.att.net 16.7% 1058. > 1060. 1045. 1073. 8.8 > 12. gar7.la2ca.ip.att.net 16.7% 1059. > 1061. 1044. 1087. 13.3 > 13. 12.249.143.98 33.3% 1059. > 1057. 1048. 1071. 7.8 > 14. ??? > > My traceroute [v0.71] > > hivemind (0.0.0.0) > Fri Apr 11 15:36:43 2014 > > Resolver: Received error response 2. (server failure)er of fields quit > > Packets > Pings > > Host Loss% Last > Avg Best Wrst StDev > 1. 138.72.xxx.xxx 0.0% 0.2 > 0.1 0.1 0.2 0.0 > 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 > 0.4 0.3 0.6 0.1 > 3. cat-vegas-01-vlan66.pixar.com 0.0% 22.0 > 21.8 21.7 22.3 0.2 > 4. 205.129.21.101 0.0% 19.4 > 19.5 19.3 19.9 0.2 > 5. ae-2-5.bar1.LasVegas1.Level3.net 0.0% 19.3 > 21.8 19.3 40.7 5.9 > 6. ae-4-4.ebr1.LosAngeles1.Level3.net 0.0% 22.0 > 22.4 21.9 26.8 1.3 > 7. ae-6-6.ebr1.Tustin1.Level3.net 0.0% 20.0 > 20.2 19.9 21.8 0.5 > 8. ae-107-3507.bar2.Tustin1.Level3.net 0.0% 22.0 > 22.0 21.9 22.1 0.0 > 9. 192.205.37.145 30.8% 1052. > 1063. 1048. 1072. 8.1 > 10. cr1.la2ca.ip.att.net 35.7% 1050. > 1060. 1050. 1070. 7.3 > 11. cr83.la2ca.ip.att.net 28.6% 1049. > 1064. 1049. 1072. 7.8 > 12. gar7.la2ca.ip.att.net 21.4% 1048. > 1061. 1048. 1072. 6.7 > 13. 12.249.143.98 28.6% 1050. > 1061. 1050. 1072. 7.9 > 14. ??? > > Just wanted to share in case anyone else is running into similar issues. I > know, I should be on the outages list. I will add myself now. :) > > Regards, > Dave Sotnick From frnkblk at iname.com Sat Apr 12 05:22:21 2014 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 12 Apr 2014 00:22:21 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <80786.1397263787@turing-police.cc.vt.edu> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <80786.1397263787@turing-police.cc.vt.edu> Message-ID: <000c01cf560f$2e4696f0$8ad3c4d0$@iname.com> I'm not sure if anyone of you has access to those automated tools, but I'd be interested in learning if any of them do catch the bug. Frank -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Friday, April 11, 2014 7:50 PM To: Matt Palmer Cc: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: Heck, there's a good chance that automated tools could have spotted it. From mysidia at gmail.com Sat Apr 12 05:45:20 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 12 Apr 2014 00:45:20 -0500 Subject: DNSSEC? In-Reply-To: <534874D8.3050205@direcpath.com> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> Message-ID: On Fri, Apr 11, 2014 at 6:03 PM, Robert Drake wrote: > The bug has a potential to show 64k of memory that may or may not be a part > of the TLS/SSL connection*. It has the potential to show various pieces of memory 64K at a time that may be related to ANY of the data the OpenSSL library works with associated with the same process. > In that 64k their may be ssh keys, dnssec keys, > pictures of cats, or anything else that needs to be safely protected. If Unlikely. For this vuln to be an issue: You need to have a vulnerable application or service that uses the SSL or TLS protocol and is sending or receiving those SSH or DNSSEC keys. > something is very important to keep secure and it was on a box that has a > TLS/SSL connection then you should regenerate keys for it, but largely this In most cases, this would be an unwarranted excessive response. For instance a SSL vuln affecting apache is not ordinarily an information leak risk equivalent to a full on root compromise. Most simply need to address secret credentials that may have been used by, transmitted, or received through a vulnerable client, server program, or app running on a vulnerable runtime framework (e.g. PHP script running on Apache with OpenSSL based mod_ssl, not Apache if using mod_nss/LibNSS instead of OpenSSL's libssl). BIND and SSH were unaffected, so... efficient and effective mitigation would not entail routinely treating these applications as if they were affected, in the absence of other issues. > * technically it is part of the connection, it's just malloc() and not > zeroed so whatever data was in it before was not cleared. If you can be > sure all your cat picture applications zero memory on exit and none of them > exited uncleanly then this isn't a problem. At high levels of paranoia this The memory leaked is not arbitrary memory spanning the entire box --- it is going to be memory belonging to the heap space of the same process instance, and almost certainly memory buffers which the OpenSSL library previously allocated for purposes such as sending/receiving data; therefore has a chance of containing data previously sent or received -- encrypted or not, such as HTTP headers, cookies, HTML content, POST forms, etc. It doesn't matter if your application exited, or if it's still running, even if it's on the same box. Protected mode and the secure memory manager on modern OSes makes what you are suggesting quite infeasible --- different processes cannot directly read each other's memory, AND on modern OSes, memory pages are always initially zero'd out some time after allocation to a process -- whenever the malloc() memory manager needs to call brk() to expand the program's data size, before the application can actually successfully read any newly mapped memory pages, the operating system will zero any existing content of that memory, just as it would do when reading unallocated sections of a file (instead of showing previous disk contents). The vulnerability is related to re-used memory pages within the same process. It also does not help that OpenSSL has its own wrapper around malloc() And instead of using the standard system libraries for memory allocation, apparently uses a high-risk memory allocation policy, that maximizes the exploitability of vulns like the Heartbeat extension issue, and prevents security mitigations from working that would otherwise be effective.....: see: http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf vv. http://article.gmane.org/gmane.os.openbsd.misc/211963 Generally free() doesn't actually release pages from a program back to the OS, the freed memory just becomes available for a later malloc within the same program. This is also what OpenSSL's homebrewed "malloc" implementation does ---- buffers not needed anymore are not actually free()'d; OpenSSL reuses buffers later to satisfy future internal memory allocation requests, bypassing the system's malloc()/free() the entire time. > isn't really something that you can be sure of though. I'm not even sure if > it's done in most crypto apps aside from gpg. OpenSSL is double-faulted > here for both not checking the length and not zeroing the memory on > malloc**. -- -JH From LarrySheldon at cox.net Sat Apr 12 06:09:09 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 12 Apr 2014 01:09:09 -0500 Subject: Heartbleed operational details Message-ID: <5348D885.6060905@cox.net> FWIIW http://xkcd.com/1354/ -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From marka at isc.org Sat Apr 12 06:22:20 2014 From: marka at isc.org (Mark Andrews) Date: Sat, 12 Apr 2014 16:22:20 +1000 Subject: DNSSEC? In-Reply-To: Your message of "Sat, 12 Apr 2014 00:45:20 -0500." References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> Message-ID: <20140412062220.45BAB13A5752@rock.dv.isc.org> Don't think for one second that using malloc directly would have saved OpenSSL here. By default malloc does not zero freed memory it returns. It is a feature that needs to be enabled. If OpenSSL wanted to zero memory it was returning could have done that itself. The only difference is that *some* malloc implementations examine the envionment and change their behaviour based on that. That OpenSSL used its own memory allocator was a problem does not stand up to rigourous analysis. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbailey at satelliteintelligencegroup.com Sat Apr 12 06:43:28 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 12 Apr 2014 06:43:28 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <000c01cf560f$2e4696f0$8ad3c4d0$@iname.com> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <80786.1397263787@turing-police.cc.vt.edu>, <000c01cf560f$2e4696f0$8ad3c4d0$@iname.com> Message-ID: I'd be interested in the other 0 days they have..;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Frank Bulk Date: 04/11/2014 11:24 PM (GMT-07:00) To: Valdis.Kletnieks at vt.edu,Matt Palmer Cc: nanog at nanog.org Subject: RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] I'm not sure if anyone of you has access to those automated tools, but I'd be interested in learning if any of them do catch the bug. Frank -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Friday, April 11, 2014 7:50 PM To: Matt Palmer Cc: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: Heck, there's a good chance that automated tools could have spotted it. From ag4ve.us at gmail.com Sat Apr 12 07:01:17 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Sat, 12 Apr 2014 03:01:17 -0400 Subject: DNSSEC? In-Reply-To: <20140412062220.45BAB13A5752@rock.dv.isc.org> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> <20140412062220.45BAB13A5752@rock.dv.isc.org> Message-ID: But it doesn't really matter if you zero out freed memory. Maybe it'll prevent you from gaining some stale session info and the like. But even if that were the case, this would still be a serious bug - you're not going to reread your private key before encrypting each bit of data after all - that'd just be wasteful. In other words, this is kind of moot. On Apr 12, 2014 2:24 AM, "Mark Andrews" wrote: > > Don't think for one second that using malloc directly would have > saved OpenSSL here. By default malloc does not zero freed memory > it returns. It is a feature that needs to be enabled. If OpenSSL > wanted to zero memory it was returning could have done that itself. > > The only difference is that *some* malloc implementations examine > the envionment and change their behaviour based on that. > > That OpenSSL used its own memory allocator was a problem does not > stand up to rigourous analysis. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > From mfidelman at meetinghouse.net Sat Apr 12 14:12:09 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 12 Apr 2014 10:12:09 -0400 Subject: responding to DMARC breakage Message-ID: <534949B9.1080704@meetinghouse.net> Hi Folks, It occurs to me that Yahoo's deployment of DMARC p=reject, and the choice of several big mail operators to honor that, has created a situation not unlike a really routing table or nameserver, snafu --- someone's published information that's caused lots of things to break. At an operational level, this comes down to Yahoo publishing a DMARC record into their nameservers containing "p=reject." As a result, Yahoo, and several other very large mail systems, are bouncing huge amounts of mail. We see, and react to, routing and nameserver snafus all the time. The response is usually an immediate, cooperative response to fix the problem as quickly as possible. Sometimes an operational problem uncovers a software bug, or vulnerability, or a protocol failure mode - which triggers various responses (CERT alert, software patches, protocol revisions via the IETF). Running a mail system and providing some hosting and list services, most of the operational issues I've run into involve nameserver corruption, over-aggressive spam blockers (and, of course, ongoing barrages of spam and persistent cracking threats). In most cases, problems are easy to resolve, and all involved are cooeprative (if sometimes slow). About the closest analogy I've encountered, to the current situation, are the more aggressive of the anti-spam blocklists (remember when someone would an entire subnet, with intent, when one host on that subnet generated some spam, or the operators who would extort payment for "expedited removal?"). By and large, market pressure has largely driven the worst actors into oblivion - but there don't seem to be any measures, with teeth, for dealing with bad actors. It strikes me that this situation is analogous: - several very big players have put a protocol into production that is, charitably, immature (DMARC is an informational internet-draft, not even an RFC, much less a standards-track RFC - and its backers have pretty much ignored any input from mailing list operators) - Yahoo published a dns record that triggers a protocol mode that results in huge amounts of mail bounces and operational disruption. - Yahoo (operationally) and the DMARC authors are intentionally un-responsive (as are hotmail, comcast, a few others; gmail, I note is not bouncing mail) How do we respond as operators, beyond late-night, ad-hoc patches to list software, that only partially resolve the problem? What kind of responses are available? In the broader scope of things, what kinds of responses are typical if someone publishes corrupted information and then doesn't cooperate in fixing the situation - be that through obliviousness, incompetence, lack of resources, laziness, or active intent (criminal or not)? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mike at mtcc.com Sat Apr 12 14:17:16 2014 From: mike at mtcc.com (Michael Thomas) Date: Sat, 12 Apr 2014 07:17:16 -0700 Subject: DNSSEC? In-Reply-To: References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> Message-ID: <53494AEC.8010901@mtcc.com> On 04/11/2014 10:45 PM, Jimmy Hess wrote: > > The vulnerability is related to re-used memory pages within the same process. > It also does not help that OpenSSL has its own wrapper around malloc() > > And instead of using the standard system libraries for memory > allocation, apparently uses a high-risk memory allocation policy, > that maximizes the exploitability of vulns like the Heartbeat > extension issue, and prevents security mitigations from working > that would otherwise be effective.....: > > Malloc doesn't write over to-be allocated memory, calloc does. Using a wrapper is hardly unusual or controversial -- malloc can be expensive, and keeping lookaside list for, say, commonly used and fixed sized blocks is, or at least used to be, a big performance win. Far from getting rid of evul wrappers, it seems to me that if they were smart with their wrappers they'd have wrapper routine for anything vaguely associated with wire output that zeros the allocated memory. Mike From bill at herrin.us Sat Apr 12 14:29:59 2014 From: bill at herrin.us (William Herrin) Date: Sat, 12 Apr 2014 10:29:59 -0400 Subject: responding to DMARC breakage In-Reply-To: <534949B9.1080704@meetinghouse.net> References: <534949B9.1080704@meetinghouse.net> Message-ID: On Sat, Apr 12, 2014 at 10:12 AM, Miles Fidelman wrote: > What kind of responses are available? In the broader scope of things, what > kinds of responses are typical if someone publishes corrupted information > and then doesn't cooperate in fixing the situation - be that through > obliviousness, incompetence, lack of resources, laziness, or active intent > (criminal or not)? 1. Treat DMARC records which break mailing lists as malformed. 2. Treat messages with malformed DMARC records as a validation failure and act as directed for validation failures. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Sat Apr 12 16:49:04 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 12 Apr 2014 12:49:04 -0400 Subject: responding to DMARC breakage In-Reply-To: Your message of "Sat, 12 Apr 2014 10:12:09 -0400." <534949B9.1080704@meetinghouse.net> References: <534949B9.1080704@meetinghouse.net> Message-ID: <9112.1397321344@turing-police.cc.vt.edu> On Sat, 12 Apr 2014 10:12:09 -0400, Miles Fidelman said: > It occurs to me that Yahoo's deployment of DMARC p=reject, and the > choice of several big mail operators to honor that, has created a > situation not unlike a really routing table or nameserver, snafu --- It's more like a peering war. Time for somebody to either bake a cake, or find alternate transit providers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mysidia at gmail.com Sat Apr 12 17:10:01 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 12 Apr 2014 12:10:01 -0500 Subject: DNSSEC? In-Reply-To: <53494AEC.8010901@mtcc.com> References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> <53494AEC.8010901@mtcc.com> Message-ID: On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas wrote: > Malloc doesn't write over to-be allocated memory, calloc does. Using a Zero'ing newly allocated memory is not the desired behavior. The desired behavior is that a segmentation fault occurs, when an application breaks the rules --- so the bug is detected, instead of being hidden. The system free() can be configured to write junk bytes to the entire freed region, and malloc can be configured to align some allocations to the end of a page (Which is a default on OpenBSD), and allocate guard pages to cause a segmentation fault to occur if an attempt is made to double free() or read past the end of the allocated buffer. > wrapper is hardly unusual or controversial -- malloc can be expensive, and > keeping lookaside list for, say, commonly used and fixed sized blocks is, Use of the wrapper is both unusual and a bit controversial. The openssl devs found some neat rope, decided to tie the noose, and leave it permanently mounted around their neck, just praying some script kiddie doesn't find the other end of the rope and tie it to something. > at least used to be, a big performance win. A very small possible performance win, with an extreme potential decrease in safety. > Far from getting rid of evul wrappers, it seems to me that if they were > smart with their wrappers they'd have wrapper routine for anything vaguely associated with wire output that zeros the allocated memory. This doesn't help with reading beyond the allocated memory. Of course........ if they correctly implement the same security mitigations that are available from the malloc() library that the system admin chose to install and link the application against, then there would have been no security complaint. > Mike -- -JH From mfidelman at meetinghouse.net Sat Apr 12 17:10:42 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 12 Apr 2014 13:10:42 -0400 Subject: responding to DMARC breakage In-Reply-To: References: <534949B9.1080704@meetinghouse.net> Message-ID: <53497392.60204@meetinghouse.net> William Herrin wrote: > On Sat, Apr 12, 2014 at 10:12 AM, Miles Fidelman > wrote: >> What kind of responses are available? In the broader scope of things, what >> kinds of responses are typical if someone publishes corrupted information >> and then doesn't cooperate in fixing the situation - be that through >> obliviousness, incompetence, lack of resources, laziness, or active intent >> (criminal or not)? > 1. Treat DMARC records which break mailing lists as malformed. > > 2. Treat messages with malformed DMARC records as a validation failure > and act as directed for validation failures. > > -Bill > > Doesn't really help if someone upstream is publishing the records, and its someone downstream who's acting on them. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Sat Apr 12 17:12:36 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 12 Apr 2014 13:12:36 -0400 Subject: responding to DMARC breakage In-Reply-To: <9112.1397321344@turing-police.cc.vt.edu> References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> Message-ID: <53497404.9040203@meetinghouse.net> Valdis.Kletnieks at vt.edu wrote: > On Sat, 12 Apr 2014 10:12:09 -0400, Miles Fidelman said: > >> It occurs to me that Yahoo's deployment of DMARC p=reject, and the >> choice of several big mail operators to honor that, has created a >> situation not unlike a really routing table or nameserver, snafu --- > It's more like a peering war. Time for somebody to either bake a cake, > or find alternate transit providers. Aaargghhh - what a horrible, but accurate analogy. Worse probably - more like a peering war with a large broadband carrier, at the edge, where it's harder to find alternate transport. Sigh.. Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From gbakos at alpinista.org Sat Apr 12 17:30:57 2014 From: gbakos at alpinista.org (George Bakos) Date: Sat, 12 Apr 2014 17:30:57 +0000 Subject: [IP] Summary of what I know so far about the Linksys botnet and/or worm In-Reply-To: References: <201402120211.TAA05575@mail.lariat.net> Message-ID: <20140412173057.2fd0d463@alpinista.org> Sounds like: https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633 g On Sat, 12 Apr 2014 00:32:55 -0400 Joly MacFie wrote: > Any comments? > > ---------- Forwarded message ---------- > From: Dave Farber > Date: Fri, Apr 11, 2014 at 8:13 PM > Subject: [IP] Summary of what I know so far about the Linksys botnet > and/or worm > To: ip > > > > > ---------- Forwarded message ---------- > From: *Brett Glass* > Date: Wednesday, February 12, 2014 > Subject: Summary of what I know so far about the Linksys botnet > and/or worm To: "Eugene H. Spafford" , > "dave at farber.net" Cc: security at linksys.com > > > Gene, Dave: > > Here is what I know so far about the Linksys router exploit that I've > been observing in the wild today. > > * The exploit has affected Linksys E1000 and E1200 routers that have > public IP addresses on our network. Those which we've shielded behind > carrier-grade NAT (the majority) have not been compromised. > > * The routers are rapidly scanning blocks of IP addresses for Web > servers on ports 80 and 8080. This choice of ports seems to indicate > that they are looking for other routers of their ilk to infect. It's > unclear whether, once they find a vulnerable router, they infect it > themselves or report its IP address back to a botmaster for later > infection. I suspect the latter, though, because infection would > require flashing the router with a modified firmware image that would > be model-specific and there is not room in a router for multiple > images. It's also likely that a central server is coordinating the > scans. > > * All of the E1000s that have been affected have the last version of > firmware that was made for this now-discontinued model. The affected > E1200s have firmware version 1.0.03 (the last one published for > hardware version 1) or 2.0.04 (not the latest for hardware version 2, > but close; there's now a 2.0.06. I do not know if 2.0.06 stops the > exploit because we have no E1200s running it with public IPs). We > have not seen any E900s infected, even though the E900 and the E1200 > use the same hardware. > > * None of the infected routers had default or easily guessable > passwords, suggesting that the backdoor or security hole through > which the exploit was performed did not require guessing a password. > > * Re-flashing routers and resetting them to factory defaults SEEMS to > clear the malware, but of course one cannot be 100% sure that it does > not protect itself from re-flashing. > > * These routers use Broadcom chipsets and Wind River's RTOS operating > system, and it wasn't swapped for a Linux-based one, so the creators > of the malware must be skilled in development for this OS -- or at > least sufficiently skilled to modify the firmware. > > At this point, it appears that those who implemented this exploit is > still building an "army" and has not used it for anything yet. > However, there are so many millions of these routers in the field, > with so many private networks behind them, that there's no telling > just how much havoc they could wreak if they were set to invasion of > privacy, DoS attacks, etc. > > I haven't been able to get in touch with anyone at Linksys to talk > about this. Their support techs are all in remote call centers in > far-flung corners of the world, and I have not been able to get them > to escalate. > > --Brett Glass > > > > > Archives > | > ModifyYour > Subscription | Unsubscribe > Now > > > > -- From mike at mtcc.com Sat Apr 12 18:43:47 2014 From: mike at mtcc.com (Michael Thomas) Date: Sat, 12 Apr 2014 11:43:47 -0700 Subject: DNSSEC? In-Reply-To: References: <201404111835.s3BIZcqQ003034@world.std.com> <20140411192529.GE21153@cmadams.net> <7E7AB3CC-F434-494A-AB99-5A745654F872@tzi.org> <20140411214715.GV15800@hezmatt.org> <534874D8.3050205@direcpath.com> <53494AEC.8010901@mtcc.com> Message-ID: <53498963.70907@mtcc.com> On 04/12/2014 10:10 AM, Jimmy Hess wrote: > On Sat, Apr 12, 2014 at 9:17 AM, Michael Thomas wrote: >> Malloc doesn't write over to-be allocated memory, calloc does. Using a > Zero'ing newly allocated memory is not the desired behavior. The > desired behavior is that a segmentation fault occurs, when an > application breaks the rules --- so the bug is detected, instead of > being hidden. There is no such memory manager. Writes can be caught that way, reads, not so much. > > The system free() can be configured to write junk bytes to the entire > freed region, and malloc can be configured to align some allocations > to the end of a page (Which is a default on OpenBSD), and allocate > guard pages to cause a segmentation fault to occur if an attempt is > made to double free() or read past the end of the allocated buffer. Yes, I'm a little surprised to hear that such a heavily scrutinized security software don't use those usual suspect mechanisms to cover their butts. The flip side, though, is that you don't want to start then *counting* on those CYA mechanisms. >> wrapper is hardly unusual or controversial -- malloc can be expensive, and >> keeping lookaside list for, say, commonly used and fixed sized blocks is, > Use of the wrapper is both unusual and a bit controversial. Bologna. It's very common. There are lots and lots and lots of reasons to wrap bare system calls in wrappers. I haven't seen their wrappers in particular but it's nonsense to say that it's unusual. > > The openssl devs found some neat rope, decided to tie the noose, and > leave it permanently mounted around their neck, just praying some > script kiddie doesn't find the other end of the rope and tie it to > something. > > >> at least used to be, a big performance win. > A very small possible performance win, with an extreme potential > decrease in safety. Depending on what you're doing, the difference can be huge. Malloc is a general purpose allocator with all of the heavyweight machinery general purpose requires. There's plenty of perfectly valid reasons to do your own memory management. Mike From hank at efes.iucc.ac.il Sat Apr 12 19:03:04 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 12 Apr 2014 22:03:04 +0300 Subject: Kit to split a 19" closet? In-Reply-To: References: Message-ID: <5.1.1.6.2.20140412220109.007b39b0@efes.iucc.ac.il> Suppose you have an existing server closet. You want to split it so that two different organizations can have access to it. Separate doors and a divider in the middle. Does anyone make kit for this for hosting centers? Thanks, Hank From dougb at dougbarton.us Sat Apr 12 19:24:09 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 12 Apr 2014 12:24:09 -0700 Subject: Kit to split a 19" closet? In-Reply-To: <5.1.1.6.2.20140412220109.007b39b0@efes.iucc.ac.il> References: <5.1.1.6.2.20140412220109.007b39b0@efes.iucc.ac.il> Message-ID: <534992D9.6040907@dougbarton.us> Please don't reply to a message on the list and change the subject line. Doing so causes your new topic to show "under" the previous one for those using mail readers that thread properly, and may cause your message to be missed altogether if someone has blocked that thread. Instead, save the list address and start a completely new message. hope this helps, Doug From jimpop at gmail.com Sat Apr 12 21:38:09 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 12 Apr 2014 17:38:09 -0400 Subject: responding to DMARC breakage In-Reply-To: <53497404.9040203@meetinghouse.net> References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> <53497404.9040203@meetinghouse.net> Message-ID: On Sat, Apr 12, 2014 at 1:12 PM, Miles Fidelman wrote: > Valdis.Kletnieks at vt.edu wrote: >> >> On Sat, 12 Apr 2014 10:12:09 -0400, Miles Fidelman said: >> >>> It occurs to me that Yahoo's deployment of DMARC p=reject, and the >>> choice of several big mail operators to honor that, has created a >>> situation not unlike a really routing table or nameserver, snafu --- >> >> It's more like a peering war. Time for somebody to either bake a cake, >> or find alternate transit providers. > > > Aaargghhh - what a horrible, but accurate analogy. Worse probably - more > like a peering war with a large broadband carrier, at the edge, where it's > harder to find alternate transport. > > Sigh.. Taking things a bit deeper... someone needs to get a legal opinion wrt the DMARC group's effort to have all mailinglists change their From: address. A legal opinion needs to be drawn on any new culpability nanog.org (or other mailinglists) would have when the list now "owns" the message that is being distributed. As it is now, there is acceptance that my posts are my content and the words there in are my responsibility. What happens when my text starts showing up as From:asdfadasfadfdsa at nanog.org ? -Jim P. From dhc2 at dcrocker.net Sat Apr 12 21:56:09 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sat, 12 Apr 2014 14:56:09 -0700 Subject: responding to DMARC breakage In-Reply-To: References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> <53497404.9040203@meetinghouse.net> Message-ID: <5349B679.1040008@dcrocker.net> On 4/12/2014 2:38 PM, Jim Popovitch wrote: > On Sat, Apr 12, 2014 at 1:12 PM, Miles Fidelman > wrote: > someone needs to get a legal opinion wrt > the DMARC group's effort to have all mailinglists change their From: > address. "The DMARC group" (presumably referring to the dmarc.org informal consortium that created DMARC) is conducting no such effort. The action taken this past week was an independent effort by Yahoo. dmarc.org had nothing to do with it. The DMARC specification is quite clear about the limitations of its use. Nothing is aided by the confusing the very basic different between a specification and the choices actors make in applying it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From lowen at pari.edu Sat Apr 12 22:03:10 2014 From: lowen at pari.edu (Lamar Owen) Date: Sat, 12 Apr 2014 18:03:10 -0400 Subject: Heartbleed Bug Found in Cisco Routers, Juniper Gear In-Reply-To: References: Message-ID: <5349B81E.8030905@pari.edu> On 04/11/2014 07:16 AM, Glen Kent wrote: >> VPN, on the other hand, is a totally different world of pain for this >> issue. >> > What about VPNs? > > SSL VPN's could possibly be vulnerable. From jimpop at gmail.com Sat Apr 12 22:12:10 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 12 Apr 2014 18:12:10 -0400 Subject: responding to DMARC breakage In-Reply-To: <5349B679.1040008@dcrocker.net> References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> <53497404.9040203@meetinghouse.net> <5349B679.1040008@dcrocker.net> Message-ID: On Sat, Apr 12, 2014 at 5:56 PM, Dave Crocker wrote: > On 4/12/2014 2:38 PM, Jim Popovitch wrote: >> >> On Sat, Apr 12, 2014 at 1:12 PM, Miles Fidelman >> wrote: >> someone needs to get a legal opinion wrt >> the DMARC group's effort to have all mailinglists change their From: >> address. > > > > "The DMARC group" (presumably referring to the dmarc.org informal consortium > that created DMARC) is conducting no such effort. > > The action taken this past week was an independent effort by Yahoo. > > dmarc.org had nothing to do with it. I wasn't writing about their website, rather the motivations of the core participants of the DMARC spec (that hang out around that website). If you haven't been paying attention all along, it's easy to miss the changes from the original DMARC objectives. Sometime after the first draft, DMARC went from only being for transactional email (i.e. behind the scenes stuff), to full blown end-all of spam with DMARC appearing on every tech blog and even CNN. That train's been barreling down the track for some time now. I posted this earlier, but for refresher: Go here: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Notice the early versions of the spec contained the word "transactional", notice the current version has it removed. Also notice that (at the point of change) one of the authors is from Yahoo!. What Yahoo! did wasn't a fluke, nor independent happenstance, it's part of a much bigger and broader picture. The ironic thing is that rather than go the IETF way (a fair amount of the DMARC folk are past IETF contributors), the decision was made to not seek peer consensus, nor to invalidate conflicting RFCs. An end run. -Jim P. From mfidelman at meetinghouse.net Sat Apr 12 22:31:42 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sat, 12 Apr 2014 18:31:42 -0400 Subject: responding to DMARC breakage In-Reply-To: <5349B679.1040008@dcrocker.net> References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> <53497404.9040203@meetinghouse.net> <5349B679.1040008@dcrocker.net> Message-ID: <5349BECE.7060209@meetinghouse.net> Dave Crocker wrote: > On 4/12/2014 2:38 PM, Jim Popovitch wrote: >> On Sat, Apr 12, 2014 at 1:12 PM, Miles Fidelman >> wrote: >> someone needs to get a legal opinion wrt >> the DMARC group's effort to have all mailinglists change their From: >> address. > > > "The DMARC group" (presumably referring to the dmarc.org informal > consortium that created DMARC) is conducting no such effort. > > The action taken this past week was an independent effort by Yahoo. > > dmarc.org had nothing to do with it. > > The DMARC specification is quite clear about the limitations of its use. > > Nothing is aided by the confusing the very basic different between a > specification and the choices actors make in applying it. > Dave, it's not that clear cut. Standards bodies have been held liable for negligence, as have participants in standards making processes (just did a little googling of case law). Trade associations have been held to be in violation of antitrust law. I would expect that the right lawyer might have a field day painting the "informal consortium that created DMARC" as colluding in violation of anti-trust law, and perhaps criminal conspiracy. At the very least, "creating a public nuisance." And that's before we even consider civil torte liability. I also expect that someone could make a good case against Yahoo for "knowingly caus[ing] the transmission of a program, information code, or command, and as a result of such conduct, intentionally causes damages without authorization to a protected computer? in violation of the Computer and Fraud Abuse Act - for publishing their p=reject policy, and possibly for hotmail, comcast, etc. for criminal conspiracy in honoring that policy. (Kind of like a DDoS attack, or domain hijacking.) But then, I'm not a lawyer, just an engineer and sometime policy wonk (who just had lots of fun working with some very smart lawyers on a bid protest). Hmm... I wonder if anybody who's suffered serious economic damage as a result of this wants to bankroll some lawyers? Could be fun. (And given the amount of pain this has inflicted on me, personally, I wouldn't mind sharing some of the pain.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From elouie at yahoo.com Sat Apr 12 22:47:24 2014 From: elouie at yahoo.com (Eric A Louie) Date: Sat, 12 Apr 2014 15:47:24 -0700 (PDT) Subject: Kit to split a 19" closet? In-Reply-To: <5.1.1.6.2.20140412220109.007b39b0@efes.iucc.ac.il> References: <5.1.1.6.2.20140412220109.007b39b0@efes.iucc.ac.il> Message-ID: <1397342844.41685.YahooMailNeo@web181606.mail.ne1.yahoo.com> Divided into vertical sections, it requires a new set of hinges and doors and lock slots front and rear, as well as solid shelves between the sections.? Think about it for a moment, or go visit your nearest colocation center and ask to see a 1/2 or 1/3 rack.? I actually have a 1/3 rack at one of my POPs. Start with your cabinet manufacturer.? I've seen 1/2 racks, 1/3 racks, and 1/4 racks in a full 84" enclosure. >________________________________ > From: Hank Nussbacher >To: nanog at nanog.org >Sent: Saturday, April 12, 2014 12:03 PM >Subject: Kit to split a 19" closet? > > >Suppose you have an existing server closet.? You want to split it so that >two different organizations can have access to it.? Separate doors and a >divider in the middle.? Does anyone make kit for this for hosting centers? > >Thanks, >Hank > > > > > From hhoffman at ip-solutions.net Sun Apr 13 00:55:17 2014 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sat, 12 Apr 2014 20:55:17 -0400 Subject: Heartbleed Bug Found in Cisco Routers, Juniper Gear In-Reply-To: <5349B81E.8030905@pari.edu> References: <5349B81E.8030905@pari.edu> Message-ID: <521AB7DF-85DA-47CA-BF4F-AED6F3769CF8@ip-solutions.net> Didn't Cisco already release a bunch of updates related to Anyconnect and heartbleed? Cheers, Harry On Apr 12, 2014, at 6:03 PM, Lamar Owen wrote: > On 04/11/2014 07:16 AM, Glen Kent wrote: >>> VPN, on the other hand, is a totally different world of pain for this >>> issue. >>> >> What about VPNs? >> >> > > SSL VPN's could possibly be vulnerable. > > From mysidia at gmail.com Sun Apr 13 01:34:22 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 12 Apr 2014 20:34:22 -0500 Subject: responding to DMARC breakage In-Reply-To: <534949B9.1080704@meetinghouse.net> References: <534949B9.1080704@meetinghouse.net> Message-ID: On Sat, Apr 12, 2014 at 9:12 AM, Miles Fidelman wrote: > - Yahoo (operationally) and the DMARC authors are intentionally > un-responsive (as are hotmail, comcast, a few others; gmail, I note is not > bouncing mail) > > How do we respond as operators, beyond late-night, ad-hoc patches to list > software, that only partially resolve the problem? In the face of intentional unresponsiveness: blacklisting. Start contacting Yahoo.com subscribers and explain the situation to these users, and inform the users that, for the time being: yahoo.com e-mail addresses can no longer participate in the mailing lists, because of Yahoo's new policy: And make some suggestions of good alternatives to using Yahoo mail. Then use mail filters to block messages to mailing list addresses with From: header yahoo.com (which cause the problem), next suspend subscriptions for @yahoo.com users, and configure mailing list software so that new @yahoo.com based e-mail addresses cannot subscribe or post to the lists. -- -JH From jeff-kell at utc.edu Sun Apr 13 01:37:36 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 12 Apr 2014 21:37:36 -0400 Subject: Heartbleed Bug Found in Cisco Routers, Juniper Gear In-Reply-To: <521AB7DF-85DA-47CA-BF4F-AED6F3769CF8@ip-solutions.net> References: <5349B81E.8030905@pari.edu> <521AB7DF-85DA-47CA-BF4F-AED6F3769CF8@ip-solutions.net> Message-ID: <5349EA60.3080801@utc.edu> On 4/12/2014 8:55 PM, Harry Hoffman wrote: > Didn't Cisco already release a bunch of updates related to Anyconnect and heartbleed? There were AnyConnect for iOS (little "i", not big "I") issues with heartbleed, but everything else has been mostly phone and UCS related. IOS XE is affected if you have enabled https:// administrative interface. Otherwise no (at least not yet, they're still checking). There were, however, four separate security issues released this week that affected SSL VPN, AnyConnect, and ASAs (I had to patch our ASAs even though we do not do SSL VPN or AnyConnect, there is a DoS attack possible via SIP). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Sun Apr 13 03:39:36 2014 From: randy at psg.com (Randy Bush) Date: Sun, 13 Apr 2014 12:39:36 +0900 Subject: spamassassin hole again? Message-ID: massive porn spam is making it through spamassassin. new filter oops? randy, still researching From sabri at cluecentral.net Sun Apr 13 11:15:16 2014 From: sabri at cluecentral.net (Sabri Berisha) Date: Sun, 13 Apr 2014 04:15:16 -0700 (PDT) Subject: spamassassin hole again? In-Reply-To: References: Message-ID: <916759130.1167.1397387716839.JavaMail.zimbra@cluecentral.net> Hi, g I suspect I've been hit by the same run, looks like the RIPE database has been harvested since I got at least one copy on an e-mail address that I've only used for the RIPE db. I also saw a lot of peering@ and noc@ addresses in from/to/cc fields. So far I've received about a hundred copies. Whoever is responsible for this spamrun is not the brightest light in the world. Thanks, Sabri ----- Original Message ----- > From: "Randy Bush" > To: "North American Network Operators' Group" > Sent: Saturday, April 12, 2014 8:39:36 PM > Subject: spamassassin hole again? > > massive porn spam is making it through spamassassin. new filter oops? > > randy, still researching > > From joly at punkcast.com Sun Apr 13 05:43:42 2014 From: joly at punkcast.com (Joly MacFie) Date: Sun, 13 Apr 2014 01:43:42 -0400 Subject: responding to DMARC breakage In-Reply-To: References: <534949B9.1080704@meetinghouse.net> Message-ID: Question: Years ago Yahoo! bought major mailing list provider egroups formerly onelist, eventually absorbing it into yahoo clubs and making something called yahoogroups. Does this break yahoogroups too? How are THEY handling it? -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From babak at farrokhi.net Sun Apr 13 05:00:38 2014 From: babak at farrokhi.net (Babak Farrokhi) Date: Sun, 13 Apr 2014 09:30:38 +0430 Subject: spamassassin hole again? In-Reply-To: References: Message-ID: <4EF5764B-D0B0-46CD-A6C5-330438EB18D8@farrokhi.net> We are not using spamasassin and only major RBLs in place and seeing the same wave of spam. Seems like a new botnot has just appeared. -- Babak -- Babak Farrokhi > On Apr 13, 2014, at 8:09 AM, Randy Bush wrote: > > massive porn spam is making it through spamassassin. new filter oops? > > randy, still researching > From jimpop at gmail.com Sun Apr 13 06:01:31 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Sun, 13 Apr 2014 02:01:31 -0400 Subject: responding to DMARC breakage In-Reply-To: References: <534949B9.1080704@meetinghouse.net> Message-ID: On Sun, Apr 13, 2014 at 1:43 AM, Joly MacFie wrote: > Question: > > Years ago Yahoo! bought major mailing list provider egroups formerly > onelist, eventually absorbing it into yahoo clubs and making something > called yahoogroups. > > Does this break yahoogroups too? How are THEY handling it? I think they broke it too. I'm a lurker on a modest sized group there (flags at yahoogroups.com). There is prominent member, with a yahoo.com account, who posts multiple times a day, every day throughout the week. His last post was on 4-April. -Jim P. From andrew.fried at gmail.com Sun Apr 13 07:10:50 2014 From: andrew.fried at gmail.com (Andrew Fried) Date: Sun, 13 Apr 2014 03:10:50 -0400 Subject: spamassassin hole again? In-Reply-To: <4EF5764B-D0B0-46CD-A6C5-330438EB18D8@farrokhi.net> References: <4EF5764B-D0B0-46CD-A6C5-330438EB18D8@farrokhi.net> Message-ID: <534A387A.5050008@gmail.com> Any chance you could provide a *clue* as to what you're seeing, eg message subject, from, etc??? Andrew Fried andrew.fried at gmail.com On 4/13/14, 1:00 AM, Babak Farrokhi wrote: > We are not using spamasassin and only major RBLs in place and seeing the same wave of spam. Seems like a new botnot has just appeared. > > -- Babak > From prt at prt.org Sun Apr 13 07:59:10 2014 From: prt at prt.org (Paul Thornton) Date: Sun, 13 Apr 2014 08:59:10 +0100 Subject: spamassassin hole again? In-Reply-To: <534A387A.5050008@gmail.com> References: <4EF5764B-D0B0-46CD-A6C5-330438EB18D8@farrokhi.net> <534A387A.5050008@gmail.com> Message-ID: <534A43CE.8020607@prt.org> On 13/04/2014 08:10, Andrew Fried wrote: > Any chance you could provide a *clue* as to what you're seeing, eg > message subject, from, etc??? The subjects seem to vary; but appear to involve animals, sex and cute women in various orders (apologies to anyone offended by that). Content is a one-liner link to porn sites. I agree with the RIPE DB scrape - the From: line on one of these is From: "Registry ripenotify" and the CC line contains our notify: E-mail (plus a load more of this junk to noc|peering|named contacts). These seem to be botted machines sending mails 'legitimately' ie: headers appear to show that the first hop was relayed out through a normal route rather than just port 25 spray. Some are even kindly pre-marked as spam. We've had >250 turn up since 23:34 UTC yesterday (12 April). Appears to have slowed/stopped around 05:00 UTC today (13 April). Paul. -- Paul Thornton From andrew.fried at gmail.com Sun Apr 13 08:09:41 2014 From: andrew.fried at gmail.com (Andrew Fried) Date: Sun, 13 Apr 2014 04:09:41 -0400 Subject: spamassassin hole again? In-Reply-To: <534A43CE.8020607@prt.org> References: <4EF5764B-D0B0-46CD-A6C5-330438EB18D8@farrokhi.net> <534A387A.5050008@gmail.com> <534A43CE.8020607@prt.org> Message-ID: <534A4645.3040305@gmail.com> Thanks, Paul. The #1 spam I'm seeing right now has the subject line "Subject: Why Internet was born?"; the domains from the URLs appear to be listed in Spamhaus DBL. Obviously a different batch. Andy Andrew Fried andrew.fried at gmail.com On 4/13/14, 3:59 AM, Paul Thornton wrote: > On 13/04/2014 08:10, Andrew Fried wrote: >> Any chance you could provide a *clue* as to what you're seeing, eg >> message subject, from, etc??? > > The subjects seem to vary; but appear to involve animals, sex and cute > women in various orders (apologies to anyone offended by that). > > Content is a one-liner link to porn sites. > > I agree with the RIPE DB scrape - the From: line on one of these is > > From: "Registry ripenotify" > and the CC line contains our notify: E-mail (plus a load more of this > junk to noc|peering|named contacts). > > These seem to be botted machines sending mails 'legitimately' ie: > headers appear to show that the first hop was relayed out through a > normal route rather than just port 25 spray. Some are even kindly > pre-marked as spam. > > We've had >250 turn up since 23:34 UTC yesterday (12 April). Appears to > have slowed/stopped around 05:00 UTC today (13 April). > > Paul. > From mpetach at netflight.com Sun Apr 13 08:39:00 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 13 Apr 2014 01:39:00 -0700 Subject: responding to DMARC breakage In-Reply-To: <53497404.9040203@meetinghouse.net> References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> <53497404.9040203@meetinghouse.net> Message-ID: On Sat, Apr 12, 2014 at 10:12 AM, Miles Fidelman wrote: > Valdis.Kletnieks at vt.edu wrote: > >> On Sat, 12 Apr 2014 10:12:09 -0400, Miles Fidelman said: >> >> It occurs to me that Yahoo's deployment of DMARC p=reject, and the >>> choice of several big mail operators to honor that, has created a >>> situation not unlike a really routing table or nameserver, snafu --- >>> >> It's more like a peering war. Time for somebody to either bake a cake, >> or find alternate transit providers. >> > > Aaargghhh - what a horrible, but accurate analogy. Worse probably - more > like a peering war with a large broadband carrier, at the edge, where it's > harder to find alternate transport. > So, if we stretch the analogy to near-breaking-point, would that make Yahoo the Comcast of the email world... or the Level3? And depending on that answer, would the community think that a similar response of petitioning the government for more oversight and control would be warranted? Or would it be just as much out of line in this case as it is in the Level3-Comcast fight? I'm genuinely curious, because for most of my 20+ years in the networking industry, I've felt like we've done a good job at internally regulating ourselves as an industry, without needing to bring in outside regulation; but now, it sometimes starts to feel like the near metastable equilibrium of the system is wobbling ever-farther from our ability to adequately control and stabilize it. Have we potentially hit the point where the 'community' (for whatever definition is appropriate) no longer has enough input or leverage to bring players back into line when they stray outside of what is considered appropriate behaviour? In spite of the peering cake having been delicious and moist (I had two pieces, it was so yummy!), that rift has never closed; Comcast is not changing their model, in spite of community outcry, and Level3 has taken the step of summoning the spectre of government intervention. Cogent seems determined to follow a similar line of reasoning with respect to interconnections ("if we think we can get money from you, we'll use our customer base as leverage; if not, we'll cry foul, and appeal to the {government, masses, media}"). Have we reached the point as a community where "rough consensus and running code" is no longer the rule by which we operate, and fear of opprobrium no longer holds any weight with operators? As an engineer, I used to be proud that I helped build and operate a system that existed and thrived under its own rules, outside the sphere of any one particular government or legal system. I looked to it as a model of how a bottoms-up planetary ecosystem might operate, with everyone cooperating towards a universal goal. Now, I'm not so sure anymore; I'm becoming a little bit worried it's more just a simple reflection of all the conflicting impulses in each of us. I don't think there's a clear right or wrong to these questions; it just seems like the simplicity and elegant optimism of the early years may have slipped away while I focused intently on what was right in front of me. [drat...i started writing that over breakfast, and then the day got busy...and here i am, finishing it up fifteen hours later, and i'm not even sure if i'm still going in the same direction with it; but i'll still toss it out, and see in which direction it floats...] Matt From lists.nanog at bengtl.net Sun Apr 13 11:34:27 2014 From: lists.nanog at bengtl.net (Bengt Larsson) Date: Sun, 13 Apr 2014 13:34:27 +0200 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140411215601.GW15800@hezmatt.org> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> Message-ID: <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Matt Palmer wrote: > * The NSA found it *amazingly* quickly (they're very good at what they do, > but I don't believe them have superhuman talents); or It's quite plausible that they watch the changes in open-source projects to find bugs. They could do nice diffs and everything. From mfidelman at meetinghouse.net Sun Apr 13 14:01:47 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Sun, 13 Apr 2014 10:01:47 -0400 Subject: responding to DMARC breakage In-Reply-To: References: <534949B9.1080704@meetinghouse.net> <9112.1397321344@turing-police.cc.vt.edu> <53497404.9040203@meetinghouse.net> Message-ID: <534A98CB.3010602@meetinghouse.net> Matthew Petach wrote: > > > > On Sat, Apr 12, 2014 at 10:12 AM, Miles Fidelman > > wrote: > > Valdis.Kletnieks at vt.edu wrote: > > On Sat, 12 Apr 2014 10:12:09 -0400, Miles Fidelman said: > > It occurs to me that Yahoo's deployment of DMARC p=reject, > and the > choice of several big mail operators to honor that, has > created a > situation not unlike a really routing table or nameserver, > snafu --- > > It's more like a peering war. Time for somebody to either > bake a cake, > or find alternate transit providers. > > > Aaargghhh - what a horrible, but accurate analogy. Worse probably > - more like a peering war with a large broadband carrier, at the > edge, where it's harder to find alternate transport. > > > So, if we stretch the analogy to near-breaking-point, > would that make Yahoo the Comcast of the email > world... or the Level3? And depending on that answer, > would the community think that a similar response of > petitioning the government for more oversight and control > would be warranted? Or would it be just as much out of > line in this case as it is in the Level3-Comcast fight? That's a big concern of mine, and one that's somewhat reflected in current discussions re. NTIA stepping away from its oversight role of ICANN/IANA. It strikes me that there are a growing number of issues that beg for some kind of institutionalized response and recourse - peering, DMARC, others - but we don't have any in place. That's the point at which people start suing each other and looking for government intervention. Sigh.... In this case: - if the tv tower 2 miles from here starts interfering with stuff, we call the FCC, and it gets fixed (particularly if it starts interfering with, for example, police radios) - various law enforcement agencies go after the bigger spam operations, and DDoS exploiters - but... Yahoo publishes a p=reject DNS record - causing, effectively, a massive DDoS - and..... what? Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From randy at psg.com Sun Apr 13 14:30:46 2014 From: randy at psg.com (Randy Bush) Date: Sun, 13 Apr 2014 23:30:46 +0900 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Message-ID: > It's quite plausible that they watch the changes in open-source > projects to find bugs. They could do nice diffs and everything. the point of open source is that the community is supposed to be doing this. we failed. randy From mike at mtcc.com Sun Apr 13 14:45:28 2014 From: mike at mtcc.com (Michael Thomas) Date: Sun, 13 Apr 2014 07:45:28 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Message-ID: <534AA308.5080509@mtcc.com> On 04/13/2014 07:30 AM, Randy Bush wrote: >> It's quite plausible that they watch the changes in open-source >> projects to find bugs. They could do nice diffs and everything. > the point of open source is that the community is supposed to be doing > this. we failed. > > Versus all of the closed source bugs that nobody can know of or do anything about? Bugs are a fact of life. The best we can do is fix, learn and evolve. Mike From randy at psg.com Sun Apr 13 14:52:32 2014 From: randy at psg.com (Randy Bush) Date: Sun, 13 Apr 2014 23:52:32 +0900 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534AA308.5080509@mtcc.com> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> Message-ID: >> the point of open source is that the community is supposed to be doing >> this. we failed. > Versus all of the closed source bugs that nobody can know of or do > anything about? for those you can blame the vendor. this one is owned by the community. it falls on us to try to lower the probability of a next one by actively auditing source as our civic duty. randy From mike at mtcc.com Sun Apr 13 15:08:46 2014 From: mike at mtcc.com (Michael Thomas) Date: Sun, 13 Apr 2014 08:08:46 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> Message-ID: <534AA87E.5070407@mtcc.com> On 04/13/2014 07:52 AM, Randy Bush wrote: >>> the point of open source is that the community is supposed to be doing >>> this. we failed. >> Versus all of the closed source bugs that nobody can know of or do >> anything about? > for those you can blame the vendor. Or not. > this one is owned by the community. > it falls on us to try to lower the probability of a next one by actively > auditing source as our civic duty. > > And we all know how well civic duty works as a motivator. If we really want to do something constructive, convince the corpro-takers to open their wallets to fund those auditing functions. Mike From niels=nanog at bakker.net Sun Apr 13 16:52:50 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Sun, 13 Apr 2014 18:52:50 +0200 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> Message-ID: <20140413165250.GI36211@burnout.tpb.net> * randy at psg.com (Randy Bush) [Sun 13 Apr 2014, 16:52 CEST]: >>>the point of open source is that the community is supposed to be >>>doing this. we failed. >>Versus all of the closed source bugs that nobody can know of or do >>anything about? >for those you can blame the vendor. BSAFE is almost worse if you go by the recent advisories that have been released about it. Many vendors incorporated OpenSSL into their products and sold the result for commercial profit without doing (in retrospect) enough due diligence. Besides, having a third party to blame doesn't make our data safer... At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-users&m=139723710923076&w=2 I hope other vendors will follow suit. >this one is owned by the community. it falls on us to try to lower >the probability of a next one by actively auditing source as our >civic duty. I donated some money to the OpenSSL project and hope others will do, or have already done, the same. It's clear that they are internet infrastructure and need more support. -- Niels. From wbailey at satelliteintelligencegroup.com Sun Apr 13 17:26:39 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 13 Apr 2014 17:26:39 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140413165250.GI36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> ,<20140413165250.GI36211@burnout.tpb.net> Message-ID: Doesn't OpenSSL even fundraise? Based on the number of dollars they've taken in (what I could find online) most of them are better off taking side jobs as psychics to pay for audits. I know of at least one thing they could have predicted in the future. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Niels Bakker Date: 04/13/2014 10:55 AM (GMT-07:00) To: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] * randy at psg.com (Randy Bush) [Sun 13 Apr 2014, 16:52 CEST]: >>>the point of open source is that the community is supposed to be >>>doing this. we failed. >>Versus all of the closed source bugs that nobody can know of or do >>anything about? >for those you can blame the vendor. BSAFE is almost worse if you go by the recent advisories that have been released about it. Many vendors incorporated OpenSSL into their products and sold the result for commercial profit without doing (in retrospect) enough due diligence. Besides, having a third party to blame doesn't make our data safer... At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-users&m=139723710923076&w=2 I hope other vendors will follow suit. >this one is owned by the community. it falls on us to try to lower >the probability of a next one by actively auditing source as our >civic duty. I donated some money to the OpenSSL project and hope others will do, or have already done, the same. It's clear that they are internet infrastructure and need more support. -- Niels. From johnl at iecc.com Sun Apr 13 21:18:57 2014 From: johnl at iecc.com (John Levine) Date: 13 Apr 2014 21:18:57 -0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534AA87E.5070407@mtcc.com> Message-ID: <20140413211857.25261.qmail@joyce.lan> >And we all know how well civic duty works as a motivator. If we really >want to do something >constructive, convince the corpro-takers to open their wallets to fund >those auditing functions. For once, I agree with Mike. (Twice in one year?) Considering how widely openssl is used, and how important it is, it's shameful how little support it gets. I'd also point out that auditing security code is hard, and auditing SSL/TLS code is extremely hard because the spec depends on a lot of unusually arcane algorithms, and its implementation is almost perversely complex (that means PKI and ASN.1.) So random programmer eyes are much less likely to find useful stuff than people who have spent a while learning about the technology. http://jl.ly/Internet/openssl.html R's, John From Matthew.Black at csulb.edu Mon Apr 14 14:38:29 2014 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 14 Apr 2014 14:38:29 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Message-ID: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. matthew black california state university, long beach -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Sunday, April 13, 2014 7:31 AM To: Bengt Larsson Cc: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > It's quite plausible that they watch the changes in open-source > projects to find bugs. They could do nice diffs and everything. the point of open source is that the community is supposed to be doing this. we failed. randy From simon.perreault at viagenie.ca Mon Apr 14 14:46:24 2014 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 14 Apr 2014 10:46:24 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Message-ID: <534BF4C0.70906@viagenie.ca> Le 2014-04-14 10:38, Matthew Black a ?crit : > Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. All modern OSes do that. What's your point? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Matthew.Black at csulb.edu Mon Apr 14 14:48:03 2014 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 14 Apr 2014 14:48:03 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> Message-ID: Also on this same idea, in his book "The Puzzle Palace," James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. matthew black california state university, long beach -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Friday, April 11, 2014 2:06 PM To: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker wrote: > Please go read up on some recent and less recent history before making > judgments on what would be unusually gutsy for that group of people. > > I'm not saying this has been happening but you will have to come up > with a better defense than "it seems unlikely to me personally". Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word "sensitive" does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill From Thijs.Stuurman at is.nl Mon Apr 14 14:55:49 2014 From: Thijs.Stuurman at is.nl (Thijs Stuurman) Date: Mon, 14 Apr 2014 14:55:49 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140413165250.GI36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> Message-ID: I applaud their effort but please see https://blogs.akamai.com/2014/04/heartbleed-update-v3.html & http://lekkertech.net/akamai.txt Kind regards / Vriendelijke groet, IS Group Thijs Stuurman -----Oorspronkelijk bericht----- Van: Niels Bakker [mailto:niels=nanog at bakker.net] Verzonden: Sunday, April 13, 2014 6:53 PM Aan: nanog at nanog.org Onderwerp: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] * randy at psg.com (Randy Bush) [Sun 13 Apr 2014, 16:52 CEST]: >>>the point of open source is that the community is supposed to be >>>doing this. we failed. >>Versus all of the closed source bugs that nobody can know of or do >>anything about? >for those you can blame the vendor. BSAFE is almost worse if you go by the recent advisories that have been released about it. Many vendors incorporated OpenSSL into their products and sold the result for commercial profit without doing (in retrospect) enough due diligence. Besides, having a third party to blame doesn't make our data safer... At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-users&m=139723710923076&w=2 I hope other vendors will follow suit. >this one is owned by the community. it falls on us to try to lower the >probability of a next one by actively auditing source as our civic >duty. I donated some money to the OpenSSL project and hope others will do, or have already done, the same. It's clear that they are internet infrastructure and need more support. -- Niels. From d3e3e3 at gmail.com Mon Apr 14 15:28:01 2014 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 14 Apr 2014 11:28:01 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> Message-ID: Matthew, On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black wrote: > Also on this same idea, in his book "The Puzzle Palace," James Bamford > claims that we knew of the pending attack on Pearl Harbor but did nothing, > because that would compromise we broke the Japanese Purple Cipher. I assume you refers to pages 36 through 39 of "The Puzzle Palace" which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says "we decided to do nothing" bears no relationship to what Bamford actually wrote. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com matthew black > california state university, long beach > > > -----Original Message----- > From: William Herrin [mailto:bill at herrin.us] > Sent: Friday, April 11, 2014 2:06 PM > To: nanog at nanog.org > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for > Years] > > On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker > wrote: > > Please go read up on some recent and less recent history before making > > judgments on what would be unusually gutsy for that group of people. > > > > I'm not saying this has been happening but you will have to come up > > with a better defense than "it seems unlikely to me personally". > > Let me know when someone finds the second shooter on the grassy knoll. > As for me, I do have some first hand knowledge as to exactly how sensitive > several portions of the federal government are to the security of the > servers which hold their data. They may not hold YOUR data in high > regard... but the word "sensitive" does not do justice to the attention > lavished on THEIR servers' security. > > In WW2 we protected the secret of having cracked enigma by deliberately > ignoring a lot of the knowledge we gained. So such things have happened. > But we didn't use enigma ourselves -- none of our secrets were at risk. And > our adversaries today have no secrets more valuable than our own. > > -Bill > > > > From mis at seiden.com Mon Apr 14 15:55:01 2014 From: mis at seiden.com (Mark Seiden) Date: Mon, 14 Apr 2014 08:55:01 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> Message-ID: On Apr 13, 2014, at 7:52 AM, Randy Bush wrote: >>> the point of open source is that the community is supposed to be doing >>> this. we failed. >> Versus all of the closed source bugs that nobody can know of or do >> anything about? > > for those you can blame the vendor. this one is owned by the community. > it falls on us to try to lower the probability of a next one by actively > auditing source as our civic duty. > is that kind of like jury duty? if only it were more like literature, which we could read for enjoyment. > randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mfidelman at meetinghouse.net Mon Apr 14 16:10:03 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 12:10:03 -0400 Subject: DMARC -> CERT? Message-ID: <534C085B.802@meetinghouse.net> Just a thought. I keep thinking that Yahoo's publishing of their "p=reject" policy, and the subsequent massive denial of service to lost of list traffic might be viewed as a "computer security" incident. Anybody think that reporting via CERT channels might be an appropriate response? (I do, and probably will - but curious what others think.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From tglassey at earthlink.net Mon Apr 14 16:26:19 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Mon, 14 Apr 2014 09:26:19 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Message-ID: <534C0C2B.8090809@earthlink.net> Yes Matthew it should. The question is whether they do or not. Todd On 4/14/2014 7:38 AM, Matthew Black wrote: > Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. > > matthew black > california state university, long beach > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Sunday, April 13, 2014 7:31 AM > To: Bengt Larsson > Cc: nanog at nanog.org > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > >> It's quite plausible that they watch the changes in open-source >> projects to find bugs. They could do nice diffs and everything. > the point of open source is that the community is supposed to be doing this. we failed. > > randy > > > > > -- ------------- Personal Email - Disclaimers Apply From mpetach at netflight.com Mon Apr 14 16:27:07 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 14 Apr 2014 09:27:07 -0700 Subject: DMARC -> CERT? In-Reply-To: <534C085B.802@meetinghouse.net> References: <534C085B.802@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 9:10 AM, Miles Fidelman wrote: > Just a thought. I keep thinking that Yahoo's publishing of their > "p=reject" policy, and the subsequent massive denial of service to lost of > list traffic might be viewed as a "computer security" incident. > > Anybody think that reporting via CERT channels might be an appropriate > response? > > (I do, and probably will - but curious what others think.) > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > I would recommend reading these two blog entries first: http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users and http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do Then, I would ask--if the situation is deemed CERT-worthy, what is the emergency the community is being asked to respond to? Is it that Yahoo has decided, after many years, to start taking action to tighten down email abuse? Or is the emergency that too many mailing lists operate fast-and-loose with email headers, and that we as a community need to take swift and immediate action to fix mailing lists to correctly identify and attribute the true source of messages from the lists? My internal guess, based on the years and years of griping about forged sender spam that I've seen on this list, among others, is that the latter case is the emergency to which you are seeking a call to action. Thanks! Matt From tglassey at earthlink.net Mon Apr 14 16:27:53 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Mon, 14 Apr 2014 09:27:53 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <80786.1397263787@turing-police.cc.vt.edu> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <80786.1397263787@turing-police.cc.vt.edu> Message-ID: <534C0C89.1010906@earthlink.net> Vladis is %100 on the money here. Lets take this a step farther and ask is there a criminal liability for the person who checked that code in - Oh you bet there is... Todd On 4/11/2014 5:49 PM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: > >> The interesting thing to me is that the article claims the NSA have been >> using this for "over two years", but 1.0.1 (the first vulnerable version) >> was only released on 14 Mar 2012. That means that either: >> * The NSA found it *amazingly* quickly (they're very good at what they do, >> but I don't believe them have superhuman talents); or > You seriously think the NSA *isn't* watching the commits to security-relevant > open source? Remember - it was a bonehead bug, it's *not* unreasonable for > somebody who was auditing the code to spot it. Heck, there's a good chance that > automated tools could have spotted it. -- ------------- Personal Email - Disclaimers Apply From mfidelman at meetinghouse.net Mon Apr 14 16:32:05 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 12:32:05 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> Message-ID: <534C0D85.3000408@meetinghouse.net> Matthew Petach wrote: > > > > On Mon, Apr 14, 2014 at 9:10 AM, Miles Fidelman > > wrote: > > Just a thought. I keep thinking that Yahoo's publishing of their > "p=reject" policy, and the subsequent massive denial of service to > lost of list traffic might be viewed as a "computer security" > incident. > > Anybody think that reporting via CERT channels might be an > appropriate response? > > (I do, and probably will - but curious what others think.) > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > > > I would recommend reading these two blog entries first: > > http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users > and > http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do > > Then, I would ask--if the situation is deemed CERT-worthy, > what is the emergency the community is being asked to > respond to? Is it that Yahoo has decided, after many years, > to start taking action to tighten down email abuse? Or is the > emergency that too many mailing lists operate fast-and-loose > with email headers, and that we as a community need to take > swift and immediate action to fix mailing lists to correctly > identify and attribute the true source of messages from > the lists? > Well... how about this, from Yahoo's own posting: We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mpetach at netflight.com Mon Apr 14 16:49:32 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 14 Apr 2014 09:49:32 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C0C89.1010906@earthlink.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <80786.1397263787@turing-police.cc.vt.edu> <534C0C89.1010906@earthlink.net> Message-ID: On Mon, Apr 14, 2014 at 9:27 AM, TGLASSEY wrote: > Vladis is %100 on the money here. Lets take this a step farther and ask is > there a criminal liability for the person who checked that code in - Oh you > bet there is... > > Todd Thank you--I needed some humour in my morning, I was starting to take the day too seriously. Thank you for putting a smile back on my face, and giving me something to laugh about today. ^_^ Matt From laszlo at heliacal.net Mon Apr 14 16:56:46 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 14 Apr 2014 16:56:46 +0000 Subject: DMARC -> CERT? In-Reply-To: <534C0D85.3000408@meetinghouse.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> Message-ID: <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> I don't see what the big deal is here. They don't want your messages and they made that clear. Their policy considers these messages spam. If you really want to get your mailing list messages through, then you need to evade their filters just like every other spammer has to. -Laszlo On Apr 14, 2014, at 4:32 PM, Miles Fidelman wrote: > Well... how about this, from Yahoo's own posting: > We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. > > To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From Valdis.Kletnieks at vt.edu Mon Apr 14 17:03:26 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 14 Apr 2014 13:03:26 -0400 Subject: DMARC -> CERT? In-Reply-To: Your message of "Mon, 14 Apr 2014 16:56:46 -0000." <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> Message-ID: <50389.1397495006@turing-police.cc.vt.edu> On Mon, 14 Apr 2014 16:56:46 -0000, Laszlo Hanyecz said: > If you really want to get your mailing list messages through, The problem isn't the rest of us trying to mail to Yahoo. The problem is when Yahoo users post to lists that use DMARC, and the result is the yahoo user's mail getting bounced or dumped on the postmaster. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mfidelman at meetinghouse.net Mon Apr 14 17:05:38 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 13:05:38 -0400 Subject: DMARC -> CERT? In-Reply-To: <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> Message-ID: <534C1562.2080408@meetinghouse.net> Isn't it the other way around? They don't want their users to be able to send to mailing lists. They receive traffic from the lists just fine. Their policy considers only effects mail originating from their users. Yahoo subscribers can receive messages form nanog just fine, but they can't send to it. Miles Laszlo Hanyecz wrote: > I don't see what the big deal is here. They don't want your messages and they made that clear. Their policy considers these messages spam. If you really want to get your mailing list messages through, then you need to evade their filters just like every other spammer has to. > > -Laszlo > > > On Apr 14, 2014, at 4:32 PM, Miles Fidelman wrote: > >> Well... how about this, from Yahoo's own posting: >> We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. >> >> To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From laszlo at heliacal.net Mon Apr 14 17:25:46 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Mon, 14 Apr 2014 17:25:46 +0000 Subject: DMARC -> CERT? In-Reply-To: <534C1562.2080408@meetinghouse.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> Message-ID: <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> By their statement it's obvious that yahoo doesn't care about what they broke. It's unfortunate that email has become so centralized that one entity can cause so much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list subscribers to use their own domains for email, and host it themselves if possible. -Laszlo On Apr 14, 2014, at 5:05 PM, Miles Fidelman wrote: > Isn't it the other way around? They don't want their users to be able to send to mailing lists. They receive traffic from the lists just fine. Their policy considers only effects mail originating from their users. Yahoo subscribers can receive messages form nanog just fine, but they can't send to it. > > Miles > > Laszlo Hanyecz wrote: >> I don't see what the big deal is here. They don't want your messages and they made that clear. Their policy considers these messages spam. If you really want to get your mailing list messages through, then you need to evade their filters just like every other spammer has to. >> >> -Laszlo >> >> >> On Apr 14, 2014, at 4:32 PM, Miles Fidelman wrote: >> >>> Well... how about this, from Yahoo's own posting: >>> We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. >>> >>> To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. >>> >>> Miles Fidelman >>> >>> -- >>> In theory, there is no difference between theory and practice. >>> In practice, there is. .... Yogi Berra >>> >>> > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From bill at herrin.us Mon Apr 14 17:29:42 2014 From: bill at herrin.us (William Herrin) Date: Mon, 14 Apr 2014 13:29:42 -0400 Subject: DMARC -> CERT? In-Reply-To: <50389.1397495006@turing-police.cc.vt.edu> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <50389.1397495006@turing-police.cc.vt.edu> Message-ID: On Mon, Apr 14, 2014 at 1:03 PM, wrote: > The problem is when Yahoo users post to lists that use DMARC, and the > result is the yahoo user's mail getting bounced or dumped on the postmaster. Basically, this is just like old ORBS. If you were an ISP, you had to check your local users' IP addresses smarthosting through your mail server against ORBS or your mail server would inevitably be listed. Now, as then, the solution is: if the domain has a DMARC listing, mail addresses using it aren't permitted to post to the list. As I tried to say before but was probably too subtle -- just flunk validation for all DMARC-using messages, across the board without exception, and then act on that failure as the DMARC DNS records indicate that the sender wants you to. Especially the ones to abuse@ and your other POCs. That'll clean up the use of DMARC right quick. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Mon Apr 14 17:30:54 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Apr 2014 13:30:54 -0400 Subject: DMARC -> CERT? In-Reply-To: <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 1:25 PM, Laszlo Hanyecz wrote: > By their statement it's obvious that yahoo doesn't care about what they broke. It's > unfortunate that email has become so centralized that one entity can cause so > much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list > subscribers to use their own domains for email, and host it themselves if possible. > I sort of wonder if this is really just yahoo trying to use a stick to motivate people to do the right thing? It seems like everyone's been trying for a while to 'make email better'... and that perhaps DMARC will make it somewhat better, and if setup properly this is a non-issue... after much faffing: "Welp, how about we whack the mail-lists (and others) with a stick and get movement int he right direction?" not sure this is all bad... and i think the fix is pretty straightforward for list folk, right? so all the faffing on this list and others took longer to do than the fix-action? -chris From mpetach at netflight.com Mon Apr 14 17:33:40 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 14 Apr 2014 10:33:40 -0700 Subject: DMARC -> CERT? In-Reply-To: <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 10:25 AM, Laszlo Hanyecz wrote: > By their statement it's obvious that yahoo doesn't care about what they > broke. It's unfortunate that email has become so centralized that one > entity can cause so much 'trouble'. Maybe it's a good opportunity to > encourage the affected mailing list subscribers to use their own domains > for email, and host it themselves if possible. > > -Laszlo > So, I take it you prefer a world in which there's no sender validation, and receiving floods of spoofed sender email spam is just part of the price of being on the internet? I'm finding myself vaguely annoyed that for so long people have complained that big mail providers need to clean up their act; and now, when one of them decides to respond to the complaints and start taking action to try to clean things up, the response seems to be "wait, we were happy just bitching and moaning--we didn't want you to actually *change* anything!" Matt From mfidelman at meetinghouse.net Mon Apr 14 18:23:41 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 14:23:41 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: <534C27AD.6040105@meetinghouse.net> Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 1:25 PM, Laszlo Hanyecz wrote: >> By their statement it's obvious that yahoo doesn't care about what they broke. It's >> unfortunate that email has become so centralized that one entity can cause so >> much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list >> subscribers to use their own domains for email, and host it themselves if possible. >> > I sort of wonder if this is really just yahoo trying to use a stick to > motivate people to do the right thing? It seems like everyone's been > trying for a while to 'make email better'... and that perhaps DMARC > will make it somewhat better, and if setup properly this is a > non-issue... after much faffing: "Welp, how about we whack the > mail-lists (and others) with a stick and get movement int he right > direction?" > > not sure this is all bad... and i think the fix is pretty > straightforward for list folk, right? so all the faffing on this list > and others took longer to do than the fix-action? > > Well, if you consider writing software patches to complicated software simple. And it would certainly help if the guidance on what to do is clearer - last week, dmarc.org's FAQ listed, as among the options for list operators: "Add an Original Authentication Results (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results. " -- which would be transparent to list subscribers but, as of a couple of days ago, that's qualified by: "*This is not a short term solution.* Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012. No receivers implementing DMARC are currently known to make use of OAR from external sources." So the low-impact (to end users) fix is now not recommended, and all the other available fixes require changes that degrade long-accepted functionality of mailing lists (e.g., the ability to reply to the author of a message). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jimpop at gmail.com Mon Apr 14 18:24:34 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 14:24:34 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 1:33 PM, Matthew Petach wrote: > > So, I take it you prefer a world in which there's no sender > validation, and receiving floods of spoofed sender email > spam is just part of the price of being on the internet? That is clearly not what this issue is about. > I'm finding myself vaguely annoyed that for so long > people have complained that big mail providers need > to clean up their act; and now, when one of them > decides to respond to the complaints and start > taking action to try to clean things up, the response > seems to be "wait, we were happy just bitching > and moaning--we didn't want you to actually > *change* anything!" What yahoo didn't do was first tell their users to unsubscribe from all mailinglists. DMARC hasn't cut down on yahoo spam so far. Yahoo's spam problem was (is?) centered on account hijacks. -Jim P. From scott at doc.net.au Mon Apr 14 19:47:13 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 12:47:13 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140413165250.GI36211@burnout.tpb.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> Message-ID: On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote: > At least one vendor, Akamai is helping out now: > http://marc.info/?l=openssl-users&m=139723710923076&w=2 > I hope other vendors will follow suit. Although it appears they may now be regretting doing so... http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ (Of course, the end result is positive, but...) Scott From patrick at ianai.net Mon Apr 14 19:59:21 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 14 Apr 2014 15:59:21 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> Message-ID: <28860040-0300-4090-AB04-4F8532076791@ianai.net> On Apr 14, 2014, at 15:47 , Scott Howard wrote: > On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote: >> At least one vendor, Akamai is helping out now: >> http://marc.info/?l=openssl-users&m=139723710923076&w=2 >> I hope other vendors will follow suit. > > > Although it appears they may now be regretting doing so... > > http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ > > (Of course, the end result is positive, but...) [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Or we can flame anyone who tries, then wonder why no one is trying. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bill at herrin.us Mon Apr 14 20:05:21 2014 From: bill at herrin.us (William Herrin) Date: Mon, 14 Apr 2014 16:05:21 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <28860040-0300-4090-AB04-4F8532076791@ianai.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> <28860040-0300-4090-AB04-4F8532076791@ianai.net> Message-ID: On Mon, Apr 14, 2014 at 3:59 PM, Patrick W. Gilmore wrote: > I applaud Akamai for trying, for being courageous enough to post > code, and for bucking the trend so many other companies are > following by being more secretive every year. > > Or we can flame anyone who tries, then wonder why no one is trying. I thought vendors existed primarily as a place to hang the blame when dealing with a manager or customer who just doesn't get it. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dougb at dougbarton.us Mon Apr 14 20:07:25 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 13:07:25 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <28860040-0300-4090-AB04-4F8532076791@ianai.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> <28860040-0300-4090-AB04-4F8532076791@ianai.net> Message-ID: <534C3FFD.4070702@dougbarton.us> On 04/14/2014 12:59 PM, Patrick W. Gilmore wrote: > On Apr 14, 2014, at 15:47 , Scott Howard wrote: >> On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote: > >>> At least one vendor, Akamai is helping out now: >>> http://marc.info/?l=openssl-users&m=139723710923076&w=2 >>> I hope other vendors will follow suit. >> >> >> Although it appears they may now be regretting doing so... >> >> http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ >> >> (Of course, the end result is positive, but...) > > [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] > > If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. > > I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. > > Or we can flame anyone who tries, then wonder why no one is trying. Agreed ... review is good, comments on needed fixes are good, but saying that Akamai, "should not be sending out non-functional, bug ridden patches to the OpenSSL community" as Pinckaers did is not constructive. Part of the problem here is the whole "You can't play in my sandbox!" attitude. Doug From scott at doc.net.au Mon Apr 14 20:10:50 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 13:10:50 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 11:24 AM, Jim Popovitch wrote: > DMARC hasn't cut down on yahoo spam so far. Yahoo's spam problem was > (is?) centered on account hijacks. > I just checked my spam folder for the past month. Out of about 80 messages "from" Yahoo, I can see about 3 that went via Yahoo's mail servers. ie, >90% were/would have been blocked using DMARC. Of course, I'm sure the spammers will simply start changing yahoo.com to somethingelse.com once they realize - but from Yahoo's perspective, that's obviously a positive. Whilst I don't agree with the way that Yahoo has done this (particularly around communication), I think the end result is only going to be positive. At a high level it's no different than when people started rejecting mail from hosts without PTR records, or when ISPs started blocking outbound port 25 - they both caused things to break, and both caused people to have to take action to fix the brokenness, but in the long run they were both hugely positive. Scott From morrowc.lists at gmail.com Mon Apr 14 20:20:16 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Apr 2014 16:20:16 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: > Whilst I don't agree with the way that Yahoo has done this (particularly > around communication), how could they have communicated this better? how can we all learn from this? -chris From bmanning at vacation.karoshi.com Mon Apr 14 20:24:51 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 14 Apr 2014 13:24:51 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <28860040-0300-4090-AB04-4F8532076791@ianai.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> <28860040-0300-4090-AB04-4F8532076791@ianai.net> Message-ID: <20140414202451.GA32719@vacation.karoshi.com> On Mon, Apr 14, 2014 at 03:59:21PM -0400, Patrick W. Gilmore wrote: > On Apr 14, 2014, at 15:47 , Scott Howard wrote: > > On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker wrote: > > >> At least one vendor, Akamai is helping out now: > >> http://marc.info/?l=openssl-users&m=139723710923076&w=2 > >> I hope other vendors will follow suit. > > > > > > Although it appears they may now be regretting doing so... > > > > http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ > > > > (Of course, the end result is positive, but...) > > [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] > > If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. > > I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. > > Or we can flame anyone who tries, then wonder why no one is trying. > > -- > TTFN, > patrick > well, if $vendor publishes code frags, the code must have been vetted and ready for _my_ environment so i'll just cut/paste and then when it doesn't work, its their fault for leading me down the primrose path... $vendor, that why I pay you... to read my mind! darn it. /bill From dougb at dougbarton.us Mon Apr 14 20:28:15 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 13:28:15 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: <534C44DF.6010909@dougbarton.us> On 04/14/2014 01:20 PM, Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: >> Whilst I don't agree with the way that Yahoo has done this (particularly >> around communication), > > how could they have communicated this better? how can we all learn from this? The obvious ones would have been to announce a flag day somewhere far enough in advance to give list software devs time to adapt, and to work with list software devs on a solution. Everyone involved in DMARC has known from day 1 that it will break mailing lists. There has been an enormous amount of whinging about this. (If you think NANOG is bad, you should see the IETF lists.) But if Yahoo! had stood up and said, "We know that this mailing lists are a problem, but we think that the value of DMARC outweighs this because ...." and then actually set a data, maybe some of the whinging could have turned into actual productive work on fixing the problem. Doug From matthias at leisi.net Mon Apr 14 20:34:39 2014 From: matthias at leisi.net (Matthias Leisi) Date: Mon, 14 Apr 2014 22:34:39 +0200 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: > > Whilst I don't agree with the way that Yahoo has done this (particularly > > around communication), > > how could they have communicated this better? how can we all learn from > this? > They could have communicated, as in "listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time". They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). -- Matthias From morrowc.lists at gmail.com Mon Apr 14 20:38:19 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Apr 2014 16:38:19 -0400 Subject: DMARC -> CERT? In-Reply-To: <534C44DF.6010909@dougbarton.us> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> Message-ID: On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote: > The obvious ones would have been to announce a flag day somewhere far enough > in advance to give list software devs time to adapt, and to work with list > software devs on a solution. where would they communicate this? on the blog that matt pointed at? in bgp announcements? err... homepage? -chris (I watch the ietf list for this, and muted the conversation...) From morrowc.lists at gmail.com Mon Apr 14 20:39:10 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Apr 2014 16:39:10 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi wrote: > They could have communicated, as in "listen folks, we are going to make a > critical change that will affect mailing lists (etc...) in four weeks time". communicated it where? > They could have made the change not late on a Friday afternoon (or well into > the weekend for most of the world). a friday change like this is not ideal... but, it looks like any time change like this would have had fallout. From jimpop at gmail.com Mon Apr 14 20:43:21 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 16:43:21 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> Message-ID: On Mon, Apr 14, 2014 at 4:38 PM, Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote: >> The obvious ones would have been to announce a flag day somewhere far enough >> in advance to give list software devs time to adapt, and to work with list >> software devs on a solution. > > where would they communicate this? > on the blog that matt pointed at? > in bgp announcements? > err... homepage? What they should have done is followed their (the dmarc spec authors, of which one works for Yahoo) own advice that dmarc wasn't for domains with users. But, hey, we all know it's hard to get good tech press by simply sponsoring and spec'ing a backend tech solution for some dark corner of the internet. -Jim P. From scott at doc.net.au Mon Apr 14 20:44:11 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 13:44:11 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi > wrote: > > They could have communicated, as in "listen folks, we are going to make a > > critical change that will affect mailing lists (etc...) in four weeks > time". > > communicated it where? > "The Internet". A blog entry and a post to a few key relevant mailing lists would have resulted in the message spreading far better than it was. There's no way that they could have communicated it to every mailing list admin on the planet, but they could have at least given a heads-up to some major parts of the community. The great thing about the Internet is that if it's important enough to be shared, you don't need to try too hard to make that happen - others will look after it for you. But you need to make the effort to get it started, and Yahoo didn't do that here (or at least, they did, but they did it by actually making the change by which time it was too late!) Scott From dougb at dougbarton.us Mon Apr 14 20:44:44 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 13:44:44 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> Message-ID: <534C48BC.1090902@dougbarton.us> On 04/14/2014 01:38 PM, Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote: >> The obvious ones would have been to announce a flag day somewhere far enough >> in advance to give list software devs time to adapt, and to work with list >> software devs on a solution. > > where would they communicate this? Well mailop for one. > on the blog that matt pointed at? I suppose ... there used to be a "Yahoo! mail blog" but I think it got shut down. BTW, another obvious benefit to announcing a flag day would have been to give more people time to set up DMARC. I haven't yet (on my personal mail server) because there hadn't been sufficient uptake to warrant it. Yahoo! telling everyone that they will be implementing it would have given people incentive. Doug From jimpop at gmail.com Mon Apr 14 20:45:29 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 16:45:29 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 4:39 PM, Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi wrote: >> They could have communicated, as in "listen folks, we are going to make a >> critical change that will affect mailing lists (etc...) in four weeks time". > > communicated it where? To their user base? They could have easily sent an email announcement to all their users explaining that the change would cause problems when their users post to mailinglists. -Jim P. From morrowc.lists at gmail.com Mon Apr 14 20:52:37 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 14 Apr 2014 16:52:37 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard wrote: > On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow > wrote: >> >> On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi >> wrote: >> > They could have communicated, as in "listen folks, we are going to make >> > a >> > critical change that will affect mailing lists (etc...) in four weeks >> > time". >> >> communicated it where? > > > "The Internet". I was trying, really, to be not-funny with my question. if you're going to do something that has the potential to affect (say, for example) email to a wide set of people, most of which are NOT your direct users, how do you go about making that public? 'the internet' isn't really a good answer for 'how do you notify'. Doug's note that: "email mailops" is good... but I'm not sure how many people that run lists listen to mailops? (I don't ... i don't run any big list, but...) I also wonder about update cycles for software in this realm? and for very larger list operators there's probably some customization and such to hurdle over on the upgrade path, eh? so how much leadtime is enough? how much is too much? 1yr seems like a long time - people will forget, 1wk doesn't seem like enough to avoid firedrills and un-intended bugs. > A blog entry and a post to a few key relevant mailing lists would have specifically which mail-lists? > resulted in the message spreading far better than it was. There's no way > that they could have communicated it to every mailing list admin on the > planet, but they could have at least given a heads-up to some major parts of > the community. > > The great thing about the Internet is that if it's important enough to be > shared, you don't need to try too hard to make that happen - others will > look after it for you. But you need to make the effort to get it started, > and Yahoo didn't do that here (or at least, they did, but they did it by > actually making the change by which time it was too late!) > > Scott > From jimpop at gmail.com Mon Apr 14 20:55:46 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 16:55:46 -0400 Subject: DMARC -> CERT? In-Reply-To: <534C48BC.1090902@dougbarton.us> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> <534C48BC.1090902@dougbarton.us> Message-ID: On Mon, Apr 14, 2014 at 4:44 PM, Doug Barton wrote: > On 04/14/2014 01:38 PM, Christopher Morrow wrote: >> >> On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton wrote: >>> >>> The obvious ones would have been to announce a flag day somewhere far >>> enough >>> in advance to give list software devs time to adapt, and to work with >>> list >>> software devs on a solution. >> >> >> where would they communicate this? > > > Well mailop for one. Or even the dmarc mailing list(s).... I've seen Yahoo operate over the years, they are usually much better at orchestrating changes, which suggests that this change wasn't well thought out (or possibly even planned). -Jim P. From rsk at gsp.org Mon Apr 14 20:58:31 2014 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 14 Apr 2014 16:58:31 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: <20140414205831.GA14434@gsp.org> On Mon, Apr 14, 2014 at 10:33:40AM -0700, Matthew Petach wrote: > So, I take it you prefer a world in which there's no sender > validation, and receiving floods of spoofed sender email > spam is just part of the price of being on the internet? Sender validation means NOTHING in a world with hundreds of millions of bots and hundreds of millions of email accounts that are either (a) hijacked or (b) created at will by the bot herders. My spamtraps see spam all day every day from all over the world that passes whatever alleged "sender validation" technology is the flavor-of-the-month. Can it work in some isolated edge cases? Sure. Can it work on an Internet scale? No. As I've said many times, email forgery is not the problem. It's a symptom of the problem, and the problem is "rotten underlying security" coupled with "negligent and incompetent operational practice". But fixing that is hard, and nobody -- not Yahoo and not anybody else either -- wants to tackle it. It's much easier to roll out stuff like this and pretend that it works and write a press release and declare success. ---rsk From scott at doc.net.au Mon Apr 14 21:00:12 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 14:00:12 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <28860040-0300-4090-AB04-4F8532076791@ianai.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> <28860040-0300-4090-AB04-4F8532076791@ianai.net> Message-ID: On Mon, Apr 14, 2014 at 12:59 PM, Patrick W. Gilmore wrote: I applaud Akamai for trying, for being courageous enough to post code, and > for bucking the trend so many other companies are following by being more > secretive every year. > Just to be clear, so do I! As I said, the end result was net positive - within hours the fact they made this code snippet "open source" resulted in it be available to many more eyeballs, and bugs in it being found. By releasing the code, Akamai has not only helped the community (at least as a starting point - even if their actual code had issues the concept is good and no doubt will be improved upon by the wider community), but helped themselves by discovering that they were operating under the mistaken impression that their SSL keys were safe when potentially they were not. On Mon, Apr 14, 2014 at 1:07 PM, Doug Barton wrote: > > Agreed ... review is good, comments on needed fixes are good, but saying > that Akamai, "should not be sending out non-functional, bug ridden patches > to the OpenSSL community" as Pinckaers did is not constructive. > Especially when the release specifically stated "*This should really be considered more of a proof of concept than something that you want to put directly into production*" and "*do not just take this patch and put it into production without careful review*." Akamai made mistakes here, but releasing what they obviously believed to be workable code in the way that they did wasn't one of them. Scott From jimpop at gmail.com Mon Apr 14 21:06:33 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 17:06:33 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: On Mon, Apr 14, 2014 at 4:52 PM, Christopher Morrow wrote: > > if you're going to do something that has the potential to affect (say, > for example) email to a wide set of people, most of which are NOT your > direct users, how do you go about making that public? > > 'the internet' isn't really a good answer for 'how do you notify'. > Doug's note that: "email mailops" is good... but I'm not sure how many > people that run lists listen to mailops? (I don't ... i don't run any > big list, but...) > > I also wonder about update cycles for software in this realm? and for > very larger list operators there's probably some customization and > such to hurdle over on the upgrade path, eh? so how much leadtime is > enough? how much is too much? 1yr seems like a long time - people will > forget, 1wk doesn't seem like enough to avoid firedrills and > un-intended bugs. First, you don't start by telling mailinglist admins to NOT worry about dmarc as they are a special case that will be handled/whitelisted/etc. The dmarc discussion archives (of which Yahoo is a primary sponsor, and a Yahoo employee is one of the spec authors) are full of discussions that clearly show no cause or care about mailinglists. I was told, several times, that mailinglists would be ok, they would be whitelisted and that there was no need for all my concern (well over 6 months ago). -Jim P. From mfidelman at meetinghouse.net Mon Apr 14 21:24:24 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 17:24:24 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: <534C5208.8030306@meetinghouse.net> Matthias Leisi wrote: > On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: >>> Whilst I don't agree with the way that Yahoo has done this (particularly >>> around communication), >> how could they have communicated this better? how can we all learn from >> this? >> > They could have communicated, as in "listen folks, we are going to make a > critical change that will affect mailing lists (etc...) in four weeks > time". > > They could have made the change not late on a Friday afternoon (or well > into the weekend for most of the world). > > On the weekend before tax filings are due in the US! And a couple of days before Passover. Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Mon Apr 14 21:27:35 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 17:27:35 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: <534C52C7.3040602@meetinghouse.net> Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard wrote: >> On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow >> wrote: >>> On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi >>> wrote: >>>> They could have communicated, as in "listen folks, we are going to make >>>> a >>>> critical change that will affect mailing lists (etc...) in four weeks >>>> time". >>> communicated it where? >> >> "The Internet". > I was trying, really, to be not-funny with my question. > > if you're going to do something that has the potential to affect (say, > for example) email to a wide set of people, most of which are NOT your > direct users, how do you go about making that public? > > 'the internet' isn't really a good answer for 'how do you notify'. > Doug's note that: "email mailops" is good... but I'm not sure how many > people that run lists listen to mailops? (I don't ... i don't run any > big list, but...) > > I also wonder about update cycles for software in this realm? and for > very larger list operators there's probably some customization and > such to hurdle over on the upgrade path, eh? so how much leadtime is > enough? how much is too much? 1yr seems like a long time - people will > forget, 1wk doesn't seem like enough to avoid firedrills and > un-intended bugs. > >> A blog entry and a post to a few key relevant mailing lists would have > specifically which mail-lists? > > How about the support lists for all the email list packages they could think of - let's start with mailman, majordomo, listserve, listproc, sympa, ezmlm, ..... Might have been nice if they'd offered some support for patching the open source ones. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jimpop at gmail.com Mon Apr 14 21:29:00 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 17:29:00 -0400 Subject: DMARC -> CERT? In-Reply-To: <534C5208.8030306@meetinghouse.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 5:24 PM, Miles Fidelman wrote: > Matthias Leisi wrote: >> >> On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow < >> morrowc.lists at gmail.com> wrote: >> >>> On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: >>>> >>>> Whilst I don't agree with the way that Yahoo has done this (particularly >>>> around communication), >>> >>> how could they have communicated this better? how can we all learn from >>> this? >>> >> They could have communicated, as in "listen folks, we are going to make a >> critical change that will affect mailing lists (etc...) in four weeks >> time". >> >> They could have made the change not late on a Friday afternoon (or well >> into the weekend for most of the world). >> >> > On the weekend before tax filings are due in the US! And a couple of days > before Passover. and in the middle of Heartbleed..... It's enough to make you believe there was absolutely no care or concern for others. -Jim P. From jay at west.net Mon Apr 14 21:37:48 2014 From: jay at west.net (Jay Hennigan) Date: Mon, 14 Apr 2014 14:37:48 -0700 Subject: Yahoo DMARC breakage In-Reply-To: <20140410112912.GA15874@gsp.org> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> Message-ID: <534C552C.30107@west.net> On 4/10/14 4:29 AM, Rich Kulawiec wrote: > An aside: > > On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote: >> Maybe this is a good thing - we can stop getting all the "sorry I'm >> out of the office" emails when posting to a list. > > I entirely support that goal, but my preferred solution is the complete > eradication of the software (a lot of which makes mistakes that have > been well-known as mistakes for decades) and thus the entire practice > of setting up "out of office" messages. As long as we're talking about complete eradication of software, please include inane disclaimers sent to lists (as well as private email). This type of thing.... NOTICE: This communication may contain confidential and/or privileged information. If you are not the intended recipient or believe that you have received this communication in error you are obligated to kill yourself and anyone else who may have read it, not necessarily in that order. So there. My disclaimer is scarier than yours. Nyaah. You started this silly nonsense. Knock it off and I will too, ok? It's worthless from a legal standpoint and is responsible for the needless suffering of billions of innocent electrons. Nobody reads it anyway. You're not actually reading this, are you? I didn't think so. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From mpetach at netflight.com Mon Apr 14 21:39:24 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 14 Apr 2014 14:39:24 -0700 Subject: DMARC -> CERT? In-Reply-To: <534C48BC.1090902@dougbarton.us> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> <534C48BC.1090902@dougbarton.us> Message-ID: On Mon, Apr 14, 2014 at 1:44 PM, Doug Barton wrote: > On 04/14/2014 01:38 PM, Christopher Morrow wrote: > > on the blog that matt pointed at? >> > > I suppose ... there used to be a "Yahoo! mail blog" but I think it got > shut down. > Still is... http://yahoomail.tumblr.com/ Matt From rwebb at ropeguru.com Mon Apr 14 21:39:44 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Mon, 14 Apr 2014 17:39:44 -0400 Subject: DMARC -> CERT? In-Reply-To: <534C52C7.3040602@meetinghouse.net> Message-ID: <19e5332588bfed48bc90f2631883b8d6@ropeguru.com> Plus I guarantee that something this SIGNIFICANT would catch the attention of many tech news outlets, social sites, and many email lists if they had given due notice and allowed people time to digest the change. But, I guess since everything except their email has become pretty much irrelevant these days, they had to do something to get attention and try to be the big bully again. I personally run only a couple of small email lists in which the subscribers are specifically added by me when someone wants on, and this has caused us, because the submitter has a long time Yahoo email address and will not change, a huge headache. The sender has had to resort to sending email from Yahoo account multiple time in order to get the emails out to the 180+ subscribers. Some people cannot change their email due to having it for so long it is just not practical. Only other work around I have for this user is to give them a private email list on the email server where he can send from that is not a Yahoo address. This causes extra work because every email he wants to forward on, he must now first send it to the new private address, then login to the private email address web mail, then forward. I have to agree with this others out there that Yahoo SHOULD, not COULD, have handled this a lot better. All the other big ISP's out there should be whipping Yahoo's a$$ about right now. But as usual, not a peep! Robert -----Original Message----- From: Miles Fidelman [mailto:mfidelman at meetinghouse.net] Sent: Monday, April 14, 2014 5:28 PM Cc: NANOG Subject: Re: DMARC -> CERT? Christopher Morrow wrote: > On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard wrote: >> On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow >> wrote: >>> On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi >>> wrote: >>>> They could have communicated, as in "listen folks, we are going to >>>> make a critical change that will affect mailing lists (etc...) in >>>> four weeks time". >>> communicated it where? >> >> "The Internet". > I was trying, really, to be not-funny with my question. > > if you're going to do something that has the potential to affect (say, > for example) email to a wide set of people, most of which are NOT your > direct users, how do you go about making that public? > > 'the internet' isn't really a good answer for 'how do you notify'. > Doug's note that: "email mailops" is good... but I'm not sure how many > people that run lists listen to mailops? (I don't ... i don't run any > big list, but...) > > I also wonder about update cycles for software in this realm? and for > very larger list operators there's probably some customization and > such to hurdle over on the upgrade path, eh? so how much leadtime is > enough? how much is too much? 1yr seems like a long time - people will > forget, 1wk doesn't seem like enough to avoid firedrills and > un-intended bugs. > >> A blog entry and a post to a few key relevant mailing lists would have > specifically which mail-lists? > > How about the support lists for all the email list packages they could think of - let's start with mailman, majordomo, listserve, listproc, sympa, ezmlm, ..... Might have been nice if they'd offered some support for patching the open source ones. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bicknell at ufp.org Mon Apr 14 21:45:09 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 14 Apr 2014 16:45:09 -0500 Subject: DMARC -> CERT? In-Reply-To: <20140414205831.GA14434@gsp.org> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <20140414205831.GA14434@gsp.org> Message-ID: <0D1AA11E-F1ED-495C-8E41-CC85A5E24A3D@ufp.org> On Apr 14, 2014, at 3:58 PM, Rich Kulawiec wrote: > As I've said many times, email forgery is not the problem. It's a symptom > of the problem, and the problem is "rotten underlying security" coupled > with "negligent and incompetent operational practice". But fixing that > is hard, and nobody -- not Yahoo and not anybody else either -- wants > to tackle it. It's much easier to roll out stuff like this and pretend > that it works and write a press release and declare success. I think you're on the right track, but still suggesting their is a technical solution. I submit there is not. There is no car alarm that prevents all car thefts, no door lock that prevents all burglaries. No trigger lock that prevents all gun deaths, no lane departure system that prevents all car crashes. Spam cannot, and will never be solved by technological measures alone. They can help reduce the levels in some cases, or "squeeze the balloon" and move the spam to some other form. Ultimately the way to reduce spam is to catch spammers, prosecute them, and put them in prison. The way we keep all of those other crimes low is primarily by enforcement; making the punishment not worth the crime. With spam, the chance that a spammer will be punished is infinitesimal. There are hundreds, or thousands, or tens of thousands of spammers for every one that is put into jail. If we'd put even 1% of the effort that's been thrown at technical measures over the years into better laws, tools for law enforcement, and helping them build cases we'd be several orders of magnitude better off than technological solutions that are little more than wack-a-mole. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mfidelman at meetinghouse.net Mon Apr 14 21:45:52 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 17:45:52 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: <534C5710.3050508@meetinghouse.net> Jim Popovitch wrote: > On Mon, Apr 14, 2014 at 5:24 PM, Miles Fidelman > wrote: >> Matthias Leisi wrote: >>> On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow < >>> morrowc.lists at gmail.com> wrote: >>> >>>> On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: >>>>> Whilst I don't agree with the way that Yahoo has done this (particularly >>>>> around communication), >>>> how could they have communicated this better? how can we all learn from >>>> this? >>>> >>> They could have communicated, as in "listen folks, we are going to make a >>> critical change that will affect mailing lists (etc...) in four weeks >>> time". >>> >>> They could have made the change not late on a Friday afternoon (or well >>> into the weekend for most of the world). >>> >>> >> On the weekend before tax filings are due in the US! And a couple of days >> before Passover. > and in the middle of Heartbleed..... > > It's enough to make you believe there was absolutely no care or > concern for others. > And.. it's worth contrasting the community response to Heartbleed - which didn't actually cause widespread denial of service! Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From scott at doc.net.au Mon Apr 14 21:48:05 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 14:48:05 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch wrote: > >> They could have made the change not late on a Friday afternoon (or well > >> into the weekend for most of the world). > >> > >> > > On the weekend before tax filings are due in the US! And a couple of > days > > before Passover. > > and in the middle of Heartbleed..... > You might have had a point - if it had been ANY of those. Other than the original claim of "Friday afternoon" it was none of those things. Scott From dougb at dougbarton.us Mon Apr 14 21:50:10 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 14:50:10 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> <534C48BC.1090902@dougbarton.us> Message-ID: <534C5812.3040808@dougbarton.us> On 04/14/2014 02:39 PM, Matthew Petach wrote: > > > > On Mon, Apr 14, 2014 at 1:44 PM, Doug Barton > wrote: > > On 04/14/2014 01:38 PM, Christopher Morrow wrote: > > on the blog that matt pointed at? > > > I suppose ... there used to be a "Yahoo! mail blog" but I think it > got shut down. > > > Still is... > > http://yahoomail.tumblr.com/ Ah ... someone should fix the my.yahoo module then, because that's where I was told the old one went away. :) Doug From jimpop at gmail.com Mon Apr 14 21:51:11 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 17:51:11 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C44DF.6010909@dougbarton.us> <534C48BC.1090902@dougbarton.us> Message-ID: On Mon, Apr 14, 2014 at 5:39 PM, Matthew Petach wrote: > On Mon, Apr 14, 2014 at 1:44 PM, Doug Barton wrote: > >> On 04/14/2014 01:38 PM, Christopher Morrow wrote: >> >> on the blog that matt pointed at? >>> >> >> I suppose ... there used to be a "Yahoo! mail blog" but I think it got >> shut down. >> > > Still is... > > http://yahoomail.tumblr.com/ And it contains nothing relevant before the dmarc change, and "makeup fluff" shortly thereafter. -Jim P. From mfidelman at meetinghouse.net Mon Apr 14 21:53:15 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 17:53:15 -0400 Subject: DMARC -> CERT? In-Reply-To: <0D1AA11E-F1ED-495C-8E41-CC85A5E24A3D@ufp.org> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <20140414205831.GA14434@gsp.org> <0D1AA11E-F1ED-495C-8E41-CC85A5E24A3D@ufp.org> Message-ID: <534C58CB.6020208@meetinghouse.net> Leo Bicknell wrote: > > Ultimately the way to reduce spam is to catch spammers, prosecute them, > and put them in prison. The way we keep all of those other crimes low > is primarily by enforcement; making the punishment not worth the crime. > With spam, the chance that a spammer will be punished is infinitesimal. > There are hundreds, or thousands, or tens of thousands of spammers for > every one that is put into jail. Follow their money trails and take their bank accounts. Counterpunch with DDoS attacks. Attack them with drones. We're investing a lot of tax dollars into offensive cybersecurity - let's give those guys some practice! Makes sense to me! From jimpop at gmail.com Mon Apr 14 21:59:39 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 17:59:39 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 5:48 PM, Scott Howard wrote: > On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch wrote: >> >> >> They could have made the change not late on a Friday afternoon (or well >> >> into the weekend for most of the world). >> >> >> >> >> > On the weekend before tax filings are due in the US! And a couple of >> > days >> > before Passover. >> >> and in the middle of Heartbleed..... > > > You might have had a point - if it had been ANY of those. Other than the > original claim of "Friday afternoon" it was none of those things. 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the last full week before the US tax filing deadline. 7-April: OpenSSL's *public* advisory (after a full week of private notifications, of which yahoo surely was one tech company in on the early notifications) 11-April: Yahoo discusses what needs to be done on their public tumblr account. -Jim P. From Matthew.Black at csulb.edu Mon Apr 14 22:09:14 2014 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 14 Apr 2014 22:09:14 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> Message-ID: IIRC, the message was sent via courier instead of cable or telephone to prevent interception. Did the military not even trust its own cryptographic methods? Or did they not think withdrawal of the Japanese ambassador was not very critical? matthew black california state university, long beach From: Donald Eastlake [mailto:d3e3e3 at gmail.com] Sent: Monday, April 14, 2014 8:28 AM To: Matthew Black Cc: William Herrin; nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Matthew, On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black > wrote: Also on this same idea, in his book "The Puzzle Palace," James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. I assume you refers to pages 36 through 39 of "The Puzzle Palace" which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says "we decided to do nothing" bears no relationship to what Bamford actually wrote. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com matthew black california state university, long beach -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Friday, April 11, 2014 2:06 PM To: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker > wrote: > Please go read up on some recent and less recent history before making > judgments on what would be unusually gutsy for that group of people. > > I'm not saying this has been happening but you will have to come up > with a better defense than "it seems unlikely to me personally". Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word "sensitive" does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill From scott at doc.net.au Mon Apr 14 22:21:40 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 15:21:40 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch wrote: > 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the > last full week before the US tax filing deadline. > The change was made on the previous Friday, so that date is largely irrelevant. 7-April: OpenSSL's *public* advisory (after a full week of private > notifications, of which yahoo surely was one tech company in on the > early notifications) > Given that many of their main services were vulnerable at the time of public disclosure, I think that's a very large assumption to make... If nothing else, I suspect the odds of it being known by the same people that made the DMARC decision/changes is low. Scott From scott at doc.net.au Mon Apr 14 22:32:13 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 15:32:13 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 3:21 PM, Scott Howard wrote: > > 7-April: OpenSSL's *public* advisory (after a full week of private >> notifications, of which yahoo surely was one tech company in on the >> early notifications) >> > > Given that many of their main services were vulnerable at the time of > public disclosure, I think that's a very large assumption to make... > Based on the article below it would appear that Yahoo did NOT know about Heartbleed at the time of public disclosure. http://www.smh.com.au/it-pro/security-it/heartbleed-disclosure-timeline-who-knew-what-and-when-20140414-zqurk.html Scott From johnl at iecc.com Mon Apr 14 22:36:00 2014 From: johnl at iecc.com (John Levine) Date: 14 Apr 2014 22:36:00 -0000 Subject: DMARC -> CERT? In-Reply-To: Message-ID: <20140414223600.32347.qmail@joyce.lan> In article you write: >On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard wrote: >> Whilst I don't agree with the way that Yahoo has done this (particularly >> around communication), > >how could they have communicated this better? how can we all learn from this? Well, telling people in advance that they were planning to do it rather than just dropping it on the world over the weekend would be a good start. R's, John From mfidelman at meetinghouse.net Mon Apr 14 22:43:46 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 14 Apr 2014 18:43:46 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: <534C64A2.7000301@meetinghouse.net> Jim Popovitch wrote: > On Mon, Apr 14, 2014 at 5:48 PM, Scott Howard wrote: >> On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch wrote: >>>>> They could have made the change not late on a Friday afternoon (or well >>>>> into the weekend for most of the world). >>>>> >>>>> >>>> On the weekend before tax filings are due in the US! And a couple of >>>> days >>>> before Passover. >>> and in the middle of Heartbleed..... >> >> You might have had a point - if it had been ANY of those. Other than the >> original claim of "Friday afternoon" it was none of those things. > > 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the > last full week before the US tax filing deadline. > > 7-April: OpenSSL's *public* advisory (after a full week of private > notifications, of which yahoo surely was one tech company in on the > early notifications) > > 11-April: Yahoo discusses what needs to be done on their public tumblr account. > 14-April: 1st night of Passover 15-April: Tax Filings due in the US -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jimpop at gmail.com Mon Apr 14 22:47:45 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 14 Apr 2014 18:47:45 -0400 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: On Mon, Apr 14, 2014 at 6:21 PM, Scott Howard wrote: > On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch wrote: >> >> 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the >> last full week before the US tax filing deadline. > > > The change was made on the previous Friday, so that date is largely > irrelevant. > >> 7-April: OpenSSL's *public* advisory (after a full week of private >> notifications, of which yahoo surely was one tech company in on the >> early notifications) > > > Given that many of their main services were vulnerable at the time of public > disclosure, I think that's a very large assumption to make... > > If nothing else, I suspect the odds of it being known by the same people > that made the DMARC decision/changes is low. I think you are right on that, but that doesn't change the fact that the sum of those things overburdened a lot of mailinglist operators. It is what it is, and the press has covered it and mailinglists are blocking/unsub'ing yahoo accounts in order to cope. -Jim P. From LarrySheldon at cox.net Mon Apr 14 23:02:12 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 14 Apr 2014 18:02:12 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> Message-ID: <534C68F4.305@cox.net> On 4/14/2014 9:38 AM, Matthew Black wrote: > Shouldn't a decent OS scrub RAM and disk sectors before allocating > them to processes, unless that process enters processor privileged > mode and sets a call flag? I recall digging through disk sectors on > RSTS/E to look for passwords and other interesting stuff over 30 > years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead in any but a classified system running up around "secret" or higher. (I know of a system in Silicon Valley where they would bring us core dumps to print because their system was down so hard. The dump program would take about a third of a box of fanfold and stack it, still blank, as I recall, in the stacker. Seems like the law of the land was "If you did not set the value, you can make no assumptions about it." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From randy at psg.com Mon Apr 14 23:06:13 2014 From: randy at psg.com (Randy Bush) Date: Tue, 15 Apr 2014 08:06:13 +0900 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> Message-ID: >> for those you can blame the vendor. this one is owned by the >> community. it falls on us to try to lower the probability of a next >> one by actively auditing source as our civic duty. > is that kind of like jury duty? if only it were more like literature, > which we could read for enjoyment. true. also, as someone whacked me, far too many networkers can not read code at all. randy From LarrySheldon at cox.net Mon Apr 14 23:11:32 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 14 Apr 2014 18:11:32 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> Message-ID: <534C6B24.8000802@cox.net> On 4/14/2014 2:59 PM, Patrick W. Gilmore wrote: > Or we can flame anyone who tries, then wonder why no one is trying. Amen. I was just thinking, after reading the umpteenth message here about spam, about the times in the 1990's that I was literally driven away because I was trying to get ahead of the spam problem (which was then a drop in the bucket as compared to now). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Mon Apr 14 23:12:48 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 14 Apr 2014 18:12:48 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <20140413165250.GI36211@burnout.tpb.net> <28860040-0300-4090-AB04-4F8532076791@ianai.net> Message-ID: <534C6B70.30806@cox.net> On 4/14/2014 3:05 PM, William Herrin wrote: > I thought vendors existed primarily as a place to hang the blame when > dealing with a manager or customer who just doesn't get it. Truth value very high. Humor value, less than none. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mike at mtcc.com Mon Apr 14 23:14:17 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 14 Apr 2014 16:14:17 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> Message-ID: <534C6BC9.7000404@mtcc.com> On 4/14/14 4:06 PM, Randy Bush wrote: >>> for those you can blame the vendor. this one is owned by the >>> community. it falls on us to try to lower the probability of a next >>> one by actively auditing source as our civic duty. >> is that kind of like jury duty? if only it were more like literature, >> which we could read for enjoyment. > true. also, as someone whacked me, far too many networkers can not read > code at all. > > It's much, much worse than that. I can still read code plenty fine, but bugs can be extremely obscure, and triply so with convoluted security code where people are actively going after you to find problems in most inventive ways. Openssl, etc, probably need to be treated more like Mars Landers than the typical github forkfest. Mike From schoen at loyalty.org Mon Apr 14 23:55:03 2014 From: schoen at loyalty.org (Seth David Schoen) Date: Mon, 14 Apr 2014 16:55:03 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C68F4.305@cox.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534C68F4.305@cox.net> Message-ID: <20140414235502.GE31388@frotz.zork.net> Larry Sheldon writes: > On 4/14/2014 9:38 AM, Matthew Black wrote: > >Shouldn't a decent OS scrub RAM and disk sectors before allocating > >them to processes, unless that process enters processor privileged > >mode and sets a call flag? I recall digging through disk sectors on > >RSTS/E to look for passwords and other interesting stuff over 30 > >years ago. > > I have been out of the loop for quite a while but my strongly held > belief is that such scrubbing would be an enormous (and intolerable) > overhead in any but a classified system running up around "secret" > or higher. (I know of a system in Silicon Valley where they would > bring us core dumps to print because their system was down so hard. In 2005, Stanford researchers "found that with careful design and implementation, secure deallocation can be accomplished with minimal overhead (roughly 1% for most workloads)". https://www.usenix.org/legacy/events/sec05/tech/full_papers/chow/chow.pdf This is for the RAM case rather than the disk case; maybe disk is worse because writes are more expensive. -- Seth David Schoen | No haiku patents http://www.loyalty.org/~schoen/ | means I've no incentive to FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150 | -- Don Marti From nangel at tetrasec.net Tue Apr 15 00:02:06 2014 From: nangel at tetrasec.net (Nathan Angelacos) Date: Mon, 14 Apr 2014 20:02:06 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C6BC9.7000404@mtcc.com> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <534C6BC9.7000404@mtcc.com> Message-ID: <534C76FE.4080109@tetrasec.net> On 04/14/2014 07:14 PM, Michael Thomas wrote: > > It's much, much worse than that. I can still read code plenty fine, but > bugs can be > extremely obscure, and triply so with convoluted security code where > people are > actively going after you to find problems in most inventive ways. > Openssl, etc, > probably need to be treated more like Mars Landers than the typical > github forkfest. > You mean this one? http://en.wikipedia.org/wiki/Mars_Climate_Orbiter ;) From johnl at iecc.com Tue Apr 15 00:50:07 2014 From: johnl at iecc.com (John Levine) Date: 15 Apr 2014 00:50:07 -0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C68F4.305@cox.net> Message-ID: <20140415005007.32870.qmail@joyce.lan> In article <534C68F4.305 at cox.net> you write: >On 4/14/2014 9:38 AM, Matthew Black wrote: >> Shouldn't a decent OS scrub RAM and disk sectors before allocating >> them to processes, unless that process enters processor privileged >> mode and sets a call flag? I recall digging through disk sectors on >> RSTS/E to look for passwords and other interesting stuff over 30 >> years ago. > >I have been out of the loop for quite a while but my strongly held >belief is that such scrubbing would be an enormous (and intolerable) >overhead ... It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. Pre-VM OS/360 may not have. R's, John From LarrySheldon at cox.net Tue Apr 15 01:00:12 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 14 Apr 2014 20:00:12 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: Message-ID: <534C849C.2090103@cox.net> On 4/14/2014 7:50 PM, John Levine wrote: > In article <534C68F4.305 at cox.net> you write: >> On 4/14/2014 9:38 AM, Matthew Black wrote: >>> Shouldn't a decent OS scrub RAM and disk sectors before allocating >>> them to processes, unless that process enters processor privileged >>> mode and sets a call flag? I recall digging through disk sectors on >>> RSTS/E to look for passwords and other interesting stuff over 30 >>> years ago. >> >> I have been out of the loop for quite a while but my strongly held >> belief is that such scrubbing would be an enormous (and intolerable) >> overhead ... > > It must be quite a while. Unix systems have routinely cleared the RAM > and disk allocated to programs since the earliest days. > > Pre-VM OS/360 may not have. HP-UX did not. Exec8 (OS1100) did not. What ever it was we ran on the 1401s and 360/30s (and 9300s) did not. We manually zeroed core on the 707xs but even then we knew it was a wasted 3 minutes because that was only done before the firs run of the day and might not happen again for several days (because each daily cycle took several days in some offices). MS-DOS and Windows (even still?) were notorious for not hurting "deleted" files. Is the heartbleed bug not proof positive that it is not being done today? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From mike at mtcc.com Tue Apr 15 01:09:31 2014 From: mike at mtcc.com (Michael Thomas) Date: Mon, 14 Apr 2014 18:09:31 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C76FE.4080109@tetrasec.net> References: <20140411193039.GA2724@gsp.org> <20140411215601.GW15800@hezmatt.org> <88tkk9991qggd0fpnkud433d3vbqkltqa3@4ax.com> <534AA308.5080509@mtcc.com> <534C6BC9.7000404@mtcc.com> <534C76FE.4080109@tetrasec.net> Message-ID: <534C86CB.7060505@mtcc.com> On 04/14/2014 05:02 PM, Nathan Angelacos wrote: > On 04/14/2014 07:14 PM, Michael Thomas wrote: >> >> It's much, much worse than that. I can still read code plenty fine, but >> bugs can be >> extremely obscure, and triply so with convoluted security code where >> people are >> actively going after you to find problems in most inventive ways. >> Openssl, etc, >> probably need to be treated more like Mars Landers than the typical >> github forkfest. >> > > You mean this one? http://en.wikipedia.org/wiki/Mars_Climate_Orbiter > > ;) > > That of course wasn't an orbiter, it was a splater. :) Mike From d3e3e3 at gmail.com Tue Apr 15 01:15:25 2014 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Mon, 14 Apr 2014 21:15:25 -0400 Subject: Pearl Harbor Message-ID: This is getting pretty far afield so I thought I should at least change the subject. There was no initial withdrawal of the Japanese ambassador - it was the Japanese withdrawing from negotiations with the USA over USA demands -- essentially Japan declaring that it had given up on finding compromise and would not accede to USA demands for Japanese troop withdrawals. There were two messages related to the negotiations from the Japanese government to their embassy in Washington. The first was so long and meandering, that it has to be broken into 14 parts for transmission. Only in the final and 14th part, which was transmitted more than 24 hours after the first 13 parts were sent, did it direct the withdrawal from negotiations. This was considered within the Japanese government as tantamount to a declaration of war and it was felt that the attack would be dishonorable if it was not communicated to the USA government before the attack. Thus, there was a second much shorter message that specifically directed that the withdrawal be communicated to the US Government, if possible to the US Secretary of State, no later than 1pm later that day, Sunday December 7th. (It was immediately apparent to the American's reading this message that 1pm in Washington was dawn in Hawaii and probably the time of an attack.) There were some other messages sent about the same time including one ordering the Japanese embassy to destroy all cipher machines and codes. There were delays in USA decryption and translation of all of these messages. Then there was delay in getting what was clearly a threat of war to someone in Washington high enough to take action. But those were accomplished more than two hours before the attack. (The Japanese embassy in Washington was by no means immune to bureaucracy and delay and did not read the messages in time to implement then before the attack.) The fastest way to communicate with the US military in Hawaii would have been analog scrambled telephone which was, correctly, considered to be insecure and inappropriate for information derived from a Purple intercept. Such scrambled calls had been unscrambled by other countries before. So, it was given to the War Department's message center, who said that it would be delivered directly within a half an hour, after they encrypted it and sent it by radio. However, atmospheric conditions blocked that method and the encrypted message was given by the message center to a commercial wire carrier to send. It arrived and was printed out at the carrier's office in Honolulu at 7:33am local time, 22 minutes before the first bomb fell. Although obviously encrypted, it was apparently not marked for any special urgent handling -- remember the sender had though it would arrive directly at the military authorities in Hawaii over an hour earlier. As a result, it was not actually delivered to those authorities until 2:40pm, after the attack was over, and not read until 20 minutes later after decryption. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com On Mon, Apr 14, 2014 at 6:09 PM, Matthew Black wrote: > > IIRC, the message was sent via courier instead of cable or telephone to prevent interception. Did the military not even trust its own cryptographic methods? Or did they not think withdrawal of the Japanese ambassador was not very critical? > > > > matthew black > > california state university, long beach > > > > From: Donald Eastlake [mailto:d3e3e3 at gmail.com] > Sent: Monday, April 14, 2014 8:28 AM > To: Matthew Black > Cc: William Herrin; nanog at nanog.org > > > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > > > > Matthew, > > > > On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black wrote: > > Also on this same idea, in his book "The Puzzle Palace," James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. > > > > I assume you refers to pages 36 through 39 of "The Puzzle Palace" which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says "we decided to do nothing" bears no relationship to what Bamford actually wrote. > > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3 at gmail.com > > > > matthew black > california state university, long beach > > > -----Original Message----- > > From: William Herrin [mailto:bill at herrin.us] > Sent: Friday, April 11, 2014 2:06 PM > To: nanog at nanog.org > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > > On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker wrote: > > Please go read up on some recent and less recent history before making > > judgments on what would be unusually gutsy for that group of people. > > > > I'm not saying this has been happening but you will have to come up > > with a better defense than "it seems unlikely to me personally". > > Let me know when someone finds the second shooter on the grassy knoll. > As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word "sensitive" does not do justice to the attention lavished on THEIR servers' security. > > In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. > > -Bill > > > From dougb at dougbarton.us Tue Apr 15 02:47:46 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 14 Apr 2014 19:47:46 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140415005007.32870.qmail@joyce.lan> References: <20140415005007.32870.qmail@joyce.lan> Message-ID: <534C9DD2.4060000@dougbarton.us> On 04/14/2014 05:50 PM, John Levine wrote: > In article <534C68F4.305 at cox.net> you write: >> On 4/14/2014 9:38 AM, Matthew Black wrote: >>> Shouldn't a decent OS scrub RAM and disk sectors before allocating >>> them to processes, unless that process enters processor privileged >>> mode and sets a call flag? I recall digging through disk sectors on >>> RSTS/E to look for passwords and other interesting stuff over 30 >>> years ago. >> >> I have been out of the loop for quite a while but my strongly held >> belief is that such scrubbing would be an enormous (and intolerable) >> overhead ... > > It must be quite a while. Unix systems have routinely cleared the RAM > and disk allocated to programs since the earliest days. When you say "clear the disk allocated to programs" what do you mean exactly? From bmanning at vacation.karoshi.com Tue Apr 15 03:17:30 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 14 Apr 2014 20:17:30 -0700 Subject: [[Infowarrior] - NSA blah blah blah blah.... In-Reply-To: <534C9DD2.4060000@dougbarton.us> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> Message-ID: <20140415031730.GA32509@vacation.karoshi.com> On Mon, Apr 14, 2014 at 07:47:46PM -0700, Doug Barton wrote: > >It must be quite a while. Unix systems have routinely cleared the RAM > >and disk allocated to programs since the earliest days. > > When you say "clear the disk allocated to programs" what do you mean > exactly? > "On a clear disc, you can seek forever" - with apologies to Barbara S. /bill From mpetach at netflight.com Tue Apr 15 03:55:38 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 14 Apr 2014 20:55:38 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C9DD2.4060000@dougbarton.us> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> Message-ID: On Mon, Apr 14, 2014 at 7:47 PM, Doug Barton wrote: > On 04/14/2014 05:50 PM, John Levine wrote: > >> In article <534C68F4.305 at cox.net> you write: >> >>> On 4/14/2014 9:38 AM, Matthew Black wrote: >>> >>>> Shouldn't a decent OS scrub RAM and disk sectors before allocating >>>> them to processes, unless that process enters processor privileged >>>> mode and sets a call flag? I recall digging through disk sectors on >>>> RSTS/E to look for passwords and other interesting stuff over 30 >>>> years ago. >>>> >>> >>> I have been out of the loop for quite a while but my strongly held >>> belief is that such scrubbing would be an enormous (and intolerable) >>> overhead ... >>> >> >> It must be quite a while. Unix systems have routinely cleared the RAM >> and disk allocated to programs since the earliest days. >> > > When you say "clear the disk allocated to programs" what do you mean > exactly? > Is that like "sudo rm -rf /bin" ? ;P Matt From scott at doc.net.au Tue Apr 15 06:54:38 2014 From: scott at doc.net.au (Scott Howard) Date: Mon, 14 Apr 2014 23:54:38 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C849C.2090103@cox.net> References: <534C849C.2090103@cox.net> Message-ID: On Mon, Apr 14, 2014 at 6:00 PM, Larry Sheldon wrote: > Is the heartbleed bug not proof positive that it is not being done today? > On the contrary. Heartbleed is "proof" that memory IS cleared before being assigned to a *process*. The data available via the vulnerability is limited to data from the process itself, not from any other process on the system. ie, Heartbleed can give up your SSL keys, but not your /etc/shadow file. If memory wasn't cleared before being allocated to a process, every multi-user systems would be vulnerable to Heartbleed-style vulnerability - just allocate some memory, and go reading. Eventually you'd get something containing /etc/shadow or other data you shouldn't be seeing. Within a process (ie, memory being re-allocated to the same process) there are ways to achieve the same thing, however as there's generally no security reasons for doing so, and as there is a non-trivial overhead, it's not done by default. Scott From Matthew.Black at csulb.edu Tue Apr 15 13:56:52 2014 From: Matthew.Black at csulb.edu (Matthew Black) Date: Tue, 15 Apr 2014 13:56:52 +0000 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534C9DD2.4060000@dougbarton.us> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> Message-ID: From: Doug Barton [mailto:dougb at dougbarton.us] > When you say "clear the disk allocated to programs" what do you mean > exactly? Seriously? When files are deleted, their sectors are simply released to the free space pool without erasing their contents. Allocation of disk sectors without clearing them gives users/programs access to file contents previously stored by other users/programs. As to why this is a problem, well, as they write in some math textbooks, the answer is trivial and left as an exercise to the reader. Well, usually trivial. matthew black california state university, long beach -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Monday, April 14, 2014 7:48 PM To: nanog at nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On 04/14/2014 05:50 PM, John Levine wrote: > In article <534C68F4.305 at cox.net> you write: >> On 4/14/2014 9:38 AM, Matthew Black wrote: >>> Shouldn't a decent OS scrub RAM and disk sectors before allocating >>> them to processes, unless that process enters processor privileged >>> mode and sets a call flag? I recall digging through disk sectors on >>> RSTS/E to look for passwords and other interesting stuff over 30 >>> years ago. >> >> I have been out of the loop for quite a while but my strongly held >> belief is that such scrubbing would be an enormous (and intolerable) >> overhead ... > > It must be quite a while. Unix systems have routinely cleared the RAM > and disk allocated to programs since the earliest days. When you say "clear the disk allocated to programs" what do you mean exactly? From glen.wiley at gmail.com Tue Apr 15 13:59:49 2014 From: glen.wiley at gmail.com (Glen Wiley) Date: Tue, 15 Apr 2014 09:59:49 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> Message-ID: <534D3B55.1050304@gmail.com> On 04/15/2014 09:56 AM, Matthew Black wrote: > From: Doug Barton [mailto:dougb at dougbarton.us] >> When you say "clear the disk allocated to programs" what do you mean >> exactly? > > Seriously? When files are deleted, their sectors are simply released to the free space pool without erasing their contents. Allocation of disk sectors without clearing them gives users/programs access to file contents previously stored by other users/programs. > > As to why this is a problem, well, as they write in some math textbooks, the answer is trivial and left as an exercise to the reader. Well, usually trivial. > > matthew black > california state university, long beach > > Bruce Schneier gave a plug for bleachbit - it does a reasonable job of trying to clean things up for you. > -----Original Message----- > From: Doug Barton [mailto:dougb at dougbarton.us] > Sent: Monday, April 14, 2014 7:48 PM > To: nanog at nanog.org > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > > On 04/14/2014 05:50 PM, John Levine wrote: >> In article <534C68F4.305 at cox.net> you write: >>> On 4/14/2014 9:38 AM, Matthew Black wrote: >>>> Shouldn't a decent OS scrub RAM and disk sectors before allocating >>>> them to processes, unless that process enters processor privileged >>>> mode and sets a call flag? I recall digging through disk sectors on >>>> RSTS/E to look for passwords and other interesting stuff over 30 >>>> years ago. >>> >>> I have been out of the loop for quite a while but my strongly held >>> belief is that such scrubbing would be an enormous (and intolerable) >>> overhead ... >> >> It must be quite a while. Unix systems have routinely cleared the RAM >> and disk allocated to programs since the earliest days. > > When you say "clear the disk allocated to programs" what do you mean > exactly? > > > > > -- Glen Wiley KK4SFV From scott at doc.net.au Tue Apr 15 16:02:46 2014 From: scott at doc.net.au (Scott Howard) Date: Tue, 15 Apr 2014 09:02:46 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> Message-ID: On Tue, Apr 15, 2014 at 6:56 AM, Matthew Black wrote: > Seriously? When files are deleted, their sectors are simply released to > the free space pool without erasing their contents. Allocation of disk > sectors without clearing them gives users/programs access to file contents > previously stored by other users/programs. > No worthwhile filesystem will allow you to read a block of disk that you haven't already written to. Once you've written to it, any existing data that was there is overwritten. The same isn't true for block-level access, but as a rule that requires admin access, and once you have that all bets are off... Scott From bzs at world.std.com Tue Apr 15 17:37:14 2014 From: bzs at world.std.com (Barry Shein) Date: Tue, 15 Apr 2014 13:37:14 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> Message-ID: <21325.28234.514877.225571@world.std.com> I can't cite chapter and verse but I seem to remember this zeroing problem was solved decades ago by just introducing a bit which said this chunk of memory or disk is new (to this process) and not zeroed but if there's any attempt to actually access it then read it back as if it were filled with zeros, or alternatively zero it. Sort of the complement of copy-on-write, you do it by lazy evaluation. For a newly allocated disk sector for example you don't have to actually zero it on the disk when allocated, you just return a block of zeros if a process tries to read it (i.e,. the kernel mediates.) Typically you allocate disk space (other than by writing blocks) by doing a seek forward, maybe write a block, and then seek backwards to access the virgin space in between. But anything in that virgin space can be marked in kernel memory as having to read back as zeros, no need to read anything at all from the actual disk. In fact, there's no need to actually allocate the block on disk which is why we have the notion of files with "holes", see for example the 'tar' man or info page for discussion of dealing with file holes when archiving. That is, whether to try to remember them as holes per se or to actually write all the zeros. It's important because it can create (it's a command line option) an actual TB tar file which has expanded that hole into blocks of zeros, a tar archive (e.g.) which might really be over a TB, or it might only be a few blocks, header info plus info that the rest is just to be treated as a TB hole. Or of course the tar archive could only appear to be a TB file but really be a big hole itself. This is not at all limited to tar, it's just some place it came up very explicitly for the reasons I described. Maybe that (lazy-evaluation of returning zeros) never got widely implemented but I thought it showed up around BSD 4.3 ca 1984. I think some of the models being presented her are somewhat oversimplified. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jarenangerbauer at gmail.com Wed Apr 16 09:27:41 2014 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Wed, 16 Apr 2014 03:27:41 -0600 Subject: DNS Issue with proofpoint.com Message-ID: All, Sending this out (to multiple lists -- apologies for the potential duplicates) in the hopes to proactively resolve any mail flow issues to / from Proofpoint customers. Earlier this evening, we had some DNS issues with our domain (proofpoint.com). We've resolved the main problem, however, due to old cached DNS information, the fall out now is that *many* (i.e. hundreds at this point) customers are are seeing major email delays. For any DNS operators, it would be much appreciated if you could flush your DNS servers for proofpoint.com. Among other providers, we are still seeing delays with mail flow to ATT Wireless and Verizon Wireless. Thanks in advance for your assistance on this. Jaren Angerbauer Deliverability & ISP Relations Manager Proofpoint From tglassey at earthlink.net Wed Apr 16 14:45:21 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Wed, 16 Apr 2014 07:45:21 -0700 Subject: DNS Issue with proofpoint.com In-Reply-To: References: Message-ID: <534E9781.7030603@earthlink.net> Wouldn't it make sense if we created a specific mail alias for requesting DNS flushes? This seems to happen statistically often enough it might be a valuable service to bundle under the NANOG umbrella. Todd On 4/16/2014 2:27 AM, Jaren Angerbauer wrote: > All, > > Sending this out (to multiple lists -- apologies for the potential > duplicates) in the hopes to proactively resolve any mail flow issues to / > from Proofpoint customers. > > Earlier this evening, we had some DNS issues with our domain (proofpoint.com). > We've resolved the main problem, however, due to old cached DNS > information, the fall out now is that *many* (i.e. hundreds at this point) > customers are are seeing major email delays. > > For any DNS operators, it would be much appreciated if you could flush your > DNS servers for proofpoint.com. > > Among other providers, we are still seeing delays with mail flow to ATT > Wireless and Verizon Wireless. > > Thanks in advance for your assistance on this. > > Jaren Angerbauer > Deliverability & ISP Relations Manager > Proofpoint > -- ------------- Personal Email - Disclaimers Apply From bill at herrin.us Wed Apr 16 14:49:24 2014 From: bill at herrin.us (William Herrin) Date: Wed, 16 Apr 2014 10:49:24 -0400 Subject: DNS Issue with proofpoint.com In-Reply-To: <534E9781.7030603@earthlink.net> References: <534E9781.7030603@earthlink.net> Message-ID: On Wed, Apr 16, 2014 at 10:45 AM, TGLASSEY wrote: > Wouldn't it make sense if we created a specific mail alias for requesting > DNS flushes? This seems to happen statistically often enough it might be a > valuable service to bundle under the NANOG umbrella. What would make sense is some sort of attribute on the DNS record which instructed servers not to cache it for so long that mistakes have a lasting impact. PEBKAC, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Wed Apr 16 15:04:36 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 16 Apr 2014 08:04:36 -0700 Subject: DNS Issue with proofpoint.com In-Reply-To: References: <534E9781.7030603@earthlink.net> Message-ID: <20140416150436.GA19155@vacation.karoshi.com> On Wed, Apr 16, 2014 at 10:49:24AM -0400, William Herrin wrote: > On Wed, Apr 16, 2014 at 10:45 AM, TGLASSEY wrote: > > Wouldn't it make sense if we created a specific mail alias for requesting > > DNS flushes? This seems to happen statistically often enough it might be a > > valuable service to bundle under the NANOG umbrella. > > What would make sense is some sort of attribute on the DNS record > which instructed servers not to cache it for so long that mistakes > have a lasting impact. > > PEBKAC, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 per RFC 1035: example.com. IN SOA ns.example.com. hostmaster.example.com. ( 2003080800 ; sn = serial number 172800 ; ref = refresh = 2d 900 ; ret = update retry = 15m 1209600 ; ex = expiry = 2w 3600 ; nx = nxdomain ttl = 1h ) From bill at herrin.us Wed Apr 16 15:41:19 2014 From: bill at herrin.us (William Herrin) Date: Wed, 16 Apr 2014 11:41:19 -0400 Subject: DNS Issue with proofpoint.com In-Reply-To: <20140416150436.GA19155@vacation.karoshi.com> References: <534E9781.7030603@earthlink.net> <20140416150436.GA19155@vacation.karoshi.com> Message-ID: On Wed, Apr 16, 2014 at 11:04 AM, wrote: > On Wed, Apr 16, 2014 at 10:49:24AM -0400, William Herrin wrote: >> On Wed, Apr 16, 2014 at 10:45 AM, TGLASSEY wrote: >> > Wouldn't it make sense if we created a specific mail alias for requesting >> > DNS flushes? This seems to happen statistically often enough it might be a >> > valuable service to bundle under the NANOG umbrella. >> >> What would make sense is some sort of attribute on the DNS record >> which instructed servers not to cache it for so long that mistakes >> have a lasting impact. > > per RFC 1035: You're kidding me! You mean they already make that? ;) -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Wed Apr 16 15:51:48 2014 From: bill at herrin.us (William Herrin) Date: Wed, 16 Apr 2014 11:51:48 -0400 Subject: badly behaved subsciber Message-ID: By the way, can we do something about this joker? I'm tired of receiving his notice every time I post to NANOG. Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu [140.247.35.201]) by magic.dirtside.com (8.14.3/) with ESMTP id s3GFgisL026781 for ; Wed, 16 Apr 2014 11:42:45 -0400 X-Really-To: Received: from hudce7.harvard.edu (hudce7.harvard.edu [140.247.198.27]) by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 96D581D839B for ; Wed, 16 Apr 2014 11:42:44 -0400 (EDT) Message-id: Date: Wed, 16 Apr 2014 11:42:33 -0400 Subject: NDN: Re: DNS Issue with proofpoint.com From: Post Office ----=_--0938c881.0938c880.cf745569 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry. Your message could not be delivered to: Rich Borroff (Mailbox or Conference is full.) -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From stevenbriggs at gmail.com Wed Apr 16 06:15:40 2014 From: stevenbriggs at gmail.com (Steven Briggs) Date: Wed, 16 Apr 2014 00:15:40 -0600 Subject: AT&T / Verizon DNS Flush? Message-ID: Hello, Not sure where to point this... I was wondering if anybody knows an inroad to reach AT&T and Verizon systems people to flush their caches for " proofpoint.com"? Any help is greatly appreciated! Steven Briggs ? From laszlo at heliacal.net Wed Apr 16 16:14:06 2014 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Wed, 16 Apr 2014 16:14:06 +0000 Subject: AT&T / Verizon DNS Flush? In-Reply-To: References: Message-ID: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> The generally accepted and scalable way to accomplish this is to advertise your freshness preferences using the SOA record of your domain. It would be pretty tricky to make this work with a swivel chair type system for every domain and host on the internet. You would have to contact every user and ask them to invalidate the caches, after asking their recursing server operator to do the same. -Laszlo On Apr 16, 2014, at 6:15 AM, Steven Briggs wrote: > Hello, > > Not sure where to point this... I was wondering if anybody knows an inroad > to reach AT&T and Verizon systems people to flush their caches for " > proofpoint.com"? > > Any help is greatly appreciated! > > Steven Briggs > ? From ak47 at gawul.net Wed Apr 16 16:17:41 2014 From: ak47 at gawul.net (Andrew Koch) Date: Wed, 16 Apr 2014 11:17:41 -0500 Subject: badly behaved subsciber In-Reply-To: References: Message-ID: <20140416161741.GC1577@bucket.gawul.net> On Wed, Apr 16, 2014 at 11:43AM -0500, William Herrin wrote: > By the way, can we do something about this joker? I'm tired of > receiving his notice every time I post to NANOG. Hi Bill and the NANOG mailing list, The NANOG Communications Committee, reachable at admins at nanog.org, is the appropriate place to bring mailing list concerns to. We may not always be aware of these types of troubles, so please do let us know. Best Regards, Andrew Koch NANOG Communications Committee > > Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu > [140.247.35.201]) by magic.dirtside.com (8.14.3/) with ESMTP id > s3GFgisL026781 for ; Wed, 16 Apr 2014 11:42:45 -0400 > X-Really-To: > Received: from hudce7.harvard.edu (hudce7.harvard.edu [140.247.198.27]) > by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 96D581D839B > for ; Wed, 16 Apr 2014 11:42:44 -0400 (EDT) > Message-id: > Date: Wed, 16 Apr 2014 11:42:33 -0400 > Subject: NDN: Re: DNS Issue with proofpoint.com > From: Post Office > > ----=_--0938c881.0938c880.cf745569 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Sorry. Your message could not be delivered to: > > Rich Borroff (Mailbox or Conference is full.) > > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From stevenbriggs at gmail.com Wed Apr 16 16:21:34 2014 From: stevenbriggs at gmail.com (Steven Briggs) Date: Wed, 16 Apr 2014 10:21:34 -0600 Subject: AT&T / Verizon DNS Flush? In-Reply-To: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> Message-ID: Yeah...I know. Unfortunately, the domain was "mishandled" by our registrar, who imposed their own TTLs on our zone, THEN turned it back over to us with a 48HR TTL. Which is very bad. I really appreciate all of your help, guys! ? On Wed, Apr 16, 2014 at 10:14 AM, Laszlo Hanyecz wrote: > The generally accepted and scalable way to accomplish this is to advertise > your freshness preferences using the SOA record of your domain. It would > be pretty tricky to make this work with a swivel chair type system for > every domain and host on the internet. You would have to contact every > user and ask them to invalidate the caches, after asking their recursing > server operator to do the same. > > -Laszlo > > > On Apr 16, 2014, at 6:15 AM, Steven Briggs wrote: > > > Hello, > > > > Not sure where to point this... I was wondering if anybody knows an > inroad > > to reach AT&T and Verizon systems people to flush their caches for " > > proofpoint.com"? > > > > Any help is greatly appreciated! > > > > Steven Briggs > > ? > > From hank at efes.iucc.ac.il Wed Apr 16 16:32:43 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 16 Apr 2014 19:32:43 +0300 Subject: AT&T / Verizon DNS Flush? In-Reply-To: References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> Message-ID: <5.1.1.6.2.20140416193130.01f61a80@efes.iucc.ac.il> At 10:21 16/04/2014 -0600, Steven Briggs wrote: Been discussed and nothing has been done: http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf https://www.dns-oarc.net/files/workshop-201005/DNS-Emergency-Alert-System.pdf Will keep happening until someone decides to act. -Hank >Yeah...I know. Unfortunately, the domain was "mishandled" by our >registrar, who imposed their own TTLs on our zone, THEN turned it back over >to us with a 48HR TTL. Which is very bad. > >I really appreciate all of your help, guys! >??? > > >On Wed, Apr 16, 2014 at 10:14 AM, Laszlo Hanyecz wrote: > > > The generally accepted and scalable way to accomplish this is to advertise > > your freshness preferences using the SOA record of your domain. It would > > be pretty tricky to make this work with a swivel chair type system for > > every domain and host on the internet. You would have to contact every > > user and ask them to invalidate the caches, after asking their recursing > > server operator to do the same. > > > > -Laszlo > > > > > > On Apr 16, 2014, at 6:15 AM, Steven Briggs wrote: > > > > > Hello, > > > > > > Not sure where to point this... I was wondering if anybody knows an > > inroad > > > to reach AT&T and Verizon systems people to flush their caches for " > > > proofpoint.com"? > > > > > > Any help is greatly appreciated! > > > > > > Steven Briggs > > > ??? > > > > From brandon.galbraith at gmail.com Wed Apr 16 16:34:01 2014 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 16 Apr 2014 11:34:01 -0500 Subject: DNS Issue with proofpoint.com In-Reply-To: References: <534E9781.7030603@earthlink.net> Message-ID: On Wed, Apr 16, 2014 at 9:49 AM, William Herrin wrote: > What would make sense is some sort of attribute on the DNS record > which instructed servers not to cache it for so long that mistakes > have a lasting impact. > Or a pub/sub method of sending an immediate invalidation request, similar to immediate CDN invalidations. Caching is nice, but mistakes happen. From blake at ispn.net Wed Apr 16 16:50:56 2014 From: blake at ispn.net (Blake Hudson) Date: Wed, 16 Apr 2014 11:50:56 -0500 Subject: AT&T / Verizon DNS Flush? In-Reply-To: <5.1.1.6.2.20140416193130.01f61a80@efes.iucc.ac.il> References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <5.1.1.6.2.20140416193130.01f61a80@efes.iucc.ac.il> Message-ID: <534EB4F0.4010702@ispn.net> Seems like the DNS protocol already addresses this issue with TTLs. The issue is that people sometimes regret the TTLs they chose (or their service provider chose for them). Any reason registrars commonly choose a 2 day TTL? Would they be just as well off with a 1 day TTL (my guess is that they would)? --Blake Hank Nussbacher wrote the following on 4/16/2014 11:32 AM: > At 10:21 16/04/2014 -0600, Steven Briggs wrote: > > Been discussed and nothing has been done: > http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf > https://www.dns-oarc.net/files/workshop-201005/DNS-Emergency-Alert-System.pdf > > > Will keep happening until someone decides to act. > > -Hank > > >> Yeah...I know. Unfortunately, the domain was "mishandled" by our >> registrar, who imposed their own TTLs on our zone, THEN turned it >> back over >> to us with a 48HR TTL. Which is very bad. >> >> I really appreciate all of your help, guys! >> ??? >> >> >> On Wed, Apr 16, 2014 at 10:14 AM, Laszlo Hanyecz >> wrote: >> >> > The generally accepted and scalable way to accomplish this is to >> advertise >> > your freshness preferences using the SOA record of your domain. It >> would >> > be pretty tricky to make this work with a swivel chair type system for >> > every domain and host on the internet. You would have to contact >> every >> > user and ask them to invalidate the caches, after asking their >> recursing >> > server operator to do the same. >> > >> > -Laszlo >> > >> > >> > On Apr 16, 2014, at 6:15 AM, Steven Briggs >> wrote: >> > >> > > Hello, >> > > >> > > Not sure where to point this... I was wondering if anybody knows an >> > inroad >> > > to reach AT&T and Verizon systems people to flush their caches for " >> > > proofpoint.com"? >> > > >> > > Any help is greatly appreciated! >> > > >> > > Steven Briggs >> > > ??? >> > >> > > > From Valdis.Kletnieks at vt.edu Wed Apr 16 16:56:59 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 16 Apr 2014 12:56:59 -0400 Subject: AT&T / Verizon DNS Flush? In-Reply-To: Your message of "Wed, 16 Apr 2014 10:21:34 -0600." References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> Message-ID: <13537.1397667419@turing-police.cc.vt.edu> On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said: > Yeah...I know. Unfortunately, the domain was "mishandled" by our > registrar, who imposed their own TTLs on our zone, THEN turned it back over > to us with a 48HR TTL. Which is very bad. That's almost calling for a name-and-shame. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From EWieling at nyigc.com Wed Apr 16 17:56:19 2014 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 16 Apr 2014 13:56:19 -0400 Subject: AT&T / Verizon DNS Flush? In-Reply-To: <13537.1397667419@turing-police.cc.vt.edu> References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <13537.1397667419@turing-police.cc.vt.edu> Message-ID: <616B4ECE1290D441AD56124FEBB03D0818EA32E86B@mailserver2007.nyigc.globe> Be grateful it is only 48 hours. Verzion (not Verizon Wireless) frequently has multi-week outages affecting multiple customers in the NYC area. One of the DS3s some customer circuits ride only works when there is no usage. Once there is usage massive errors occur. This has been going on for 6 - 8 weeks. Circuit usually comes back up when they test it. They admit there is a problem, they have no clue what it might be. All these customers are served out of the same CO. -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Wednesday, April 16, 2014 12:57 PM To: Steven Briggs Cc: nanog at nanog.org Subject: Re: AT&T / Verizon DNS Flush? On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said: > Yeah...I know. Unfortunately, the domain was "mishandled" by our > registrar, who imposed their own TTLs on our zone, THEN turned it back > over to us with a 48HR TTL. Which is very bad. That's almost calling for a name-and-shame. From mysidia at gmail.com Wed Apr 16 18:25:04 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 16 Apr 2014 13:25:04 -0500 Subject: AT&T / Verizon DNS Flush? In-Reply-To: <13537.1397667419@turing-police.cc.vt.edu> References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <13537.1397667419@turing-police.cc.vt.edu> Message-ID: On Wed, Apr 16, 2014 at 11:56 AM, wrote: > On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said: >> Yeah...I know. Unfortunately, the domain was "mishandled" by our >> registrar, who imposed their own TTLs on our zone, THEN turned it back over >> to us with a 48HR TTL. Which is very bad. > > That's almost calling for a name-and-shame. It's not hard to use WHOIS to lookup the registrar of each of the nameservers for proofpoint.com (ns1.proofpoint.us, ns3.proofpoint.us). Long TTLS are appropriate for a production zone, but in my estimation, it is improper for a registrar to impose or select by default a TTL longer than 1 hour, for a newly published or newly changed zone. The TTL can and should be reasonably low initially and automatically increased gradually over time, only after the zone has aged with no record changes and confidence is increased that the newly published zone is correct. -- -JH From bill at herrin.us Wed Apr 16 19:59:50 2014 From: bill at herrin.us (William Herrin) Date: Wed, 16 Apr 2014 15:59:50 -0400 Subject: AT&T / Verizon DNS Flush? In-Reply-To: References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <13537.1397667419@turing-police.cc.vt.edu> Message-ID: On Wed, Apr 16, 2014 at 2:25 PM, Jimmy Hess wrote: > It's not hard to use WHOIS to lookup the registrar of each of the > nameservers for proofpoint.com > (ns1.proofpoint.us, ns3.proofpoint.us). > > Long TTLS are appropriate for a production zone, but in my > estimation, it is improper for > a registrar to impose or select by default a TTL longer than 1 hour, > for a newly published or newly changed zone. > > The TTL can and should be reasonably low initially and > automatically increased gradually over time, > only after the zone has aged with no record changes and confidence is > increased > that the newly published zone is correct. There was a study on an unrelated topic a presented at a NANOG or ARIN meeting a few years back. I don't recall the exact details. The interesting bit was the analysis they did on DNS caching to see the impact from varying the TTL. I don't remember the exact numbers, but short TTLs exhibited only a small increase in query rate over long ones. There's really no driving need to set the TTL higher than 1 hour, ever, under any circumstances. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jason.iannone at gmail.com Wed Apr 16 21:34:13 2014 From: jason.iannone at gmail.com (Jason Iannone) Date: Wed, 16 Apr 2014 15:34:13 -0600 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <21325.28234.514877.225571@world.std.com> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> Message-ID: I can't cite chapter and verse but I seem to remember this zeroing problem was solved decades ago by just introducing a bit which said this chunk of memory or disk is new (to this process) and not zeroed but if there's any attempt to actually access it then read it back as if it were filled with zeros, or alternatively zero it. Isn't that a result of the language? Low level languages give that power to the author rather than assuming any responsibility. Hacker News had a fairly in-depth discussion regarding the nature of C with some convincing opinions as to why it's not exactly the right tool to build this sort of system with. The gist, forcing the author of a monster like OpenSSL to manage memory is a problem. On Tue, Apr 15, 2014 at 11:37 AM, Barry Shein wrote: > > I can't cite chapter and verse but I seem to remember this zeroing > problem was solved decades ago by just introducing a bit which said > this chunk of memory or disk is new (to this process) and not zeroed > but if there's any attempt to actually access it then read it back as > if it were filled with zeros, or alternatively zero it. > > Sort of the complement of copy-on-write, you do it by lazy evaluation. > > For a newly allocated disk sector for example you don't have to > actually zero it on the disk when allocated, you just return a block > of zeros if a process tries to read it (i.e,. the kernel mediates.) > > Typically you allocate disk space (other than by writing blocks) by > doing a seek forward, maybe write a block, and then seek backwards to > access the virgin space in between. > > But anything in that virgin space can be marked in kernel memory as > having to read back as zeros, no need to read anything at all from the > actual disk. > > In fact, there's no need to actually allocate the block on disk which > is why we have the notion of files with "holes", see for example the > 'tar' man or info page for discussion of dealing with file holes when > archiving. That is, whether to try to remember them as holes per se or > to actually write all the zeros. > > It's important because it can create (it's a command line option) an > actual TB tar file which has expanded that hole into blocks of zeros, > a tar archive (e.g.) which might really be over a TB, or it might only > be a few blocks, header info plus info that the rest is just to be > treated as a TB hole. Or of course the tar archive could only appear > to be a TB file but really be a big hole itself. > > This is not at all limited to tar, it's just some place it came up > very explicitly for the reasons I described. > > Maybe that (lazy-evaluation of returning zeros) never got widely > implemented but I thought it showed up around BSD 4.3 ca 1984. > > I think some of the models being presented her are somewhat > oversimplified. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > From LarrySheldon at cox.net Wed Apr 16 23:07:52 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 16 Apr 2014 18:07:52 -0500 Subject: badly behaved subsciber In-Reply-To: References: Message-ID: <534F0D48.80608@cox.net> On 4/16/2014 11:17 AM, Andrew Koch wrote: > On Wed, Apr 16, 2014 at 11:43AM -0500, William Herrin wrote: > >> By the way, can we do something about this joker? I'm tired of >> receiving his notice every time I post to NANOG. > > > Hi Bill and the NANOG mailing list, > > The NANOG Communications Committee, reachable at admins at nanog.org, is > the appropriate place to bring mailing list concerns to. We may not > always be aware of these types of troubles, so please do let us know. I sent notice to that address--not clear that it did any good. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Wed Apr 16 23:12:50 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 16 Apr 2014 18:12:50 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> Message-ID: <534F0E72.5000909@cox.net> On 4/16/2014 4:34 PM, Jason Iannone wrote: > I can't cite chapter and verse but I seem to remember this zeroing > problem was solved decades ago by just introducing a bit which said > this chunk of memory or disk is new (to this process) and not zeroed > but if there's any attempt to actually access it then read it back as > if it were filled with zeros, or alternatively zero it. > > Isn't that a result of the language? Low level languages give that > power to the author rather than assuming any responsibility. Hacker > News had a fairly in-depth discussion regarding the nature of C with > some convincing opinions as to why it's not exactly the right tool to > build this sort of system with. The gist, forcing the author of a > monster like OpenSSL to manage memory is a problem. I dropped out of the discussion because I couldn't get a foot-hold, but I would like to know this: If the hardware (as has been suggested) or the OS does any of this, how do diagnostic routine in or running under the OS work? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From john-nanog at peachfamily.net Wed Apr 16 17:05:28 2014 From: john-nanog at peachfamily.net (John Peach) Date: Wed, 16 Apr 2014 13:05:28 -0400 Subject: AT&T / Verizon DNS Flush? In-Reply-To: <13537.1397667419@turing-police.cc.vt.edu> References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <13537.1397667419@turing-police.cc.vt.edu> Message-ID: <20140416130528.1b7acd2e@jpeach-desktop.anbg.mssm.edu> Looks to be godaddy. No surprise then. On Wed, 16 Apr 2014 12:56:59 -0400 Valdis.Kletnieks at vt.edu wrote: > On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said: > > Yeah...I know. Unfortunately, the domain was "mishandled" by our > > registrar, who imposed their own TTLs on our zone, THEN turned it > > back over to us with a 48HR TTL. Which is very bad. > > That's almost calling for a name-and-shame. From randy at psg.com Thu Apr 17 00:12:13 2014 From: randy at psg.com (Randy Bush) Date: Thu, 17 Apr 2014 09:12:13 +0900 Subject: badly behaved subsciber In-Reply-To: <20140416161741.GC1577@bucket.gawul.net> References: <20140416161741.GC1577@bucket.gawul.net> Message-ID: > The NANOG Communications Committee, reachable at admins at nanog.org, is > the appropriate place to bring mailing list concerns to. dear god, please save me from an operational community becoming a hidebound bureaucrazy From scott at doc.net.au Thu Apr 17 00:14:09 2014 From: scott at doc.net.au (Scott Howard) Date: Wed, 16 Apr 2014 17:14:09 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534F0E72.5000909@cox.net> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> <534F0E72.5000909@cox.net> Message-ID: On Wed, Apr 16, 2014 at 4:12 PM, Larry Sheldon wrote: > If the hardware (as has been suggested) or the OS does any of this, how do > diagnostic routine in or running under the OS work? > The OS does it, when allocating memory to userland programs. For memory, before memory is allocated to a new process it is cleared. If the same block of memory is re-allocated to (or within) that process then it is generally NOT cleared. ie, if you request some memory within a process there's no guarantee that it'll be zeroed out (unless you specifically request it to be), but there is a guarantee that anything in the memory is something that your own process put there. For kernel-level code, this does NOT happen by default (again, depending on which exact functional you call). So within the kernel you can allocate a block of memory and end up with random user-land data it in - but if you think that's a problem then you probably don't understand where the kernel fits in within the bigger picture. (Hint: at a minimum, it can real any memory anywhere in the system) There is obviously a cost of clearing that memory, which is why it's normally only done when absolutely necessary (eg, allocating a new page to a userland process), but not when it's not (eg, allocating to the kernel) For disk, physical space normally isn't assigned by the filesystem until you actually write to a block. Writing obviously overwrites what was there previously, so reading it back only gives you your own data. If you read back an area of a file that you haven't yet written (presuming the filesystem supports it) then you've got what's called a "sparse" file, and as no block on disk has yet been allocated for that space yet the OS simply returns you a pile of zeros. Those zeros never actually existed on the disk, they are just a logical concept for any blocks that have not yet been written to. None of these controls stops someone with root access from accessing memory or disk - root generally has access to interfaces like /proc/mem and the raw disk devices, so can read anything. Scott From gdt at gdt.id.au Thu Apr 17 00:33:08 2014 From: gdt at gdt.id.au (Glen Turner) Date: Thu, 17 Apr 2014 10:03:08 +0930 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> Message-ID: <9E5AB9F0-CC61-4699-97FB-F5BFBAF79B5A@gdt.id.au> Jason Iannone wrote: > I can't cite chapter and verse but I seem to remember this zeroing > problem was solved decades ago by just introducing a bit which said > this chunk of memory or disk is new (to this process) and not zeroed > but if there's any attempt to actually access it then read it back as > if it were filled with zeros, or alternatively zero it. That's true of virtual memory pages which are new to the process. But that isn't what malloc() usually returns, otherwise all malloc()ed allocations would require a 4KB virtual memory page. Rather malloc() and free() in the C library manage a pool of allocations and when that pool empties more virtual memory is allocated by using the brk() system call to ask the operating system for a new 4KB page of virtual memory -- which the operating system does set to zero, using the hardware to (perhaps lazily) set the page to zero if such a hardware feature is available. As a result the memory returned by malloc() often isn't zeroed and may contain data previously used by the process. Therefore a process can leak information between a program and its use of libraries. Because there is no inter-process information leakage this isn't seen as a problem in the traditional Unix view of security. You may have differing views if your program is a daemon servicing a multitude of networked users. Thus the interest in alternative malloc() and free() implementations. -- Glen Turner From marka at isc.org Thu Apr 17 00:38:28 2014 From: marka at isc.org (Mark Andrews) Date: Thu, 17 Apr 2014 10:38:28 +1000 Subject: DNS Issue with proofpoint.com In-Reply-To: Your message of "Wed, 16 Apr 2014 11:34:01 -0500." References: <534E9781.7030603@earthlink.net> Message-ID: <20140417003828.EDEA513F542A@rock.dv.isc.org> In message , B randon Galbraith writes: > On Wed, Apr 16, 2014 at 9:49 AM, William Herrin wrote: > > > What would make sense is some sort of attribute on the DNS record > > which instructed servers not to cache it for so long that mistakes > > have a lasting impact. > > > > Or a pub/sub method of sending an immediate invalidation request, similar > to immediate CDN invalidations. > > Caching is nice, but mistakes happen. Which is why you should choose appropriate ttls. Also for CDN you are talking to 1 company which has administative control over the caches. For DNS you have highly distributed caches which are talking to millions of servers. There are nowhere near comparible in terms of management. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bzs at world.std.com Thu Apr 17 02:50:40 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 16 Apr 2014 22:50:40 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <9E5AB9F0-CC61-4699-97FB-F5BFBAF79B5A@gdt.id.au> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> <9E5AB9F0-CC61-4699-97FB-F5BFBAF79B5A@gdt.id.au> Message-ID: <21327.16768.946701.2078@world.std.com> On April 17, 2014 at 10:03 gdt at gdt.id.au (Glen Turner) wrote: > Jason Iannone wrote: > > I can't cite chapter and verse but I seem to remember this zeroing > > problem was solved decades ago by just introducing a bit which said > > this chunk of memory or disk is new (to this process) and not zeroed > > but if there's any attempt to actually access it then read it back as > > if it were filled with zeros, or alternatively zero it. Actually those were my words trying to describe kernel management of disk blocks, sparse files, etc, not user space. -b From bzs at world.std.com Thu Apr 17 03:01:33 2014 From: bzs at world.std.com (Barry Shein) Date: Wed, 16 Apr 2014 23:01:33 -0400 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> Message-ID: <21327.17421.768466.468971@world.std.com> On April 16, 2014 at 15:34 jason.iannone at gmail.com (Jason Iannone) wrote: > I can't cite chapter and verse but I seem to remember this zeroing > problem was solved decades ago by just introducing a bit which said > this chunk of memory or disk is new (to this process) and not zeroed > but if there's any attempt to actually access it then read it back as > if it were filled with zeros, or alternatively zero it. Those were my words. I was talking about kernel memory/disk management. And then Jason Iannone... > Isn't that a result of the language? Low level languages give that > power to the author rather than assuming any responsibility. Hacker > News had a fairly in-depth discussion regarding the nature of C with > some convincing opinions as to why it's not exactly the right tool to > build this sort of system with. The gist, forcing the author of a > monster like OpenSSL to manage memory is a problem. This is a potentially huge discussion with many dimensions. A library like openssl is intended to fit into a huge software ecosystem much of which is already written in C. Writing it in another language (other than perhaps C++) would require a cross-language API or similar (e.g., IPC) which introduces other issues. So, oftentimes you use a three-prong plug because you are faced with three-prong receptacles and rebuilding the entire building to a new standard just isn't practical even if you believe the result presents a potential shock hazard. And, if I may editorialize, there's a reason most of that ecosystem is built in C, it's not only legacy. Other languages have their own shortcomings, you can't just consider one aspect. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From nobody at snovc.com Thu Apr 17 04:19:18 2014 From: nobody at snovc.com (Private Sender) Date: Wed, 16 Apr 2014 21:19:18 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: <534F5646.4050805@snovc.com> On 04/14/2014 03:47 PM, Jim Popovitch wrote: > On Mon, Apr 14, 2014 at 6:21 PM, Scott Howard wrote: >> On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch wrote: >>> 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the >>> last full week before the US tax filing deadline. >> >> The change was made on the previous Friday, so that date is largely >> irrelevant. >> >>> 7-April: OpenSSL's *public* advisory (after a full week of private >>> notifications, of which yahoo surely was one tech company in on the >>> early notifications) >> >> Given that many of their main services were vulnerable at the time of public >> disclosure, I think that's a very large assumption to make... >> >> If nothing else, I suspect the odds of it being known by the same people >> that made the DMARC decision/changes is low. > I think you are right on that, but that doesn't change the fact that > the sum of those things overburdened a lot of mailinglist operators. > It is what it is, and the press has covered it and mailinglists are > blocking/unsub'ing yahoo accounts in order to cope. > > -Jim P. > I'm sorry but is there a fundamental misunderstanding of dmarc going on in this thread? Yahoo doesn't want you to be able to send "@yahoo.com" email from anything other than THEIR servers which contain the private key that corresponds to their DKIM implementation, and conversely dmarc. "p=reject" tells the receiving domain to reject the message if it isn't signed by the private key that corresponds with the public key that is in the dkim txt record for "yahoo.com" Isn't this the whole point of dmarc? Stop spammers from sending email with "@yahoo.com" that doesn't originate from a valid yahoo email server. Yahoo's implementation of dmarc is working as intended. Stealing someones password, and logging into their yahoo mail account and spamming isn't going to matter to dmarc. The mail originated from yahoo, and it was an authenticated user; the mail will be signed with the DKIM key, it will be accepted by the receiving domain (unless the email address is blacklisted by the receiving domain). There is no need to flame a company because they implemented a policy to ensure QoS to their customers. Either push your mail through their servers, or Just find somewhere else you can push your mailing lists through. Cheers From LarrySheldon at cox.net Thu Apr 17 04:29:32 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 16 Apr 2014 23:29:32 -0500 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> Message-ID: <534F58AC.404@cox.net> On 4/16/2014 11:19 PM, Private Sender wrote: Does that raise any alarms? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jimpop at gmail.com Thu Apr 17 04:38:26 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 17 Apr 2014 00:38:26 -0400 Subject: DMARC -> CERT? In-Reply-To: <534F58AC.404@cox.net> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F58AC.404@cox.net> Message-ID: On Thu, Apr 17, 2014 at 12:29 AM, Larry Sheldon wrote: > On 4/16/2014 11:19 PM, Private Sender wrote: > > Does that raise any alarms? Of course it does. http://whois.domaintools.com/snovc.com .... computerguy0001 at yahoo.com Bret Taylor .... -Jim P. From tglassey at earthlink.net Thu Apr 17 04:39:14 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Wed, 16 Apr 2014 21:39:14 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <21327.16768.946701.2078@world.std.com> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> <9E5AB9F0-CC61-4699-97FB-F5BFBAF79B5A@gdt.id.au> <21327.16768.946701.2078@world.std.com> Message-ID: <534F5AF2.3060303@earthlink.net> BAE did this cute poster on the attack model https://image-store.slidesharecdn.com/6f0027d2-c58c-11e3-af1f-12313d0148e5-original.jpeg?goback=%2Egde_1271127_member_5862330295302262788 On 4/16/2014 7:50 PM, Barry Shein wrote: > On April 17, 2014 at 10:03 gdt at gdt.id.au (Glen Turner) wrote: > > Jason Iannone wrote: > > > I can't cite chapter and verse but I seem to remember this zeroing > > > problem was solved decades ago by just introducing a bit which said > > > this chunk of memory or disk is new (to this process) and not zeroed > > > but if there's any attempt to actually access it then read it back as > > > if it were filled with zeros, or alternatively zero it. > > Actually those were my words trying to describe kernel management of > disk blocks, sparse files, etc, not user space. > > -b > > -- ------------- Personal Email - Disclaimers Apply From jimpop at gmail.com Thu Apr 17 04:40:11 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 17 Apr 2014 00:40:11 -0400 Subject: DMARC -> CERT? In-Reply-To: <534F5646.4050805@snovc.com> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F5646.4050805@snovc.com> Message-ID: On Thu, Apr 17, 2014 at 12:19 AM, Private Sender wrote: > On 04/14/2014 03:47 PM, Jim Popovitch wrote: > > On Mon, Apr 14, 2014 at 6:21 PM, Scott Howard wrote: > >> On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch > wrote: > >>> 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the > >>> last full week before the US tax filing deadline. > >> > >> The change was made on the previous Friday, so that date is largely > >> irrelevant. > >> > >>> 7-April: OpenSSL's *public* advisory (after a full week of private > >>> notifications, of which yahoo surely was one tech company in on the > >>> early notifications) > >> > >> Given that many of their main services were vulnerable at the time of > public > >> disclosure, I think that's a very large assumption to make... > >> > >> If nothing else, I suspect the odds of it being known by the same people > >> that made the DMARC decision/changes is low. > > I think you are right on that, but that doesn't change the fact that > > the sum of those things overburdened a lot of mailinglist operators. > > It is what it is, and the press has covered it and mailinglists are > > blocking/unsub'ing yahoo accounts in order to cope. > > > > -Jim P. > > > > I'm sorry but is there a fundamental misunderstanding of dmarc going on > in this thread? Yahoo doesn't want you to be able to send "@yahoo.com" > email from anything other than THEIR servers which contain the private > key that corresponds to their DKIM implementation, and conversely dmarc. > "p=reject" tells the receiving domain to reject the message if it isn't > signed by the private key that corresponds with the public key that is > in the dkim txt record for "yahoo.com" > > Isn't this the whole point of dmarc? Stop spammers from sending email > with "@yahoo.com" that doesn't originate from a valid yahoo email server. > Yes, but @yahoo.com is a bad example because it delivers user originated content. > Yahoo's implementation of dmarc is working as intended. > Are you also speaking for all yahoo uses when you declare that they should no longer be able to participate on mailinglists? > Stealing someones password, and logging into their yahoo mail account > and spamming isn't going to matter to dmarc. The mail originated from > yahoo, and it was an authenticated user; the mail will be signed with > the DKIM key, it will be accepted by the receiving domain (unless the > email address is blacklisted by the receiving domain). > But, but, but.... Yahoo implemented DMARC to supposedly stop Spam...(which ironically others have shown that a lot of spam originates from Yahoo servers, but I digress) > > There is no need to flame a company because they implemented a policy to > ensure QoS to their customers. Either push your mail through their > servers, or Just find somewhere else you can push your mailing lists > through. > > LOL QoS, really? QoS to me, a yahoo account holder, would be less inbound spam. -Jim P. From scott at doc.net.au Thu Apr 17 05:41:12 2014 From: scott at doc.net.au (Scott Howard) Date: Wed, 16 Apr 2014 22:41:12 -0700 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <534F5AF2.3060303@earthlink.net> References: <20140415005007.32870.qmail@joyce.lan> <534C9DD2.4060000@dougbarton.us> <21325.28234.514877.225571@world.std.com> <9E5AB9F0-CC61-4699-97FB-F5BFBAF79B5A@gdt.id.au> <21327.16768.946701.2078@world.std.com> <534F5AF2.3060303@earthlink.net> Message-ID: On Wed, Apr 16, 2014 at 9:39 PM, TGLASSEY wrote: > BAE did this cute poster on the attack model > > https://image-store.slidesharecdn.com/6f0027d2- > c58c-11e3-af1f-12313d0148e5-original.jpeg?goback=%2Egde_1271127_member_ > 5862330295302262788 I'm guessing accuracy probably wasn't their primary concern, but... The SSL handshake shown is wrong. Obviously it's over-simplified, and that's to be expected, but to claim that the client generates and session key and then "Encrypts it with the servers private key" and sends it over the wire is outright wrong. The session key in and of itself is *never* transmitted over the wire (encrypted or not). Exactly what is sent depends on the exact algorithm, but presuming they are describing RSA key exchange then it's the "pre-master secret", which is then used by both the client and the server (along with other information they have exchanged) to both independently generate the session key. Semantics perhaps, but... Scott From fernando at gont.com.ar Thu Apr 17 10:30:25 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 17 Apr 2014 07:30:25 -0300 Subject: Requirements for IPv6 Firewalls Message-ID: <534FAD41.8040604@gont.com.ar> Folks, A few months ago we published an IETF I-D with requirements for IPv6 firewalls. Based on the feedback received since then, we've published a revision of the I-D: If you have any feedback/thoughts, please do let us know (please CC , such that all co-authors receive your feedback). FWIW, this I-D is being discussed on the IETF opsec wg list (, ). Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dustin at rseng.net Thu Apr 17 12:35:01 2014 From: dustin at rseng.net (Dustin Jurman) Date: Thu, 17 Apr 2014 12:35:01 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FAD41.8040604@gont.com.ar> References: <534FAD41.8040604@gont.com.ar> Message-ID: Fernando, I did not see: - packets per second - Firewall Level - Hosts level - packet size information - Average for FW of all Network hosts - Negotiated Between Hosts I apologize if I missed it. Dustin Dustin Jurman CEO Rapid Systems Corporation 1211 N. West Shore Blvd. Suite 711 Tampa, FL 33607 Ph: 813-232-4887 Cell: 813-892-7006 http://www.rapidsys.com "Building Better Infrastructure"? -----Original Message----- From: Fernando Gont [mailto:fernando at gont.com.ar] Sent: Thursday, April 17, 2014 6:30 AM To: NANOG Subject: Requirements for IPv6 Firewalls Folks, A few months ago we published an IETF I-D with requirements for IPv6 firewalls. Based on the feedback received since then, we've published a revision of the I-D: If you have any feedback/thoughts, please do let us know (please CC , such that all co-authors receive your feedback). FWIW, this I-D is being discussed on the IETF opsec wg list (, ). Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rdobbins at arbor.net Thu Apr 17 12:51:17 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 17 Apr 2014 12:51:17 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> Message-ID: <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> On Apr 17, 2014, at 7:35 PM, Dustin Jurman wrote: > - packets per second > - Firewall Level > - Hosts level This is getting into QoS territory . . . > - packet size information Concur - packet-length. > - Average for FW of all Network hosts This isn't very operationally useful, IMHO. > - Negotiated Between Hosts I'm not sure what this means? But classifiers for everything in the IP, TCP, UDP, and ICMP headers, along with packet length, makes a lot of sense. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From nobody at snovc.com Thu Apr 17 13:13:47 2014 From: nobody at snovc.com (Private Sender) Date: Thu, 17 Apr 2014 06:13:47 -0700 Subject: DMARC -> CERT? In-Reply-To: References: <534C085B.802@meetinghouse.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F5646.4050805@snovc.com> Message-ID: <534FD38B.3020901@snovc.com> On Wed 16 Apr 2014 09:40:11 PM PDT, Jim Popovitch wrote: > On Thu, Apr 17, 2014 at 12:19 AM, Private Sender wrote: > >> On 04/14/2014 03:47 PM, Jim Popovitch wrote: >>> On Mon, Apr 14, 2014 at 6:21 PM, Scott Howard wrote: >>>> On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch >> wrote: >>>>> 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the >>>>> last full week before the US tax filing deadline. >>>> >>>> The change was made on the previous Friday, so that date is largely >>>> irrelevant. >>>> >>>>> 7-April: OpenSSL's *public* advisory (after a full week of private >>>>> notifications, of which yahoo surely was one tech company in on the >>>>> early notifications) >>>> >>>> Given that many of their main services were vulnerable at the time of >> public >>>> disclosure, I think that's a very large assumption to make... >>>> >>>> If nothing else, I suspect the odds of it being known by the same people >>>> that made the DMARC decision/changes is low. >>> I think you are right on that, but that doesn't change the fact that >>> the sum of those things overburdened a lot of mailinglist operators. >>> It is what it is, and the press has covered it and mailinglists are >>> blocking/unsub'ing yahoo accounts in order to cope. >>> >>> -Jim P. >>> >> >> I'm sorry but is there a fundamental misunderstanding of dmarc going on >> in this thread? Yahoo doesn't want you to be able to send "@yahoo.com" >> email from anything other than THEIR servers which contain the private >> key that corresponds to their DKIM implementation, and conversely dmarc. >> "p=reject" tells the receiving domain to reject the message if it isn't >> signed by the private key that corresponds with the public key that is >> in the dkim txt record for "yahoo.com" >> >> Isn't this the whole point of dmarc? Stop spammers from sending email >> with "@yahoo.com" that doesn't originate from a valid yahoo email server. >> > > Yes, but @yahoo.com is a bad example because it delivers user originated > content. > > >> Yahoo's implementation of dmarc is working as intended. >> > > Are you also speaking for all yahoo uses when you declare that they should > no longer be able to participate on mailinglists? > > >> Stealing someones password, and logging into their yahoo mail account >> and spamming isn't going to matter to dmarc. The mail originated from >> yahoo, and it was an authenticated user; the mail will be signed with >> the DKIM key, it will be accepted by the receiving domain (unless the >> email address is blacklisted by the receiving domain). >> > > But, but, but.... Yahoo implemented DMARC to supposedly stop Spam...(which > ironically others have shown that a lot of spam originates from Yahoo > servers, but I digress) > > >> >> There is no need to flame a company because they implemented a policy to >> ensure QoS to their customers. Either push your mail through their >> servers, or Just find somewhere else you can push your mailing lists >> through. >> >> > LOL QoS, really? QoS to me, a yahoo account holder, would be less inbound > spam. > > -Jim P. Well yeah inbound spam filtering would be nice. But they have refused to do anything about if for a better part of a decade. Sadly, they can't control mail originating from other domains (other than mail stating it's from yahoo). Is it possible yahoo doesn't understand how dmarc works? -- -- Bret Taylor From mike at mtcc.com Thu Apr 17 14:02:03 2014 From: mike at mtcc.com (Michael Thomas) Date: Thu, 17 Apr 2014 07:02:03 -0700 Subject: DMARC -> CERT? In-Reply-To: <534F5646.4050805@snovc.com> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F5646.4050805@snovc.com> Message-ID: <534FDEDB.6010209@mtcc.com> On 04/16/2014 09:19 PM, Private Sender wrote: > > I'm sorry but is there a fundamental misunderstanding of dmarc going on > in this thread? Yahoo doesn't want you to be able to send "@yahoo.com" > email from anything other than THEIR servers which contain the private > key that corresponds to their DKIM implementation, and conversely dmarc. > "p=reject" tells the receiving domain to reject the message if it isn't > signed by the private key that corresponds with the public key that is > in the dkim txt record for "yahoo.com" > > Isn't this the whole point of dmarc? Stop spammers from sending email > with "@yahoo.com" that doesn't originate from a valid yahoo email server. There fundamental misunderstanding is the assumption that DKIM signatures are never broken for valid uses of mail. They are. Would things be so simple. Mike From dnewman at networktest.com Thu Apr 17 15:26:03 2014 From: dnewman at networktest.com (David Newman) Date: Thu, 17 Apr 2014 08:26:03 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> References: <534FAD41.8040604@gont.com.ar> <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> Message-ID: <534FF28B.9090807@networktest.com> On 4/17/14, 5:51 AM, Dobbins, Roland wrote: >> - packets per second >> - Firewall Level >> - Hosts level > > This is getting into QoS territory . . . > >> - packet size information > > Concur - packet-length. The use of RFC 2544-esque metrics for firewall performance testing mostly benefits ill-informed or unscrupulous firewall marketeers, who send 1500-byte UDP packets and then brag about excellent performance. For firewalls handling TCP traffic, upper-layer traffic metrics such as HTTP object size, concurrent connection capacity, and connection setup rate are a lot more meaningful. The RFC 2544/2889 approach is OK if you only ever use your firewall as a router or a switch. The performance of a firewall used as an L2-L7 device should be measured with L2-L7 traffic. dn From Valdis.Kletnieks at vt.edu Thu Apr 17 15:34:35 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Apr 2014 11:34:35 -0400 Subject: DMARC -> CERT? In-Reply-To: Your message of "Wed, 16 Apr 2014 21:19:18 -0700." <534F5646.4050805@snovc.com> References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F5646.4050805@snovc.com> Message-ID: <57392.1397748875@turing-police.cc.vt.edu> On Wed, 16 Apr 2014 21:19:18 -0700, Private Sender said: > I'm sorry but is there a fundamental misunderstanding of dmarc going on > in this thread? Yes, apparently mostly on the part of Yahoo apologists... > There is no need to flame a company because they implemented a policy to > ensure QoS to their customers. Either push your mail through their > servers, or Just find somewhere else you can push your mailing lists > through. Is it me, or has every single Yahoo apologist in this thread insisted on this same misrepresentation of the situation? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From mike at mtcc.com Thu Apr 17 15:48:34 2014 From: mike at mtcc.com (Michael Thomas) Date: Thu, 17 Apr 2014 08:48:34 -0700 Subject: DMARC -> CERT? In-Reply-To: <57392.1397748875@turing-police.cc.vt.edu> References: <534C085B.802@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F5646.4050805@snovc.com> <57392.1397748875@turing-police.cc.vt.edu> Message-ID: <534FF7D2.4000108@mtcc.com> On 04/17/2014 08:34 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 16 Apr 2014 21:19:18 -0700, Private Sender said: > >> I'm sorry but is there a fundamental misunderstanding of dmarc going on >> in this thread? > Yes, apparently mostly on the part of Yahoo apologists... > >> There is no need to flame a company because they implemented a policy to >> ensure QoS to their customers. Either push your mail through their >> servers, or Just find somewhere else you can push your mailing lists >> through. > Is it me, or has every single Yahoo apologist in this thread insisted > on this same misrepresentation of the situation? > I'm rather interested to hear from the dmarc folks, one author of whom both works for y! and i've seen post to this list. I find this all rather incomprehensible; I wonder what Mark Delaney thinks about this. Mike From bill at herrin.us Thu Apr 17 15:51:50 2014 From: bill at herrin.us (William Herrin) Date: Thu, 17 Apr 2014 11:51:50 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FAD41.8040604@gont.com.ar> References: <534FAD41.8040604@gont.com.ar> Message-ID: On Thu, Apr 17, 2014 at 6:30 AM, Fernando Gont wrote: > A few months ago we published an IETF I-D with requirements for IPv6 > firewalls. > > Based on the feedback received since then, we've published a revision of > the I-D: > Hi Fernando, The feedback I would offer is this: You missed. By a lot. For one thing, many of the requirements are vague, like REQ APP-20. I've mitigated spam by allowing the operator to configure static packet filters for the bad guy's netblock, right? Requirements "must" be precise. Where you can't make it precise, drop it to a "should." And why is spam mitigation a firewall requirement in the first place? Traditionally that's handled by a specialty appliance, largely because it's such a moving target. Also, I note your draft is entitled "Requirements for IPv6 Enterprise Firewalls." Frankly, no "enterprise" firewall will be taken seriously without address-overloaded NAT. I realize that's a controversial statement in the IPv6 world but until you get past it you're basically wasting your time on a document which won't be useful to industry. Take it back to the drawing board. You're not there yet. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rdobbins at arbor.net Thu Apr 17 15:54:29 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 17 Apr 2014 15:54:29 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FF28B.9090807@networktest.com> References: <534FAD41.8040604@gont.com.ar> <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> <534FF28B.9090807@networktest.com> Message-ID: <8C058238-4A35-4EE5-9C16-A7255BD93FAE@arbor.net> On Apr 17, 2014, at 10:26 PM, David Newman wrote: > For firewalls handling TCP traffic, upper-layer traffic metrics such as HTTP object size, concurrent connection capacity, and connection setup rate are a lot more meaningful. I'm referring here to the ability to use packet-length as a classifier in a policy, not about bps/pps/tps/cps, et. al., apologies for being unclear. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mfidelman at meetinghouse.net Thu Apr 17 15:58:10 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 17 Apr 2014 11:58:10 -0400 Subject: DMARC -> CERT? In-Reply-To: <534FF7D2.4000108@mtcc.com> References: <534C085B.802@meetinghouse.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> <534C5208.8030306@meetinghouse.net> <534F5646.4050805@snovc.com> <57392.1397748875@turing-police.cc.vt.edu> <534FF7D2.4000108@mtcc.com> Message-ID: <534FFA12.1070505@meetinghouse.net> Michael Thomas wrote: > On 04/17/2014 08:34 AM, Valdis.Kletnieks at vt.edu wrote: >> On Wed, 16 Apr 2014 21:19:18 -0700, Private Sender said: >> >>> I'm sorry but is there a fundamental misunderstanding of dmarc going on >>> in this thread? >> Yes, apparently mostly on the part of Yahoo apologists... >> >>> There is no need to flame a company because they implemented a >>> policy to >>> ensure QoS to their customers. Either push your mail through their >>> servers, or Just find somewhere else you can push your mailing lists >>> through. >> Is it me, or has every single Yahoo apologist in this thread insisted >> on this same misrepresentation of the situation? >> > > I'm rather interested to hear from the dmarc folks, one author of whom > both > works for y! and i've seen post to this list. I find this all rather > incomprehensible; > I wonder what Mark Delaney thinks about this. Of course, they shouldn't send it from a @yahoo.com email address. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From fernando at gont.com.ar Thu Apr 17 15:59:53 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 17 Apr 2014 12:59:53 -0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FF28B.9090807@networktest.com> References: <534FAD41.8040604@gont.com.ar> <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> <534FF28B.9090807@networktest.com> Message-ID: <534FFA79.5020609@gont.com.ar> Hi, David, Thanks so much for your feedback! -- Comments in-line.... On 04/17/2014 12:26 PM, David Newman wrote: > > The use of RFC 2544-esque metrics for firewall performance testing > mostly benefits ill-informed or unscrupulous firewall marketeers, who > send 1500-byte UDP packets and then brag about excellent performance. > > For firewalls handling TCP traffic, upper-layer traffic metrics such as > HTTP object size, concurrent connection capacity, and connection setup > rate are a lot more meaningful. > > The RFC 2544/2889 approach is OK if you only ever use your firewall as a > router or a switch. The performance of a firewall used as an L2-L7 > device should be measured with L2-L7 traffic. Are you referring to this text from our document? > REQ GEN-5: > The firewall MUST include performance benchmarking documentation. > Such documentation MUST include information that reflects firewall > performance with respect to IPv6 packet, but also regarding how > IPv6 traffic may affect the performance of IPv4 traffic. The > aforementioned documentation MUST be, at the very least, > conditionally-compliant with both [RFC3511] and [RFC5180] (that > is, it MUST support all "MUST" requirements in such documents, and > may also support the "SHOULD" requirements in such documents). > > NOTE: This is for operators to spot be able to identify cases > where a devices may under-perform in the presence of IPv6 > traffic (see e.g. [FW-Benchmark]). XXX: This note may be > removed before publication if deemed appropriate. Because he RFCs we reference do require to make the measurements as you describe... Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Thu Apr 17 16:15:22 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 17 Apr 2014 13:15:22 -0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> Message-ID: <534FFE1A.8030100@gont.com.ar> Hi, William! Thanks so much for your feedback! One meta comment: this document is an Internet-Draft, not an RFC. It's just the second version (-01) we have published... so it's not meant to be there. The reason for posting the I-D here was so that I could get your input as early in the production of this document as possible. Comments in-line.... On 04/17/2014 12:51 PM, William Herrin wrote: > > The feedback I would offer is this: You missed. By a lot. > > For one thing, many of the requirements are vague, like REQ APP-20. > I've mitigated spam by allowing the operator to configure static > packet filters for the bad guy's netblock, right? Requirements "must" > be precise. Where you can't make it precise, drop it to a "should." Ok, will expand REQ APP-20... > And why is spam mitigation a firewall requirement in the first place? > Traditionally that's handled by a specialty appliance, largely because > it's such a moving target. > > Also, I note your draft is entitled "Requirements for IPv6 Enterprise > Firewalls." Frankly, no "enterprise" firewall will be taken seriously > without address-overloaded NAT. Just double-checking: you're referring to NAT where the same address is mployed for multiple hosts in the local network, and where the transport-protocol port needs to be re-written by the NAT device? (i.e., a NAT-PT) > I realize that's a controversial > statement in the IPv6 world but until you get past it you're basically > wasting your time on a document which won't be useful to industry. That's certainly controversial in the IPv6 world, but I have no problem with that. This sort of input (even much better if more people weigh) in is exactly what we're looking for. Such that when we apply the corresponding changes, and folks from other circles complain about them, I can point them to this sort of discussion. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From sander at steffann.nl Thu Apr 17 16:55:24 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 17 Apr 2014 18:55:24 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> Message-ID: <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Hi Bill, > Also, I note your draft is entitled "Requirements for IPv6 Enterprise > Firewalls." Frankly, no "enterprise" firewall will be taken seriously > without address-overloaded NAT. I realize that's a controversial > statement in the IPv6 world but until you get past it you're basically > wasting your time on a document which won't be useful to industry. I disagree. While there certainly will be organisations that want such a 'feature' it is certainly not a requirement for every (I hope most, but I might be optimistic) enterprises. Cheers, Sander From dustin at rseng.net Thu Apr 17 18:04:56 2014 From: dustin at rseng.net (Dustin Jurman) Date: Thu, 17 Apr 2014 18:04:56 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> References: <534FAD41.8040604@gont.com.ar> <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> Message-ID: Always interesting responding to a NANOG thread. - the approach is from an end user than service provider. The firewall operator would be more interested in identifying PPS for attacks / compromised hosts VS QOS but I supposed it could be used for QOS as well. (Not my intent) So today we have NAT'd firewalls that overload a particular interface, IMHO since properly implemented V6 should not use NAT I would want my FW vendor to allow me to see what's going on PPS wise via the dashboard function. Most V4 firewalls do this today at an interface level. - Average packet size for all hosts would allow operator to make a determination and set thresholds for new forms of attacks and exploits. (Thinking forward once applications take advantage of V6) - MTU Negotiated Between Hosts - Since this happens between endpoints in v6 this could be help identify tunnels in the network / changes in WAN topology.. Not like we haven't seen that before. While a change in flight should create a drop.. when the session reestablishes it could resize. Dustin jurman -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Thursday, April 17, 2014 8:51 AM To: NANOG Subject: Re: Requirements for IPv6 Firewalls On Apr 17, 2014, at 7:35 PM, Dustin Jurman wrote: > - packets per second > - Firewall Level > - Hosts level This is getting into QoS territory . . . > - packet size information Concur - packet-length. > - Average for FW of all Network hosts This isn't very operationally useful, IMHO. > - Negotiated Between Hosts I'm not sure what this means? But classifiers for everything in the IP, TCP, UDP, and ICMP headers, along with packet length, makes a lot of sense. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bill at herrin.us Thu Apr 17 18:05:39 2014 From: bill at herrin.us (William Herrin) Date: Thu, 17 Apr 2014 14:05:39 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FFE1A.8030100@gont.com.ar> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Thu, Apr 17, 2014 at 12:15 PM, Fernando Gont wrote: > Thanks so much for your feedback! One meta comment: this document is an > Internet-Draft, not an RFC. It's just the second version (-01) we have > published... so it's not meant to be there. Hi Fernando, I apologize; my tone was out of line. > On 04/17/2014 12:51 PM, William Herrin wrote: >> Also, I note your draft is entitled "Requirements for IPv6 Enterprise >> Firewalls." Frankly, no "enterprise" firewall will be taken seriously >> without address-overloaded NAT. > > Just double-checking: you're referring to NAT where the same address is > mployed for multiple hosts in the local network, and where the > transport-protocol port needs to be re-written by the NAT device? > (i.e., a NAT-PT) Correct. The "other" NAT, the one described in RFC 1631, is rather unloved. >> I realize that's a controversial >> statement in the IPv6 world but until you get past it you're basically >> wasting your time on a document which won't be useful to industry. > > That's certainly controversial in the IPv6 world, but I have no problem > with that. This sort of input (even much better if more people weigh) in > is exactly what we're looking for. Such that when we apply the > corresponding changes, and folks from other circles complain about them, > I can point them to this sort of discussion. Here's the drill: From an enterprise security perspective, deploying IPv6 is high risk. I have to re-implement every rule I set on my IPv4 addresses all over again with my IPv6 addresses and hope I don't screw it up in a way that lets an adversary wander right in. That risk is compounded exponentially if the _initial_ deployment can't follow an identical security posture to the IPv4 system. Without availability of the kind of NAT present in the IPv4 deployment, I have a problem whose solution is: sorry network team, return when the technology is mature. There's a fair argument to be made which says that kind of NAT is unhealthy. If its proponents are correct, they'll win that argument later on with NAT-incompatible technology that enterprises want. After all, enterprise security folk didn't want the Internet in the corporate network at all, but having a web browser on every desk is just too darn useful. Where they won't win that argument is in the stretch of maximum risk for the enterprise security folk. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From eugen at imacandi.net Thu Apr 17 18:32:02 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 17 Apr 2014 21:32:02 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Thu, Apr 17, 2014 at 9:05 PM, William Herrin wrote: > > Here's the drill: From an enterprise security perspective, deploying > IPv6 is high risk. I have to re-implement every rule I set on my IPv4 > addresses all over again with my IPv6 addresses and hope I don't screw > it up in a way that lets an adversary wander right in. That risk is > compounded exponentially if the _initial_ deployment can't follow an > identical security posture to the IPv4 system. Without availability of > the kind of NAT present in the IPv4 deployment, I have a problem whose > solution is: sorry network team, return when the technology is mature. > > It's a bigger risk to think that NAT somehow magically protects you against stuff on the Internet. Also, if your problem is that someone can screw up firewalls rules, then you have bigger issue in your organization than IPv6. There's a fair argument to be made which says that kind of NAT is > unhealthy. If its proponents are correct, they'll win that argument > later on with NAT-incompatible technology that enterprises want. After > all, enterprise security folk didn't want the Internet in the > corporate network at all, but having a web browser on every desk is > just too darn useful. Where they won't win that argument is in the > stretch of maximum risk for the enterprise security folk. > > Any technology has associated risks, it's a matter of how you reduce/mitigate them. This paranoia thingie about IPv6 is getting a bit old. Just because you don't (seem to) understand how it works, it doesn't mean no one else should use it. Eugeniu From cgrundemann at gmail.com Thu Apr 17 18:50:17 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 17 Apr 2014 12:50:17 -0600 Subject: Call for Presenters: The Future of the Internet 2014: Defining Software Defined Networks Message-ID: Hail NANOG, The Future of the Internet 2014: Defining Software Defined Networks call for presenters is now open! The Future of the Internet 2014 (TFI2014) will be held in Denver, Colorado on Friday, 22 August, 2014. At this year's event, the Colorado Chapter of the Internet Society (CO ISOC) is bringing together experts and professionals from across the globe to discuss SDN, NfV, open networking, and all things related to *network programability*; the ability for networked applications to more directly interact with network elements. Whether you call it *Software Defined Networking*, Software Driven Networks, Open Source Networking, Cloud Routing, Network Virtualization, or something else; the exciting part is extrapolating this "SDN" trend into the future as we make these programs and languages more fully featured and more standardized. Come extrapolate with us! The format for this event will be a bit different than your typical networking conference. While we intend to have several standard lecture spots, and a panel or two as well, the real focus is on conversation and debate. The idea is to fill the room with a mix of experts and people who want to learn more and get everyone thinking, and talking, about what this all means. We're not hosting yet-another-conference, instead we are setting up a breeding ground for new ideas. Because of that, we are issuing this call for presenters, rather than papers or presentations. Note we however, that all materials ultimately presented must be free of product pitches, marketing jargon, and really anything other than solid technical content. If you are interested in being a presenter at TFI2014, please send the following information to chair at coisoc.org by 30 May 2014: Full name Preferred email address Short (<1 page) biography Links to relevant online profiles or websites A short (<1000 words) response to one (or more) of the following questions: - What is SDN? - Why are you excited about SDN? - How does the network of the future differ from today's? We expect presenter spots to fill quickly and encourage you to respond as soon as possible. All materials provided may be made public should you be selected as a presenter for TFI2014. Connect with TFI2014 on Facebook: *https://www.facebook.com/events/175863782622579 * Register for TFI2014 now (early bird pricing ends 1 May): *http://is.gd/futureinternet2014 * I hope to see you all in Denver this August! Cheers, ~Chris Founding Chair, CO ISOC http://www.coisoc.org -- @ChrisGrundemann http://chrisgrundemann.com From bill at herrin.us Thu Apr 17 18:50:01 2014 From: bill at herrin.us (William Herrin) Date: Thu, 17 Apr 2014 14:50:01 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Thu, Apr 17, 2014 at 2:32 PM, Eugeniu Patrascu wrote: > It's a bigger risk to think that NAT somehow magically protects you against > stuff on the Internet. You are entitled to your opinion and you are entitled to run your network in accordance with your opinion. To vendors who would sell me product, I would respectfully suggest that attempts to forcefully educate me as to what I *should want* offers neither a short nor particularly successful path to closing a sale. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Thu Apr 17 20:04:59 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Apr 2014 16:04:59 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: Your message of "Thu, 17 Apr 2014 14:50:01 -0400." References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: <13891.1397765099@turing-police.cc.vt.edu> On Thu, 17 Apr 2014 14:50:01 -0400, William Herrin said: > To vendors who would sell me product, I would respectfully suggest > that attempts to forcefully educate me as to what I *should want* > offers neither a short nor particularly successful path to closing a > sale. Which is why you reject vendors that forcefully cram IP down your throat and insist on X.25 support as well, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tmorizot at gmail.com Thu Apr 17 20:20:44 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Thu, 17 Apr 2014 15:20:44 -0500 Subject: Requirements for IPv6 Firewalls In-Reply-To: <13891.1397765099@turing-police.cc.vt.edu> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <13891.1397765099@turing-police.cc.vt.edu> Message-ID: On Apr 17, 2014 3:07 PM, wrote: > > On Thu, 17 Apr 2014 14:50:01 -0400, William Herrin said: > > > To vendors who would sell me product, I would respectfully suggest > > that attempts to forcefully educate me as to what I *should want* > > offers neither a short nor particularly successful path to closing a > > sale. > > Which is why you reject vendors that forcefully cram IP down your throat > and insist on X.25 support as well, right? And speaking as the IPv6 transition lead at a large enterprise who has already deployed IPv6 in our Internet connection points (including firewalls) and made significant internal deployment progress, we would have rejected out of hand any firewall vendor who tried to sell us some proprietary, non-standard, IPv6 'NAT66' implementation. By its nature, it would have lacked any meaningful comparative benchmarks, objective tests, or any way to ensure a proper or secure implementation. At the IP level, we want our perimeter products to conform to the standards. Scott From bill at herrin.us Thu Apr 17 20:24:21 2014 From: bill at herrin.us (William Herrin) Date: Thu, 17 Apr 2014 16:24:21 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <13891.1397765099@turing-police.cc.vt.edu> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <13891.1397765099@turing-police.cc.vt.edu> Message-ID: On Thu, Apr 17, 2014 at 4:04 PM, wrote: > On Thu, 17 Apr 2014 14:50:01 -0400, William Herrin said: > >> To vendors who would sell me product, I would respectfully suggest >> that attempts to forcefully educate me as to what I *should want* >> offers neither a short nor particularly successful path to closing a >> sale. > > Which is why you reject vendors that forcefully cram IP down your throat > and insist on X.25 support as well, right? I've said my piece. Belittle it to your detriment. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From george.herbert at gmail.com Thu Apr 17 20:45:59 2014 From: george.herbert at gmail.com (George Herbert) Date: Thu, 17 Apr 2014 13:45:59 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Thu, Apr 17, 2014 at 11:32 AM, Eugeniu Patrascu wrote: > ... > It's a bigger risk to think that NAT somehow magically protects you against > stuff on the Internet. > Also, if your problem is that someone can screw up firewalls rules, then > you have bigger issue in your organization than IPv6. > There's a fair argument to be made which says that kind of NAT is > > unhealthy. If its proponents are correct, they'll win that argument > > later on with NAT-incompatible technology that enterprises want. After > > all, enterprise security folk didn't want the Internet in the > > corporate network at all, but having a web browser on every desk is > > just too darn useful. Where they won't win that argument is in the > > stretch of maximum risk for the enterprise security folk. > > > > > Any technology has associated risks, it's a matter of how you > reduce/mitigate them. > This paranoia thingie about IPv6 is getting a bit old. > Just because you don't (seem to) understand how it works, it doesn't mean > no one else should use it. You are missing the point. Granted, anyone who is IPv6 aware doing a green-field enterprise firewall design today should probably choose another way than NAT. What you are failing is that "redesign firewall rules and approach from scratch along with the IPv6 implementation" usually is not the chosen path, versus "re-implement the same v4 firewall rules and technologies in IPv6 for the IPv6 implementation", because all the IPv6 aware net admins are having too much to do dealing with all the other conversion issues, vendor readiness all across the stack, etc. Variations on this theme are part of why it's 2014 and IPv6 hasn't already taken over the world. The more rabid IPv6 proponents have in fact shot the transition in the legs repeatedly, and those of us who have been on the front lines would like you all to please shut up and get out of the way so we can actually finish effecting v6 deployment and move on to mopping up things like NAT later. This is why listening to operators is important. -- -george william herbert george.herbert at gmail.com From rdobbins at arbor.net Thu Apr 17 21:00:54 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 17 Apr 2014 21:00:54 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <4FC140D7-7464-4BDA-9562-A79A37F1458F@arbor.net> Message-ID: <7FBB6199-5C81-4166-AB70-8198D1A3F2C1@arbor.net> On Apr 18, 2014, at 1:04 AM, Dustin Jurman wrote: > - the approach is from an end user than service provider. The firewall operator would be more interested in identifying PPS for attacks / compromised hosts VS QOS but I supposed it could be used for QOS as well. (Not my intent) So today we have NAT'd firewalls that overload a particular interface, IMHO since properly implemented V6 should not use NAT I would want my FW vendor to allow me to see what's going on PPS wise via the dashboard function. Most V4 firewalls do this today at an interface level. This is a telemetry function (separately, I noted IPFIX functionality should be included). > - Average packet size for all hosts would allow operator to make a determination and set thresholds for new forms of attacks and exploits. (Thinking forward once applications take advantage of V6) Again, this is a telemetry function, not a policy function. > - MTU Negotiated Between Hosts - Since this happens between endpoints in v6 this could be help identify tunnels in the network / changes in WAN topology.. Not like we haven't seen that before. While a change in flight should create a drop.. when the session reestablishes it could resize. Yet again, a telemetry function. The MTU negotiation itself is irrelevant; the resultant packet-size is relevant, from a classification point of view. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From matthew at matthew.at Thu Apr 17 21:48:08 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 17 Apr 2014 14:48:08 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: <53504C18.7050406@matthew.at> On 4/17/2014 1:45 PM, George Herbert wrote: > This is why listening to operators is important. Why start now? After all, most of the useful input operators could have provided would have been much more useful at the beginning. Matthew Kaufman From marka at isc.org Thu Apr 17 22:38:13 2014 From: marka at isc.org (Mark Andrews) Date: Fri, 18 Apr 2014 08:38:13 +1000 Subject: Requirements for IPv6 Firewalls In-Reply-To: Your message of "Thu, 17 Apr 2014 14:48:08 -0700." <53504C18.7050406@matthew.at> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53504C18.7050406@matthew.at> Message-ID: <20140417223814.0A90E1412FC3@rock.dv.isc.org> In message <53504C18.7050406 at matthew.at>, Matthew Kaufman writes: > On 4/17/2014 1:45 PM, George Herbert wrote: > > This is why listening to operators is important. > > Why start now? After all, most of the useful input operators could have > provided would have been much more useful at the beginning. > > Matthew Kaufman NAT from a firewall perspective is "default deny in". As far as I can tell no one is arguing that a firewall should not support that. Now mangling the addresses and ports is not a firewall's job. Its never has been a firewall's job. That is what a NAT box does. Now sometimes a NAT and Firewall are implemented in the same hardware and people fail to make the distinction. As for doing the same as v4 in a firewall for v6, only a idiot would do that, as it will often break IPv6. There are rules, often deployed in v4, that are mostly harmless to IPv4 but will totally break IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fernando at gont.com.ar Thu Apr 17 22:38:24 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Thu, 17 Apr 2014 19:38:24 -0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: <53504C18.7050406@matthew.at> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53504C18.7050406@matthew.at> Message-ID: <535057E0.3090602@gont.com.ar> On 04/17/2014 06:48 PM, Matthew Kaufman wrote: > On 4/17/2014 1:45 PM, George Herbert wrote: >> This is why listening to operators is important. > > Why start now? After all, most of the useful input operators could have > provided would have been much more useful at the beginning. I cannot speak for that, unfortunately. But I can tell you that the reason for which we posted a note on this list regarding our I-D is because your feedback does matter to us (us == at least the co-authors of this document) Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From bross at pobox.com Thu Apr 17 23:20:53 2014 From: bross at pobox.com (Brandon Ross) Date: Thu, 17 Apr 2014 19:20:53 -0400 (EDT) Subject: Requirements for IPv6 Firewalls In-Reply-To: <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: On Thu, 17 Apr 2014, Sander Steffann wrote: >> Also, I note your draft is entitled "Requirements for IPv6 Enterprise >> Firewalls." Frankly, no "enterprise" firewall will be taken seriously >> without address-overloaded NAT. I realize that's a controversial >> statement in the IPv6 world but until you get past it you're basically >> wasting your time on a document which won't be useful to industry. > > I disagree. While there certainly will be organisations that want such a > 'feature' it is certainly not a requirement for every (I hope most, but > I might be optimistic) enterprises. And I not only agree with Sander, but would also argue for a definitive statement in a document like this SPECIFICALLY to help educate the enterprise networking community on how to implement a secure border for IPv6 without the need for NAT. Having a document to point at that has been blessed by the IETF/community is key to helping recover the end-to-end principle. Such a document may or may not be totally in scope for a "firewall" document, but should talk about concepts like default-deny inbound traffic, stateful inspection and the use of address space that is not announced to the Internet and/or is completely blocked at borders for all traffic. Heck, we could even make it less specific to IPv6 and create a document that describes these concepts and show how NAT is not necessary nor wise for IPv4, either. (Yes, yes, other than address conservation.) -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From matthew at matthew.at Fri Apr 18 00:51:03 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 17 Apr 2014 17:51:03 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: While you're at it, the document can explain to admins who have been burned, often more than once, by the pain of re-numbering internal services at static addresses how IPv6 without NAT will magically solve this problem. Matthew Kaufman (Sent from my iPhone) > On Apr 17, 2014, at 4:20 PM, Brandon Ross wrote: > > On Thu, 17 Apr 2014, Sander Steffann wrote: > >>> Also, I note your draft is entitled "Requirements for IPv6 Enterprise >>> Firewalls." Frankly, no "enterprise" firewall will be taken seriously >>> without address-overloaded NAT. I realize that's a controversial >>> statement in the IPv6 world but until you get past it you're basically >>> wasting your time on a document which won't be useful to industry. >> >> I disagree. While there certainly will be organisations that want such a 'feature' it is certainly not a requirement for every (I hope most, but I might be optimistic) enterprises. > > And I not only agree with Sander, but would also argue for a definitive statement in a document like this SPECIFICALLY to help educate the enterprise networking community on how to implement a secure border for IPv6 without the need for NAT. Having a document to point at that has been blessed by the IETF/community is key to helping recover the end-to-end principle. Such a document may or may not be totally in scope for a "firewall" document, but should talk about concepts like default-deny inbound traffic, stateful inspection and the use of address space that is not announced to the Internet and/or is completely blocked at borders for all traffic. > > Heck, we could even make it less specific to IPv6 and create a document that describes these concepts and show how NAT is not necessary nor wise for IPv4, either. (Yes, yes, other than address conservation.) > > -- > Brandon Ross Yahoo & AIM: BrandonNRoss > +1-404-635-6667 ICQ: 2269442 > Skype: brandonross > Schedule a meeting: http://www.doodle.com/bross > From tmorizot at gmail.com Fri Apr 18 02:05:17 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Thu, 17 Apr 2014 21:05:17 -0500 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: On Apr 17, 2014 7:52 PM, "Matthew Kaufman" wrote: > > While you're at it, the document can explain to admins who have been burned, often more than once, by the pain of re-numbering internal services at static addresses how IPv6 without NAT will magically solve this problem. If you're worried about that issue, either get your own end user assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix translation) at the perimeter. That's not even a hard question. From mvoity at uvm.edu Fri Apr 18 02:28:03 2014 From: mvoity at uvm.edu (Michael T. Voity) Date: Thu, 17 Apr 2014 22:28:03 -0400 Subject: Thank you Comcast In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: <53508DB3.5000808@uvm.edu> To the Comcast v6 Team, Thank you for enabling my CMTS for v6 in Colchester, VT Works great! Thanks, -Mike Michael T. Voity Network Engineer University of Vermont From bross at pobox.com Fri Apr 18 02:32:18 2014 From: bross at pobox.com (Brandon Ross) Date: Thu, 17 Apr 2014 22:32:18 -0400 (EDT) Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: On Thu, 17 Apr 2014, Timothy Morizot wrote: > On Apr 17, 2014 7:52 PM, "Matthew Kaufman" wrote: >> >> While you're at it, the document can explain to admins who have been > burned, often more than once, by the pain of re-numbering internal services > at static addresses how IPv6 without NAT will magically solve this problem. > > If you're worried about that issue, either get your own end user > assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix > translation) at the perimeter. That's not even a hard question. Until you responded, Timothy, I didn't realize that Matthew was being sarcastic. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From mehmet at akcin.net Fri Apr 18 03:01:38 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 17 Apr 2014 20:01:38 -0700 Subject: Thank you Comcast In-Reply-To: <53508DB3.5000808@uvm.edu> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <53508DB3.5000808@uvm.edu> Message-ID: <7B4B01BC-748F-4295-B3BD-F86606A4D177@akcin.net> + Redmond, WA. Good job guys. mehmet On Apr 17, 2014, at 7:28 PM, Michael T. Voity wrote: > To the Comcast v6 Team, > > Thank you for enabling my CMTS for v6 in Colchester, VT > > Works great! > > Thanks, > > -Mike > > Michael T. Voity > Network Engineer > University of Vermont > > > From dougb at dougbarton.us Fri Apr 18 03:45:55 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 17 Apr 2014 20:45:55 -0700 Subject: Thank you Comcast In-Reply-To: <53508DB3.5000808@uvm.edu> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <53508DB3.5000808@uvm.edu> Message-ID: <53509FF3.3040903@dougbarton.us> Please don't reply to a message on the list and change the subject line. Doing so causes your new topic to show "under" the previous one for those using mail readers that thread properly, and may cause your message to be missed altogether if someone has blocked that thread. Instead, save the list address and start a completely new message. hope this helps, Doug From matthew at matthew.at Fri Apr 18 03:56:54 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 17 Apr 2014 20:56:54 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: <52D0FD4D-2A96-423C-827F-C12C76EA4A3C@matthew.at> I think I got you to say "NAT" Matthew Kaufman (Sent from my iPhone) > On Apr 17, 2014, at 7:05 PM, Timothy Morizot wrote: > > > On Apr 17, 2014 7:52 PM, "Matthew Kaufman" wrote: > > > > While you're at it, the document can explain to admins who have been burned, often more than once, by the pain of re-numbering internal services at static addresses how IPv6 without NAT will magically solve this problem. > > If you're worried about that issue, either get your own end user assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix translation) at the perimeter. That's not even a hard question. From kamtha at ak-labs.net Fri Apr 18 05:00:11 2014 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Fri, 18 Apr 2014 01:00:11 -0400 Subject: Internap Contact? Message-ID: <20140418050011.GA15322@ak-labs.net> Hello, I was wondering if anyone can recommend a good contact at Internap to discuss thier anycast services. Please contact me directly. Any help is greatly appreciated.. Cheers, Carlos. From seth.mos at dds.nl Fri Apr 18 05:16:51 2014 From: seth.mos at dds.nl (Seth Mos) Date: Fri, 18 Apr 2014 07:16:51 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: <7086CD1F-96D4-40A9-AD76-AB36204C8BC7@dds.nl> Op 17 apr. 2014, om 20:50 heeft William Herrin het volgende geschreven: > On Thu, Apr 17, 2014 at 2:32 PM, Eugeniu Patrascu wrote: >> It's a bigger risk to think that NAT somehow magically protects you against >> stuff on the Internet. > > You are entitled to your opinion and you are entitled to run your > network in accordance with your opinion. > > To vendors who would sell me product, I would respectfully suggest > that attempts to forcefully educate me as to what I *should want* > offers neither a short nor particularly successful path to closing a > sale. Having deployed IPv6 at the internet point and halfway into the company I work for I can tell you that I am *really* glad that I can now see what a firewall rule does properly instead of also having to peer at the NAT table which is 1:1 or a port forward etc. Also, when IPv4 NAT and rules don?t match up, hilarity ensues. It greatly improves my workflow, it?s just become a whole lot easier for me. NAT66 definitely has a place, and I?m a huge proponent for it so the small SMB people and home users so they can do Multi Wan without BGP. The part that isn?t solved yet by the IETF, but at least there is a really good RFC for NPt. In my experience it improves security because of the transparency. For anything resembling > 100 people, get a ASN, PI and BGP. You?ll thank me later, unlikely to have to renumber anything(1). Kind regards, Seth (1) Yeah I know, unless you grow from a /48 to a /32 > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us09o > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From mpalmer at hezmatt.org Fri Apr 18 06:57:57 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 18 Apr 2014 16:57:57 +1000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: <20140418065757.GS15800@hezmatt.org> On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote: > On Apr 17, 2014 7:52 PM, "Matthew Kaufman" wrote: > > While you're at it, the document can explain to admins who have been > burned, often more than once, by the pain of re-numbering internal services > at static addresses how IPv6 without NAT will magically solve this problem. > > If you're worried about that issue, either get your own end user > assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix > translation) at the perimeter. That's not even a hard question. Why use NAT-PT in that instance? Since IPv6 interfaces are happy running with multiple addresses, the machines can have their publically-accessable address and also their ULA address, with internal services binding to (and referring to, via DNS, et al) the ULA address; when you change providers, the publically-accessable address changes (whoopee!), but the internal service address doesn't. - Matt From seth.mos at dds.nl Fri Apr 18 07:15:59 2014 From: seth.mos at dds.nl (Seth Mos) Date: Fri, 18 Apr 2014 09:15:59 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: <20140418065757.GS15800@hezmatt.org> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <20140418065757.GS15800@hezmatt.org> Message-ID: <5350D12F.9080606@dds.nl> On 18-4-2014 8:57, Matt Palmer wrote: > On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote: >> On Apr 17, 2014 7:52 PM, "Matthew Kaufman" wrote: >>> While you're at it, the document can explain to admins who have been >> burned, often more than once, by the pain of re-numbering internal services >> at static addresses how IPv6 without NAT will magically solve this problem. >> >> If you're worried about that issue, either get your own end user >> assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix >> translation) at the perimeter. That's not even a hard question. > > Why use NAT-PT in that instance? Since IPv6 interfaces are happy running > with multiple addresses, the machines can have their publically-accessable > address and also their ULA address, with internal services binding to (and > referring to, via DNS, et al) the ULA address; when you change providers, > the publically-accessable address changes (whoopee!), but the internal > service address doesn't. Sounds good in theory, I tried it but it got ugly really fast. Before you know it you have a layers of obfuscation, and even more work to get it to work right. That's really not a good argument for the general IPv6 case. Then there's the issue of making not just hosts do address selection but bringing that down to making applications choose address selection. As a admin I really don't want to go there. I just want a central point where I can pass, block or redirect. Just keep it as simple as possible, but not simpler. A host with a IPv4 and GLA IPv6 address is as complicated as you want it. The only case I see for NPt is for cheap multi wan where you have the primary prefix on your "LAN" and perform NPt for that prefix when it goes out the "3G" stick. Note that you would still need the same (delegated) prefix size on both connections (e.g. /64, /56 or /48) What is also nice is that in the case of NPt the firewall rules for both "WAN" and "3G" can be the same as the destination address (after performing NPt) is still the same. "Manageable". Kind regards, Seth From eugen at imacandi.net Fri Apr 18 07:31:37 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Fri, 18 Apr 2014 10:31:37 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Thu, Apr 17, 2014 at 11:45 PM, George Herbert wrote: > > > > On Thu, Apr 17, 2014 at 11:32 AM, Eugeniu Patrascu wrote: > >> ... >> It's a bigger risk to think that NAT somehow magically protects you >> against >> stuff on the Internet. >> Also, if your problem is that someone can screw up firewalls rules, then >> you have bigger issue in your organization than IPv6. > > > >> There's a fair argument to be made which says that kind of NAT is >> > unhealthy. If its proponents are correct, they'll win that argument >> > later on with NAT-incompatible technology that enterprises want. After >> > all, enterprise security folk didn't want the Internet in the >> > corporate network at all, but having a web browser on every desk is >> > just too darn useful. Where they won't win that argument is in the >> > stretch of maximum risk for the enterprise security folk. >> > >> > >> Any technology has associated risks, it's a matter of how you >> reduce/mitigate them. >> This paranoia thingie about IPv6 is getting a bit old. >> Just because you don't (seem to) understand how it works, it doesn't mean >> no one else should use it. > > > > You are missing the point. > > Granted, anyone who is IPv6 aware doing a green-field enterprise firewall > design today should probably choose another way than NAT. > > That's why you have gazzilions of IP addresses in IPv6, so you don't need to NAT anything (among other things). I don't understand why people cling to NAT stuff when you can just route. > What you are failing is that "redesign firewall rules and approach from > scratch along with the IPv6 implementation" usually is not the chosen path, > versus "re-implement the same v4 firewall rules and technologies in IPv6 > for the IPv6 implementation", because all the IPv6 aware net admins are > having too much to do dealing with all the other conversion issues, vendor > readiness all across the stack, etc. > > You treat IPv6 like the only protocol running and design the implementation taking that into consideration. Where necessary you publish AAAA records and so only devices/services that are IPv6 aware will be accessed over IPv6, all others can stay on IPv4 until they are migrated. It works wonderful. This idea of matching IPv4 1:1 to IPv6 is not the way to go. > Variations on this theme are part of why it's 2014 and IPv6 hasn't already > taken over the world. The more rabid IPv6 proponents have in fact shot the > transition in the legs repeatedly, and those of us who have been on the > front lines would like you all to please shut up and get out of the way so > we can actually finish effecting v6 deployment and move on to mopping up > things like NAT later. > I don't get this paragraph. From my perspective, if you want IPv6 you can do it. From all the organizations I get in contact and ask about IPv6 is the lack of knowledge and interest that puts a stop to the deployment, nothing else. Eugeniu From erey at ernw.de Fri Apr 18 07:57:31 2014 From: erey at ernw.de (Enno Rey) Date: Fri, 18 Apr 2014 09:57:31 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: <20140418075731.GA10795@ernw.de> Hi, On Thu, Apr 17, 2014 at 06:55:24PM +0200, Sander Steffann wrote: > Hi Bill, > > > Also, I note your draft is entitled "Requirements for IPv6 Enterprise > > Firewalls." Frankly, no "enterprise" firewall will be taken seriously > > without address-overloaded NAT. I realize that's a controversial > > statement in the IPv6 world but until you get past it you're basically > > wasting your time on a document which won't be useful to industry. > > I disagree. While there certainly will be organisations that want such a 'feature' it is certainly not a requirement for every (I hope most, but I might be optimistic) enterprises. I fully second Sander's input. I've been involved in IPv6 planning in a number of very large enterprises now and _none_ of them required/asked for (66/overloading) NAT for their firewall environments. A few think about very specific deployments of NPTv6 like stuff for connections to supplier/partner networks (to map those to their own address space) but these are corner cases not even relevant for their "firewalls". best Enno > > Cheers, > Sander > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From erey at ernw.de Fri Apr 18 08:14:51 2014 From: erey at ernw.de (Enno Rey) Date: Fri, 18 Apr 2014 10:14:51 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: <20140418065757.GS15800@hezmatt.org> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <20140418065757.GS15800@hezmatt.org> Message-ID: <20140418081451.GB10795@ernw.de> Hi, On Fri, Apr 18, 2014 at 04:57:57PM +1000, Matt Palmer wrote: > On Thu, Apr 17, 2014 at 09:05:17PM -0500, Timothy Morizot wrote: > > On Apr 17, 2014 7:52 PM, "Matthew Kaufman" wrote: > > > While you're at it, the document can explain to admins who have been > > burned, often more than once, by the pain of re-numbering internal services > > at static addresses how IPv6 without NAT will magically solve this problem. > > > > If you're worried about that issue, either get your own end user > > assignment(s) from ARIN or use ULA internally and employ NAT-PT (prefix > > translation) at the perimeter. That's not even a hard question. > > Why use NAT-PT in that instance? Since IPv6 interfaces are happy running > with multiple addresses, the machines can have their publically-accessable > address and also their ULA address, with internal services binding to (and > referring to, via DNS, et al) the ULA address there's two problems with that approach: a) what is "an internal service"? In a world of complex data center environments running/offering all types of services to various parties ($ORG's employees, business partners, customers and closed groups from customers, "public"/Internet) you can't make that distinction any longer. And even if you could, latest trying to reflect that distinction in your DNS setup will screw you. At the end of the day you'll still end up in "address selection hell". b) from my operational experience address selection is still a "hugely unresolved problem", despite RFC 3484 and RFC 6724. As long as this (problem) persists, from our perspective there's a simple recommendation/solution: "when there's a [continued] decision problem, just don't offer a choice". Read, in IPv6 context: "go with GUAs only and only one per interface". best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From vanbever at CS.Princeton.EDU Fri Apr 18 13:04:37 2014 From: vanbever at CS.Princeton.EDU (Laurent Vanbever) Date: Fri, 18 Apr 2014 09:04:37 -0400 Subject: EIGRP support !Cisco In-Reply-To: References: <6434672$51e7277a$2af2e41c$@flhsi.com> <52D017C3.40805@foobar.org> Message-ID: <6BEAAF58-DBCD-4A9B-8AD2-E391DB31276A@cs.princeton.edu> Hi folks, A bunch of collaborators and I worked on the problem of IGP migration/reconfiguration before. Basically, we augmented Vijay?s methodology to guarantee its correctness. Indeed, when you start flipping Administrative Distance (AD) between IGP1 and IGP2, bad stuff (i.e., forwarding loops, BGP oscillations) can happen if you?re not careful. Also, what Vijay describes is a migration between two Link State (LS) protocols (in this case, OSPF to ISIS). Migrating from EIGRP to a LS has to be treated differently since EIGRP is a Distance Vector (DV) protocol: when you flip the AD on router X, routing decisions at router Y can be impacted (this was not the case in the AOL migration). Fortunately, we managed to get that case covered to. If you?re interested in knowing more, we covered the LS-to-LS migration case in ?Seamless Network-Wide IGP Migrations? (see http://vanbever.eu/pdfs/vanbever_igpmig_sigcomm_2011.pdf). Our work about DV-to/from-LS is not published yet, but I?d be happy to share it privately (just ping me). Also, something to keep in mind when you start messing with an IGP: usually, there is BGP running on top of it? And changing the IGP can make BGP decisions go crazy (the decision process rely on IGP cost). We described this in another work ?When the Cure is Worse than the Disease: the Impact of Graceful IGP Operations on BGP? (http://vanbever.eu/pdfs/vanbever_igp_bgp_infocom_2013.pdf). Nick, I?d be happy to chat OOB if you want to know more or go further with this migration. Cheers, ? Laurent On Jan 24, 2014, at 8:04 AM, Jimmy Hess wrote: > On Fri, Jan 10, 2014 at 9:57 AM, Christopher Morrow > wrote: > >> On Fri, Jan 10, 2014 at 10:54 AM, Nick Hilliard wrote: >>> On 08/01/2014 18:14, Christopher Morrow wrote: >>>> question... there's people that have done this before even :) >>> https://www.nanog.org/meetings/nanog29/presentations/gill.pdf >> >> oh yea! that guy! I hear he's done this sort of thing a few times >> now... probably has practice and tools and stuff :) >> > > Hey... Tools.... why not... Control+Click... select all the routers.... > Right click "Upgrade IGP to ISIS" > > Go grab a drink... Come back... "Done" click OK. No more Eigrp. > > I suppose PuTTy / SecureCRT haven't added the feature yet... > perhaps in a few releases? :) > > > -- > -JH From nick at foobar.org Fri Apr 18 13:32:34 2014 From: nick at foobar.org (Nick Hilliard) Date: Fri, 18 Apr 2014 14:32:34 +0100 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: <53512972.8050303@foobar.org> On 18/04/2014 01:51, Matthew Kaufman wrote: > While you're at it, the document can explain to admins who have been > burned, often more than once, by the pain of re-numbering internal > services at static addresses how IPv6 without NAT will magically solve > this problem. it's magic. There's no need to explain, silly! Nick From bill at herrin.us Fri Apr 18 15:02:45 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 11:02:45 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu wrote: > On Thu, Apr 17, 2014 at 11:45 PM, George Herbert > wrote: >> You are missing the point. >> >> Granted, anyone who is IPv6 aware doing a green-field enterprise firewall >> design today should probably choose another way than NAT. >> > > That's why you have gazzilions of IP addresses in IPv6, so you don't need to > NAT anything (among other things). I don't understand why people cling to > NAT stuff when you can just route. Hi Eugeniu, That's correct: you don't understand. Until you do, just accept: there are more than a few folks who want to, intend to and will use NAT for IPv6. They will wait until NAT is available in their preferred products before making any significant deployment efforts. The main drivers behind the desire for NAT in IPv6 you've heard before, but I'll repeat them for the sake of clarity: 1. Easier to manage the network if the IPv4 and IPv6 versions are identical but for the IP addresses. Would've been even easier if the IP addresses were identical too, but that ship sailed more than a decade ago. 2. Risk management - developing a new operating posture for a new protocol is high risk. Translating the existing posture is lower risk. In most places the existing posture includes extensive NAT. The number of IPv4 networks in which no NAT is employed is vanishingly small. 3. Renumbering - works about as well in IPv6 as in IPv4, which is to say badly. And doubling down on the addresses assigned to hosts is still half baked -- a worthwhile idea but needs more time in the kitchen. 4. Defense in depth is a core principle of all security, network and physical. If you don't practice it, your security is weak. Equipment which is not externally addressable (due to address-overloaded NAT) has an additional obstruction an adversary must bypass versus an identical system where the equipment is externally addressable (1:1 NAT, static port translation and simple routing). This constrains the kinds of attacks an adversary may employ. Feel free to refute all four points. No doubt you have arguments you personally find compelling. Your arguments will fall on deaf ears. At best the arguments propose theory that runs contrary to decades of many folks' experience. More likely the arguments are simply wrong. Either way, you need NAT in the firewall products or you need some miracle application, the desire for which compels folks to move past the rationale above. Do you see the latter happening any time soon? Neither do I. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tmorizot at gmail.com Fri Apr 18 17:15:39 2014 From: tmorizot at gmail.com (Timothy Morizot) Date: Fri, 18 Apr 2014 12:15:39 -0500 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Apr 18, 2014 10:04 AM, "William Herrin" wrote: > That's correct: you don't understand. Until you do, just accept: there > are more than a few folks who want to, intend to and will use NAT for > IPv6. They will wait until NAT is available in their preferred > products before making any significant deployment efforts. Actually, the few like you will hold off until they are behind the curve, then scramble to catch up. Good luck with that strategy! From eyeronic.design at gmail.com Fri Apr 18 17:25:35 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 18 Apr 2014 10:25:35 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: Depends on your definition of "behind the curve". You could make the argument that folks who aren't IPv6 ready now are behind the curve. A weak argument considering IPv4 works perfectly fine for those of 'behind the curve'. I agree with Bill. You can poopoo NAT all you want, but it's a fact of most networks and will continue to remain so until you can make a compelling case to move away from it. On that note, it's awesome that Fernando is seeking feedback this early in the game. Kudos to you sir. On Fri, Apr 18, 2014 at 10:15 AM, Timothy Morizot wrote: > On Apr 18, 2014 10:04 AM, "William Herrin" wrote: >> That's correct: you don't understand. Until you do, just accept: there >> are more than a few folks who want to, intend to and will use NAT for >> IPv6. They will wait until NAT is available in their preferred >> products before making any significant deployment efforts. > > Actually, the few like you will hold off until they are behind the curve, > then scramble to catch up. Good luck with that strategy! -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From simon at per.reau.lt Fri Apr 18 17:31:20 2014 From: simon at per.reau.lt (Simon Perreault) Date: Fri, 18 Apr 2014 13:31:20 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: <53516168.6010002@per.reau.lt> Le 2014-04-18 13:25, Mike Hale a ?crit : > I agree with Bill. You can poopoo NAT all you want, but it's a fact > of most networks and will continue to remain so until you can make a > compelling case to move away from it. Does that mean all IPv6 firewalls should support NAT? Remember, we're aiming for a base set of requirements applying to all IPv6 firewalls. Simon From bill at herrin.us Fri Apr 18 17:35:30 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 13:35:30 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <53516168.6010002@per.reau.lt> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> Message-ID: On Fri, Apr 18, 2014 at 1:31 PM, Simon Perreault wrote: > Le 2014-04-18 13:25, Mike Hale a ?crit : >> I agree with Bill. You can poopoo NAT all you want, but it's a fact >> of most networks and will continue to remain so until you can make a >> compelling case to move away from it. > > Does that mean all IPv6 firewalls should support NAT? > > Remember, we're aiming for a base set of requirements applying to all > IPv6 firewalls. Your document specifies "Enterprise" firewalls. Frankly I think that's wise. Consumer and enterprise users have very different needs and very different cost points. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Apr 18 17:38:32 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 13:38:32 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 1:15 PM, Timothy Morizot wrote: > On Apr 18, 2014 10:04 AM, "William Herrin" wrote: >> That's correct: you don't understand. Until you do, just accept: there >> are more than a few folks who want to, intend to and will use NAT for >> IPv6. They will wait until NAT is available in their preferred >> products before making any significant deployment efforts. > > Actually, the few like you will hold off until they are behind the curve, > then scramble to catch up. Good luck with that strategy! You know, you zealots are playing this stupid. You've already won: no NAT in consumer devices means that when (if) IPv4 starts its decline, nat traversal will leave consumer-focused software. And sooner or later there will be a consumer app that business has to have. The only way you can snatch defeat from the jaws of victory is if IPv6 fails to launch. Look around you. IPv6 use on the Internet, actual use, is still barely in the single digits. If you let us get used to extending IPv4 with carrier NAT, markets and so on you lose everything. And if you think the math says that can't happen, you badly underestimate folks' ingenuity. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From simon at per.reau.lt Fri Apr 18 17:40:26 2014 From: simon at per.reau.lt (Simon Perreault) Date: Fri, 18 Apr 2014 13:40:26 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> Message-ID: <5351638A.2080601@per.reau.lt> Le 2014-04-18 13:35, William Herrin a ?crit : >> Does that mean all IPv6 firewalls should support NAT? >> >> Remember, we're aiming for a base set of requirements applying to all >> IPv6 firewalls. > > Your document specifies "Enterprise" firewalls. Frankly I think that's > wise. Consumer and enterprise users have very different needs and very > different cost points. Over here we have no use for IPv6 NAT. We have our own PI space. I suspect many other enterprises would be in a similar situation. I totally get your position, but I don't see how it can justify an Internet-wide requirement. Simon From mikea at mikea.ath.cx Fri Apr 18 17:46:09 2014 From: mikea at mikea.ath.cx (Mike A) Date: Fri, 18 Apr 2014 12:46:09 -0500 Subject: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: References: <20140411193039.GA2724@gsp.org> <20140411201044.GG36211@burnout.tpb.net> Message-ID: <20140418174609.GA33320@mikea.ath.cx> On Mon, Apr 14, 2014 at 10:09:14PM +0000, Matthew Black wrote: > IIRC, the message was sent via courier instead of cable or telephone to > prevent interception. Did the military not even trust its own cryptographic > methods? Or did they not think withdrawal of the Japanese ambassador was not > very critical? The message was sent by Western Union. There being no cable between the Hawaiian Islands and the mainland at the time, the message went by commercial radio, in plaintext, and thence by civilian bicycle messenger (of Japanese ancestry, as it happened) to Fort Shafter, where it was read while the attack was in progress. David Kahn's fine book, _The Codebreakers_, discusses this in rather more detail. I recommend the original version; the paperback and later hardback editions contain rather less meat. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From eyeronic.design at gmail.com Fri Apr 18 17:54:03 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 18 Apr 2014 10:54:03 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351638A.2080601@per.reau.lt> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> Message-ID: Many enterprises probably are in the same position, but a whole lot of them aren't. Maybe this comes down to "should" versus "must". I don't think all IPv6 firewalls "must" support NAT, but they should. On Fri, Apr 18, 2014 at 10:40 AM, Simon Perreault wrote: > Le 2014-04-18 13:35, William Herrin a ?crit : >>> Does that mean all IPv6 firewalls should support NAT? >>> >>> Remember, we're aiming for a base set of requirements applying to all >>> IPv6 firewalls. >> >> Your document specifies "Enterprise" firewalls. Frankly I think that's >> wise. Consumer and enterprise users have very different needs and very >> different cost points. > > Over here we have no use for IPv6 NAT. We have our own PI space. I > suspect many other enterprises would be in a similar situation. > > I totally get your position, but I don't see how it can justify an > Internet-wide requirement. > > Simon > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From bill at herrin.us Fri Apr 18 18:00:33 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 14:00:33 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351638A.2080601@per.reau.lt> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> Message-ID: On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault wrote: > Le 2014-04-18 13:35, William Herrin a ?crit : >> Your document specifies "Enterprise" firewalls. Frankly I think that's >> wise. Consumer and enterprise users have very different needs and very >> different cost points. > > Over here we have no use for IPv6 NAT. We have our own PI space. I > suspect many other enterprises would be in a similar situation. > > I totally get your position, but I don't see how it can justify an > Internet-wide requirement. As I understand your document, you're trying to scope a set of minimum required features for a firewall that will be able to describe itself as "RFC whatever compliant." The idea is for folks working for large enterprises to be able to use such a tag as a discriminator for potential purchases. Since a pretty humongous number of them are using NAT with IPv4 and are likely to want to do so with IPv6, leaving that out of the required feature list seems counter-productive to your goal of a document which has utility to them. Besides, you have spam control and URL filtering in there. Do you seriously propose that spam control and URL filtering rank above NAT on the *firewall* requirements list? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gary.buhrmaster at gmail.com Fri Apr 18 18:02:41 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 18 Apr 2014 18:02:41 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 3:02 PM, William Herrin wrote: .... > The main drivers behind the desire for NAT in IPv6 you've heard > before, but I'll repeat them for the sake of clarity: 5. Some industries (PCI compliance) *require* NAT as part of the audit-able requirements. Yes, that should get changed. But until it does, (at least some) enterprises are going to be between a rock and a hard place. As Bill says, the place to get this fixed is not to tell the enterprises they are doing it wrong, but to change the requirements that auditors measure against. I would cheer the effort to engage those bodies to get them to understand that NAT is not the way (for it is not). This does not mean ignore the problem. It does not mean to tell people they are doing it wrong. It means active engagement with such organizations. And it is hard, policy type, work, From simon at per.reau.lt Fri Apr 18 18:06:17 2014 From: simon at per.reau.lt (Simon Perreault) Date: Fri, 18 Apr 2014 14:06:17 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> Message-ID: <53516999.5080605@per.reau.lt> Le 2014-04-18 14:00, William Herrin a ?crit : > On Fri, Apr 18, 2014 at 1:40 PM, Simon Perreault wrote: >> Le 2014-04-18 13:35, William Herrin a ?crit : >>> Your document specifies "Enterprise" firewalls. Frankly I think that's >>> wise. Consumer and enterprise users have very different needs and very >>> different cost points. >> >> Over here we have no use for IPv6 NAT. We have our own PI space. I >> suspect many other enterprises would be in a similar situation. >> >> I totally get your position, but I don't see how it can justify an >> Internet-wide requirement. > > As I understand your document, you're trying to scope a set of minimum > required features for a firewall that will be able to describe itself > as "RFC whatever compliant." The idea is for folks working for large > enterprises to be able to use such a tag as a discriminator for > potential purchases. Since a pretty humongous number of them are using > NAT with IPv4 and are likely to want to do so with IPv6, leaving that > out of the required feature list seems counter-productive to your goal > of a document which has utility to them. > > Besides, you have spam control and URL filtering in there. Do you > seriously propose that spam control and URL filtering rank above NAT > on the *firewall* requirements list? Well, it's not *my* document, but I'm very interested in it. IMHO it should not be a shopping list of features that people might want. The goal should not be to be a base for RFPs. IMHO, what the IETF can do is recommend a set of behavioural traits that make IPv6 firewalls behave like good citizens in the Internet ecosystem. Meaning that a firewall that obeys those requirements will not break the Internet. For example, passing ICMPv6 Too Big messages is important to not break the Internet. I think we can get consensus on such requirements, and I think it would fit the IETF's role. A feature shopping list, not so much. Simon From will at loopfree.net Fri Apr 18 18:12:06 2014 From: will at loopfree.net (Will Orton) Date: Fri, 18 Apr 2014 11:12:06 -0700 Subject: Cogent to Comcast IPv6 broken? Message-ID: <20140418181206.GA25643@loopfree.net> Cogent from various west coast USA locations seems to have trouble getting to some Comcast ipv6 addresses: Cogent LG Los Angeles to www.comcast6.net traceroute to 2001:558:fe16:7:69:252:216:215 (2001:558:fe16:7:69:252:216:215), 30 hops max, 80 byte packets 1 2001:550:1:317::1 (2001:550:1:317::1) 70.184 ms 70.181 ms 2 * * 3 * * 4 2001:550:4::51 (2001:550:4::51) 15.013 ms 14.981 ms 5 * * 6 * * [ ... ] Cogent LG San Francisco ipv6 trace to www.comcast6.net traceroute to 2001:558:fe16:7:69:252:216:215 (2001:558:fe16:7:69:252:216:215), 30 hops max, 80 byte packets 1 2001:550:1:31f::1 (2001:550:1:31f::1) 0.367 ms 0.369 ms 2 * * 3 * * 4 * * [ ... ] Cogent LG San Jose ipv6 ping to www.comcast6.net PING 2001:558:fe16:7:69:252:216:215(2001:558:fe16:7:69:252:216:215) 56 data bytes --- 2001:558:fe16:7:69:252:216:215 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 13999ms Cogent LG San Jose ipv6 ping to speedtest.comcast.net (Los Angeles does same thing, but Kansas City works): PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes --- 2001:558:fe2a:3:69:241:64:6 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 14000ms from Los Angeles same thing, but from Cogent's LG Kansas City it works: PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=1 ttl=55 time=35.6 ms 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=2 ttl=55 time=35.7 ms 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=3 ttl=55 time=35.6 ms 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=4 ttl=55 time=35.6 ms 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=5 ttl=55 time=35.6 ms --- 2001:558:fe2a:3:69:241:64:6 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4043ms rtt min/avg/max/mdev = 35.620/35.676/35.734/0.241 ms This is similar to issues I see with a Cogent IPv6/BGP-enabled transit connection in Los Angeles to a random Comcast customer address (that is otherwise up and reachable from HE.net, NTT, etc): (from router with ipv6 BGP Cogent transit connection): traceroute6 to 2601:7:1300:3d2::1 (2601:7:1300:3d2::1) from 2001:550:2:18::5:2, 64 hops max, 12 byte packets 1 2001:550:2:18::5:1 (2001:550:2:18::5:1) 1.903 ms 1.120 ms 10.771 ms 2 * * * 3 * 2001:550::57 (2001:550::57) 15.654 ms * MPLS Label=19852 CoS=2 TTL=255 S=0 MPLS Label=19207 CoS=2 TTL=255 S=1 4 * * * I have Cogent ticket #HD0000005706297 on that but I'm being ignored. I see the similar things from Cogent IP6 transit out of San Jose. Anyone at Cogent able to look at this? I basically blackhole big chunks of Comcast ipv6 on my network when I enable ipv6 to Cogent. -Will From cscora at apnic.net Fri Apr 18 18:12:48 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Apr 2014 04:12:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201404181812.s3IICmQG002573@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Apr, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 492222 Prefixes after maximum aggregation: 193201 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 242977 Total ASes present in the Internet Routing Table: 46643 Prefixes per ASN: 10.55 Origin-only ASes present in the Internet Routing Table: 35761 Origin ASes announcing only one prefix: 16379 Transit ASes present in the Internet Routing Table: 6050 Transit-only ASes present in the Internet Routing Table: 174 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1858 Unregistered ASNs in the Routing Table: 473 Number of 32-bit ASNs allocated by the RIRs: 6417 Number of 32-bit ASNs visible in the Routing Table: 4832 Prefixes from 32-bit ASNs in the Routing Table: 15924 Number of bogon 32-bit ASNs visible in the Routing Table: 90 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 440 Number of addresses announced to Internet: 2669487108 Equivalent to 159 /8s, 29 /16s and 36 /24s Percentage of available address space announced: 72.1 Percentage of allocated address space announced: 72.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.1 Total number of prefixes smaller than registry allocations: 171386 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 116903 Total APNIC prefixes after maximum aggregation: 34905 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 119739 Unique aggregates announced from the APNIC address blocks: 49900 APNIC Region origin ASes present in the Internet Routing Table: 4917 APNIC Prefixes per ASN: 24.35 APNIC Region origin ASes announcing only one prefix: 1221 APNIC Region transit ASes present in the Internet Routing Table: 852 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table: 912 Number of APNIC addresses announced to Internet: 731230080 Equivalent to 43 /8s, 149 /16s and 175 /24s Percentage of available APNIC address space announced: 85.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 167455 Total ARIN prefixes after maximum aggregation: 83038 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 168921 Unique aggregates announced from the ARIN address blocks: 78775 ARIN Region origin ASes present in the Internet Routing Table: 16215 ARIN Prefixes per ASN: 10.42 ARIN Region origin ASes announcing only one prefix: 6106 ARIN Region transit ASes present in the Internet Routing Table: 1671 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 87 Number of ARIN addresses announced to Internet: 1068987008 Equivalent to 63 /8s, 183 /16s and 114 /24s Percentage of available ARIN address space announced: 56.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 123457 Total RIPE prefixes after maximum aggregation: 62486 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 127706 Unique aggregates announced from the RIPE address blocks: 81131 RIPE Region origin ASes present in the Internet Routing Table: 17680 RIPE Prefixes per ASN: 7.22 RIPE Region origin ASes announcing only one prefix: 8305 RIPE Region transit ASes present in the Internet Routing Table: 2861 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2693 Number of RIPE addresses announced to Internet: 657743236 Equivalent to 39 /8s, 52 /16s and 93 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 55999 Total LACNIC prefixes after maximum aggregation: 10071 LACNIC Deaggregation factor: 5.56 Prefixes being announced from the LACNIC address blocks: 62354 Unique aggregates announced from the LACNIC address blocks: 28522 LACNIC Region origin ASes present in the Internet Routing Table: 2087 LACNIC Prefixes per ASN: 29.88 LACNIC Region origin ASes announcing only one prefix: 547 LACNIC Region transit ASes present in the Internet Routing Table: 427 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1116 Number of LACNIC addresses announced to Internet: 158042752 Equivalent to 9 /8s, 107 /16s and 138 /24s Percentage of available LACNIC address space announced: 94.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12379 Total AfriNIC prefixes after maximum aggregation: 2664 AfriNIC Deaggregation factor: 4.65 Prefixes being announced from the AfriNIC address blocks: 13062 Unique aggregates announced from the AfriNIC address blocks: 4278 AfriNIC Region origin ASes present in the Internet Routing Table: 713 AfriNIC Prefixes per ASN: 18.32 AfriNIC Region origin ASes announcing only one prefix: 200 AfriNIC Region transit ASes present in the Internet Routing Table: 149 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 24 Number of AfriNIC addresses announced to Internet: 53143296 Equivalent to 3 /8s, 42 /16s and 231 /24s Percentage of available AfriNIC address space announced: 52.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2951 11591 914 Korea Telecom 17974 2779 903 78 PT Telekomunikasi Indonesia 7545 2218 336 116 TPG Telecom Limited 4755 1844 396 197 TATA Communications formerly 9829 1622 1288 35 National Internet Backbone 9583 1331 103 544 Sify Limited 9498 1258 313 82 BHARTI Airtel Ltd. 7552 1218 1082 13 Viettel Corporation 4808 1205 2142 351 CNCGROUP IP network China169 24560 1123 384 177 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2993 3688 53 BellSouth.net Inc. 22773 2413 2938 137 Cox Communications Inc. 1785 2194 698 132 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1702 1685 575 Charter Communications 4323 1624 1072 406 tw telecom holdings, inc. 701 1480 11156 751 MCI Communications Services, 30036 1400 303 542 Mediacom Communications Corp 22561 1309 402 232 CenturyTel Internet Holdings, 7018 1264 18243 830 AT&T Services, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1607 544 16 OJSC "Vimpelcom" 34984 1564 263 279 TELLCOM ILETISIM HIZMETLERI A 20940 1322 510 998 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1018 45 19 Freenet Ltd. 8551 927 370 41 Bezeq International-Ltd 6849 830 360 30 JSC "Ukrtelecom" 6830 766 2329 427 Liberty Global Operations B.V 12479 720 797 56 France Telecom Espana SA 35228 553 245 16 Telefonica UK Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3740 1952 100 NET Servi?os de Comunica??o S 10620 2835 457 202 Telmex Colombia S.A. 18881 1924 972 21 Global Village Telecom 7303 1754 1174 229 Telecom Argentina S.A. 8151 1398 2942 405 Uninet S.A. de C.V. 6503 1147 434 60 Axtel, S.A.B. de C.V. 7738 914 1754 40 Telemar Norte Leste S.A. 27947 864 114 50 Telconet S.A 11830 844 364 15 Instituto Costarricense de El 26615 819 2325 35 Tim Celular S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1634 240 6 Sudanese Mobile Telephone (ZA 24863 953 280 26 Link Egypt (Link.NET) 6713 614 722 28 Office National des Postes et 8452 565 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 275 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 29571 228 22 18 Cote d'Ivoire Telecom 37054 222 23 11 Data Telecom Service 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3740 1952 100 NET Servi?os de Comunica??o S 6389 2993 3688 53 BellSouth.net Inc. 4766 2951 11591 914 Korea Telecom 10620 2835 457 202 Telmex Colombia S.A. 17974 2779 903 78 PT Telekomunikasi Indonesia 22773 2413 2938 137 Cox Communications Inc. 7545 2218 336 116 TPG Telecom Limited 1785 2194 698 132 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1924 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2993 2940 BellSouth.net Inc. 17974 2779 2701 PT Telekomunikasi Indonesia 10620 2835 2633 Telmex Colombia S.A. 22773 2413 2276 Cox Communications Inc. 7545 2218 2102 TPG Telecom Limited 1785 2194 2062 PaeTec Communications, Inc. 4766 2951 2037 Korea Telecom 18881 1924 1903 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1844 1647 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:30 /11:90 /12:258 /13:478 /14:961 /15:1672 /16:12941 /17:6797 /18:11574 /19:24188 /20:33939 /21:36613 /22:52582 /23:46014 /24:261827 /25:802 /26:943 /27:406 /28:13 /29:20 /30:7 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2002 2047 MegaPath Corporation 6389 1695 2993 BellSouth.net Inc. 22773 1652 2413 Cox Communications Inc. 36998 1599 1634 Sudanese Mobile Telephone (ZA 8402 1287 1607 OJSC "Vimpelcom" 30036 1237 1400 Mediacom Communications Corp 11492 1188 1232 CABLE ONE, INC. 1785 1164 2194 PaeTec Communications, Inc. 6983 1041 1228 ITC^Deltacom 34984 1022 1564 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1017 2:701 3:3 4:15 5:937 6:19 8:730 12:1860 13:4 14:973 15:13 16:2 17:31 18:21 20:35 23:814 24:1745 25:1 27:1777 31:1512 32:40 33:2 34:5 36:129 37:1866 38:952 39:5 40:197 41:3205 42:249 44:10 46:2187 47:18 49:688 50:921 52:12 54:47 55:6 57:28 58:1228 59:605 60:393 61:1525 62:1222 63:1985 64:4368 65:2246 66:4149 67:2075 68:1039 69:3291 70:848 71:453 72:2000 74:2619 75:312 76:411 77:1518 78:988 79:719 80:1310 81:1144 82:734 83:755 84:707 85:1259 86:453 87:1187 88:517 89:1815 90:140 91:5724 92:665 93:1712 94:2067 95:1495 96:543 97:350 98:1074 99:48 100:54 101:787 103:4679 105:534 106:170 107:566 108:578 109:2050 110:983 111:1284 112:655 113:845 114:882 115:1113 116:1042 117:918 118:1404 119:1339 120:373 121:800 122:1906 123:1289 124:1423 125:1399 128:657 129:324 130:345 131:650 132:394 133:162 134:319 135:74 136:252 137:323 138:355 139:169 140:211 141:364 142:569 143:413 144:503 145:104 146:612 147:439 148:927 149:377 150:167 151:633 152:422 153:218 154:262 155:478 156:336 157:339 158:244 159:893 160:339 161:507 162:1335 163:219 164:685 165:615 166:282 167:611 168:1029 169:124 170:1365 171:190 172:22 173:1631 174:697 175:621 176:1484 177:2891 178:1963 179:648 180:1719 181:1110 182:1562 183:516 184:709 185:1509 186:2729 187:1502 188:1928 189:1460 190:7485 191:201 192:7182 193:5488 194:4025 195:3394 196:1389 197:1136 198:5012 199:5600 200:6229 201:2647 202:9000 203:9006 204:4671 205:2706 206:2940 207:2963 208:4010 209:3718 210:3111 211:1690 212:2183 213:2101 214:890 215:85 216:5462 217:1677 218:590 219:321 220:1280 221:594 222:349 223:612 End of report From bill at herrin.us Fri Apr 18 18:20:20 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 14:20:20 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <53516999.5080605@per.reau.lt> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> Message-ID: On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault wrote: > IMHO, what the IETF can do is recommend a set of behavioural traits that > make IPv6 firewalls behave like good citizens in the Internet ecosystem. > Meaning that a firewall that obeys those requirements will not break the > Internet. For example, passing ICMPv6 Too Big messages is important to > not break the Internet. That would either be a very short document or a document so ideologically loaded that it has no technical utility. The Internet is pretty resilient. There isn't much a firewall can do to break it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From simon at per.reau.lt Fri Apr 18 18:32:47 2014 From: simon at per.reau.lt (Simon Perreault) Date: Fri, 18 Apr 2014 14:32:47 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> Message-ID: <53516FCF.9050000@per.reau.lt> Le 2014-04-18 14:20, William Herrin a ?crit : > On Fri, Apr 18, 2014 at 2:06 PM, Simon Perreault wrote: >> IMHO, what the IETF can do is recommend a set of behavioural traits that >> make IPv6 firewalls behave like good citizens in the Internet ecosystem. >> Meaning that a firewall that obeys those requirements will not break the >> Internet. For example, passing ICMPv6 Too Big messages is important to >> not break the Internet. > > That would either be a very short document or a document so > ideologically loaded that it has no technical utility. The Internet is > pretty resilient. There isn't much a firewall can do to break it. In IETF we routinely use the phrase "breaking the Internet" to mean something rather more limited than "breaking all of the Internet". There are tons of things firewalls can do, and some do today, that would be considered breaking the Internet. FYI, we had a similar document targeted at CGNs: http://tools.ietf.org/html/rfc6888 >From the abstract: This document describes behavior that is required of those multi- subscriber NATs for interoperability. It is not an IETF endorsement of CGNs or a real specification for CGNs; rather, it is just a minimal set of requirements that will increase the likelihood of applications working across CGNs. That is exactly the kind of requirements I am thinking of when I say "not breaking the Internet". Still, there were a few "feature shopping list" requirements that crept into that RFC. It's far from perfect. Simon From bill at herrin.us Fri Apr 18 18:57:13 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 14:57:13 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <53516FCF.9050000@per.reau.lt> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <53516FCF.9050000@per.reau.lt> Message-ID: On Fri, Apr 18, 2014 at 2:32 PM, Simon Perreault wrote: > Le 2014-04-18 14:20, William Herrin a ?crit : >> That would either be a very short document or a document so >> ideologically loaded that it has no technical utility. The Internet is >> pretty resilient. There isn't much a firewall can do to break it. > > In IETF we routinely use the phrase "breaking the Internet" to mean > something rather more limited than "breaking all of the Internet". There > are tons of things firewalls can do, and some do today, that would be > considered breaking the Internet. > > FYI, we had a similar document targeted at CGNs: > > http://tools.ietf.org/html/rfc6888 Excluding references and remarks RFC 6888 is 8 pages long with 15 total requirements. Short. I'll let the firewall document's authors speak for themselves about their document's purpose. In the abstract, they said: ''This has typically been a problem for network operators, who typically have to produce a "Request for Proposal" from scratch that describes such features.'' That says, "discriminator for potential purchases" to me. What's your take? I agree that a "don't break the Internet' firewall requirements document could have utility. But that doesn't appear to be this document. And if done well, such a document would be short just like RFC 6888. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dougb at dougbarton.us Fri Apr 18 18:59:04 2014 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 18 Apr 2014 11:59:04 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <20140418075731.GA10795@ernw.de> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <20140418075731.GA10795@ernw.de> Message-ID: <535175F8.2050907@dougbarton.us> On 04/18/2014 12:57 AM, Enno Rey wrote: > I fully second Sander's input. I've been involved in IPv6 planning in a number of very large enterprises now and_none_ of them required/asked for (66/overloading) NAT for their firewall environments. A few think about very specific deployments of NPTv6 like stuff for connections to supplier/partner networks (to map those to their own address space) but these are corner cases not even relevant for their "firewalls". How many of those networks were implementing with IPv6 PI space? My experience has been that those customers are not interested in IPv6 NAT, but instead utilize network segmentation to define "internal" vs. "external." OTOH, customers for whom PI space is not realistic (for whatever reasons, and yes there are reasons) are very interested in the combination of ULA + NTPv6 to handle internal resources without having to worry about renumbering down the road. Doug From simon at per.reau.lt Fri Apr 18 19:03:13 2014 From: simon at per.reau.lt (Simon Perreault) Date: Fri, 18 Apr 2014 15:03:13 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <53516FCF.9050000@per.reau.lt> Message-ID: <535176F1.5000302@per.reau.lt> Le 2014-04-18 14:57, William Herrin a ?crit : > Excluding references and remarks RFC 6888 is 8 pages long with 15 > total requirements. Short. Given the trend toward ever-fluffier RFCs, I'll take that as a compliment. :) > I'll let the firewall document's authors speak for themselves about > their document's purpose. In the abstract, they said: ''This has > typically been a problem for network operators, who typically have to > produce a "Request for Proposal" from scratch that describes such > features.'' > > That says, "discriminator for potential purchases" to me. What's your take? I agree with your interpretation, and I disagree with the intent. > I agree that a "don't break the Internet' firewall requirements > document could have utility. But that doesn't appear to be this > document. And if done well, such a document would be short just like > RFC 6888. Full agreement. Simon From jim.clausing at acm.org Fri Apr 18 19:49:36 2014 From: jim.clausing at acm.org (Jim Clausing) Date: Fri, 18 Apr 2014 15:49:36 -0400 (EDT) Subject: Requirements for IPv6 Firewalls In-Reply-To: <535176F1.5000302@per.reau.lt> References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <53516FCF.9050000@per.reau.lt> <535176F1.5000302@per.reau.lt> Message-ID: And maybe I'm just dense, but ho one has been able to tell me how I accomplish this in IPv6 without NAT, I have the requirement in certain circumstances to transparently redirect all outbound DNS (well, on TCP or UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers. No, simply blocking it at the firewall and making the user "fix" the problem is not an option (especially when the problem is created by malware). It is a simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? Not flaming or anything, but I really want to know how I'm supposed to accomplish that in the ideal IPv6 world with no NAT? -- Jim Clausing GIAC GSE #26, GREM(G), CISSP GPG fingerprint = A507 774A 39D6 A702 9F7C 8808 3D13 77B8 AACD 848D On or about Fri, 18 Apr 2014, Simon Perreault pontificated thusly: > Le 2014-04-18 14:57, William Herrin a ?crit : >> Excluding references and remarks RFC 6888 is 8 pages long with 15 >> total requirements. Short. > > Given the trend toward ever-fluffier RFCs, I'll take that as a > compliment. :) > >> I'll let the firewall document's authors speak for themselves about >> their document's purpose. In the abstract, they said: ''This has >> typically been a problem for network operators, who typically have to >> produce a "Request for Proposal" from scratch that describes such >> features.'' >> >> That says, "discriminator for potential purchases" to me. What's your take? > > I agree with your interpretation, and I disagree with the intent. > >> I agree that a "don't break the Internet' firewall requirements >> document could have utility. But that doesn't appear to be this >> document. And if done well, such a document would be short just like >> RFC 6888. > > Full agreement. > > Simon > > From cb.list6 at gmail.com Fri Apr 18 20:06:51 2014 From: cb.list6 at gmail.com (TheIpv6guy .) Date: Fri, 18 Apr 2014 13:06:51 -0700 Subject: Cogent to Comcast IPv6 broken? In-Reply-To: <20140418181206.GA25643@loopfree.net> References: <20140418181206.GA25643@loopfree.net> Message-ID: On Fri, Apr 18, 2014 at 11:12 AM, Will Orton wrote: > Cogent from various west coast USA locations seems to have trouble getting to some Comcast ipv6 addresses: > > Cogent LG Los Angeles to www.comcast6.net > traceroute to 2001:558:fe16:7:69:252:216:215 (2001:558:fe16:7:69:252:216:215), 30 hops max, 80 byte packets > 1 2001:550:1:317::1 (2001:550:1:317::1) 70.184 ms 70.181 ms > 2 * * > 3 * * > 4 2001:550:4::51 (2001:550:4::51) 15.013 ms 14.981 ms > 5 * * > 6 * * > [ ... ] > > > Cogent LG San Francisco ipv6 trace to www.comcast6.net > traceroute to 2001:558:fe16:7:69:252:216:215 (2001:558:fe16:7:69:252:216:215), 30 hops max, 80 byte packets > 1 2001:550:1:31f::1 (2001:550:1:31f::1) 0.367 ms 0.369 ms > 2 * * > 3 * * > 4 * * > [ ... ] > > Cogent LG San Jose ipv6 ping to www.comcast6.net > PING 2001:558:fe16:7:69:252:216:215(2001:558:fe16:7:69:252:216:215) 56 data bytes > > --- 2001:558:fe16:7:69:252:216:215 ping statistics --- > 5 packets transmitted, 0 received, 100% packet loss, time 13999ms > > > Cogent LG San Jose ipv6 ping to speedtest.comcast.net (Los Angeles does same thing, but Kansas City works): > PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes > > --- 2001:558:fe2a:3:69:241:64:6 ping statistics --- > 5 packets transmitted, 0 received, 100% packet loss, time 14000ms > > from Los Angeles same thing, but from Cogent's LG Kansas City it works: > PING 2001:558:fe2a:3:69:241:64:6(2001:558:fe2a:3:69:241:64:6) 56 data bytes > 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=1 ttl=55 time=35.6 ms > 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=2 ttl=55 time=35.7 ms > 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=3 ttl=55 time=35.6 ms > 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=4 ttl=55 time=35.6 ms > 64 bytes from 2001:558:fe2a:3:69:241:64:6: icmp_seq=5 ttl=55 time=35.6 ms > > --- 2001:558:fe2a:3:69:241:64:6 ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4043ms > rtt min/avg/max/mdev = 35.620/35.676/35.734/0.241 ms > > > This is similar to issues I see with a Cogent IPv6/BGP-enabled transit connection in Los Angeles to a random > Comcast customer address (that is otherwise up and reachable from HE.net, NTT, etc): > > (from router with ipv6 BGP Cogent transit connection): > traceroute6 to 2601:7:1300:3d2::1 (2601:7:1300:3d2::1) from 2001:550:2:18::5:2, 64 hops max, 12 byte packets > 1 2001:550:2:18::5:1 (2001:550:2:18::5:1) 1.903 ms 1.120 ms 10.771 ms > 2 * * * > 3 * 2001:550::57 (2001:550::57) 15.654 ms * > MPLS Label=19852 CoS=2 TTL=255 S=0 > MPLS Label=19207 CoS=2 TTL=255 S=1 > 4 * * * > > > I have Cogent ticket #HD0000005706297 on that but I'm being ignored. > I see the similar things from Cogent IP6 transit out of San Jose. > > Anyone at Cogent able to look at this? I basically blackhole big chunks of Comcast ipv6 on my network when I > enable ipv6 to Cogent. > > > -Will > This is probably a better discussion for outages@ ... but ... i notice that i could NOT get to anything from IPv6 on Comcast at home this morning. And quick look at their comcast route servers shows things are NOT ok route-server.newyork.ny.ibone>ping www.yahoo.com Translating "www.yahoo.com"...domain server (68.87.64.164) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:4998:F00B:1FE::3001, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms route-server.newyork.ny.ibone>ping www.facebook.com Translating "www.facebook.com"...domain server (68.87.64.164) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2A03:2880:2130:7F07:FACE:B00C:0:1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) route-server.newyork.ny.ibone>ping www.google.com Translating "www.google.com"...domain server (68.87.64.164) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2607:F8B0:400C:C04::6A, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) From george.herbert at gmail.com Fri Apr 18 20:33:47 2014 From: george.herbert at gmail.com (George Herbert) Date: Fri, 18 Apr 2014 13:33:47 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 10:15 AM, Timothy Morizot wrote: > On Apr 18, 2014 10:04 AM, "William Herrin" wrote: > > That's correct: you don't understand. Until you do, just accept: there > > are more than a few folks who want to, intend to and will use NAT for > > IPv6. They will wait until NAT is available in their preferred > > products before making any significant deployment efforts. > > Actually, the few like you will hold off until they are behind the curve, > then scramble to catch up. Good luck with that strategy! > Again. You're speaking down to William as if he's not IPv6 aware, which is wrong, and ascribing to him misunderstandings and resistance that he (and I) are trying to communicate to explain why customers in real life are lagging so badly. The reason the IPv6 market penetration is so poor right now is because of antagonistic attitudes like this when actual implementers in the field try to feed back what the actual, real objections are that are slowing things down. "That shouldn't happen," is not acceptable as a response to an actual user saying "No, not until I get NAT.". If William and I fight that fight, lose it, and come back and tell you "They won't go because insufficient NAT" you need to listen. I've fought this in a dozen places and lost 8 of them, not because I don't know v6, but because the clients have inertia and politics around security posture changes (and in some cases, PCI compliance regs). -- -george william herbert george.herbert at gmail.com From cidr-report at potaroo.net Fri Apr 18 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Apr 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201404182200.s3IM00DE046211@wattle.apnic.net> This report has been generated at Fri Apr 18 21:13:52 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 11-04-14 498748 282207 12-04-14 498501 281955 13-04-14 498250 282063 14-04-14 498353 282141 15-04-14 498798 282300 16-04-14 499258 282348 17-04-14 499301 282302 18-04-14 499254 282237 AS Summary 46860 Number of ASes in routing system 19112 Number of ASes announcing only one prefix 3741 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 119829504 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 18Apr14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 499535 282214 217321 43.5% All ASes AS28573 3741 271 3470 92.8% NET Servi?os de Comunica??o S.A.,BR AS6389 2992 56 2936 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2780 238 2542 91.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2951 923 2028 68.7% KIXS-AS-KR Korea Telecom,KR AS18881 1924 37 1887 98.1% Global Village Telecom,BR AS1785 2194 483 1711 78.0% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2835 1340 1495 52.7% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS36998 1634 156 1478 90.5% SDN-MOBITEL,SD AS4323 2929 1510 1419 48.4% TWTC - tw telecom holdings, inc.,US AS7303 1758 457 1301 74.0% Telecom Argentina S.A.,AR AS4755 1844 608 1236 67.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2232 1075 1157 51.8% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1219 110 1109 91.0% VIETEL-AS-AP Viettel Corporation,VN AS22561 1309 241 1068 81.6% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1228 217 1011 82.3% ITCDELTA - Earthlink, Inc.,US AS9829 1622 733 889 54.8% BSNL-NIB National Internet Backbone,IN AS22773 2416 1593 823 34.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS24560 1123 302 821 73.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1205 387 818 67.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS4788 1028 253 775 75.4% TMNET-AS-AP TM Net, Internet Service Provider,MY AS18101 946 188 758 80.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS7738 914 184 730 79.9% Telemar Norte Leste S.A.,BR AS8151 1408 678 730 51.8% Uninet S.A. de C.V.,MX AS701 1480 751 729 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS26615 819 109 710 86.7% Tim Celular S.A.,BR AS855 755 57 698 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS6147 779 112 667 85.6% Telefonica del Peru S.A.A.,PE AS9808 994 327 667 67.1% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN AS4780 1038 372 666 64.2% SEEDNET Digital United Inc.,TW Total 52144 14333 37811 72.5% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.119.240.0/22 AS26072 -Reserved AS-,ZZ 64.119.240.0/23 AS26072 -Reserved AS-,ZZ 64.119.242.0/23 AS26072 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.119.236.0/23 AS26368 -Reserved AS-,ZZ 74.119.239.0/24 AS26368 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.23.36.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 107.189.32.0/19 AS7363 YOMURA - Lightstream Transmission and Telecom Inc,US 107.190.128.0/20 AS33182 DIMENOC - HostDime.com, Inc.,US 107.190.160.0/20 AS20360 OPPOBOX - OppoBox,US 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 162.247.32.0/22 AS27288 DPCHICO-1 - Digital Path,US 162.247.48.0/22 AS62710 RACK911 - Rack911,US 162.247.60.0/22 AS26311 RANCH-WIFI - Ranch WiFi LLC,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.8.0.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.1.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.2.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.3.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.4.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.5.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.6.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.7.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.16.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.16.0/21 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.24.0/21 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.32.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.33.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.34.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.35.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.36.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.37.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.38.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.39.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.40.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.41.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.42.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.43.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.44.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.45.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.46.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.47.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.48.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.49.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.50.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.51.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.52.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.53.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.54.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.55.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.56.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.57.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.58.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.59.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.61.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.62.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.63.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.64.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.80.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.81.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.82.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.83.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.84.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.85.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.86.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.87.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.88.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.89.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.90.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.91.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.92.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.93.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.94.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.95.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.96.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.128.0/21 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.136.0/21 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.143.0/24 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.144.0/20 AS36224 HCLTA94085 - HCL AMERICA INC,US 192.8.176.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.178.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.180.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.182.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.184.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.185.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.186.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.187.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.190.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.191.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.192.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.192.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.194.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.194.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.195.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.196.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.197.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.198.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.199.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.200.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.200.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.201.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.202.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.206.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.208.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.210.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.211.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.212.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.212.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.213.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.214.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.216.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.217.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.218.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.219.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.220.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.221.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.222.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.222.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.223.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.224.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.226.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.226.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.227.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.228.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.229.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.230.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.230.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.231.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.236.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.237.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.238.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.238.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.239.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.240.0/21 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.248.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.249.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.250.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.252.0/23 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.252.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.254.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.8.255.0/24 AS24084 HCL-TECH-IN PLOT NO: 3A, SECTOR 126, SEZ, NOIDA,IN 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 -Reserved AS-,ZZ 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.106.0/23 AS42444 -Reserved AS-,ZZ 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 196.216.129.0/24 AS36886 -Reserved AS-,ZZ 196.216.130.0/24 AS36886 -Reserved AS-,ZZ 196.216.131.0/24 AS36886 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.134.6.0/23 AS63063 APSALAR - Apsalar Inc.,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport-McMoran Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.87.166.0/24 AS26368 -Reserved AS-,ZZ 199.87.167.0/24 AS26368 -Reserved AS-,ZZ 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.102.73.0/24 AS26368 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.0.0.0/16 AS7545 TPG-INTERNET-AP TPG Telecom Limited,AU 203.83.16.0/21 AS17828 TIARE-AS-PG Tiare, a business unit of Pacific Mobile Communications.,PG 203.91.112.0/21 AS24559 203.91.112.0/24 AS24559 203.142.219.0/24 AS45149 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.14.64.0/20 AS14728 -Reserved AS-,ZZ 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 18 22:00:01 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Apr 2014 22:00:01 GMT Subject: BGP Update Report Message-ID: <201404182200.s3IM01Ru046229@wattle.apnic.net> BGP Update Report Interval: 10-Apr-14 -to- 17-Apr-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7029 152556 5.1% 289.5 -- WINDSTREAM - Windstream Communications Inc,US 2 - AS9829 72653 2.4% 78.0 -- BSNL-NIB National Internet Backbone,IN 3 - AS28573 40432 1.4% 16.5 -- NET Servi?os de Comunica??o S.A.,BR 4 - AS29571 35579 1.2% 173.6 -- CITelecom-AS,CI 5 - AS33597 33070 1.1% 194.5 -- INFORELAY - InfoRelay Online Systems, Inc.,US 6 - AS45169 30868 1.0% 2057.9 -- GLOBAL-DESCON-AS-AP Descon Limited,IN 7 - AS8402 28794 1.0% 16.7 -- CORBINA-AS OJSC "Vimpelcom",RU 8 - AS13188 27400 0.9% 26.4 -- BANKINFORM-AS TOV "Bank-Inform",UA 9 - AS31148 25814 0.9% 25.4 -- FREENET-AS Freenet Ltd.,UA 10 - AS48159 21835 0.7% 83.0 -- TIC-AS Telecommunication Infrastructure Company,IR 11 - AS13118 21752 0.7% 472.9 -- ASN-YARTELECOM OJSC Rostelecom,RU 12 - AS36998 21728 0.7% 13.3 -- SDN-MOBITEL,SD 13 - AS10620 21505 0.7% 9.5 -- Telmex Colombia S.A.,CO 14 - AS41691 21050 0.7% 877.1 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 15 - AS28146 19506 0.7% 354.7 -- Mhnet Empreendimentos Ltda,BR 16 - AS390 18473 0.6% 84.0 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group,US 17 - AS7552 18185 0.6% 16.5 -- VIETEL-AS-AP Viettel Corporation,VN 18 - AS14259 17893 0.6% 67.3 -- Gtd Internet S.A.,CL 19 - AS4755 17510 0.6% 12.3 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 20 - AS4775 16241 0.5% 193.3 -- GLOBE-TELECOM-AS Globe Telecoms,PH TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18135 8869 0.3% 8869.0 -- BTV BTV Cable television,JP 2 - AS34635 6517 0.2% 6517.0 -- LIBERTY-AS Liberty Poland S.A.,PL 3 - AS62892 2589 0.1% 2589.0 -- TW-EIS - Turner Broadcasting System, Inc.,US 4 - AS54465 7242 0.2% 2414.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 5 - AS20450 2148 0.1% 2148.0 -- THL16-ASN - Trojan Hosting, LLC.,US 6 - AS45169 30868 1.0% 2057.9 -- GLOBAL-DESCON-AS-AP Descon Limited,IN 7 - AS38909 6018 0.2% 2006.0 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 8 - AS58822 5835 0.2% 1945.0 -- IDNIC-UNESA-AS-ID Universitas Negeri Surabaya,ID 9 - AS2 3732 0.1% 2024.0 -- UDEL-DCN - University of Delaware,US 10 - AS6629 11113 0.4% 1852.2 -- NOAA-AS - NOAA,US 11 - AS22557 3251 0.1% 1625.5 -- UTHL - UNITED TLD HOLDCO LTD,KY 12 - AS3 1404 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 13 - AS33643 1393 0.1% 1393.0 -- JELLYBELLY - Jelly Belly Candy Company,US 14 - AS60345 1259 0.0% 1259.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 15 - AS2167 5665 0.2% 1133.0 -- HPES - Hewlett-Packard Company,US 16 - AS41691 21050 0.7% 877.1 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 17 - AS23295 1475 0.1% 737.5 -- EA-01 - Extend America,US 18 - AS54274 718 0.0% 718.0 -- HENNYPENNYCORP - Henny Penny Corporation,US 19 - AS57201 703 0.0% 703.0 -- EDF-AS Estonian Defence Forces,EE 20 - AS22688 653 0.0% 653.0 -- DOLGENCORP - Dollar General Corporation,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 21627 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 2 - 89.221.206.0/24 20887 0.7% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 3 - 121.52.144.0/24 13243 0.4% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 4 - 192.58.232.0/24 11100 0.3% AS6629 -- NOAA-AS - NOAA,US 5 - 166.149.142.0/24 10047 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 6 - 42.83.48.0/20 8869 0.3% AS18135 -- BTV BTV Cable television,JP 7 - 120.28.62.0/24 8038 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - 205.247.12.0/24 7778 0.2% AS6459 -- TRANSBEAM - I-2000, Inc.,US 9 - 222.127.0.0/24 7516 0.2% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 10 - 50.96.132.0/24 7466 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 11 - 206.152.15.0/24 7238 0.2% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 12 - 194.126.221.0/24 6517 0.2% AS34635 -- LIBERTY-AS Liberty Poland S.A.,PL 13 - 210.4.14.0/24 6010 0.2% AS38909 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 14 - 62.164.26.0/24 4315 0.1% AS2134 -- GSVNET-AS GS Virtual Network Produban,ES 15 - 199.187.118.0/24 3800 0.1% AS11054 -- LIVEPERSON - LivePerson, Inc.,US 16 - 186.211.97.0/24 3583 0.1% AS53062 -- G G NET - Telecomunica??es LTDA EPP,BR 17 - 78.109.192.0/20 3304 0.1% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 18 - 67.140.240.0/20 3213 0.1% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 19 - 187.85.144.0/24 3209 0.1% AS53062 -- G G NET - Telecomunica??es LTDA EPP,BR 20 - 67.141.226.0/24 3203 0.1% AS7029 -- WINDSTREAM - Windstream Communications Inc,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From Lee at asgard.org Fri Apr 18 22:01:24 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 18 Apr 2014 18:01:24 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: On 4/17/14 8:51 PM, "Matthew Kaufman" wrote: >While you're at it, the document can explain to admins who have been >burned, often more than once, by the pain of re-numbering internal >services at static addresses how IPv6 without NAT will magically solve >this problem. http://datatracker.ietf.org/doc/rfc6879/ This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation. Lee > >Matthew Kaufman > >(Sent from my iPhone) > >> On Apr 17, 2014, at 4:20 PM, Brandon Ross wrote: >> >> On Thu, 17 Apr 2014, Sander Steffann wrote: >> >>>> Also, I note your draft is entitled "Requirements for IPv6 Enterprise >>>> Firewalls." Frankly, no "enterprise" firewall will be taken seriously >>>> without address-overloaded NAT. I realize that's a controversial >>>> statement in the IPv6 world but until you get past it you're basically >>>> wasting your time on a document which won't be useful to industry. >>> >>> I disagree. While there certainly will be organisations that want such >>>a 'feature' it is certainly not a requirement for every (I hope most, >>>but I might be optimistic) enterprises. >> >> And I not only agree with Sander, but would also argue for a definitive >>statement in a document like this SPECIFICALLY to help educate the >>enterprise networking community on how to implement a secure border for >>IPv6 without the need for NAT. Having a document to point at that has >>been blessed by the IETF/community is key to helping recover the >>end-to-end principle. Such a document may or may not be totally in >>scope for a "firewall" document, but should talk about concepts like >>default-deny inbound traffic, stateful inspection and the use of address >>space that is not announced to the Internet and/or is completely blocked >>at borders for all traffic. >> >> Heck, we could even make it less specific to IPv6 and create a document >>that describes these concepts and show how NAT is not necessary nor wise >>for IPv4, either. (Yes, yes, other than address conservation.) >> >> -- >> Brandon Ross Yahoo & AIM: >>BrandonNRoss >> +1-404-635-6667 ICQ: >>2269442 >> Skype: >>brandonross >> Schedule a meeting: http://www.doodle.com/bross >> > > From Lee at asgard.org Fri Apr 18 22:10:26 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 18 Apr 2014 18:10:26 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> Message-ID: On 4/17/14 11:51 AM, "William Herrin" wrote: > >Also, I note your draft is entitled "Requirements for IPv6 Enterprise >Firewalls." Frankly, no "enterprise" firewall will be taken seriously >without address-overloaded NAT. I realize that's a controversial >statement in the IPv6 world but until you get past it you're basically >wasting your time on a document which won't be useful to industry. You've said this before, and it is still an absurdly over-broad statement. Many security professionals have deployed enterprise firewalls to their satisfaction without NAT-PT. We had this debate, what, a month ago? Your position hasn't changed. No new use cases have emerged. Are we done here? Lee From eugen at imacandi.net Fri Apr 18 22:19:26 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 19 Apr 2014 01:19:26 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 6:02 PM, William Herrin wrote: > On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu > wrote: > > On Thu, Apr 17, 2014 at 11:45 PM, George Herbert < > george.herbert at gmail.com> > > wrote: > >> You are missing the point. > >> > >> Granted, anyone who is IPv6 aware doing a green-field enterprise > firewall > >> design today should probably choose another way than NAT. > >> > > > > That's why you have gazzilions of IP addresses in IPv6, so you don't > need to > > NAT anything (among other things). I don't understand why people cling to > > NAT stuff when you can just route. > > 4. Defense in depth is a core principle of all security, network and > physical. If you don't practice it, your security is weak. Equipment > which is not externally addressable (due to address-overloaded NAT) > has an additional obstruction an adversary must bypass versus an > identical system where the equipment is externally addressable (1:1 > NAT, static port translation and simple routing). This constrains the > kinds of attacks an adversary may employ. > > Let's make it simple: Scenario (A) w/ IPv4 [Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address :80/TCP Scenario (B) w/ IPv6 [Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP In scenario (A) I hide a server behind a firewall and to a simple destination NAT (most common setup found in all companies). In scenario (B) I have a firewall rule that only allows port 80 to a machine in my network. Explain to me how from a security standpoint Scenario (A) is better than scenario (B). Defense in depth, to my knowledge - and feel free to correct me, is to have defenses at every point in the network and at the host level to protect against different attack vectors that are possible at those points. For example a firewall that understands traffic at the protocol level, a hardened application server, a hardened application, secure coding practices and so on depending of the complexity of the network and the security requirements. > Feel free to refute all four points. No doubt you have arguments you > personally find compelling. Your arguments will fall on deaf ears. At > best the arguments propose theory that runs contrary to decades of > many folks' experience. More likely the arguments are simply wrong. > > Just because some people have decades of experience, it doesn't mean they are right or know what they are doing. Eugeniu From eugen at imacandi.net Fri Apr 18 22:26:27 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 19 Apr 2014 01:26:27 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <53516FCF.9050000@per.reau.lt> <535176F1.5000302@per.reau.lt> Message-ID: On Fri, Apr 18, 2014 at 10:49 PM, Jim Clausing wrote: > And maybe I'm just dense, but ho one has been able to tell me how I > accomplish this in IPv6 without NAT, I have the requirement in certain > circumstances to transparently redirect all outbound DNS (well, on TCP or > UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers. No, > simply blocking it at the firewall and making the user "fix" the problem is > not an option (especially when the problem is created by malware). It is a > simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? Not > flaming or anything, but I really want to know how I'm supposed to > accomplish that in the ideal IPv6 world with no NAT? > > Nothing stops you from using NAT :) This discussion got a bit off track. I'm not saying NAT should be banned completely, I'm saying that with IPv6 we can actually simplify things a lot get rid of all hacks we had to do in the network do get services up and running (e.g. using a firewall's public ip address to hide several distinct services behind it on different hosts, like web, dns, smtp etc). I believe in simplicity, and now IPv6 for me makes things simple: I can have all the IP addresses I want and do not need to use hacks to get things working because no one would give 2048 IPv4 addresses just to do stuff with them and run lots of servers with "public" IP addresses. From Lee at asgard.org Fri Apr 18 22:36:15 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 18 Apr 2014 18:36:15 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On 4/17/14 4:45 PM, "George Herbert" wrote: > >> There's a fair argument to be made which says that kind of NAT is >> > unhealthy. If its proponents are correct, they'll win that argument >> > later on with NAT-incompatible technology that enterprises want. After >> > all, enterprise security folk didn't want the Internet in the >> > corporate network at all, but having a web browser on every desk is >> > just too darn useful. Where they won't win that argument is in the >> > stretch of maximum risk for the enterprise security folk. >> > >> > >> Any technology has associated risks, it's a matter of how you >> reduce/mitigate them. >> This paranoia thingie about IPv6 is getting a bit old. >> Just because you don't (seem to) understand how it works, it doesn't >>mean >> no one else should use it. > > > >You are missing the point. > >Granted, anyone who is IPv6 aware doing a green-field enterprise firewall >design today should probably choose another way than NAT. > >What you are failing is that "redesign firewall rules and approach from >scratch along with the IPv6 implementation" usually is not the chosen >path, >versus "re-implement the same v4 firewall rules and technologies in IPv6 >for the IPv6 implementation", because all the IPv6 aware net admins are >having too much to do dealing with all the other conversion issues, vendor >readiness all across the stack, etc. One of the things we (operator hat) like about IPv6 is that we get to clean up the mess we made in IPv4. In many cases we've significantly reduced the number of firewall rules or ACL lines, because we don't have disaggregate blocks we have to stack up. On my enterprise firewalls, I had a couple of DMZs, a couple of internal networks, and policies for what could get where. Firewalls referred to objects of various kinds, some of which had multiple addresses listed; putting servers with similar policies in a single /64 (or a /60 if I needed separate VLANs) would have simplified things. And the policy/rule difference between net 10 addresses internally and GUA prefixes internally is null. So, yeah, you have to give your firewall administrator time to walk through the rules and figure out what they ought to be in IPv6. Your firewall administrator has been wanting to clean up the rules for the last two years, anyway. Even if the above doesn't apply to you, what rules do you have that you can't copy? * deny ICMP to any. Can't do that. Must allow at least some messages. * deny (public address range) to (private address range) unless initiated form inside. Substitute external and internal prefixes. * deny (outside) to (DMZ) except (port ranges). Same in IPv6. * deny (inside) to (DMZ) except (port ranges). Same in IPv6. As I recall, the rules were in place even when we used NAT. If "no thinking required" firewall administration is your goal, I'm not clear how this interferes. > >Variations on this theme are part of why it's 2014 and IPv6 hasn't already >taken over the world. The more rabid IPv6 proponents have in fact shot >the >transition in the legs repeatedly, and those of us who have been on the >front lines would like you all to please shut up and get out of the way so >we can actually finish effecting v6 deployment and move on to mopping up >things like NAT later. > >This is why listening to operators is important. Some operators want NAT. Some don't. There are loud voices on both sides. Consensus seems slightly against. However, ULA + NPT works. Lee From Lee at asgard.org Fri Apr 18 22:37:28 2014 From: Lee at asgard.org (Lee Howard) Date: Fri, 18 Apr 2014 18:37:28 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On 4/18/14 4:33 PM, "George Herbert" wrote: > >If William and I fight that fight, lose it, and come back and tell you >"They won't go because insufficient NAT" you need to listen. I've fought >this in a dozen places and lost 8 of them, not because I don't know v6, >but >because the clients have inertia and politics around security posture >changes (and in some cases, PCI compliance regs). IPv6 evangelists are used to fighting inertia. PCI, however. . . anyone have any contacts there? Lee From surfer at mauigateway.com Fri Apr 18 22:47:25 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 18 Apr 2014 15:47:25 -0700 Subject: OT: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Message-ID: <20140418154725.4473A077@m0048139.ppops.net> :: There being no cable between the Hawaiian Islands :: and the mainland at the time Wait...what? https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific "The first trans-pacific cables were completed in 1902-03, linking the US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. Canada, Australia, New Zealand and Fiji were also linked in 1902. scott --- mikea at mikea.ath.cx wrote: From: Mike A On Mon, Apr 14, 2014 at 10:09:14PM +0000, Matthew Black wrote: > IIRC, the message was sent via courier instead of cable or telephone to > prevent interception. Did the military not even trust its own cryptographic > methods? Or did they not think withdrawal of the Japanese ambassador was not > very critical? The message was sent by Western Union. There being no cable between the Hawaiian Islands and the mainland at the time, the message went by commercial radio, in plaintext, and thence by civilian bicycle messenger (of Japanese ancestry, as it happened) to Fort Shafter, where it was read while the attack was in progress. David Kahn's fine book, _The Codebreakers_, discusses this in rather more detail. I recommend the original version; the paperback and later hardback editions contain rather less meat. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From bill at herrin.us Fri Apr 18 22:47:18 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 18:47:18 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 6:36 PM, Lee Howard wrote: > Some operators want NAT. Some don't. There are loud voices on both > sides. Consensus seems slightly against. Hi Lee, Some operators want NAT. That's it. End of discussion. This isn't a consensus question. Some operators want NAT. Period. Full stop. They'll hold off deploying and when IPv6 is sufficiently valuable, they'll pay someone to give them NAT. Regardless of whether the consensus of the IETF approves. These are the folks who made Gauntlet and its transparent proxies the #1 firewall product back during the bubble. They don't see the Internet the way you do. And if there are more of them than you think, IPv6 won't achieve sufficient value, won't reach critical mass. Then you'll really REALLY be stuck with NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mpalmer at hezmatt.org Fri Apr 18 23:02:04 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 19 Apr 2014 09:02:04 +1000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FFE1A.8030100@gont.com.ar> Message-ID: <20140418230204.GX15800@hezmatt.org> On Fri, Apr 18, 2014 at 06:37:28PM -0400, Lee Howard wrote: > On 4/18/14 4:33 PM, "George Herbert" wrote: > > > >If William and I fight that fight, lose it, and come back and tell you > >"They won't go because insufficient NAT" you need to listen. I've fought > >this in a dozen places and lost 8 of them, not because I don't know v6, > >but > >because the clients have inertia and politics around security posture > >changes (and in some cases, PCI compliance regs). > > IPv6 evangelists are used to fighting inertia. > PCI, however. . . anyone have any contacts there? If you get to talk to them, they'll probably look at you funny and say, "whatchoo talkin' 'bout?". PCI DSS *does not require NAT*. Anyone who says differently is selling something (probably a NAT box). You can refer to the source documents yourself -- they're freely available (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf, for example). As a testimonial, we run a no-NAT environment and got full PCI compliance with nary a twitch of the eyebrow. Didn't even have to argue the toss with anyone. - Matt From matthew at matthew.at Fri Apr 18 23:03:53 2014 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 18 Apr 2014 16:03:53 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: <648E2AC9-25E4-4293-925E-41CA5C101D97@matthew.at> Ignoring security, A is superior because I can change it to DNAT to the new server, or DNAT to the load balancer now that said server needs 10 replicas, etc. B requires re-numbering the server or *if* I am lucky enough that it is reached by DNS name and I can change that DNS promptly, assigning a new address and adding another firewall rule that didn't exist. Matthew Kaufman (Sent from my iPhone) > On Apr 18, 2014, at 3:19 PM, Eugeniu Patrascu wrote: > >> On Fri, Apr 18, 2014 at 6:02 PM, William Herrin wrote: >> >> On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu >> wrote: >>> On Thu, Apr 17, 2014 at 11:45 PM, George Herbert < >> george.herbert at gmail.com> >>> wrote: >>>> You are missing the point. >>>> >>>> Granted, anyone who is IPv6 aware doing a green-field enterprise >> firewall >>>> design today should probably choose another way than NAT. >>> >>> That's why you have gazzilions of IP addresses in IPv6, so you don't >> need to >>> NAT anything (among other things). I don't understand why people cling to >>> NAT stuff when you can just route. >> >> 4. Defense in depth is a core principle of all security, network and >> physical. If you don't practice it, your security is weak. Equipment >> which is not externally addressable (due to address-overloaded NAT) >> has an additional obstruction an adversary must bypass versus an >> identical system where the equipment is externally addressable (1:1 >> NAT, static port translation and simple routing). This constrains the >> kinds of attacks an adversary may employ. > Let's make it simple: > > Scenario (A) w/ IPv4 > [Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address > :80/TCP > > Scenario (B) w/ IPv6 > [Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP > > > In scenario (A) I hide a server behind a firewall and to a simple > destination NAT (most common setup found in all companies). > In scenario (B) I have a firewall rule that only allows port 80 to a > machine in my network. > > > Explain to me how from a security standpoint Scenario (A) is better than > scenario (B). > > > Defense in depth, to my knowledge - and feel free to correct me, is to have > defenses at every point in the network and at the host level to protect > against different attack vectors that are possible at those points. For > example a firewall that understands traffic at the protocol level, a > hardened application server, a hardened application, secure coding > practices and so on depending of the complexity of the network and the > security requirements. > > >> Feel free to refute all four points. No doubt you have arguments you >> personally find compelling. Your arguments will fall on deaf ears. At >> best the arguments propose theory that runs contrary to decades of >> many folks' experience. More likely the arguments are simply wrong. > Just because some people have decades of experience, it doesn't mean they > are right or know what they are doing. > > > Eugeniu From bill at herrin.us Fri Apr 18 23:06:53 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 19:06:53 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu wrote: > On Fri, Apr 18, 2014 at 6:02 PM, William Herrin wrote: >> 4. Defense in depth is a core principle of all security, network and >> physical. If you don't practice it, your security is weak. Equipment >> which is not externally addressable (due to address-overloaded NAT) >> has an additional obstruction an adversary must bypass versus an >> identical system where the equipment is externally addressable (1:1 >> NAT, static port translation and simple routing). This constrains the >> kinds of attacks an adversary may employ. > > Let's make it simple: > > Scenario (A) w/ IPv4 > [Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address > :80/TCP > > Scenario (B) w/ IPv6 > [Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP > > > In scenario (A) I hide a server behind a firewall and to a simple > destination NAT (most common setup found in all companies). > In scenario (B) I have a firewall rule that only allows port 80 to a machine > in my network. > > > Explain to me how from a security standpoint Scenario (A) is better than > scenario (B). So your question is: how does one variant of being externally addressable (simple routing with a packet filter or perhaps a stateful firewall) differ from another variant of being externally addressable (static inbound port translation)? Hell man, I don't like seeing these in IPv4 let alone IPv6. But when I'm asking a guy to make a much bigger leap of faith, like implementing IPv6, I don't plan to distract him with the fact that he's taken NAT=good from the situation where it's probably true and applied it to a situation where its value is more dubious. > Defense in depth, to my knowledge - and feel free to correct me, is to have > defenses at every point in the network and at the host level to protect > against different attack vectors that are possible at those point. And a heart attack is that you clutch your chest and fall over dead. You describe what defense in depth looks like, not what it is. Defense in depth is that you have a fence and a security guard and a spotlight. And a locked door, an alarm system and a safe too. But you don't just have the fence, the door and the safe, a single form of protection at each point. That would be a shallow defense. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From george.herbert at gmail.com Fri Apr 18 23:11:04 2014 From: george.herbert at gmail.com (George Herbert) Date: Fri, 18 Apr 2014 16:11:04 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: Lee Howard: > > So, yeah, you have to give your firewall administrator time to walk > through the rules and figure out what they ought to be in IPv6. Your > firewall administrator has been wanting to clean up the rules for the last > two years, anyway. The arrogance in this assertion is amazing. You're describing best practice. Yes, of course, you should have well documented technical and business needs for what's open and what's closed in firewalls, and should have traceability from the rules in place to the requirements, and be able to walk the rules and understand them and reinterpret them from v4 to v6, to a new firewall vendor, etc etc. Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE. Policymakers baldly asserting that it should be otherwise does not change reality on the ground in numerous enterprise customers. You and the others are ascribing to me and William blame for this. Shoot the messenger all you want; all we're doing it relaying on why we've failed to convert all our customers. It's not because we don't understand firewalls or v6. It's because the real world is substantially messier, often man-decades of work messier than you all assert it could possibly be. Again - policy community blinders on understanding what real systems are like out in the world has repeatedly shot the conversion in the legs. If you're going to start floating standards for this kind of stuff, then listen to feedback on why things are failing. On Fri, Apr 18, 2014 at 3:36 PM, Lee Howard wrote: > > > On 4/17/14 4:45 PM, "George Herbert" wrote: > > > >> There's a fair argument to be made which says that kind of NAT is > >> > unhealthy. If its proponents are correct, they'll win that argument > >> > later on with NAT-incompatible technology that enterprises want. After > >> > all, enterprise security folk didn't want the Internet in the > >> > corporate network at all, but having a web browser on every desk is > >> > just too darn useful. Where they won't win that argument is in the > >> > stretch of maximum risk for the enterprise security folk. > >> > > >> > > >> Any technology has associated risks, it's a matter of how you > >> reduce/mitigate them. > >> This paranoia thingie about IPv6 is getting a bit old. > >> Just because you don't (seem to) understand how it works, it doesn't > >>mean > >> no one else should use it. > > > > > > > >You are missing the point. > > > >Granted, anyone who is IPv6 aware doing a green-field enterprise firewall > >design today should probably choose another way than NAT. > > > >What you are failing is that "redesign firewall rules and approach from > >scratch along with the IPv6 implementation" usually is not the chosen > >path, > >versus "re-implement the same v4 firewall rules and technologies in IPv6 > >for the IPv6 implementation", because all the IPv6 aware net admins are > >having too much to do dealing with all the other conversion issues, vendor > >readiness all across the stack, etc. > > One of the things we (operator hat) like about IPv6 is that we get to > clean up the mess we made in IPv4. In many cases we've significantly > reduced the number of firewall rules or ACL lines, because we don't have > disaggregate blocks we have to stack up. > > On my enterprise firewalls, I had a couple of DMZs, a couple of internal > networks, and policies for what could get where. Firewalls referred to > objects of various kinds, some of which had multiple addresses listed; > putting servers with similar policies in a single /64 (or a /60 if I > needed separate VLANs) would have simplified things. And the policy/rule > difference between net 10 addresses internally and GUA prefixes internally > is null. > > So, yeah, you have to give your firewall administrator time to walk > through the rules and figure out what they ought to be in IPv6. Your > firewall administrator has been wanting to clean up the rules for the last > two years, anyway. > > Even if the above doesn't apply to you, what rules do you have that you > can't copy? > * deny ICMP to any. Can't do that. Must allow at least some messages. > * deny (public address range) to (private address range) unless initiated > form inside. Substitute external and internal prefixes. > * deny (outside) to (DMZ) except (port ranges). Same in IPv6. > * deny (inside) to (DMZ) except (port ranges). Same in IPv6. > > As I recall, the rules were in place even when we used NAT. If "no > thinking required" firewall administration is your goal, I'm not clear how > this interferes. > > > > > >Variations on this theme are part of why it's 2014 and IPv6 hasn't already > >taken over the world. The more rabid IPv6 proponents have in fact shot > >the > >transition in the legs repeatedly, and those of us who have been on the > >front lines would like you all to please shut up and get out of the way so > >we can actually finish effecting v6 deployment and move on to mopping up > >things like NAT later. > > > >This is why listening to operators is important. > > Some operators want NAT. Some don't. There are loud voices on both > sides. Consensus seems slightly against. > However, ULA + NPT works. > > Lee > > > -- -george william herbert george.herbert at gmail.com From bill at herrin.us Fri Apr 18 23:22:57 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 19:22:57 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 7:06 PM, William Herrin wrote: > On Fri, Apr 18, 2014 at 6:19 PM, Eugeniu Patrascu wrote: >> Defense in depth, to my knowledge - and feel free to correct me, is to have >> defenses at every point in the network and at the host level to protect >> against different attack vectors that are possible at those point. > > And a heart attack is that you clutch your chest and fall over dead. > You describe what defense in depth looks like, not what it is. > > Defense in depth is that you have a fence and a security guard and a > spotlight. And a locked door, an alarm system and a safe too. But you > don't just have the fence, the door and the safe, a single form of > protection at each point. That would be a shallow defense. Put more succinctly: depth isn't where you place the defenses, it's how many defenses times the quality of each defense that an adversary has to slip past. If an adversary has to bypass three defenses, that's more shallow than if he has to bypass the same three and three more. Whether all six are at the perimeter or half are at the perimeter two are at the host and one is in the application is only indirectly relevant to the depth of your defense. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Apr 18 23:34:56 2014 From: bill at herrin.us (William Herrin) Date: Fri, 18 Apr 2014 19:34:56 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 6:10 PM, Lee Howard wrote: > On 4/17/14 11:51 AM, "William Herrin" wrote: >>Also, I note your draft is entitled "Requirements for IPv6 Enterprise >>Firewalls." Frankly, no "enterprise" firewall will be taken seriously >>without address-overloaded NAT. I realize that's a controversial >>statement in the IPv6 world but until you get past it you're basically >>wasting your time on a document which won't be useful to industry. > > You've said this before, and it is still an absurdly over-broad statement. Hi Lee, That tends to happen when one takes a nuanced topic involving the intersection of technology with human social behavior and boils it down to two sentences. Perhaps I could have said, "taken seriously by enough of your target audience without." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gdt at gdt.id.au Sat Apr 19 00:24:23 2014 From: gdt at gdt.id.au (Glen Turner) Date: Sat, 19 Apr 2014 09:54:23 +0930 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FAD41.8040604@gont.com.ar> References: <534FAD41.8040604@gont.com.ar> Message-ID: <8B5C560E-698F-4E98-824E-305055DDD5F3@gdt.id.au> Fernando, Perhaps the document should have opened with a disclaimer that it is impossible to describe the full customer requirements for a firewall and thus a customer can reasonably add additional requirements. Then everyone knows where they stand and we avoid stupid (perhaps contractual) arguments that a firewall is acceptable solely because it meets this IETF publication. The document varies between specification and advice. My view is that it that as it stands the document is too specific to a particular type of firewall in a particular type of network to be anything other than advice, and should remove words such as "specify". My view is that there is scope for a different document -- or a much later revision of this document -- which actually specifies the minimum acceptable behaviour of a IPv6 network boundary firewall. You need an copyeditor. Expressions such as "but at times has also meant that a number of important/basic features have remained unimplemented by major firewall vendors, or that aforementioned features have not behaved as expected." are simply a poor use of the language. REQ GEN-5. Benchmarking is far too vague. Replace with a list of tests. REQ GEN-10 This is a requirement for the author of this specification. You should take that requirement and implement it throughout the document, and have a corresponding SNMP MIB which SHOULD be implemented. Counters we can't retrieve are pointless. REQ GEN-20 Define "basic access control list". Is that drop-and-count on destination address prefix? That would be the understanding based on the use of that term in Cisco IOS for IPv4. REQ GEN-30 Which transport layers are required for stateless inspection? TCP? UDP? OSPF? REQ GEN-50 This should not be a general requirement at all. There are good reasons not to use TCP proxying, not the least of which is the load on the firewall. REQ GEN-70 Doesn't allowing ACLs meet the uRPF requirement for non-routers? Is a vendor which supports ACLs automatically compliant? If not, state so. REQ GEN-80 Redirection of HTTPS traffic independent of other traffic is a specific feature for content providers not justifying a MUST for all firewalls. REQ SPC-10 This requirement squibs the most important single statement you can make about a IPv6 firewall: defining ICMP types which SHOULD be forwarded and those which SHOULD NOT when crossing a network boundary. This was a major issue for IPv4 and requires greater depth for IPv6 then is given here. REQ SPC-20 List the extension headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-30: List the routing headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-40 List the options which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-50 This requirement need much more work, as the specification is handwaving. REQ SPC-70 Cannot be implemented in anything but a simplistic network. ICMPv6 errors can come from anywhere on the forwarding path between the firewall and the host. The firewall cannot tell if a ICMPv6 from an unknown address is on the forwarding path for a connection. All it can do is validate uRPF, which is already a requirement. REQ SPC-80 Duplicate requirement REQ SPC-90 Poorly expressed. Rephrase in terms of packet parsing. REQ SPC-100 Rewriting Hop Limit? If you are going to proceed with the requirement then *reducing* Hop Limit is the only safe behaviour, and the only which a firewall SHOULD be required to support. If you are doing this to hide topology then the firewall manufacturer can reduce Hop Limit to the next lowest in a predefined set of values. Setting Hop Limit to an arbitrary value MAY be possible, and that should be accompanied by a note pointing out that this can lead to network failure unless all topologies containing the firewall are loop-free at all times. Why should a firewall support VPNs at all? Maybe you need to be clearer about the applicability of each section to a product. Do you mean that if a firewall implemented VPNs it must do so meeting these requirements? REQ VPN-20 is dynamic multipoint VPNs really a MUST for all VPN servers? You are saying that is it not possible for their to be a valid VPN design which does not include dynamic multipoint VPN. You'll excuse my doubt on that point. REQ VPN-60 needs more work. Some environments require certificates and keys to be manually altered. DOS. There are a lot of "must be able to protect against" which is handwaving. REQ DoS-70. This introduces a new requirement for filtering on VLAN or MPLS. That requirement needs to be higher in the document, not hidden. REQ DoS-80. I contest the MUST participate in blackhole infrastructure. There seems to be an assumption in this document that all valid IP firewalls designs are for use on Internet-connected networks. Ditto REQ DoS-85. REQ DoS-100. Underspecified. Or is "detected" the limit of the behaviour the firewall needs to implement to be compliant? (ie, it need not be able to drop). REQ DoS-110. "The minimum actions required are the following:" ? "send an email/SMS/pager text to the firewall administrator". No, this is not the IETF network management architecture. I'll refer you to SNMP Traps. Operators have already set up whatever escalation they see as necessary based on the IETF's standard (ie, international standard) network management architecture. REQ APP-10. Underspecified, "such as" is far too broad for a MUST requirement. REQ APP-20. So a device aimed at application filtering for VoIP calls must also implement spam filtering? The MUST says so. REQ SOC-10 Once again, there is a IETF network management architecture. The requirement is overbroad -- when I add a user to a directory service, which is then exposed via RADIUS so networking equipment can validate administrators, how can the firewall meet the MUST log for "new or removed administrators". Logging *all* added and removed "devices in a group" is asking for trouble. Network operators are more than familiar with the ability of routing protocols to make neighbours come and go at a rate which will defeat a logger which records *all* neighbour changes. In any case, the inconsistency between this "all" and the later log rate limiting is unresolved. REQ SOC-20 MUST provide: "Local log storage", "Real time log viewer", "Automatic log file compression", "Log file rotation". Again operators already have logging architectures which do all of this. It's a perfectly fine design choice for a firewall vendor to punt messages into that existing facility. REQ SOC-30 "all the logins, logouts and failed login attempts from firewall administrators", "any modifications or disabling of the firewall rules". If you are going to MUST that then also MUST the disabling of that. Leaving that much forensic material on a device an attacker might gain access to isn't a pretty thought. REQ SOC-60 "Full payload" is asking too much for a SHOULD. REQ SOC-80 "The firewall MUST be able to send logs in multiple ways and formats" It is a valid design choice for a vendor to implement one method of logging, especially if that method is the one which suits their customers. You are making a design choice (general market or specific market) best left to the vendor. REQ CON-10 Delete. Yet again -- encourage people to use the IETF's network management architecture, where facilities like "dashboards" already exist. Better still that integrate all of a customers networking and account information, not just their firewall. REQ CON-20 Delete REQ CON-30 Delete REQ CON-40 Delete REQ CON-50 Delete REQ REP-20 Delete. See previous comments about logging. In general this document seems to be overreach -- it is considering desirable attributes for a specific type of firewall in a specific type of network, but claims to be setting a minimum for all IPv6 firewalls. It could do with a considerable pruning to get to the core of what are the base requirements for a network boundary IPv6 firewall. -glen From gdt at gdt.id.au Sat Apr 19 00:24:23 2014 From: gdt at gdt.id.au (Glen Turner) Date: Sat, 19 Apr 2014 09:54:23 +0930 Subject: Requirements for IPv6 Firewalls In-Reply-To: <534FAD41.8040604@gont.com.ar> References: <534FAD41.8040604@gont.com.ar> Message-ID: <8B5C560E-698F-4E98-824E-305055DDD5F3@gdt.id.au> Fernando, Perhaps the document should have opened with a disclaimer that it is impossible to describe the full customer requirements for a firewall and thus a customer can reasonably add additional requirements. Then everyone knows where they stand and we avoid stupid (perhaps contractual) arguments that a firewall is acceptable solely because it meets this IETF publication. The document varies between specification and advice. My view is that it that as it stands the document is too specific to a particular type of firewall in a particular type of network to be anything other than advice, and should remove words such as "specify". My view is that there is scope for a different document -- or a much later revision of this document -- which actually specifies the minimum acceptable behaviour of a IPv6 network boundary firewall. You need an copyeditor. Expressions such as "but at times has also meant that a number of important/basic features have remained unimplemented by major firewall vendors, or that aforementioned features have not behaved as expected." are simply a poor use of the language. REQ GEN-5. Benchmarking is far too vague. Replace with a list of tests. REQ GEN-10 This is a requirement for the author of this specification. You should take that requirement and implement it throughout the document, and have a corresponding SNMP MIB which SHOULD be implemented. Counters we can't retrieve are pointless. REQ GEN-20 Define "basic access control list". Is that drop-and-count on destination address prefix? That would be the understanding based on the use of that term in Cisco IOS for IPv4. REQ GEN-30 Which transport layers are required for stateless inspection? TCP? UDP? OSPF? REQ GEN-50 This should not be a general requirement at all. There are good reasons not to use TCP proxying, not the least of which is the load on the firewall. REQ GEN-70 Doesn't allowing ACLs meet the uRPF requirement for non-routers? Is a vendor which supports ACLs automatically compliant? If not, state so. REQ GEN-80 Redirection of HTTPS traffic independent of other traffic is a specific feature for content providers not justifying a MUST for all firewalls. REQ SPC-10 This requirement squibs the most important single statement you can make about a IPv6 firewall: defining ICMP types which SHOULD be forwarded and those which SHOULD NOT when crossing a network boundary. This was a major issue for IPv4 and requires greater depth for IPv6 then is given here. REQ SPC-20 List the extension headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-30: List the routing headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-40 List the options which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-50 This requirement need much more work, as the specification is handwaving. REQ SPC-70 Cannot be implemented in anything but a simplistic network. ICMPv6 errors can come from anywhere on the forwarding path between the firewall and the host. The firewall cannot tell if a ICMPv6 from an unknown address is on the forwarding path for a connection. All it can do is validate uRPF, which is already a requirement. REQ SPC-80 Duplicate requirement REQ SPC-90 Poorly expressed. Rephrase in terms of packet parsing. REQ SPC-100 Rewriting Hop Limit? If you are going to proceed with the requirement then *reducing* Hop Limit is the only safe behaviour, and the only which a firewall SHOULD be required to support. If you are doing this to hide topology then the firewall manufacturer can reduce Hop Limit to the next lowest in a predefined set of values. Setting Hop Limit to an arbitrary value MAY be possible, and that should be accompanied by a note pointing out that this can lead to network failure unless all topologies containing the firewall are loop-free at all times. Why should a firewall support VPNs at all? Maybe you need to be clearer about the applicability of each section to a product. Do you mean that if a firewall implemented VPNs it must do so meeting these requirements? REQ VPN-20 is dynamic multipoint VPNs really a MUST for all VPN servers? You are saying that is it not possible for their to be a valid VPN design which does not include dynamic multipoint VPN. You'll excuse my doubt on that point. REQ VPN-60 needs more work. Some environments require certificates and keys to be manually altered. DOS. There are a lot of "must be able to protect against" which is handwaving. REQ DoS-70. This introduces a new requirement for filtering on VLAN or MPLS. That requirement needs to be higher in the document, not hidden. REQ DoS-80. I contest the MUST participate in blackhole infrastructure. There seems to be an assumption in this document that all valid IP firewalls designs are for use on Internet-connected networks. Ditto REQ DoS-85. REQ DoS-100. Underspecified. Or is "detected" the limit of the behaviour the firewall needs to implement to be compliant? (ie, it need not be able to drop). REQ DoS-110. "The minimum actions required are the following:" ? "send an email/SMS/pager text to the firewall administrator". No, this is not the IETF network management architecture. I'll refer you to SNMP Traps. Operators have already set up whatever escalation they see as necessary based on the IETF's standard (ie, international standard) network management architecture. REQ APP-10. Underspecified, "such as" is far too broad for a MUST requirement. REQ APP-20. So a device aimed at application filtering for VoIP calls must also implement spam filtering? The MUST says so. REQ SOC-10 Once again, there is a IETF network management architecture. The requirement is overbroad -- when I add a user to a directory service, which is then exposed via RADIUS so networking equipment can validate administrators, how can the firewall meet the MUST log for "new or removed administrators". Logging *all* added and removed "devices in a group" is asking for trouble. Network operators are more than familiar with the ability of routing protocols to make neighbours come and go at a rate which will defeat a logger which records *all* neighbour changes. In any case, the inconsistency between this "all" and the later log rate limiting is unresolved. REQ SOC-20 MUST provide: "Local log storage", "Real time log viewer", "Automatic log file compression", "Log file rotation". Again operators already have logging architectures which do all of this. It's a perfectly fine design choice for a firewall vendor to punt messages into that existing facility. REQ SOC-30 "all the logins, logouts and failed login attempts from firewall administrators", "any modifications or disabling of the firewall rules". If you are going to MUST that then also MUST the disabling of that. Leaving that much forensic material on a device an attacker might gain access to isn't a pretty thought. REQ SOC-60 "Full payload" is asking too much for a SHOULD. REQ SOC-80 "The firewall MUST be able to send logs in multiple ways and formats" It is a valid design choice for a vendor to implement one method of logging, especially if that method is the one which suits their customers. You are making a design choice (general market or specific market) best left to the vendor. REQ CON-10 Delete. Yet again -- encourage people to use the IETF's network management architecture, where facilities like "dashboards" already exist. Better still that integrate all of a customers networking and account information, not just their firewall. REQ CON-20 Delete REQ CON-30 Delete REQ CON-40 Delete REQ CON-50 Delete REQ REP-20 Delete. See previous comments about logging. In general this document seems to be overreach -- it is considering desirable attributes for a specific type of firewall in a specific type of network, but claims to be setting a minimum for all IPv6 firewalls. It could do with a considerable pruning to get to the core of what are the base requirements for a network boundary IPv6 firewall. -glen From rdobbins at arbor.net Sat Apr 19 01:53:16 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 19 Apr 2014 01:53:16 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> Message-ID: <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> On Apr 19, 2014, at 1:20 AM, William Herrin wrote: > There isn't much a firewall can do to break it. As someone who sees firewalls break the Internet all the time for those whose packets have the misfortune to traverse one, I must respectfully disagree. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From jeff-kell at utc.edu Sat Apr 19 02:04:35 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 18 Apr 2014 22:04:35 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> Message-ID: <5351D9B3.2030902@utc.edu> On 4/18/2014 9:53 PM, Dobbins, Roland wrote: > On Apr 19, 2014, at 1:20 AM, William Herrin wrote: > >> There isn't much a firewall can do to break it. > As someone who sees firewalls break the Internet all the time for those whose packets have the misfortune to traverse one, I must respectfully disagree. If end-to-end connectivity is your idea of "the Internet", then a firewall's primary purpose is to break the Internet. It's how we provide access control. If a firewall blocks "legitimate, authorized" access then perhaps it adds to breakage (PMTU, ICMP, other blocking) but otherwise it works. As to address the other argument in this threat on NAT / private addressing, PCI requirement 1.3.8 pretty much requires RFC1918 addressing of the computers in scope... has anyone hinted at PCI for IPv6? Jeff From cb.list6 at gmail.com Sat Apr 19 02:10:44 2014 From: cb.list6 at gmail.com (TheIpv6guy .) Date: Fri, 18 Apr 2014 19:10:44 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> Message-ID: On Fri, Apr 18, 2014 at 6:53 PM, Dobbins, Roland wrote: > > On Apr 19, 2014, at 1:20 AM, William Herrin wrote: > >> There isn't much a firewall can do to break it. > > As someone who sees firewalls break the Internet all the time for those whose packets have the misfortune to traverse one, I must respectfully disagree. > > ;> > Yep. I have seen many more security / availability events caused by a firewall tipping over than anything else. Firewalls tend to be put in as single points of failure so that there is one point of inspection / policy enforcement. And, HA pairs are generally a joke. 2 failure mode i have seen: Firewall ALG saw a SIP packet option that it did not like, so it reloaded itself. In the process, it reflected the session state with fatal information to it's HA mate, which immediately failed. Same story with SYN floods, too many sessions coming in, FW cannot keep up with figuring out what is good, what is bad... Kablamoo. The firewall is the weakest link in the chain. Oh, and, then there is this... where the firewall, which is the one point of security control is in fact an open tap to your entire network http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140110-sbd But, it leads to clever things like this where home routers get hijacked as proxies...for whatever ... http://danmcinerney.org/how-to-exploit-home-routers-for-anonymity/ I think stateful network based firewalls are more harm than good and I would like host and applications to be the ultimate front line of defense. To each their own. Just a data point. Enjoy CB > ----------------------------------------------------------------------- > Roland Dobbins // > > Luck is the residue of opportunity and design. > > -- John Milton > > From rdobbins at arbor.net Sat Apr 19 02:10:45 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 19 Apr 2014 02:10:45 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351D9B3.2030902@utc.edu> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> Message-ID: <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> On Apr 19, 2014, at 9:04 AM, Jeff Kell wrote: > It's how we provide access control. Firewalls <> 'access control'. Firewalls are one (generally, very poor and grossly misused) way of providing access control. They're often wedged in where stateless ACLs in hardware-based routers and/or layer-3 switches would do a much better job, such as in front of servers: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mpalmer at hezmatt.org Sat Apr 19 02:16:09 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sat, 19 Apr 2014 12:16:09 +1000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351D9B3.2030902@utc.edu> References: <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> Message-ID: <20140419021608.GY15800@hezmatt.org> On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote: > As to address the other argument in this threat on NAT / private > addressing, PCI requirement 1.3.8 pretty much requires RFC1918 addressing > of the computers in scope... has anyone hinted at PCI for IPv6? 1.3.8 lists use of RFC1918 address space as one of four possible implementations, immediately after the phrase "may include, but are not limited to". I don't interpret that as "pretty much requires RFC1918". Now, if you'd like to claim that 1.3.8 is completely useless, I won't argue with you -- it's security-by-obscurity of the worst possible form. But don't blame PCI compliance for any inability to deploy IPv6, because it just ain't true. - Matt From erey at ernw.de Sat Apr 19 02:58:39 2014 From: erey at ernw.de (Enno Rey) Date: Sat, 19 Apr 2014 04:58:39 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: <535175F8.2050907@dougbarton.us> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <20140418075731.GA10795@ernw.de> <535175F8.2050907@dougbarton.us> Message-ID: <20140419025838.GA17947@ernw.de> Hi, On Fri, Apr 18, 2014 at 11:59:04AM -0700, Doug Barton wrote: > On 04/18/2014 12:57 AM, Enno Rey wrote: > > I fully second Sander's input. I've been involved in IPv6 planning in a number of very large enterprises now and_none_ of them required/asked for (66/overloading) NAT for their firewall environments. A few think about very specific deployments of NPTv6 like stuff for connections to supplier/partner networks (to map those to their own address space) but these are corner cases not even relevant for their "firewalls". > > How many of those networks were implementing with IPv6 PI space? all of them My > experience has been that those customers are not interested in IPv6 NAT, > but instead utilize network segmentation to define "internal" vs. > "external." > > OTOH, customers for whom PI space is not realistic (for whatever > reasons, and yes there are reasons) are very interested in the > combination of ULA + NTPv6 to handle internal resources without having > to worry about renumbering down the road. true. it's just we don't see many of those (actually I've yet to encounter a single one) and it could be debatable if they belong to "Enterprise" networks (which is in the title of the ID). best Enno > > Doug > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From jeff-kell at utc.edu Sat Apr 19 03:29:40 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 18 Apr 2014 23:29:40 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> Message-ID: <5351EDA4.6030009@utc.edu> On 4/18/2014 10:10 PM, Dobbins, Roland wrote: > On Apr 19, 2014, at 9:04 AM, Jeff Kell wrote: > >> It's how we provide access control. > Firewalls <> 'access control'. > > Firewalls are one (generally, very poor and grossly misused) way of providing access control. They're often wedged in where stateless ACLs in hardware-based routers and/or layer-3 switches would do a much better job, such as in front of servers: I call BS... what do you expect closes the gap, host firewalls? Most 3rd party crap has no firewalls and gets no specific rules for local LANs or authorized users. Firewalls are front-line defense, for the crap that is too generic / misconfigured to protect itself. And there are tons of these. Anyone ever pentested you? It's an enlightening experience. Jeff From rdobbins at arbor.net Sat Apr 19 04:10:26 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 19 Apr 2014 04:10:26 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351EDA4.6030009@utc.edu> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> Message-ID: <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> On Apr 19, 2014, at 10:29 AM, Jeff Kell wrote: > I call BS... You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, because it's very easy to knock them over due to state exhaustion. In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts. Also, you might want to search the NANOG email archive on this topic. There's lots of previous discussion, which boils down to the fact that serious organizations running serious applications/services don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers. The only way to secure hosts/applications/service against compromise is via those hosts/applications/services themselves. Inserting stateful middleboxes doesn't actually accomplish anything to enhance confidentiality and integrity, actually increases the attack surface due to middlebox exploits (read the numerous security notices for various commercial and open-source stateful firewalls for compromise exploits), and has a negative impact on availability. Again, take a look at this preso: And take a look at pp. 17-18 of this preso: I've seen 3mb/sec of spoofed SYN-flooding take down a supposedly 20gb/sec stateful firewall due to state exhaustion in about 2 minutes; I've seen 6kpps of HOIC take down a supposedly 10gb/sec load-balancer due to state-table exhaustion in 60 seconds. Each of those devices required an ~30-minute hard reboot - and those are just two of too many examples to keep track of, heh. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From mysidia at gmail.com Sat Apr 19 04:16:56 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 18 Apr 2014 23:16:56 -0500 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Fri, Apr 18, 2014 at 10:02 AM, William Herrin wrote: It would appear point (5) in favor of NAT with IPv6 is the only point that has any merit there. (1) to (4) are just rationalizations. None of (1) to (4) are the reasons IPv4 got NAT, none are valid, and none are good reasons to bring NAT to IPv6 or use NAT in designs of IPv6 networks. You could also add as good reasons.. (6) Requirement for NAT based on personal preference, and... (7) "You don't need this NAT function anymore," is not a good reason to 'withhold the feature as a design and implementation option'. -- "IPv6 is clearly not as mature as IPv4, when my IPv4 router has greater flexibility in translation options" --- (1) to (4) are just excuses for people who want NAT to not admit the real reasons which are illogical, BUT still important. (5) is quite valid. Also, you cannot fight it. When you have customers that demand NAT, even though there is absolutely no sound reason for NAT anymore. The users will still buy whatever gives them the feature they deemed important, based on their experience with IPv4. The fact of the matter is, the demand has irrational sources contributing: comfort and change-aversity and loss-aversity. People want to keep and not lose their IPv4 or their IPv4 features. They expect to cherrypick IPv6's advantages and not lose any functionality from V4 or have any extra work to do, or re-thinking of their understanding of IP networking to be doing. So if you are building IPv6 firewall SW, you should definitely include any NAT functionality you believe that many of your potential customers will demand. The fact is... as a product vendor to move the maximal number of people to the IPv6 paradigm: you are still going to have to cater to people with IPv4-like thinking. Therefore... I fully expect all the NAT features of IPv4 to have an IPv6 equivalent appearing. > 1. Easier to manage the network if the IPv4 and IPv6 versions are [...] > 2. Risk management - developing a new operating posture for a new [...] > 3. Renumbering - works about as well in IPv6 as in IPv4, which is to [...] > 4. Defense in depth is a core principle of all security, network and [...] 5. > Feel free to refute all four points. No doubt you have arguments you > personally find compelling. Your arguments will fall on deaf ears. At > best the arguments propose theory that runs contrary to decades of > many folks' experience. More likely the arguments are simply wrong. -- -JH From alter3d at alter3d.ca Sat Apr 19 04:25:27 2014 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sat, 19 Apr 2014 00:25:27 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351EDA4.6030009@utc.edu> References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> Message-ID: <5351FAB7.3080004@alter3d.ca> On 4/18/2014 11:29 PM, Jeff Kell wrote: > Anyone ever pentested you? It's an enlightening experience. Jeff At a previous job, we hired a company (with CISSP-certified pentesters) to do a black box pentest of our network. Things I was "enlightened" by: - It's OK to work in a highly technical field with no technical background. The pentester they sent couldn't get Backtrack running on the machine we had provided to him because the onboard video didn't support 32-bit color under Linux (IIRC, a P4-era Dell desktop). The concept of reading log files to find out what was wrong was completely foreign to him, as was the required 1-line fix in the X11 config. - It's OK to not report a horribly insecure box to the client if you're stupid or lazy. We had set up a honeypot box on our network to see if the pentester would find it, and despite tons of log evidence showing that he both found the box and the weak services... no mention of it was made on the report submitted to us. Needless to say, this made the entire report suspect, and my boss had great pleasure in yelling at the vendor when I brought it to her attention. - It's OK to not know anything at all about the tools you're using to do the job. The pentester called us because he was getting "weird nmap results" and couldn't grok them (and insisted that we had given him the wrong IP addresses). The reason? A firewall that dropped unwanted traffic. Seriously. CISSP certified and he couldn't figure out how to detect firewalls that have a default-drop policy. - It's OK to rely only on automated tools and blindly trust their output. No attempts at targeted attacks were made, despite being specifically asked and authorized to do destructive testing against our test servers. We KNEW from our own testing that there were some SQL injection and buffer overflow holes there (again, some even placed on purpose to see what he'd find), and his automated tools didn't find them so he assumed everything was fine. And that's just SOME of the stuff from that particular experience. Enlightening? Yes. I now do my own pentesting, because I'd rather not waste $20K+ on a report of questionable quality done by someone who may or may not know how to run nmap, let alone more technical application-level attacks. There are undoubtedly some good pen-testers out there that are worth every dime they charge. However, like every other technical speciality, there are a LOT of really, really, really terrible practitioners. Shelling out big money to hopefully find the former in a field of mostly the latter is bound to be an exercise in both frustration and misspent resources. From eugen at imacandi.net Sat Apr 19 08:45:09 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 19 Apr 2014 11:45:09 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: <648E2AC9-25E4-4293-925E-41CA5C101D97@matthew.at> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <648E2AC9-25E4-4293-925E-41CA5C101D97@matthew.at> Message-ID: On Sat, Apr 19, 2014 at 2:03 AM, Matthew Kaufman wrote: > Ignoring security, A is superior because I can change it to DNAT to the > new server, or DNAT to the load balancer now that said server needs 10 > replicas, etc. > > B requires re-numbering the server or *if* I am lucky enough that it is > reached by DNS name and I can change that DNS promptly, assigning a new > address and adding another firewall rule that didn't exist. > > What you're describing is how to set up infrastructure to handle rapidly changing environments in cases where the whole setup not thought out in it's entirety to account for that. My point with IPv6 is that we get the chance to clear up all the mess that happened with IPv4 (or the lack of addresses in IPv4) with NATs and NATs over even more NAT. I'm not arguing against NAT completely in IPv6, I'm arguing against applying IPv4 style thinking applied to IPv6. Eugeniu From eugen at imacandi.net Sat Apr 19 08:52:02 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sat, 19 Apr 2014 11:52:02 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351D9B3.2030902@utc.edu> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> Message-ID: On Sat, Apr 19, 2014 at 5:04 AM, Jeff Kell wrote: > On 4/18/2014 9:53 PM, Dobbins, Roland wrote: > > On Apr 19, 2014, at 1:20 AM, William Herrin wrote: > > > >> There isn't much a firewall can do to break it. > > As someone who sees firewalls break the Internet all the time for those > whose packets have the misfortune to traverse one, I must respectfully > disagree. > > If end-to-end connectivity is your idea of "the Internet", then a > firewall's primary purpose is to break the Internet. It's how we > provide access control. > > If a firewall blocks "legitimate, authorized" access then perhaps it > adds to breakage (PMTU, ICMP, other blocking) but otherwise it works. > > As to address the other argument in this threat on NAT / private > addressing, PCI requirement 1.3.8 pretty much requires RFC1918 > addressing of the computers in scope... has anyone hinted at PCI for IPv6? > > 1.3.8: Do not disclose private IP addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to: - Network Address Translation (NAT) - Placing servers containing cardholder data behind proxy servers/firewalls or content caches - Removal or filtering of route advertisements for private networks that employ registered addressing - Internal use of RFC1918 address space instead of registered addresses. >From what I see in the requirement it says "don't let people on the outside know that your webserver has 192.168.100.200 as an IP address", not that you should NAT everything. Also if you are lucky enough to have lots of IPv4 addresses and assign them to all your servers/devices in your PCI compliant infrastructure this requirement (1.3.8) will not even apply to you. Eugeniu From fw at deneb.enyo.de Sat Apr 19 10:23:37 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 19 Apr 2014 12:23:37 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: <53516168.6010002@per.reau.lt> (Simon Perreault's message of "Fri, 18 Apr 2014 13:31:20 -0400") References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> Message-ID: <87k3alty6u.fsf@mid.deneb.enyo.de> * Simon Perreault: > Le 2014-04-18 13:25, Mike Hale a ?crit : >> I agree with Bill. You can poopoo NAT all you want, but it's a fact >> of most networks and will continue to remain so until you can make a >> compelling case to move away from it. > > Does that mean all IPv6 firewalls should support NAT? In the sense that they "MUST be able to provide email filtering features": yes. > Remember, we're aiming for a base set of requirements applying to > all IPv6 firewalls. The document has more than just base requirements. From joelja at bogus.com Sat Apr 19 14:29:42 2014 From: joelja at bogus.com (joel jaeggli) Date: Sat, 19 Apr 2014 07:29:42 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5351D9B3.2030902@utc.edu> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> Message-ID: <53528856.9000604@bogus.com> On 4/18/14, 7:04 PM, Jeff Kell wrote: > PCI requirement 1.3.8 pretty much requires RFC1918 > addressing of the computers in scope... It does not 1.3.8 Do not disclose private IP addresses and routing information to unauthorized parties. Note : Methods to obscure IP addressing may include, but are not limited to:  Network Address Translation (NAT)  Placing servers containing cardholder data behind proxy servers/firewalls or content caches,  Removal or filtering of route advertisements for private networks that employ registered addressing,  Internal use of RFC1918 address space instead of registered addresses. from version two with further explication https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf version 3 https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf > has anyone hinted at PCI for IPv6? If by hinted at you mean deployed in pci compliant environments then yes. > Jeff > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From gary.buhrmaster at gmail.com Sat Apr 19 15:47:31 2014 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 19 Apr 2014 15:47:31 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <53528856.9000604@bogus.com> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <53528856.9000604@bogus.com> Message-ID: On Sat, Apr 19, 2014 at 2:29 PM, joel jaeggli wrote: > On 4/18/14, 7:04 PM, Jeff Kell wrote: >> PCI requirement 1.3.8 pretty much requires RFC1918 >> addressing of the computers in scope... > > It does not You are correct. In theory. However, for those organizations that have chosen to use a firewall with NAT rather than apply one of the other alternatives, the practice says that to implement IPv6, the firewall they want needs to do NAT. Again, telling someone that they are doing it wrong (and that they should change) will not be successful. Especially if the network people do not talk to the systems people, and do not talk to the applications people, and do not talk to the auditors.... Not that any organization would be so stove-piped. Perhaps there should be a I-D BCP about not stove-piping organizations too. And, while PCI compliance was the straw-man, I have seen other audit results that called out a lack of using NAT too (even though they, also, should not have done so; it was the policy that they should have called out. But that would require real understanding rather than a checklist). Gary From ljb at merit.edu Sat Apr 19 16:55:18 2014 From: ljb at merit.edu (Larry J. Blunk) Date: Sat, 19 Apr 2014 12:55:18 -0400 (EDT) Subject: NANOG Mail Server Maintenance In-Reply-To: <113813365.653074.1397925450270.JavaMail.zimbra@merit.edu> Message-ID: <1572796038.653231.1397926518720.JavaMail.zimbra@merit.edu> Greetings, The NANOG Mail server will be transitioning to a new system next Saturday, April 26th. The maintenance window for this transition will be from 10:00 - 10:30 UTC. This will impact the main NANOG list and associated lists hosted on mailman.nanog.org. The addresses for the server will be changing, but they will remain within the same prefixes (50.31.151.64/28 and 2001:1838:2001:8::/64). Regards, Larry Blunk NANOG Communications Committee From george.herbert at gmail.com Sat Apr 19 18:08:26 2014 From: george.herbert at gmail.com (George William Herbert) Date: Sat, 19 Apr 2014 11:08:26 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: Sent from Kangphone On Apr 18, 2014, at 9:10 PM, "Dobbins, Roland" wrote: > You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, I don't know where you find ideas like this. There are stateful firewalls in the security packages in front of all the internet facing servers in all the major service providers I've worked at. Not *just* stateful firewalls, but they're in there. That one company is trying something different does not mean there isn't widespread standardized use of the technology. -george william herbert george.herbert at gmail.com From lukasz at bromirski.net Sat Apr 19 18:44:14 2014 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Sat, 19 Apr 2014 20:44:14 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.603000 9@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: On 19 Apr 2014, at 20:08, George William Herbert wrote: > On Apr 18, 2014, at 9:10 PM, "Dobbins, Roland" wrote: > >> You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, > > I don't know where you find ideas like this. From real world. > There are stateful firewalls in the security packages in front of all the internet facing servers in all the major service providers I've worked at. Not *just* stateful firewalls, but they're in there. There?s no sense in putting stateful firewall in front of DNS server, unless the DNS server is underperforming, and then it should be exchanged and not protected by stateful firewall. You can try to protect mail/WWW servers with stateful firewalls, but it often achieves nothing but makes the firewalls weakest link in the setup. And tuning it to perform reasonably well in normal and peak traffic is usually not achievable. In case of DDoS attack, the stateful firewall goes out first. I?ve seen them burn too. To protect high-performance services, you do stateless filtering + NetFlow based QoS policies, or shunt to dedicated DDoS filtering boxes. Adding state where it?s not needed, is sign of bad design. And just because a lot of people do that, doesn?t make it any better. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mysidia at gmail.com Sat Apr 19 18:44:22 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 19 Apr 2014 13:44:22 -0500 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: On Sat, Apr 19, 2014 at 1:08 PM, George William Herbert wrote: > On Apr 18, 2014, at 9:10 PM, "Dobbins, Roland" wrote: > I don't know where you find ideas like this. > > There are stateful firewalls in the security packages in front of all the internet facing servers in all the major service providers I've worked at. Not *just* stateful firewalls, but they're in there. > That one company is trying something different does not mean there isn't widespread standardized use of the technology. There is not widespread use of stateful firewall units with the stateful element as a single point of failure in front of large public web farms. This is different from "security package software" on individual web servers. There is plenty of one-off usage in small web farms, where DDoS is not a concern. > -george william herbert -- -JH From george.herbert at gmail.com Sat Apr 19 19:32:04 2014 From: george.herbert at gmail.com (George William Herbert) Date: Sat, 19 Apr 2014 12:32:04 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: On Apr 19, 2014, at 11:44 AM, Jimmy Hess wrote: > There is not widespread use of stateful firewall units with the > stateful element as a single point of failure in front of large public > web farms. I have 20-30,000 counterexamples in mind that I worked with directly in the last decade. And "SPOF" is changing the goalposts; nobody single-strings anything at scale. -george william herbert george.herbert at gmail.com Sent from Kangphone From dougb at dougbarton.us Sat Apr 19 20:34:32 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 19 Apr 2014 13:34:32 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <20140419025838.GA17947@ernw.de> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <20140418075731.GA10795@ernw.de> <535175F8.2050907@dougbarton.us> <20140419025838.GA17947@ernw.de> Message-ID: <5352DDD8.6080202@dougbarton.us> On 04/18/2014 07:58 PM, Enno Rey wrote: > Hi, > > On Fri, Apr 18, 2014 at 11:59:04AM -0700, Doug Barton wrote: >> On 04/18/2014 12:57 AM, Enno Rey wrote: >>> I fully second Sander's input. I've been involved in IPv6 planning in a number of very large enterprises now and_none_ of them required/asked for (66/overloading) NAT for their firewall environments. A few think about very specific deployments of NPTv6 like stuff for connections to supplier/partner networks (to map those to their own address space) but these are corner cases not even relevant for their "firewalls". >> >> How many of those networks were implementing with IPv6 PI space? > > all of them Et Voila! > My >> experience has been that those customers are not interested in IPv6 NAT, >> but instead utilize network segmentation to define "internal" vs. >> "external." >> >> OTOH, customers for whom PI space is not realistic (for whatever >> reasons, and yes there are reasons) are very interested in the >> combination of ULA + NTPv6 to handle internal resources without having >> to worry about renumbering down the road. > > true. it's just we don't see many of those (actually I've yet to encounter a single one) and it could be debatable if they belong to "Enterprise" networks (which is in the title of the ID). If the draft wants to define "enterprise network" as "big enough and technically capable enough to warrant PI space" I wouldn't necessarily object, but the business customers I work with who aren't, might. Doug From neil at knd.org Sun Apr 20 01:24:25 2014 From: neil at knd.org (Neil Davidson) Date: Sat, 19 Apr 2014 19:24:25 -0600 Subject: AT&T Wireless Message-ID: Can someone from AT&T Wireless contact me off-list? ... thanks ... n From rdobbins at arbor.net Sun Apr 20 01:27:16 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 20 Apr 2014 01:27:16 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: On Apr 20, 2014, at 2:32 AM, George William Herbert wrote: > I have 20-30,000 counterexamples in mind that I worked with directly in the last decade. People do stupid things all the time - but generally, it's hard to do them at scale. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From eugen at imacandi.net Sun Apr 20 06:47:20 2014 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 20 Apr 2014 09:47:20 +0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: On Sun, Apr 20, 2014 at 4:27 AM, Dobbins, Roland wrote: > > On Apr 20, 2014, at 2:32 AM, George William Herbert < > george.herbert at gmail.com> wrote: > > > I have 20-30,000 counterexamples in mind that I worked with directly in > the last decade. > > People do stupid things all the time - but generally, it's hard to do them > at scale. > Just go watch government at work :) From rdobbins at arbor.net Sun Apr 20 07:41:03 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 20 Apr 2014 07:41:03 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: <1AEE3517-4C2D-4E8E-9C71-A4B0FBD7E3D0@arbor.net> On Apr 20, 2014, at 1:47 PM, Eugeniu Patrascu wrote: > Just go watch government at work :) Precisely. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins at arbor.net Sun Apr 20 14:04:28 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 20 Apr 2014 14:04:28 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <3F1DEC33DC0C274C99B16F166A25DF75CDB0B941@aucbr1ex1.ahq.net.au> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <3F1DEC33DC0C274C99B16F166A25DF75CDB0B941@aucbr1ex1.ahq.net.au> Message-ID: <20E4FBF7-7DAD-4801-8AC3-E940219B7882@arbor.net> On Apr 20, 2014, at 8:52 PM, Seamus Ryan wrote: > Similarly if most of the time I just need to protect my relatively simple network by implementing a few separate zones I will get a firewall, im not going to deploy expensive stateless devices that can push a billion pps everywhere and send flow stats to expensive DDoS mitigation hardware *cough* arbor *cough* just so I can protect against an attack that many only happen a few times a year. I'm talking about stateless ACLs on hardware-based routers and switches for enforcing network access policies - nothing to do with Arbor. Arbor doesn't make routers or switches. Stateful firewalls make servers far more vulnerable to DDoS (and to compromise, for that matter; they broaden the attack surface amazingly) than they would be without deploying stateful firewalls. Vendors of commercial DDoS mitigation solutions [full disclosure: I work for a vendor of such solutions] who wish to drum up business should be *encouraging* organizations to deploy stateful firewalls, not discouraging them from doing so. Anyone who knows me knows that I do *not* violate NANOG rules (or the rules of any other community list) by pushing commercial solutions. What I advocate is for folks to avoid spending extra money and time and effort in order to negatively impact their security posture, and instead utilize their existing investments in network infrastructure devices to enforce network access policies via stateless ACLs, as well as to deploy reaction/mitigation tools such as S/RTBH and flowspec. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From s.ryan at uber.com.au Sun Apr 20 13:52:27 2014 From: s.ryan at uber.com.au (Seamus Ryan) Date: Sun, 20 Apr 2014 13:52:27 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> Message-ID: <3F1DEC33DC0C274C99B16F166A25DF75CDB0B941@aucbr1ex1.ahq.net.au> Every time I see a Firewall related thread on one of the *NOG lists I count how many replies Roland will make before posting his State of Danger presentation. We got to 10 this time :-) FYI not having a go here Roland, it's a very insightful, interesting and well put together preso that I have forwarded on many times! I totally agree with the better part of it. However.... While ACL's on stateless devices in the right place (routers/switches etc) are certainly the way to protect against "a 3mb/sec of spoofed SYN-flooding taking down a supposedly 20gb/sec stateful firewall", the truth is that if I spend all day every day chopping wood, I would probably buy an electric saw. But if I only hammer two pieces of wood together a few times a year, im not going to waste my money on a nail gun, I would probably just get a hammer. Similarly if most of the time I just need to protect my relatively simple network by implementing a few separate zones I will get a firewall, im not going to deploy expensive stateless devices that can push a billion pps everywhere and send flow stats to expensive DDoS mitigation hardware *cough* arbor *cough* just so I can protect against an attack that many only happen a few times a year. If you're the type of enterprise that IS seeing those types of attacks on a regular basis, unless they only started in the last few weeks the chances are you already know who the DDoS mitigation players are and how to implement them correctly (if not pre-sales aren't doing their job right!). That's how I see it anyhow. The right tool for the right job... though in most cases you still need the whole toolbox. Regards, Seamus Thoughts are entirely my own -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Saturday, 19 April 2014 12:11 PM To: nanog at nanog.org Subject: Re: Requirements for IPv6 Firewalls On Apr 19, 2014, at 9:04 AM, Jeff Kell wrote: > It's how we provide access control. Firewalls <> 'access control'. Firewalls are one (generally, very poor and grossly misused) way of providing access control. They're often wedged in where stateless ACLs in hardware-based routers and/or layer-3 switches would do a much better job, such as in front of servers: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From s.ryan at uber.com.au Sun Apr 20 15:15:32 2014 From: s.ryan at uber.com.au (Seamus Ryan) Date: Sun, 20 Apr 2014 15:15:32 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <20E4FBF7-7DAD-4801-8AC3-E940219B7882@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <3F1DEC33DC0C274C99B16F166A25DF75CDB0B941@aucbr1ex1.ahq.net.au> <20E4FBF7-7DAD-4801-8AC3-E940219B7882@arbor.net> Message-ID: <3F1DEC33DC0C274C99B16F166A25DF75CDB0C2E0@aucbr1ex1.ahq.net.au> >>I'm talking about stateless ACLs on hardware-based routers and switches for enforcing network access policies - nothing to do with Arbor. Arbor doesn't make routers or switches. I am aware what Arbor do, have tested the kit before and it is neat stuff. It was more a friendly stab at the way DDoS mitigation providers push their products; stateless router + ddos appliance = problem solved, throw everything else out :-) From rdobbins at arbor.net Sun Apr 20 15:47:16 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 20 Apr 2014 15:47:16 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <3F1DEC33DC0C274C99B16F166A25DF75CDB0C2E0@aucbr1ex1.ahq.net.au> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <3F1DEC33DC0C274C99B16F166A25DF75CDB0B941@aucbr1ex1.ahq.net.au> <20E4FBF7-7DAD-4801-8AC3-E940219B7882@arbor.net> <3F1DEC33DC0C274C99B16F166A25DF75CDB0C2E0@aucbr1ex1.ahq.net.au> Message-ID: On Apr 20, 2014, at 10:15 PM, Seamus Ryan wrote: > It was more a friendly stab at the way DDoS mitigation providers push their products; stateless router + ddos appliance = problem solved, throw everything else out ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From shortdudey123 at gmail.com Sun Apr 20 17:52:21 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sun, 20 Apr 2014 10:52:21 -0700 Subject: Whois Database In-Reply-To: References: Message-ID: Anyone else get an email like this? Headers: Delivered-To: shortdudey123 at gmail.com Received: by 10.76.100.232 with SMTP id fb8csp151578oab; Sun, 20 Apr 2014 09:45:10 -0700 (PDT) X-Received: by 10.68.137.136 with SMTP id qi8mr33622066pbb.79.1398012309733; Sun, 20 Apr 2014 09:45:09 -0700 (PDT) Return-Path: Received: from whois.directory.com ([198.143.157.226]) by mx.google.com with ESMTPS id ck1si5595778pad.204.2014.04.20.09.45.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Apr 2014 09:45:09 -0700 (PDT) Received-SPF: temperror (google.com: error in processing during lookup of whois at whois.directory.com: DNS timeout) client-ip=198.143.157.226; Authentication-Results: mx.google.com; spf=temperror (google.com: error in processing during lookup of whois at whois.directory.com: DNS timeout) smtp.mail=whois at whois.directory.com Received: from whois by whois.directory.com with local (Exim 4.82) (envelope-from ) id 1WaDge-0007ww-NN for shortdudey123 at gmail.com; Tue, 15 Apr 2014 19:26:49 -0500 To: shortdudey123 at gmail.com Subject: Whois Database Message-Id: From: whois at whois.directory.com Date: Tue, 15 Apr 2014 19:26:48 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - whois.directory.com X-AntiAbuse: Original Domain - gmail.com X-AntiAbuse: Originator/Caller UID/GID - [517 514] / [47 12] X-AntiAbuse: Sender Address Domain - whois.directory.com X-Get-Message-Sender-Via: whois.directory.com: authenticated_id: whois/primary_hostname/system user If you need access to the domain WHOIS database, email whoisdataapi at gmail.com. -Grant On Tue, Apr 15, 2014 at 5:26 PM, wrote: > If you need access to the domain WHOIS database, email > whoisdataapi at gmail.com. > From fmartin at linkedin.com Sun Apr 20 22:01:38 2014 From: fmartin at linkedin.com (Franck Martin) Date: Sun, 20 Apr 2014 22:01:38 +0000 Subject: Yahoo DMARC breakage In-Reply-To: <534C552C.30107@west.net> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> Message-ID: So I believe, if this list was not stripping the HTML part of the emails, as it does not add a subject tag nor a footer, then DKIM would survive the list and all would be fine? why does this list break DKIM when forwarding? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From barney at databus.com Sun Apr 20 22:08:36 2014 From: barney at databus.com (Barney Wolff) Date: Sun, 20 Apr 2014 18:08:36 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> Message-ID: <20140420220836.GD90302@pit.databus.com> On Sun, Apr 20, 2014 at 10:01:38PM +0000, Franck Martin wrote: > So I believe, if this list was not stripping the HTML part of the emails, as it does not add a subject tag nor a footer, then DKIM would survive the list and all would be fine? > > why does this list break DKIM when forwarding? My system says your message passed DKIM and DMARC. Perhaps that's because linkedin.com does not publish an SPF record. From me at staticsafe.ca Sun Apr 20 22:17:20 2014 From: me at staticsafe.ca (staticsafe) Date: Sun, 20 Apr 2014 18:17:20 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <20140420220836.GD90302@pit.databus.com> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> <20140420220836.GD90302@pit.databus.com> Message-ID: <53544770.7040707@staticsafe.ca> On 4/20/2014 18:08, Barney Wolff wrote: > On Sun, Apr 20, 2014 at 10:01:38PM +0000, Franck Martin wrote: >> So I believe, if this list was not stripping the HTML part of the emails, as it does not add a subject tag nor a footer, then DKIM would survive the list and all would be fine? >> >> why does this list break DKIM when forwarding? > > My system says your message passed DKIM and DMARC. Perhaps that's because > linkedin.com does not publish an SPF record. > They actually do: linkedin.com. 86400 IN SPF "v=spf1 ip4:8.18.31.21 ip4:8.18.31.22 ip4:69.28.149.0/24 ip4:199.101.160.0/25 ip4:199.101.162.0/25 ip4:108.174.3.0/24 ip6:2620:109:c006:104::/64 ip4:216.136.162.65 mx mx:docusign.net ~all" -- staticsafe https://asininetech.com From fmartin at linkedin.com Sun Apr 20 22:22:54 2014 From: fmartin at linkedin.com (Franck Martin) Date: Sun, 20 Apr 2014 22:22:54 +0000 Subject: Yahoo DMARC breakage In-Reply-To: <20140420220836.GD90302@pit.databus.com> References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> <20140420220836.GD90302@pit.databus.com> Message-ID: <97ED95C5-2A0D-4FD5-821A-E777F882E635@linkedin.com> On Apr 20, 2014, at 3:08 PM, Barney Wolff wrote: > On Sun, Apr 20, 2014 at 10:01:38PM +0000, Franck Martin wrote: >> So I believe, if this list was not stripping the HTML part of the emails, as it does not add a subject tag nor a footer, then DKIM would survive the list and all would be fine? >> >> why does this list break DKIM when forwarding? > > My system says your message passed DKIM and DMARC. Perhaps that's because > linkedin.com does not publish an SPF record. Linkedin.com publishes an SPF record, but the list change the envelope from, so while they may be an SPF pass it won?t be aligned. If I send this email in plain text, DKIM survives, therefore DMARC pass. If I send this email with plain text and html, the list strips the HTML and DKIM fails. Therefore DMARC fails DMARC=(SPF OR DKIM pass) with domain alignment. The ASCII blue ribbon campaign officially ended in june 2013, time to move with the times? ;) http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From scott at doc.net.au Sun Apr 20 23:07:37 2014 From: scott at doc.net.au (Scott Howard) Date: Sun, 20 Apr 2014 16:07:37 -0700 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> Message-ID: On Sun, Apr 20, 2014 at 3:01 PM, Franck Martin wrote: > why does this list break DKIM when forwarding? > >From the Gmail headers your email : Authentication-Results: mx.google.com; spf=neutral (google.com: nanog-bounces+scott=example.com at nanog.orgdoes not designate permitted sender hosts) smtp.mail=nanog-bounces+scott= example.com at nanog.org; dkim=pass header.i=@linkedin.com; *dmarc=pass* (p=REJECT dis=NONE) header.from=linkedin.com Scott From fmartin at linkedin.com Sun Apr 20 23:59:44 2014 From: fmartin at linkedin.com (Franck Martin) Date: Sun, 20 Apr 2014 23:59:44 +0000 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> , Message-ID: <2F02824E-FD47-4CFC-BB26-6F744E344071@linkedin.com> Sure as long as I make sure my post is plain text which you know is not anymore a standard on many email clients. So if this lists stop to strip the HTML mime part it will pass DMARC regardless of the email client defaults. Toute connaissance est une r?ponse ? une question. On Apr 20, 2014, at 16:07, "Scott Howard" > wrote: On Sun, Apr 20, 2014 at 3:01 PM, Franck Martin > wrote: why does this list break DKIM when forwarding? >From the Gmail headers your email : Authentication-Results: mx.google.com; spf=neutral (google.com: nanog-bounces+scott=example.com at nanog.org does not designate permitted sender hosts) smtp.mail=nanog-bounces+scott=example.com at nanog.org; dkim=pass header.i=@linkedin.com; dmarc=pass (p=REJECT dis=NONE) header.from=linkedin.com Scott From dhc2 at dcrocker.net Mon Apr 21 00:21:50 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sun, 20 Apr 2014 17:21:50 -0700 Subject: Yahoo DMARC breakage In-Reply-To: <20140410030056.GB3886@dyn.com> References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> Message-ID: <5354649E.9030903@dcrocker.net> On 4/9/2014 8:00 PM, Andrew Sullivan wrote: > On Wed, Apr 09, 2014 at 12:27:55PM -0500, Dave Crocker wrote: > >> >But it's the result of an informed >> >corporate choice rather than software or operations error. > Why do you think (it seems to me you've said it more than once) that > this was "informed" choice? Sorry for not responding when you posted this; I missed it. The answer is that Yahoo was an active participant in the creation of DMARC and the applicability and limitations of the design were well and fully discussed. Many times. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fmartin at linkedin.com Mon Apr 21 03:57:20 2014 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 21 Apr 2014 03:57:20 +0000 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140409200558.3314.qmail@joyce.lan> <20140410112912.GA15874@gsp.org> <534C552C.30107@west.net> Message-ID: <758873B5-15B0-4F90-BE7B-03A012093344@linkedin.com> On Apr 20, 2014, at 4:07 PM, Scott Howard wrote: > On Sun, Apr 20, 2014 at 3:01 PM, Franck Martin wrote: > why does this list break DKIM when forwarding? > > From the Gmail headers your email : > > Authentication-Results: mx.google.com; > spf=neutral (google.com: nanog-bounces+scott=example.com at nanog.org does not designate permitted sender hosts) smtp.mail=nanog-bounces+scott=example.com at nanog.org; > dkim=pass header.i=@linkedin.com; > dmarc=pass (p=REJECT dis=NONE) header.from=linkedin.com > > Scott > Sure as long as I make sure my post is plain text only which you know is not anymore a standard on many email clients (and not configureable on many mobile mail clients). So if this list stops to strip the HTML mime part it will pass DMARC in all cases. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fernando at gont.com.ar Mon Apr 21 09:03:55 2014 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 21 Apr 2014 06:03:55 -0300 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> Message-ID: <5354DEFB.7050400@gont.com.ar> Hi, Brandon, On 04/17/2014 08:20 PM, Brandon Ross wrote: > On Thu, 17 Apr 2014, Sander Steffann wrote: > >>> Also, I note your draft is entitled "Requirements for IPv6 Enterprise >>> Firewalls." Frankly, no "enterprise" firewall will be taken seriously >>> without address-overloaded NAT. I realize that's a controversial >>> statement in the IPv6 world but until you get past it you're basically >>> wasting your time on a document which won't be useful to industry. >> >> I disagree. While there certainly will be organisations that want such >> a 'feature' it is certainly not a requirement for every (I hope most, >> but I might be optimistic) enterprises. > > And I not only agree with Sander, but would also argue for a definitive > statement in a document like this SPECIFICALLY to help educate the > enterprise networking community on how to implement a secure border for > IPv6 without the need for NAT. Having a document to point at that has > been blessed by the IETF/community is key to helping recover the > end-to-end principle. Such a document may or may not be totally in > scope for a "firewall" document, but should talk about concepts like > default-deny inbound traffic, stateful inspection and the use of address > space that is not announced to the Internet and/or is completely blocked > at borders for all traffic. Are you argung against of e.g. "default-deny inbound traffic"? Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From Lee at asgard.org Mon Apr 21 16:10:31 2014 From: Lee at asgard.org (Lee Howard) Date: Mon, 21 Apr 2014 12:10:31 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <20140419021608.GY15800@hezmatt.org> References: <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <20140419021608.GY15800@hezmatt.org> Message-ID: On 4/18/14 10:16 PM, "Matt Palmer" wrote: >On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote: >> As to address the other argument in this threat on NAT / private >> addressing, PCI requirement 1.3.8 pretty much requires RFC1918 >>addressing >> of the computers in scope... has anyone hinted at PCI for IPv6? > >1.3.8 lists use of RFC1918 address space as one of four possible >implementations, immediately after the phrase "may include, but are not >limited to". I don't interpret that as "pretty much requires RFC1918". It's not clear whether those are alternatives or should all be employed. An auditor will tend to recommend all of them. > >Now, if you'd like to claim that 1.3.8 is completely useless, I won't >argue >with you -- it's security-by-obscurity of the worst possible form. But >don't blame PCI compliance for any inability to deploy IPv6, because it >just >ain't true. "Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks." https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf Based on my experience with compliance auditors, they won't understand many of the words in this sentence, and will assume NAT and RFC1918. They can often (but not always) be taught, but you have to take the time to explain how IPv6 works, and how you prevent a reconnaissance attack. Many enterprise network administrators are not up to this task, unfortunately. ULA + NPT66 should be pretty easy to explain, both technically, and as a method of demonstrating compliance. However, preventing outbound route leaks of more-specifics, and blocking inbound recon attacks/probes *should* be equally compliant. Lee From Lee at asgard.org Mon Apr 21 16:32:40 2014 From: Lee at asgard.org (Lee Howard) Date: Mon, 21 Apr 2014 12:32:40 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: From: George Herbert Date: Friday, April 18, 2014 7:11 PM To: Lee Howard Cc: Eugeniu Patrascu , "draft-gont-opsec-ipv6-firewall-reqs at tools.ietf.org" , "nanog at nanog.org" Subject: Re: Requirements for IPv6 Firewalls > Lee Howard: >> So, yeah, you have to give your firewall administrator time to walk >> through the rules and figure out what they ought to be in IPv6. Your >> firewall administrator has been wanting to clean up the rules for the last >> two years, anyway. > > > The arrogance in this assertion is amazing. What arrogance? I think I assert that IPv6 is time-consuming. There is no "deploy IPv6" button. fwiw, I do have enterprise network experience. > > You're describing best practice. Yes, of course, you should have well > documented technical and business needs for what's open and what's closed in > firewalls, and should have traceability from the rules in place to the > requirements, and be able to walk the rules and understand them and > reinterpret them from v4 to v6, to a new firewall vendor, etc etc. Yes. Any publicly-traded company will have this because their auditors require it. I would think that companies without this documentation are probably not ready to deploy a new protocol. I concede that tracing the rules to the requirements is a hard one in practice (and a PITA in operational practice), but I don't think it's required to be able to map IPv4 rules to IPv6 rules. > > Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE. To clarify: are you asserting that IPv6 uptake in enterprises is slow, which is a sign of inertia, and the reason is that firewalls are poorly documented and therefore we must have IPv6 NAT? Maybe "lack of (perceived) business need" is the reason more enterprises don't have IPv6. ? > > Again - policy community blinders on understanding what real systems are like > out in the world has repeatedly shot the conversion in the legs. If you're > going to start floating standards for this kind of stuff, then listen to > feedback on why things are failing. I don't agree that things are failing. I would absolutely like to see enterprises adopt IPv6. Maybe at this stage enterprises with no firewall documentation are not good candidates for dual-stack. Those do seem to me to be the kind of clients who are likely to blame IPv6 for any problem, and insist it be turned off before any other troubleshooting. Lee From bross at pobox.com Mon Apr 21 16:39:11 2014 From: bross at pobox.com (Brandon Ross) Date: Mon, 21 Apr 2014 12:39:11 -0400 (EDT) Subject: Requirements for IPv6 Firewalls In-Reply-To: <5354DEFB.7050400@gont.com.ar> References: <534FAD41.8040604@gont.com.ar> <6EA825F3-C229-4BE6-801C-5B272AE65ACA@steffann.nl> <5354DEFB.7050400@gont.com.ar> Message-ID: On Mon, 21 Apr 2014, Fernando Gont wrote: > Are you argung against of e.g. "default-deny inbound traffic"? Absolutely not, default deny of traffic should most certainly be one of the tools in the toolbox. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross From Valdis.Kletnieks at vt.edu Mon Apr 21 17:20:40 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 21 Apr 2014 13:20:40 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: Your message of "Mon, 21 Apr 2014 12:10:31 -0400." References: <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <20140419021608.GY15800@hezmatt.org> Message-ID: <5153.1398100840@turing-police.cc.vt.edu> On Mon, 21 Apr 2014 12:10:31 -0400, Lee Howard said: > "Methods used to meet the intent of this > requirement may vary depending on the specific > networking technology being used. For example, > the controls used to meet this requirement may be > different for IPv4 networks than for IPv6 networks." > https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf > > Based on my experience with compliance auditors, they won't understand > many of the words in this sentence, and will assume NAT and RFC1918. So there's the *real* problem in a nutshell. People think we're supposed to hobble our networks with crap design just because the auditors can't get their industry's shit together. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From tdurack at gmail.com Mon Apr 21 18:42:27 2014 From: tdurack at gmail.com (Tim Durack) Date: Mon, 21 Apr 2014 14:42:27 -0400 Subject: Pluggable Coherent DWDM 10Gig Message-ID: Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no such thing.) How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter receive side might be doable?) -- Tim:> p.s. Before you ask, DTAG Terastream has got me thinking... From zwicky at yahoo-inc.com Mon Apr 21 18:55:19 2014 From: zwicky at yahoo-inc.com (Elizabeth Zwicky) Date: Mon, 21 Apr 2014 18:55:19 +0000 Subject: Yahoo DMARC breakage In-Reply-To: <5354649E.9030903@dcrocker.net> References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> <5354649E.9030903@dcrocker.net> Message-ID: I believe that our public statements make it clear that we realize that significant use cases are broken: http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-p rotect-our-users http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what -should-senders-do Elizabeth Zwicky From tdurack at gmail.com Mon Apr 21 18:57:44 2014 From: tdurack at gmail.com (Tim Durack) Date: Mon, 21 Apr 2014 14:57:44 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: As a follow up, I did not miss a zero. TenGig. If you want to know why: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf (I'll take 100Gig once I can get the optics for less than the cost of a v.nice sports car...) On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack wrote: > Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no > such thing.) > > How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter > receive side might be doable?) > > -- > Tim:> > > p.s. Before you ask, DTAG Terastream has got me thinking... > -- Tim:> From george.herbert at gmail.com Mon Apr 21 18:58:12 2014 From: george.herbert at gmail.com (George Herbert) Date: Mon, 21 Apr 2014 11:58:12 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> Message-ID: On Mon, Apr 21, 2014 at 9:32 AM, Lee Howard wrote: > > You're describing best practice. Yes, of course, you should have well > documented technical and business needs for what's open and what's closed > in firewalls, and should have traceability from the rules in place to the > requirements, and be able to walk the rules and understand them and > reinterpret them from v4 to v6, to a new firewall vendor, etc etc. > > > Yes. Any publicly-traded company will have this because their auditors > require it. > I would think that companies without this documentation are probably not > ready to deploy a new protocol. > I concede that tracing the rules to the requirements is a hard one in > practice (and a PITA in operational practice), but I don't think it's > required to be able to map IPv4 rules to IPv6 rules. > > You would think that any publicly-traded or sufficiently large or high profile company would have that because their auditors should require that. Yes, that's a reasonable assertion and hope. I regret to inform the discussion that it's a forlorn hope in a number of actual real world organizations. > I'm not making noise to be remembered on the lists as a pissed off troublemaker. I've been doing enterprise IT consulting since the early 1990s, and am relaying what the state of reality is, and attempting to get people at various levels to deal with that rather than assume higher levels of competence than are really out there... -- -george william herbert george.herbert at gmail.com From jared at puck.nether.net Mon Apr 21 19:01:51 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 21 Apr 2014 15:01:51 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: <0409DA81-1E81-48CF-BCA1-D2D6C9124B9D@puck.nether.net> You can get 100G-LR4 CFP for ~10k from good vendors. You can get them sub-10k from china what i'm hearing, but those failure rates are higher.. - Jared On Apr 21, 2014, at 2:57 PM, Tim Durack wrote: > As a follow up, I did not miss a zero. TenGig. If you want to know why: > https://ripe67.ripe.net/presentations/131-ripe2-2.pdf > > (I'll take 100Gig once I can get the optics for less than the cost of a > v.nice sports car...) > > > On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack wrote: > >> Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no >> such thing.) >> >> How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter >> receive side might be doable?) >> >> -- >> Tim:> >> >> p.s. Before you ask, DTAG Terastream has got me thinking... >> > > > > -- > Tim:> From fw at deneb.enyo.de Mon Apr 21 19:04:18 2014 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 21 Apr 2014 21:04:18 +0200 Subject: DMARC -> CERT? In-Reply-To: (Christopher Morrow's message of "Mon, 14 Apr 2014 13:30:54 -0400") References: <534C085B.802@meetinghouse.net> <534C0D85.3000408@meetinghouse.net> <5BA8DD2F-EBA5-4521-945D-EBF9A4ECDB74@heliacal.net> <534C1562.2080408@meetinghouse.net> <5070AC5F-BC83-4F41-B491-7F38758D4527@heliacal.net> Message-ID: <87lhuyv70t.fsf@mid.deneb.enyo.de> * Christopher Morrow: > I sort of wonder if this is really just yahoo trying to use a stick to > motivate people to do the right thing? But what is the right thing here? Do we really want that *all* mailing lists must not provider "reply to sender" option to all their users? Will this list make the change? Probably not. From tdurack at gmail.com Mon Apr 21 19:07:38 2014 From: tdurack at gmail.com (Tim Durack) Date: Mon, 21 Apr 2014 15:07:38 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: On Mon, Apr 21, 2014 at 2:57 PM, Tim Durack wrote: > On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack wrote: > >> Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding >> no such thing.) >> >> How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter >> receive side might be doable?) >> >> -- >> Tim:> >> >> p.s. Before you ask, DTAG Terastream has got me thinking... >> > > As a follow up, I did not miss a zero. TenGig. If you want to know why: > https://ripe67.ripe.net/presentations/131-ripe2-2.pdf > > (I'll take 100Gig once I can get the optics for less than the cost of a > v.nice sports car...) > As another follow-up, coherent 'cos I want tuned receive as well as transmit, so the WDM system can be truly "colorless" and "directionless", plus the nice high CD limit would be great. Maybe I should ask for a pony too? :-) -- Tim:> From jimpop at gmail.com Mon Apr 21 19:18:30 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Mon, 21 Apr 2014 15:18:30 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> <5354649E.9030903@dcrocker.net> Message-ID: On Mon, Apr 21, 2014 at 2:55 PM, Elizabeth Zwicky wrote: > > > I believe that our public statements make it clear that we realize that > significant use cases are broken: > > http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-p > rotect-our-users > > http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what > -should-senders-do > > Elizabeth Zwicky > While this issue has been beaten into the ground quite far, it's important to point out that Mailinglist sofware is adapting to address the headaches thrust upon us by your own internal spam problems. ;-) Fairly soon NANOG and other Mailman based lists will be able to flip a switch and wrap+attach emails from domains with strict policies. It may clutter up the archives a bit, but eventually users will tire of it and move on to a not-so-anal email service. :-) -Jim P. From hannigan at gmail.com Mon Apr 21 20:04:48 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 21 Apr 2014 16:04:48 -0400 Subject: Call for Presenations: NANOG 61 Data Center Track Message-ID: Hi Everyone, We are soliciting presentation proposals for a 30m time slot during the Data Center Track being held at NANOG 61 in Bellevue, WA. See http://bit.ly/1rg4eyn for dates/location. The topics that we'd like to hear from you on are: - Data Center Infrastructure Management "DCIM" (use cases, design, benefits) - Medium Voltage (use, requirements, distribution technology, substations, benefits) - High Power and Dense Deployments (examples, u's, kW metrics, challenges, benefits) Presenter should be the subject matter expert related to the topic that you are submitting for consideration i.e. designer, developer, implementer, operator. We will be selecting one presentation. In order to be considered, we need your proposal and completed abstract no later than May 1, 2014. Contact us with your proposal or questions at: - Dan Golding - Martin Hannigan Best Regards, -M< From mikea at mikea.ath.cx Mon Apr 21 21:36:28 2014 From: mikea at mikea.ath.cx (Mike A) Date: Mon, 21 Apr 2014 16:36:28 -0500 Subject: OT: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] In-Reply-To: <20140418154725.4473A077@m0048139.ppops.net> References: <20140418154725.4473A077@m0048139.ppops.net> Message-ID: <20140421213628.GA71638@mikea.ath.cx> On Fri, Apr 18, 2014 at 03:47:25PM -0700, Scott Weeks wrote: > > :: There being no cable between the Hawaiian Islands > :: and the mainland at the time > > Wait...what? > > https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific > > "The first trans-pacific cables were completed in 1902-03, linking the > US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. > Canada, Australia, New Zealand and Fiji were also linked in 1902. Thanks! I slouch (really comfy chair) corrected. But the War Dept. didn't have the cable sent by cable. And I really am grateful for the information. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From surfer at mauigateway.com Mon Apr 21 23:45:54 2014 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 21 Apr 2014 16:45:54 -0700 Subject: OT:[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years Message-ID: <20140421164554.44602B5C@m0005298.ppops.net> --- mikea at mikea.ath.cx wrote: From: Mike A On Fri, Apr 18, 2014 at 03:47:25PM -0700, Scott Weeks wrote: > > :: There being no cable between the Hawaiian Islands > :: and the mainland at the time > > Wait...what? > > https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific > > "The first trans-pacific cables were completed in 1902-03, linking the > US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. > Canada, Australia, New Zealand and Fiji were also linked in 1902. Thanks! I slouch (really comfy chair) corrected. But the War Dept. didn't have the cable sent by cable. And I really am grateful for the information. ----------------------------------------------- No problem and no biggie. I have a picture of the guys in the ceremony for the first official message sent to the US mainland on my wall here because I have always been interested in the history of communications here in Hawaii since I first found out about ALOHAnet. :-) http://atlantic-cable.com//Article/1902-JournElec/1902-CPC-08.jpg http://atlantic-cable.com//Article/1902-JournElec scott From mfidelman at meetinghouse.net Tue Apr 22 00:04:12 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 21 Apr 2014 20:04:12 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> <5354649E.9030903@dcrocker.net> Message-ID: <5355B1FC.70506@meetinghouse.net> Elizabeth Zwicky wrote: > > I believe that our public statements make it clear that we realize that > significant use cases are broken: > > http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-p > rotect-our-users > > http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what > -should-senders-do > > Elizabeth Zwicky > What I do notice as interesting is that yahoo-inc.com and yahoogroups.com both publish dmarc records with "p=none" Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From network.ipdog at gmail.com Tue Apr 22 01:45:38 2014 From: network.ipdog at gmail.com (Network IPdog) Date: Mon, 21 Apr 2014 18:45:38 -0700 Subject: [Infowarrior] - FYI ~ attrition.org uses an invalid security certificate for mailing list sign-up In-Reply-To: <20140418154725.4473A077@m0048139.ppops.net> References: <20140418154725.4473A077@m0048139.ppops.net> Message-ID: <5355c9c3.aa86440a.35c6.fffff520@mx.google.com> FYI... Say it isn't so.... In today's Heartbleed state of affairs... attrition.org uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is only valid for Lyger The certificate expired on.... 12/21/2012 1:44 PM. The current time is 4/21/2014 6:18 PM. (Error code: sec_error_expired_issuer_certificate) Ruff, Ruff...! Network IPdog Ephesians 4:32 & Cheers!!! A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it. -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Friday, April 18, 2014 3:47 PM To: nanog at nanog.org Subject: OT: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] :: There being no cable between the Hawaiian Islands :: and the mainland at the time Wait...what? https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific "The first trans-pacific cables were completed in 1902-03, linking the US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. Canada, Australia, New Zealand and Fiji were also linked in 1902. scott --- mikea at mikea.ath.cx wrote: From: Mike A On Mon, Apr 14, 2014 at 10:09:14PM +0000, Matthew Black wrote: > IIRC, the message was sent via courier instead of cable or telephone > to prevent interception. Did the military not even trust its own > cryptographic methods? Or did they not think withdrawal of the > Japanese ambassador was not very critical? The message was sent by Western Union. There being no cable between the Hawaiian Islands and the mainland at the time, the message went by commercial radio, in plaintext, and thence by civilian bicycle messenger (of Japanese ancestry, as it happened) to Fort Shafter, where it was read while the attack was in progress. David Kahn's fine book, _The Codebreakers_, discusses this in rather more detail. I recommend the original version; the paperback and later hardback editions contain rather less meat. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From infinityape at gmail.com Tue Apr 22 02:29:29 2014 From: infinityape at gmail.com (Dennis B) Date: Mon, 21 Apr 2014 22:29:29 -0400 Subject: AT&T / Verizon DNS Flush? In-Reply-To: <20140416130528.1b7acd2e@jpeach-desktop.anbg.mssm.edu> References: <2225B1FE-BA2E-4F39-9571-8AB01AC2E633@heliacal.net> <13537.1397667419@turing-police.cc.vt.edu> <20140416130528.1b7acd2e@jpeach-desktop.anbg.mssm.edu> Message-ID: The default TTL should be 300 secs, esp with everyone switching A records to cloud providers, imho. That way, who ever is the SOA and the zone master, can update it based on design scale or sla of that provider. DNS needs a protocol refresh anyways. Dennis B. On Apr 16, 2014 7:30 PM, "John Peach" wrote: > Looks to be godaddy. No surprise then. > > > On Wed, 16 Apr 2014 12:56:59 -0400 > Valdis.Kletnieks at vt.edu wrote: > > > On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said: > > > Yeah...I know. Unfortunately, the domain was "mishandled" by our > > > registrar, who imposed their own TTLs on our zone, THEN turned it > > > back over to us with a 48HR TTL. Which is very bad. > > > > That's almost calling for a name-and-shame. > > From nick at foobar.org Tue Apr 22 08:26:07 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 22 Apr 2014 10:26:07 +0200 Subject: US patent 5473599 Message-ID: <5356279F.8020405@foobar.org> ... turns 20 today. This is the patent which covers hsrp, vrrp, many applications of carp and some other vendor-specific standby protocols. Assuming no term adjustments, 20 years is the normal term for US patents so unless there's been any adjustments / continuations, probably this patent is now expired. More details on: https://www.google.com/patents/US5473599 Nick From hb-nanog at bsws.de Tue Apr 22 10:31:33 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 22 Apr 2014 12:31:33 +0200 Subject: US patent 5473599 In-Reply-To: <5356279F.8020405@foobar.org> References: <5356279F.8020405@foobar.org> Message-ID: <20140422103133.GL18864@quigon.bsws.de> * Nick Hilliard [2014-04-22 10:29]: > ... turns 20 today. > > This is the patent which covers hsrp, vrrp, many applications of carp and > some other vendor-specific standby protocols. it does NOT cover carp, not at all. carp was carefully designed to specifically avoid that. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From simon at per.reau.lt Tue Apr 22 12:01:28 2014 From: simon at per.reau.lt (Simon Perreault) Date: Tue, 22 Apr 2014 08:01:28 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <87k3alty6u.fsf@mid.deneb.enyo.de> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <87k3alty6u.fsf@mid.deneb.enyo.de> Message-ID: <53565A18.6090205@per.reau.lt> Le 2014-04-19 06:23, Florian Weimer a ?crit : >>> I agree with Bill. You can poopoo NAT all you want, but it's a fact >>> of most networks and will continue to remain so until you can make a >>> compelling case to move away from it. >> >> Does that mean all IPv6 firewalls should support NAT? > > In the sense that they "MUST be able to provide email filtering > features": yes. That requirement should be removed. >> Remember, we're aiming for a base set of requirements applying to >> all IPv6 firewalls. > > The document has more than just base requirements. The document is flawed as-is. Simon From nick at foobar.org Tue Apr 22 12:10:23 2014 From: nick at foobar.org (Nick Hilliard) Date: Tue, 22 Apr 2014 14:10:23 +0200 Subject: US patent 5473599 In-Reply-To: <20140422103133.GL18864@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> Message-ID: <53565C2F.9010304@foobar.org> On 22/04/2014 12:31, Henning Brauer wrote: > it does NOT cover carp, not at all. that is a political statement rather than a legal opinion. If you read the patent, it's pretty obvious that when you have a group of carp-enabled devices providing a stable gateway IP address, and these devices are routing traffic received via the carp published address, this configuration provides the same functionality that's described in the patent claims. This hasn't been tested in court and neither of us is a lawyer and the patent seems to have expired, so it's academic at this stage. Nick From pauldotwall at gmail.com Tue Apr 22 13:20:26 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Tue, 22 Apr 2014 09:20:26 -0400 Subject: US patent 5473599 In-Reply-To: <20140422103133.GL18864@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> Message-ID: On Tuesday, April 22, 2014, Henning Brauer wrote: > * Nick Hilliard > [2014-04-22 10:29]: > > ... turns 20 today. > > > > This is the patent which covers hsrp, vrrp, many applications of carp and > > some other vendor-specific standby protocols. > > it does NOT cover carp, not at all. carp was carefully designed to > specifically avoid that. > > CARP is a nonstandard protocol that was carefully designed to cause outages. Its authors submitted a slide deck describing their protocol instead of an internet-draft, which somehow managed to not get any traction in the IETF (funny that). The bar is pretty low for an informational RFC but the CARPheads couldn't be bothered. They threw a tantrum which involved camping out on the IETF's OUI (rather than getting their own) and deliberately choosing host bytes that conflict with the VRRP standard. This has the same predictable result as any duplicate MAC address, but since odds are it conflicts with a router, takes out the entire subnet instead of a single host. Of course this is not mentioned anywhere in CARP's documentation. That's why I encourage my competitors to run it. Drive slow, Paul From blair.trosper at gmail.com Tue Apr 22 14:06:35 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 22 Apr 2014 09:06:35 -0500 Subject: Comcast transit problems? Message-ID: I'm being inundated with reports from Comcast customers in various markets about their inability to reach anything on AWS. For example, we have a few people in Atlanta that are all having this issue. What's more, they're having weird issues reaching things like Twitter or RingCentral (while other sites like Google and CNN work fine). (RingCentral's support department apparently knows about this and is telling their customers that use Comcast that they're aware of the issue but don't know what's going on at the present time.) Calls to the Comcast customer support just yield the "everything's fine, you're crazy" response from the staff. Can anyone from Comcast give me some help (or information) off list? -bt From josh at 2cold.net Tue Apr 22 14:15:53 2014 From: josh at 2cold.net (Joshua McDonald) Date: Tue, 22 Apr 2014 10:15:53 -0400 Subject: Comcast transit problems? In-Reply-To: References: Message-ID: <-4509539149888271429@unknownmsgid> Not sure what the connectivity is between Comcast and AWS, but Level3 is having issues in Atlanta. Sent from my iPhone > On Apr 22, 2014, at 10:07, Blair Trosper wrote: > > I'm being inundated with reports from Comcast customers in various markets > about their inability to reach anything on AWS. For example, we have a few > people in Atlanta that are all having this issue. > > What's more, they're having weird issues reaching things like Twitter or > RingCentral (while other sites like Google and CNN work fine). > > (RingCentral's support department apparently knows about this and is > telling their customers that use Comcast that they're aware of the issue > but don't know what's going on at the present time.) > > Calls to the Comcast customer support just yield the "everything's fine, > you're crazy" response from the staff. > > Can anyone from Comcast give me some help (or information) off list? > > -bt From jneiberger at gmail.com Tue Apr 22 14:19:59 2014 From: jneiberger at gmail.com (John Neiberger) Date: Tue, 22 Apr 2014 08:19:59 -0600 Subject: Comcast transit problems? In-Reply-To: <-4509539149888271429@unknownmsgid> References: <-4509539149888271429@unknownmsgid> Message-ID: Yep, that does seem to be the problem. John On Apr 22, 2014 8:17 AM, "Joshua McDonald" wrote: > Not sure what the connectivity is between Comcast and AWS, but Level3 > is having issues in Atlanta. > > Sent from my iPhone > > > On Apr 22, 2014, at 10:07, Blair Trosper > wrote: > > > > I'm being inundated with reports from Comcast customers in various > markets > > about their inability to reach anything on AWS. For example, we have a > few > > people in Atlanta that are all having this issue. > > > > What's more, they're having weird issues reaching things like Twitter or > > RingCentral (while other sites like Google and CNN work fine). > > > > (RingCentral's support department apparently knows about this and is > > telling their customers that use Comcast that they're aware of the issue > > but don't know what's going on at the present time.) > > > > Calls to the Comcast customer support just yield the "everything's fine, > > you're crazy" response from the staff. > > > > Can anyone from Comcast give me some help (or information) off list? > > > > -bt > > From blair.trosper at gmail.com Tue Apr 22 14:23:10 2014 From: blair.trosper at gmail.com (Blair Trosper) Date: Tue, 22 Apr 2014 09:23:10 -0500 Subject: Comcast transit problems? In-Reply-To: References: <-4509539149888271429@unknownmsgid> Message-ID: At least it's not a Friday or a holiday. :) On Tue, Apr 22, 2014 at 9:19 AM, John Neiberger wrote: > Yep, that does seem to be the problem. > > John > On Apr 22, 2014 8:17 AM, "Joshua McDonald" wrote: > >> Not sure what the connectivity is between Comcast and AWS, but Level3 >> is having issues in Atlanta. >> >> Sent from my iPhone >> >> > On Apr 22, 2014, at 10:07, Blair Trosper >> wrote: >> > >> > I'm being inundated with reports from Comcast customers in various >> markets >> > about their inability to reach anything on AWS. For example, we have a >> few >> > people in Atlanta that are all having this issue. >> > >> > What's more, they're having weird issues reaching things like Twitter or >> > RingCentral (while other sites like Google and CNN work fine). >> > >> > (RingCentral's support department apparently knows about this and is >> > telling their customers that use Comcast that they're aware of the issue >> > but don't know what's going on at the present time.) >> > >> > Calls to the Comcast customer support just yield the "everything's fine, >> > you're crazy" response from the staff. >> > >> > Can anyone from Comcast give me some help (or information) off list? >> > >> > -bt >> >> From ryanshea at google.com Tue Apr 22 14:23:57 2014 From: ryanshea at google.com (Ryan Shea) Date: Tue, 22 Apr 2014 10:23:57 -0400 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> Message-ID: Great news about the patent age. Paul, sounds like this outage-causing catastrophe you mention could happen to your competitors _if_ they happened to run vrrp and carp on the same subnet _and_ happened to have a host identifier conflict - is that right? I just wanted to clarify. CARP has been a great solution for me in the past and is one of the features of BSD I think is great (along with OpenNTPd, OpenBGPd - which probably have similar standards non-compliance). Has anyone tried to use the userspace VRRP implementation on Linux... I recall delicacy and kludginess from the one time I used it - so again, CARP = rad. On Tue, Apr 22, 2014 at 9:20 AM, Paul WALL wrote: > On Tuesday, April 22, 2014, Henning Brauer wrote: > > > * Nick Hilliard > [2014-04-22 10:29]: > > > ... turns 20 today. > > > > > > This is the patent which covers hsrp, vrrp, many applications of carp > and > > > some other vendor-specific standby protocols. > > > > it does NOT cover carp, not at all. carp was carefully designed to > > specifically avoid that. > > > > > CARP is a nonstandard protocol that was carefully designed to cause > outages. > > Its authors submitted a slide deck describing their protocol instead of an > internet-draft, which somehow managed to not get any traction in the IETF > (funny that). The bar is pretty low for an informational RFC but the > CARPheads couldn't be bothered. They threw a tantrum which involved camping > out on the IETF's OUI (rather than getting their own) and deliberately > choosing host bytes that conflict with the VRRP standard. This has the > same predictable result as any duplicate MAC address, but since odds are it > conflicts with a router, takes out the entire subnet instead of a single > host. Of course this is not mentioned anywhere in CARP's documentation. > > That's why I encourage my competitors to run it. > > Drive slow, > Paul > From hb-nanog at bsws.de Tue Apr 22 15:07:16 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 22 Apr 2014 17:07:16 +0200 Subject: US patent 5473599 In-Reply-To: <53565C2F.9010304@foobar.org> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <53565C2F.9010304@foobar.org> Message-ID: <20140422150716.GM1206@quigon.bsws.de> * Nick Hilliard [2014-04-22 15:33]: > On 22/04/2014 12:31, Henning Brauer wrote: > > it does NOT cover carp, not at all. > that is a political statement rather than a legal opinion. If you read the > patent, it's pretty obvious that when you have a group of carp-enabled > devices providing a stable gateway IP address, and these devices are > routing traffic received via the carp published address, this configuration > provides the same functionality that's described in the patent claims. > This hasn't been tested in court and neither of us is a lawyer and the > patent seems to have expired, so it's academic at this stage. it is academic, indeed. I was involved with carp's creation, we did all the work to make sure it just avoids being covered by the patent. and that included getting legal advice. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From hb-nanog at bsws.de Tue Apr 22 15:11:22 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 22 Apr 2014 17:11:22 +0200 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> Message-ID: <20140422151122.GN1206@quigon.bsws.de> I won't waste time on your uninformed ramblings, you have the facts plain wrong. There is enough material on the net for everybody to read up on what happened. "carp causing outages" however is nothing short of a lie. carp announces itself as vrrp version 3. anything trying to parse it as vrrp2 without checking the version number in the header is buggy as hell and that is ITS fault, not carps. affected cisco 3600, afair. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From hb-nanog at bsws.de Tue Apr 22 15:14:25 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 22 Apr 2014 17:14:25 +0200 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> Message-ID: <20140422151425.GO1206@quigon.bsws.de> * Ryan Shea [2014-04-22 16:24]: > along with OpenNTPd, OpenBGPd - which > probably have similar standards non-compliance I wrote both of them, they are as standards compliant as it gets. we would have implemented vrrp if it hadn't been patent encumbered. in the end, that was even good, since carp, opposed to vrrp, has authentication and is address family independent. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From marco at paesani.it Tue Apr 22 15:27:14 2014 From: marco at paesani.it (Marco Paesani) Date: Tue, 22 Apr 2014 17:27:14 +0200 Subject: Prefix problem on full routing table Message-ID: Hi, do you know more news about prefix today ? Regards, Marco [image: Immagine in linea 1] -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 43912 bytes Desc: not available URL: From rwebb at ropeguru.com Tue Apr 22 17:03:28 2014 From: rwebb at ropeguru.com (rwebb at ropeguru.com) Date: Tue, 22 Apr 2014 13:03:28 -0400 Subject: Comcast transit problems? In-Reply-To: References: Message-ID: Looks like they are having issues other than Atlanta. http://downdetector.com/status/comcast-xfinity/map On Tue, 22 Apr 2014 09:06:35 -0500 Blair Trosper wrote: > I'm being inundated with reports from Comcast customers in various >markets > about their inability to reach anything on AWS. For example, we >have a few > people in Atlanta that are all having this issue. > > What's more, they're having weird issues reaching things like >Twitter or > RingCentral (while other sites like Google and CNN work fine). > > (RingCentral's support department apparently knows about this and is > telling their customers that use Comcast that they're aware of the >issue > but don't know what's going on at the present time.) > > Calls to the Comcast customer support just yield the "everything's >fine, > you're crazy" response from the staff. > > Can anyone from Comcast give me some help (or information) off list? > > -bt From pauldotwall at gmail.com Tue Apr 22 17:30:32 2014 From: pauldotwall at gmail.com (Paul WALL) Date: Tue, 22 Apr 2014 13:30:32 -0400 Subject: US patent 5473599 In-Reply-To: <20140422151122.GN1206@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> Message-ID: On Tuesday, April 22, 2014, Henning Brauer wrote: > I won't waste time on your uninformed ramblings, you have the facts > plain wrong. There is enough material on the net for everybody to read > up on what happened. > > "carp causing outages" however is nothing short of a lie. carp > announces itself as vrrp version 3. anything trying to parse it as > vrrp2 without checking the version number in the header is buggy as > hell and that is ITS fault, not carps. affected cisco 3600, afair. I wasn't talking about CARP's announcements causing outages due to bugs in VRRP implementations, I was talking about CARP's intentional use of another organization's OUI and deliberately constructing its bits in the host section to conflict with established practice for VRRP. That was childish, and causes outages. This design choice should be documented in CARP's man page. It is not. In response to Ryan Shea, here's the way it breaks down: Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made). The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck. If either of these decisions had not been made, we would not be having this discussion today. The last octet is the VRID for both CARP and VRRP. If you don't have the same VRID configured, the protocols should peacefully coexist, assuming no bugs in the software listening to the multicast advertisements (which Henning mentioned above - a legitimate concern to be sure, but not the big one). So yes, the problem only exists if you are running VRRP and CARP on the same subnet (say, a pair of routers speaking VRRP and a pair of firewalls backing each other with CARP and pfsync, which is actually fairly common) and happen to have a host identifier conflict. In a completely random world the likelihood of this is 1 in 256. Unfortunately, human nature and a plethora of examples on the intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" reasonably likely. The same human nature causes the out of the box configuration on many products, e.g. pfSense, to be "ifconfig carp0 vhid 1". Presto - outage for everyone on the subnet. Soapbox time. There are some people who decide that they will only run FOSS software because of how they feel about software patents. In my case, I will not run CARP because of how I feel about folks deliberately violating the interoperability maxim ("be conservative in what you send and liberal in what you accept") and causing *me* to be the collateral damage. I think we all have enough on our plates dealing with legitimate software bugs without having rogue protocols deliberately interfering with our networks because of a grudge. Is CARP malware? A trojan? I'm not sure I'd go that far, but it seems to meet some of the definitions. Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake. If your lawyers have advised you not to apologize because of liability concerns (despite that "no warranty" bit in the BSD license) it's OK - I completely understand. Drive Slow, Paul From sclark at netwolves.com Tue Apr 22 17:46:37 2014 From: sclark at netwolves.com (Steve Clark) Date: Tue, 22 Apr 2014 13:46:37 -0400 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> Message-ID: <5356AAFD.5070808@netwolves.com> On 04/22/2014 01:30 PM, Paul WALL wrote: > On Tuesday, April 22, 2014, Henning Brauer wrote: > >> I won't waste time on your uninformed ramblings, you have the facts >> plain wrong. There is enough material on the net for everybody to read >> up on what happened. >> >> "carp causing outages" however is nothing short of a lie. carp >> announces itself as vrrp version 3. anything trying to parse it as >> vrrp2 without checking the version number in the header is buggy as >> hell and that is ITS fault, not carps. affected cisco 3600, afair. > > I wasn't talking about CARP's announcements causing outages due to > bugs in VRRP implementations, I was talking about CARP's intentional > use of another organization's OUI and deliberately constructing its > bits in the host section to conflict with established practice for > VRRP. That was childish, and causes outages. This design choice > should be documented in CARP's man page. It is not. > > In response to Ryan Shea, here's the way it breaks down: > > Both CARP and VRRP use virtual router MAC addresses that start with > 00:00:5e. This organizational unique identifier (OUI) is assigned to > IANA, not OpenBSD or a related project. The CARP authors could have > gotten their own from IEEE. OUIs are not free but the cost is quite > reasonable (and was even more reasonable years ago when this > unfortunate decision was made). > > The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, > the CARP folks *also* decided to use 00:01 after they got upset at the > IETF for dissing their slide deck. > > If either of these decisions had not been made, we would not be having > this discussion today. > > The last octet is the VRID for both CARP and VRRP. If you don't have > the same VRID configured, the protocols should peacefully coexist, > assuming no bugs in the software listening to the multicast > advertisements (which Henning mentioned above - a legitimate concern > to be sure, but not the big one). > > So yes, the problem only exists if you are running VRRP and CARP on > the same subnet (say, a pair of routers speaking VRRP and a pair of > firewalls backing each other with CARP and pfsync, which is actually > fairly common) and happen to have a host identifier conflict. In a > completely random world the likelihood of this is 1 in 256. > Unfortunately, human nature and a plethora of examples on the > intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" > reasonably likely. The same human nature causes the out of the box > configuration on many products, e.g. pfSense, to be "ifconfig carp0 > vhid 1". Presto - outage for everyone on the subnet. > > Soapbox time. There are some people who decide that they will only > run FOSS software because of how they feel about software patents. In > my case, I will not run CARP because of how I feel about folks > deliberately violating the interoperability maxim ("be conservative in > what you send and liberal in what you accept") and causing *me* to be > the collateral damage. I think we all have enough on our plates > dealing with legitimate software bugs without having rogue protocols > deliberately interfering with our networks because of a grudge. Is > CARP malware? A trojan? I'm not sure I'd go that far, but it seems > to meet some of the definitions. > > Nothing personal Henning (and I like what you did with OpenBGPd and > OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a > bunch of other people's, if you publicly admitted the CARP OUI > decision was a huge mistake. If your lawyers have advised you not to > apologize because of liability concerns (despite that "no warranty" > bit in the BSD license) it's OK - I completely understand. > > Drive Slow, > Paul > I think there is also the issue it uses the same protocol number - 112. From /etc/protocolsvrrp 112 VRRP # Virtual Router Redundancy Protocol -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From wbailey at satelliteintelligencegroup.com Tue Apr 22 18:06:12 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 22 Apr 2014 18:06:12 +0000 Subject: US patent 5473599 In-Reply-To: <5356AAFD.5070808@netwolves.com> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> , <5356AAFD.5070808@netwolves.com> Message-ID: Imitation is the highest form of flattery. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Steve Clark Date: 04/22/2014 11:48 AM (GMT-07:00) To: Paul WALL Cc: nanog at nanog.org Subject: Re: US patent 5473599 On 04/22/2014 01:30 PM, Paul WALL wrote: > On Tuesday, April 22, 2014, Henning Brauer wrote: > >> I won't waste time on your uninformed ramblings, you have the facts >> plain wrong. There is enough material on the net for everybody to read >> up on what happened. >> >> "carp causing outages" however is nothing short of a lie. carp >> announces itself as vrrp version 3. anything trying to parse it as >> vrrp2 without checking the version number in the header is buggy as >> hell and that is ITS fault, not carps. affected cisco 3600, afair. > > I wasn't talking about CARP's announcements causing outages due to > bugs in VRRP implementations, I was talking about CARP's intentional > use of another organization's OUI and deliberately constructing its > bits in the host section to conflict with established practice for > VRRP. That was childish, and causes outages. This design choice > should be documented in CARP's man page. It is not. > > In response to Ryan Shea, here's the way it breaks down: > > Both CARP and VRRP use virtual router MAC addresses that start with > 00:00:5e. This organizational unique identifier (OUI) is assigned to > IANA, not OpenBSD or a related project. The CARP authors could have > gotten their own from IEEE. OUIs are not free but the cost is quite > reasonable (and was even more reasonable years ago when this > unfortunate decision was made). > > The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, > the CARP folks *also* decided to use 00:01 after they got upset at the > IETF for dissing their slide deck. > > If either of these decisions had not been made, we would not be having > this discussion today. > > The last octet is the VRID for both CARP and VRRP. If you don't have > the same VRID configured, the protocols should peacefully coexist, > assuming no bugs in the software listening to the multicast > advertisements (which Henning mentioned above - a legitimate concern > to be sure, but not the big one). > > So yes, the problem only exists if you are running VRRP and CARP on > the same subnet (say, a pair of routers speaking VRRP and a pair of > firewalls backing each other with CARP and pfsync, which is actually > fairly common) and happen to have a host identifier conflict. In a > completely random world the likelihood of this is 1 in 256. > Unfortunately, human nature and a plethora of examples on the > intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" > reasonably likely. The same human nature causes the out of the box > configuration on many products, e.g. pfSense, to be "ifconfig carp0 > vhid 1". Presto - outage for everyone on the subnet. > > Soapbox time. There are some people who decide that they will only > run FOSS software because of how they feel about software patents. In > my case, I will not run CARP because of how I feel about folks > deliberately violating the interoperability maxim ("be conservative in > what you send and liberal in what you accept") and causing *me* to be > the collateral damage. I think we all have enough on our plates > dealing with legitimate software bugs without having rogue protocols > deliberately interfering with our networks because of a grudge. Is > CARP malware? A trojan? I'm not sure I'd go that far, but it seems > to meet some of the definitions. > > Nothing personal Henning (and I like what you did with OpenBGPd and > OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a > bunch of other people's, if you publicly admitted the CARP OUI > decision was a huge mistake. If your lawyers have advised you not to > apologize because of liability concerns (despite that "no warranty" > bit in the BSD license) it's OK - I completely understand. > > Drive Slow, > Paul > I think there is also the issue it uses the same protocol number - 112. From /etc/protocolsvrrp 112 VRRP # Virtual Router Redundancy Protocol -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From EWieling at nyigc.com Tue Apr 22 18:16:18 2014 From: EWieling at nyigc.com (Eric Wieling) Date: Tue, 22 Apr 2014 14:16:18 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> Message-ID: <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> It seems to me you are saying we should get rid of firewalls and rely on applications network security. This is so utterly idiotic I must be misunderstanding something. There are a few things we can count on in life, death, taxes, and application developers leaving giant security holes in their applications. -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Saturday, April 19, 2014 12:10 AM To: nanog at nanog.org Subject: Re: Requirements for IPv6 Firewalls You can 'call' it all you like - but people who actually want to keep their servers up and running don't put stateful firewalls in front of them, because it's very easy to knock them over due to state exhaustion. In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts. Also, you might want to search the NANOG email archive on this topic. There's lots of previous discussion, which boils down to the fact that serious organizations running serious applications/services don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers. The only way to secure hosts/applications/service against compromise is via those hosts/applications/services themselves. Inserting stateful middleboxes doesn't actually accomplish anything to enhance confidentiality and integrity, actually increases the attack surface due to middlebox exploits (read the numerous security notices for various commercial and open-source stateful firewalls for compromise exploits), and has a negative impact on availability. From smeuse at mara.org Tue Apr 22 18:44:06 2014 From: smeuse at mara.org (Steve Meuse) Date: Tue, 22 Apr 2014 14:44:06 -0400 Subject: Comcast transit problems? In-Reply-To: References: Message-ID: If anyone want to provide me with *useful* troubleshooting information, I'll be glad to help. I can't tell what use that website has, it offers zero detail. -Steve On Tue, Apr 22, 2014 at 1:03 PM, rwebb at ropeguru.com wrote: > > Looks like they are having issues other than Atlanta. > > http://downdetector.com/status/comcast-xfinity/map > > > On Tue, 22 Apr 2014 09:06:35 -0500 > Blair Trosper wrote: > >> I'm being inundated with reports from Comcast customers in various markets >> about their inability to reach anything on AWS. For example, we have a >> few >> people in Atlanta that are all having this issue. >> >> What's more, they're having weird issues reaching things like Twitter or >> RingCentral (while other sites like Google and CNN work fine). >> >> (RingCentral's support department apparently knows about this and is >> telling their customers that use Comcast that they're aware of the issue >> but don't know what's going on at the present time.) >> >> Calls to the Comcast customer support just yield the "everything's fine, >> you're crazy" response from the staff. >> >> Can anyone from Comcast give me some help (or information) off list? >> >> -bt >> > > > From bjohnson at drtel.com Tue Apr 22 18:55:03 2014 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 22 Apr 2014 18:55:03 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> Message-ID: Eric, If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that. I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths. - Brian > -----Original Message----- > From: Eric Wieling [mailto:EWieling at nyigc.com] > Sent: Tuesday, April 22, 2014 1:16 PM > To: Dobbins, Roland; nanog at nanog.org > Subject: RE: Requirements for IPv6 Firewalls > > It seems to me you are saying we should get rid of firewalls and rely on > applications network security. > > This is so utterly idiotic I must be misunderstanding something. There are a > few things we can count on in life, death, taxes, and application developers > leaving giant security holes in their applications. > > -----Original Message----- > From: Dobbins, Roland [mailto:rdobbins at arbor.net] > Sent: Saturday, April 19, 2014 12:10 AM > To: nanog at nanog.org > Subject: Re: Requirements for IPv6 Firewalls > > You can 'call' it all you like - but people who actually want to keep their > servers up and running don't put stateful firewalls in front of them, because > it's very easy to knock them over due to state exhaustion. In fact, it's far > easier to knock them over than to knock over properly-tuned naked hosts. > > Also, you might want to search the NANOG email archive on this topic. > There's lots of previous discussion, which boils down to the fact that serious > organizations running serious applications/services don't put stateful > firewalls (or 'IPS', or NATs, et. al.) in front of their servers. > > The only way to secure hosts/applications/service against compromise is via > those hosts/applications/services themselves. Inserting stateful > middleboxes doesn't actually accomplish anything to enhance confidentiality > and integrity, actually increases the attack surface due to middlebox exploits > (read the numerous security notices for various commercial and open-source > stateful firewalls for compromise exploits), and has a negative impact on > availability. > > From morrowc.lists at gmail.com Tue Apr 22 19:18:21 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Apr 2014 15:18:21 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> Message-ID: On Tue, Apr 22, 2014 at 2:55 PM, Brian Johnson wrote: > Eric, > > If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that. > Roland's saying basically: 1) if you deploy something on 'the internet' you should secure that something 2) the securing of that 'thing' should NOT be be placing a stateful device between your users and the 'thing'. In a simple case of: "Put a web server on the internet" Roland's advice breaks down to: 1) deploy server 2) put acl on upstream router like: permit tcp any any eq 80 deny ip any any 3) profit The router + acl will process line-rate traffic without care. -chris > I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths. > > - Brian > >> -----Original Message----- >> From: Eric Wieling [mailto:EWieling at nyigc.com] >> Sent: Tuesday, April 22, 2014 1:16 PM >> To: Dobbins, Roland; nanog at nanog.org >> Subject: RE: Requirements for IPv6 Firewalls >> >> It seems to me you are saying we should get rid of firewalls and rely on >> applications network security. >> >> This is so utterly idiotic I must be misunderstanding something. There are a >> few things we can count on in life, death, taxes, and application developers >> leaving giant security holes in their applications. >> >> -----Original Message----- >> From: Dobbins, Roland [mailto:rdobbins at arbor.net] >> Sent: Saturday, April 19, 2014 12:10 AM >> To: nanog at nanog.org >> Subject: Re: Requirements for IPv6 Firewalls >> >> You can 'call' it all you like - but people who actually want to keep their >> servers up and running don't put stateful firewalls in front of them, because >> it's very easy to knock them over due to state exhaustion. In fact, it's far >> easier to knock them over than to knock over properly-tuned naked hosts. >> >> Also, you might want to search the NANOG email archive on this topic. >> There's lots of previous discussion, which boils down to the fact that serious >> organizations running serious applications/services don't put stateful >> firewalls (or 'IPS', or NATs, et. al.) in front of their servers. >> >> The only way to secure hosts/applications/service against compromise is via >> those hosts/applications/services themselves. Inserting stateful >> middleboxes doesn't actually accomplish anything to enhance confidentiality >> and integrity, actually increases the attack surface due to middlebox exploits >> (read the numerous security notices for various commercial and open-source >> stateful firewalls for compromise exploits), and has a negative impact on >> availability. >> >> > > From morrowc.lists at gmail.com Tue Apr 22 19:45:57 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 22 Apr 2014 15:45:57 -0400 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> Message-ID: On Tue, Apr 22, 2014 at 3:41 PM, Matthew Huff wrote: > I think some of the disconnect is the difference between a provider network and a corporate one. > > For example, www.foo.com if it is highly visible and has a high traffic rate would have load balancers and line rate routers, but no statefull firewalls. > > Corporate foo.com, on the other hand, where end-users, and internal servers reside, almost certainly has a statefull firewall. > doesn't this come down to design of the whole system though? or rather, I bet roland would point out that this comes down to the design of the whole system... and tradeoffs folk decide to make/break. watching a corporate mail server complex melt down because some 'well intentioned admin' put a stateful firewall (with a single rule; "permit smtp"!) in front of the mail servers ... Having to explain to them (and losing because 'policy') that 'permit tcp any any eq 25' was more effective and better for their systems health was quite painful. eventually the CIO didn't listen and he works elsewhere. > Personally, if I were told to use only host based security on a corporate network and no central administrated firewall, I'd be shopping my resume. why? sure there's a place for things like firewalls, but there's also a fine place for just 'drop packets with filters and don't maintain state'. it really comes down to the design goals of the whole system. -chris > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Tuesday, April 22, 2014 3:18 PM > To: Brian Johnson > Cc: nanog at nanog.org > Subject: Re: Requirements for IPv6 Firewalls > > On Tue, Apr 22, 2014 at 2:55 PM, Brian Johnson wrote: >> Eric, >> >> If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that. >> > > Roland's saying basically: > 1) if you deploy something on 'the internet' you should secure that something > 2) the securing of that 'thing' should NOT be be placing a stateful device between your users and the 'thing'. > > In a simple case of: > "Put a web server on the internet" > > Roland's advice breaks down to: > 1) deploy server > 2) put acl on upstream router like: > permit tcp any any eq 80 > deny ip any any > 3) profit > > The router + acl will process line-rate traffic without care. > > -chris > >> I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths. >> >> - Brian >> >>> -----Original Message----- >>> From: Eric Wieling [mailto:EWieling at nyigc.com] >>> Sent: Tuesday, April 22, 2014 1:16 PM >>> To: Dobbins, Roland; nanog at nanog.org >>> Subject: RE: Requirements for IPv6 Firewalls >>> >>> It seems to me you are saying we should get rid of firewalls and rely >>> on applications network security. >>> >>> This is so utterly idiotic I must be misunderstanding something. There are a >>> few things we can count on in life, death, taxes, and application >>> developers leaving giant security holes in their applications. >>> >>> -----Original Message----- >>> From: Dobbins, Roland [mailto:rdobbins at arbor.net] >>> Sent: Saturday, April 19, 2014 12:10 AM >>> To: nanog at nanog.org >>> Subject: Re: Requirements for IPv6 Firewalls >>> >>> You can 'call' it all you like - but people who actually want to keep >>> their servers up and running don't put stateful firewalls in front of >>> them, because it's very easy to knock them over due to state >>> exhaustion. In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts. >>> >>> Also, you might want to search the NANOG email archive on this topic. >>> There's lots of previous discussion, which boils down to the fact >>> that serious organizations running serious applications/services >>> don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers. >>> >>> The only way to secure hosts/applications/service against compromise >>> is via those hosts/applications/services themselves. Inserting >>> stateful middleboxes doesn't actually accomplish anything to enhance >>> confidentiality and integrity, actually increases the attack surface >>> due to middlebox exploits (read the numerous security notices for >>> various commercial and open-source stateful firewalls for compromise >>> exploits), and has a negative impact on availability. >>> >>> >> >> > From dougb at dougbarton.us Tue Apr 22 20:02:43 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 22 Apr 2014 13:02:43 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> Message-ID: <5356CAE3.6040809@dougbarton.us> On 04/22/2014 12:18 PM, Christopher Morrow wrote: > Roland's saying basically: > 1) if you deploy something on 'the internet' you should secure that something > 2) the securing of that 'thing' should NOT be be placing a stateful > device between your users and the 'thing'. > > In a simple case of: > "Put a web server on the internet" > > Roland's advice breaks down to: > 1) deploy server > 2) put acl on upstream router like: > permit tcp any any eq 80 > deny ip any any > 3) profit > > The router + acl will process line-rate traffic without care. A key part of this overall strategy is also "Harden the system to run only those services it needs to do its job." And the above implies that things like ssh (i.e., management services) should be ACL'ed to only allow access from inside .... etc. But otherwise, yes; and yes, this strategy is very successful. It removes the stateful firewall as the SPOF. Doug From mhuff at ox.com Tue Apr 22 20:15:37 2014 From: mhuff at ox.com (Matthew Huff) Date: Tue, 22 Apr 2014 20:15:37 +0000 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <534FFE1A.8030100@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> Message-ID: I should have clarified that better. I wouldn't manage a corporate network without a centrally managed firewall (stateful; or not). Depending on host security alone, especially Windows desktops, isn't something I would care to be a part of. Some IPv6 pundits have pushed the idea of re-establishing the norm of end-to-end connectivity without regard to anything other than host security. This may be fine for educational, residential, and/or public networks, but IMHO a really bad idea for corporate networks. Compliance and auditing are only a few of the issues. BTW, There are a number of reasons for coroporate use of source and destination NATing that have nothing to do with the type of security that has been discussed. For example: 1) We have a business partner that requires all access to their data come from a small IP range (1-4 addresses). We have a distributed batch system that downloads/processes nightly data. We had to implement NAT so that all of our machines appear to come from those 4 address. I made it known how easy it was to defeat their access security, and how inane it was. I spoke directly to their VP of IT, and it didn't matter. If we wanted their data, we had to comply. Since no other company provides that data, we had to use NAT. Elegant design always loses to practical concerns. 2) We use source and destination nat via our extranet provider (BT-Radianz) over private lines. NAT is done for a number of reasons including traffic engineering and network information hiding. Most of the partners on the other side of the extranet have very tight ACLs. If we were to need to change our source IP, it would take a miracle to get it changed on their side short of 3-4 weeks. That's the world some people live in. ---- Matthew Huff???????????? | 1 Manhattanville Rd Director of Operations?? | Purchase, NY 10577 OTA Management LLC??? ???| Phone: 914-460-4039 -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, April 22, 2014 3:46 PM To: Matthew Huff Cc: Brian Johnson; nanog at nanog.org Subject: Re: Requirements for IPv6 Firewalls On Tue, Apr 22, 2014 at 3:41 PM, Matthew Huff wrote: > I think some of the disconnect is the difference between a provider network and a corporate one. > > For example, www.foo.com if it is highly visible and has a high traffic rate would have load balancers and line rate routers, but no statefull firewalls. > > Corporate foo.com, on the other hand, where end-users, and internal servers reside, almost certainly has a statefull firewall. > doesn't this come down to design of the whole system though? or rather, I bet roland would point out that this comes down to the design of the whole system... and tradeoffs folk decide to make/break. watching a corporate mail server complex melt down because some 'well intentioned admin' put a stateful firewall (with a single rule; "permit smtp"!) in front of the mail servers ... Having to explain to them (and losing because 'policy') that 'permit tcp any any eq 25' was more effective and better for their systems health was quite painful. eventually the CIO didn't listen and he works elsewhere. > Personally, if I were told to use only host based security on a corporate network and no central administrated firewall, I'd be shopping my resume. why? sure there's a place for things like firewalls, but there's also a fine place for just 'drop packets with filters and don't maintain state'. it really comes down to the design goals of the whole system. -chris > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Tuesday, April 22, 2014 3:18 PM > To: Brian Johnson > Cc: nanog at nanog.org > Subject: Re: Requirements for IPv6 Firewalls > > On Tue, Apr 22, 2014 at 2:55 PM, Brian Johnson wrote: >> Eric, >> >> If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that. >> > > Roland's saying basically: > 1) if you deploy something on 'the internet' you should secure that something > 2) the securing of that 'thing' should NOT be be placing a stateful device between your users and the 'thing'. > > In a simple case of: > "Put a web server on the internet" > > Roland's advice breaks down to: > 1) deploy server > 2) put acl on upstream router like: > permit tcp any any eq 80 > deny ip any any > 3) profit > > The router + acl will process line-rate traffic without care. > > -chris > >> I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths. >> >> - Brian >> >>> -----Original Message----- >>> From: Eric Wieling [mailto:EWieling at nyigc.com] >>> Sent: Tuesday, April 22, 2014 1:16 PM >>> To: Dobbins, Roland; nanog at nanog.org >>> Subject: RE: Requirements for IPv6 Firewalls >>> >>> It seems to me you are saying we should get rid of firewalls and >>> rely on applications network security. >>> >>> This is so utterly idiotic I must be misunderstanding something. There are a >>> few things we can count on in life, death, taxes, and application >>> developers leaving giant security holes in their applications. >>> >>> -----Original Message----- >>> From: Dobbins, Roland [mailto:rdobbins at arbor.net] >>> Sent: Saturday, April 19, 2014 12:10 AM >>> To: nanog at nanog.org >>> Subject: Re: Requirements for IPv6 Firewalls >>> >>> You can 'call' it all you like - but people who actually want to >>> keep their servers up and running don't put stateful firewalls in >>> front of them, because it's very easy to knock them over due to >>> state exhaustion. In fact, it's far easier to knock them over than to knock over properly-tuned naked hosts. >>> >>> Also, you might want to search the NANOG email archive on this topic. >>> There's lots of previous discussion, which boils down to the fact >>> that serious organizations running serious applications/services >>> don't put stateful firewalls (or 'IPS', or NATs, et. al.) in front of their servers. >>> >>> The only way to secure hosts/applications/service against compromise >>> is via those hosts/applications/services themselves. Inserting >>> stateful middleboxes doesn't actually accomplish anything to enhance >>> confidentiality and integrity, actually increases the attack surface >>> due to middlebox exploits (read the numerous security notices for >>> various commercial and open-source stateful firewalls for compromise >>> exploits), and has a negative impact on availability. >>> >>> >> >> > From dougb at dougbarton.us Tue Apr 22 20:28:34 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 22 Apr 2014 13:28:34 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> Message-ID: <5356D0F2.5050909@dougbarton.us> On 04/22/2014 01:15 PM, Matthew Huff wrote: > I wouldn't manage a corporate network without a centrally managed firewall (stateful; or not). Matthew, No one is saying that. What Roland is saying, and the position that I agree with, is that putting a firewall in front of a system _that is intended to be ON the Internet, serving external users_, is a bad idea. I think it's a given that you'd want to protect your internal systems with a firewall (except for the aforementioned IPv6 illuminati, of whom I am not one). Doug From george.herbert at gmail.com Tue Apr 22 20:49:29 2014 From: george.herbert at gmail.com (George Herbert) Date: Tue, 22 Apr 2014 13:49:29 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: <5356D0F2.5050909@dougbarton.us> References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> <5356D0F2.5050909@dougbarton.us> Message-ID: As long as the various stateful firewalls and IDS systems offer hostile action detection and blocking capabilities that raw webservers lack, there are certainly counterarguments to the "port filter only" approach being advocated here. Focusing only on DDOS prevention from one narrow range of attack vectors targeting the firewalls themselves is narrowminded. The security threat envelope is pretty wide. Vulnerabilities of similar nature exist on the webservers themselves, and on load balancer devices you will likely need anyways. Any number of enterprises have chosen that if a DDOS or other advanced attack is going to be successful, to let that be successful in bringing down a firewall on the external shell of the security envelope rather than having penetrated to the servers level. Smart design can also handle transparently failing over should such a vendor-specific attack succeed. The idea that anyone doing real, big complex networks would or has to accept any SPOF is ludicrous. The question is, how important is avoiding SPOFs, and how committed you are. If the answer is "absolutely must, and we have enough budget to do so" then it's entirely doable. On Tue, Apr 22, 2014 at 1:28 PM, Doug Barton wrote: > On 04/22/2014 01:15 PM, Matthew Huff wrote: > >> I wouldn't manage a corporate network without a centrally managed >> firewall (stateful; or not). >> > > Matthew, > > No one is saying that. What Roland is saying, and the position that I > agree with, is that putting a firewall in front of a system _that is > intended to be ON the Internet, serving external users_, is a bad idea. > > I think it's a given that you'd want to protect your internal systems with > a firewall (except for the aforementioned IPv6 illuminati, of whom I am not > one). > > Doug > > > -- -george william herbert george.herbert at gmail.com From dougb at dougbarton.us Tue Apr 22 22:28:08 2014 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 22 Apr 2014 15:28:08 -0700 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> <5356D0F2.5050909@dougbarton.us> Message-ID: <5356ECF8.1090501@dougbarton.us> On 04/22/2014 01:49 PM, George Herbert wrote: > As long as the various stateful firewalls and IDS systems offer hostile > action detection and blocking capabilities that raw webservers lack, > there are certainly counterarguments to the "port filter only" approach > being advocated here. Right, but now you're talking about something other than just a firewall. > Focusing only on DDOS prevention from one narrow range of attack vectors > targeting the firewalls themselves is narrowminded. The security threat > envelope is pretty wide. Vulnerabilities of similar nature exist on the > webservers themselves, and on load balancer devices you will likely need > anyways. Again, sure, but removing a needless firewall from the equation is one less thing to worry about. > Any number of enterprises have chosen that if a DDOS or other advanced > attack is going to be successful, to let that be successful in bringing > down a firewall on the external shell of the security envelope rather > than having penetrated to the servers level. And if they are making that choice proactively who am I to argue? I disagree, but their network, their rules. What usually happens though is that enterprises believe that the firewall will protect them, without understanding that it can actually create a SPOF instead. > Smart design can also handle transparently failing over should such a > vendor-specific attack succeed. The idea that anyone doing real, big > complex networks would or has to accept any SPOF is ludicrous. The > question is, how important is avoiding SPOFs, and how committed you are. > If the answer is "absolutely must, and we have enough budget to do so" > then it's entirely doable. Of course. Doug From lukasz at bromirski.net Tue Apr 22 22:50:57 2014 From: lukasz at bromirski.net (Lukasz Bromirski) Date: Wed, 23 Apr 2014 00:50:57 +0200 Subject: Requirements for IPv6 Firewalls In-Reply-To: References: <534FAD41.8040604@gont.com.ar> <53516168.6010002@per.reau.lt> <5351638A.2080601@per.reau.lt> <53516999.5080605@per.reau.lt> <6C9B51B5-8C16-467F-8F83-464549359F94@arbor.net> <5351D9B3.2030902@utc.edu> <0CFB0993-B486-451D-BF22-C7309E3406AC@arbor.net> <5351EDA4.6030009@utc.edu> <46E462F4-B382-4948-99BB-57B9700CC987@arbor.net> <616B4ECE1290D441AD56124FEBB03D0818EB7AE0B9@mailserver2007.nyigc.globe> < 5356D0F2.5050909@dougbarton.us> Message-ID: <7772DD5C-F741-40B6-B4C6-44E073D082BC@bromirski.net> On 22 Apr 2014, at 22:49, George Herbert wrote: > Any number of enterprises have chosen that if a DDOS or other advanced > attack is going to be successful, to let that be successful in bringing > down a firewall on the external shell of the security envelope rather than > having penetrated to the servers level. And I don?t think there?s problem with that approach. The problem starts, when those anonymous enterprises ?silently" expect, that: a) firewall will somehow magically defend the network, scrub the ?bad? traffic and let good traffic pass (?that?s why we?ve paid for state of the art firewall, right?!?) b) firewall will fail gracefully, taking down all services, and doing real hole in the transport and not jabbing some packets there and there, maybe malformed, maybe parts of different connections crammed in wrong headers? until reboot; and the reboot may not be also totally transparent, as links will go up, down, init, and so on c) insert your own horror-story here ?and using those assumptions to advocate for stateful firewall everywhere. If you?re aware of that assumptions, and you?re aware of the constraints we?re facing with actually developing working edge defence for the network, you?ll be anyway advocating creation of a funnel - with stateless first lines od defense, taking care of all the trash that can come from the internet, and rate-limiting the traffic that seems to be legitimate if above certain thresholds. And at that point - stateful firewall may not be needed anymore, because service itself can scale better. Nowadays, enterprise networks are picking up best practices from SPs, where scale does matter and networks are built to actually have that characteristics. Anycast DNS is often found in enterprise networks, as well as other anycasted services (usually in ?shared IP? model) - mail, web, AAA and other services. The same goes for actually protecting the internet edge. How often your network is being DDoSed? Be it 300kpps or 5Mpps, how will your stateful firewall at the edge of it deal with it? And by the way, when we?re speaking about internet visible services - how many stateful firewalls defend www.google.com? Or www.amazon.com? Or OpenDNS servers? Or 8.8.8.8/8.8.4.4? I bet none. But would love to hear from people maintaining them. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From charles at thefnf.org Tue Apr 22 23:53:19 2014 From: charles at thefnf.org (Charles N. Wyble) Date: Tue, 22 Apr 2014 18:53:19 -0500 Subject: Someone with IP clue @Suddenlink please contact me Message-ID: <535700EF.3080602@thefnf.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, Anyone from Suddenlink on this list? If so, please contact me unicast. I'm seeing some very significant issues originating in your network core and want to get them sorted out. The normal channels haven't been helpful. Yes I'm a downstream customer. Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTVwDvAAoJEMvvG/TyLEAtS7wQAJeK2dnSlelTM5uL7FiUHzxN bKIMXgGdcT4rbP1vvNnLH9kRTUQC7gTHAUbhCxaTjEhhNJKEzlsRR9b1d7nxCaKv 2m1knsb793CI/AbaRG0WUBxpXOvYoQicRMjht5ynoL5jSVzL+HmgMUF7LBdFBH8g 8MnS+3LVb1B120NvPobuzMGdcz4reg4L78MHJFUDVRWKp47u0adKpEacGHMcahz8 CJzECfD8Z7gQfLpup8kIpl/ZzxlQwvfdR4oUBSaaqVK0OBILE0TXZ5erqxn2zlCx 4KJMF8jhVNNs54KBSpXo+qCCcRCCZ663EVaSnSAzT6ODJwk+QpLua/NZXWstn2AS 9e8bMpa10yjbzlXSLYYjaAgvHeRUJ/CFm3pZR8iitYNUt8yU5Br38R3RZFKRFUBB ionEmuMU4XjdhYSJrtbZ+Ag2CDEOidOP7LXTt+Wf7GMeII+kE18LJX03QE1/cxxu ErWPaWDTb7fl4RkUcQ6E+QUSzR6ib+WCgFj7SZ41jm8HXr9U09FkXYTnU2AcJULn y0PI1/9x66kCi64mZE03qBC5nv+M/vaFT/w9y1kL8KJxXCkY/4Qz8tdilB2SsBvc R1gVDnyjWzNN0p7mqM4ZlruSPQlJyENzF8Zf/ksPM/DFY19bxE6pH4RKMmz6kpIf i4cU78SeVaa7ETXm7auO =lhNi -----END PGP SIGNATURE----- From ed at edgeoc.net Tue Apr 22 15:19:14 2014 From: ed at edgeoc.net (Edward Salonia) Date: Tue, 22 Apr 2014 11:19:14 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: <46DA92A5-5BED-4F02-A7F2-E0F792E10FBF@edgeoc.net> Not sure what platform you are working with but does the ONS-SC+-10G-C ppm help in your situation? Check out: http://www.cisco.com/c/en/us/products/collateral/optical-networking/ons-15454-series-multiservice-provisioning-platforms/data_sheet_c78-713296.html - Ed On Apr 21, 2014, at 14:57, Tim Durack wrote: As a follow up, I did not miss a zero. TenGig. If you want to know why: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf (I'll take 100Gig once I can get the optics for less than the cost of a v.nice sports car...) > On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack wrote: > > Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no > such thing.) > > How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter > receive side might be doable?) > > -- > Tim:> > > p.s. Before you ask, DTAG Terastream has got me thinking... -- Tim:> From leo.vegoda at icann.org Tue Apr 22 23:20:13 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 22 Apr 2014 16:20:13 -0700 Subject: New RIPE NCC contribution to the IANA IPv4 Recovered Address Space registry Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A63@EXVPMBX100-1.exc.icann.org> Hi, In April 2014, ICANN updated the IANA IPv4 Recovered Address Space registry to reflect the return of 14 /24 prefixes (5,376 IPv4 addresses) by the RIPE NCC. The updated registry can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space Kind regards, Leo Vegoda ICANN IANA -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From shortdudey123 at gmail.com Wed Apr 23 05:45:46 2014 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 22 Apr 2014 22:45:46 -0700 Subject: AOL Mail updates DMARC policy to 'reject' Message-ID: Thought i would throw this out there. http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ -Grant From LarrySheldon at cox.net Wed Apr 23 05:49:48 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 23 Apr 2014 00:49:48 -0500 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: References: Message-ID: <5357547C.2010900@cox.net> On 4/23/2014 12:45 AM, Grant Ridder wrote: > Thought i would throw this out there. > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ Bet THAT will get Yahoo's attention! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From eyeronic.design at gmail.com Wed Apr 23 06:19:09 2014 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 22 Apr 2014 23:19:09 -0700 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <5357547C.2010900@cox.net> References: <5357547C.2010900@cox.net> Message-ID: "We recognize that some legitimate senders will be challenged by this change and forced to update how they send mail and we sincerely regret the inconvenience to you." No they don't. On Tue, Apr 22, 2014 at 10:49 PM, Larry Sheldon wrote: > On 4/23/2014 12:45 AM, Grant Ridder wrote: >> >> Thought i would throw this out there. >> >> http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ > > Bet THAT will get Yahoo's attention! > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jcurran at arin.net Wed Apr 23 14:04:12 2014 From: jcurran at arin.net (John Curran) Date: Wed, 23 Apr 2014 14:04:12 +0000 Subject: ARIN Enters Phase Four of the IPv4 Countdown Plan References: <5357B964.3020601@arin.net> Message-ID: NANOGers - ARIN's regional IPv4 free pool has reached the equivalent of one /8 of IPv4 space, which means we are approaching runout of IPv4 space availability in this region. (See attached announcement from ARIN regarding occurrence of this event) There are some changes to processing of requests as we enter this final phase, and obviously service providers ought to be thinking about IPv6-based services, if not already in deployment. FYI, /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] ARIN Enters Phase Four of the IPv4 Countdown Plan Date: April 23, 2014 at 10:00:20 AM GMT-3 To: arin-announce at arin.net ARIN is down to its final /8 of available space in its inventory and has moved into Phase Four of its IPv4 Countdown Plan. All IPv4 requests are now subject to Countdown Plan processes, so please review the following details carefully. All IPv4 requests will be processed on a "First in, First out" basis, and all requests of any size will be subject to team review, and requests for /15 or larger will require department director approval. ARIN's resource analysts will respond to tickets as they appear chronologically in the queue. Each ticket response is treated as an individual transaction, so the completion time of a single request may vary based on customer response times and the number of requests waiting in the queue. Because each correspondence will be processed in sequence, it is possible that response times may exceed our usual two-day turnaround. The hold period for returned, reclaimed, and revoked blocks is now reduced to 60 days. All returned, revoked, and reclaimed IPv4 address space will go back into the available pool when the 60 day period has expired. Staff will continue to check routing/filtering on space being reissued and will notify recipients if there are issues. When a request is approved, the recipient will have 60 days to complete payment and/or an RSA. On the 61st day, the address space will be released back to the available pool if payment and RSA are not completed. We encourage you to visit the IPv4 Countdown Phase Four page at: https://www.arin.net/resources/request/countdown_phase4.html ARIN may experience situations where it can no longer fulfill qualifying IPv4 requests due to a lack of inventory of the desired block size. At that time, the requester may opt to accept the largest available block size or they may ask to be placed on the Waiting List for Unmet Requests. Full details about this process are available at: https://www.arin.net/resources/request/waiting_list.html Please contact hostmaster at arin.net or our Help Desk +1.703.227.0660 if you have questions about these procedural changes. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From contact at winterei.se Wed Apr 23 14:35:20 2014 From: contact at winterei.se (Paul S.) Date: Wed, 23 Apr 2014 23:35:20 +0900 Subject: ARIN Enters Phase Four of the IPv4 Countdown Plan In-Reply-To: References: <5357B964.3020601@arin.net> Message-ID: <5357CFA8.10108@winterei.se> Am I the only one who thinks this 'clench' is rather absurd especially right after one company pretty much got 1/4th of all remaining address space when there's such an insane crunch looming? Regardless of how large / important they are, that is. If anything, this is just gonna make things more difficult for smaller companies while larger ones roam free. On 4/23/2014 ?? 11:04, John Curran wrote: > NANOGers - > > ARIN's regional IPv4 free pool has reached the equivalent of one /8 of IPv4 space, > which means we are approaching runout of IPv4 space availability in this region. > (See attached announcement from ARIN regarding occurrence of this event) > > There are some changes to processing of requests as we enter this final phase, > and obviously service providers ought to be thinking about IPv6-based services, > if not already in deployment. > > FYI, > /John > > John Curran > President and CEO > ARIN > > Begin forwarded message: > > From: ARIN > > Subject: [arin-announce] ARIN Enters Phase Four of the IPv4 Countdown Plan > Date: April 23, 2014 at 10:00:20 AM GMT-3 > To: arin-announce at arin.net > > ARIN is down to its final /8 of available space in its inventory and has moved into Phase Four of its IPv4 Countdown Plan. All IPv4 requests are now subject to Countdown Plan processes, so please review the following details carefully. > > All IPv4 requests will be processed on a "First in, First out" basis, and all requests of any size will be subject to team review, and requests for /15 or larger will require department director approval. ARIN's resource analysts will respond to tickets as they appear chronologically in the queue. Each ticket response is treated as an individual transaction, so the completion time of a single request may vary based on customer response times and the number of requests waiting in the queue. Because each correspondence will be processed in sequence, it is possible that response times may exceed our usual two-day turnaround. > > The hold period for returned, reclaimed, and revoked blocks is now reduced to 60 days. All returned, revoked, and reclaimed IPv4 address space will go back into the available pool when the 60 day period has expired. Staff will continue to check routing/filtering on space being reissued and will notify recipients if there are issues. > > When a request is approved, the recipient will have 60 days to complete payment and/or an RSA. On the 61st day, the address space will be released back to the available pool if payment and RSA are not completed. > > We encourage you to visit the IPv4 Countdown Phase Four page at: > > https://www.arin.net/resources/request/countdown_phase4.html > > ARIN may experience situations where it can no longer fulfill qualifying IPv4 requests due to a lack of inventory of the desired block size. At that time, the requester may opt to accept the largest available block size or they may ask to be placed on the Waiting List for Unmet Requests. Full details about this process are available at: > > https://www.arin.net/resources/request/waiting_list.html > > Please contact hostmaster at arin.net or our Help Desk +1.703.227.0660 if you have questions about these procedural changes. > > Regards, > > Leslie Nobile > Director, Registration Services > American Registry for Internet Numbers (ARIN) > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > From patrick at ianai.net Wed Apr 23 14:47:19 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 23 Apr 2014 10:47:19 -0400 Subject: ARIN Enters Phase Four of the IPv4 Countdown Plan In-Reply-To: <5357CFA8.10108@winterei.se> References: <5357B964.3020601@arin.net> <5357CFA8.10108@winterei.se> Message-ID: <4C955FEC-565C-4938-A6DA-529D5C08EF56@ianai.net> If you didn't like it, you could have participated in the rule making where things like this were discussed at length, and voted on by the "community" (which turned out to be a very few people who gave a shit). -- TTFN, patrick On Apr 23, 2014, at 10:35, "Paul S." wrote: > > Am I the only one who thinks this 'clench' is rather absurd especially right after one company pretty much got 1/4th of all remaining address space when there's such an insane crunch looming? > > Regardless of how large / important they are, that is. > > If anything, this is just gonna make things more difficult for smaller companies while larger ones roam free. > >> On 4/23/2014 ?? 11:04, John Curran wrote: >> NANOGers - >> >> ARIN's regional IPv4 free pool has reached the equivalent of one /8 of IPv4 space, >> which means we are approaching runout of IPv4 space availability in this region. >> (See attached announcement from ARIN regarding occurrence of this event) >> >> There are some changes to processing of requests as we enter this final phase, >> and obviously service providers ought to be thinking about IPv6-based services, >> if not already in deployment. >> >> FYI, >> /John >> >> John Curran >> President and CEO >> ARIN >> >> Begin forwarded message: >> >> From: ARIN > >> Subject: [arin-announce] ARIN Enters Phase Four of the IPv4 Countdown Plan >> Date: April 23, 2014 at 10:00:20 AM GMT-3 >> To: arin-announce at arin.net >> >> ARIN is down to its final /8 of available space in its inventory and has moved into Phase Four of its IPv4 Countdown Plan. All IPv4 requests are now subject to Countdown Plan processes, so please review the following details carefully. >> >> All IPv4 requests will be processed on a "First in, First out" basis, and all requests of any size will be subject to team review, and requests for /15 or larger will require department director approval. ARIN's resource analysts will respond to tickets as they appear chronologically in the queue. Each ticket response is treated as an individual transaction, so the completion time of a single request may vary based on customer response times and the number of requests waiting in the queue. Because each correspondence will be processed in sequence, it is possible that response times may exceed our usual two-day turnaround. >> >> The hold period for returned, reclaimed, and revoked blocks is now reduced to 60 days. All returned, revoked, and reclaimed IPv4 address space will go back into the available pool when the 60 day period has expired. Staff will continue to check routing/filtering on space being reissued and will notify recipients if there are issues. >> >> When a request is approved, the recipient will have 60 days to complete payment and/or an RSA. On the 61st day, the address space will be released back to the available pool if payment and RSA are not completed. >> >> We encourage you to visit the IPv4 Countdown Phase Four page at: >> >> https://www.arin.net/resources/request/countdown_phase4.html >> >> ARIN may experience situations where it can no longer fulfill qualifying IPv4 requests due to a lack of inventory of the desired block size. At that time, the requester may opt to accept the largest available block size or they may ask to be placed on the Waiting List for Unmet Requests. Full details about this process are available at: >> >> https://www.arin.net/resources/request/waiting_list.html >> >> Please contact hostmaster at arin.net or our Help Desk +1.703.227.0660 if you have questions about these procedural changes. >> >> Regards, >> >> Leslie Nobile >> Director, Registration Services >> American Registry for Internet Numbers (ARIN) >> _______________________________________________ >> ARIN-Announce >> You are receiving this message because you are subscribed to >> the ARIN Announce Mailing List (ARIN-announce at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-announce >> Please contact info at arin.net if you experience any issues. >> > From dwcarder at wisc.edu Wed Apr 23 14:51:53 2014 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 23 Apr 2014 09:51:53 -0500 Subject: ARIN Enters Phase Four of the IPv4 Countdown Plan In-Reply-To: <5357CFA8.10108@winterei.se> References: <5357B964.3020601@arin.net> <5357CFA8.10108@winterei.se> Message-ID: <20140423145152.GH35861@ricotta.doit.wisc.edu> Thus spake Paul S. (contact at winterei.se) on Wed, Apr 23, 2014 at 11:35:20PM +0900: > Am I the only one who thinks this 'clench' is rather absurd > especially right after one company pretty much got 1/4th of all > remaining address space when there's such an insane crunch looming? Deck Chairs. Dale From bob at FiberInternetCenter.com Wed Apr 23 15:13:03 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Wed, 23 Apr 2014 08:13:03 -0700 Subject: ARIN Enters Phase Four of the IPv4 Countdown Plan In-Reply-To: <4C955FEC-565C-4938-A6DA-529D5C08EF56@ianai.net> References: <5357B964.3020601@arin.net> <5357CFA8.10108@winterei.se> <4C955FEC-565C-4938-A6DA-529D5C08EF56@ianai.net> Message-ID: Yes, you could have shown up to discuss, present arguments , vote .... there many. meetings on this as well as ARIN email discussion threads. All the hot topics are always presented at nanog/arin meets in an effort to create community awareness and gather community interest. I attended ARIN only meetings where the rooms were full - this was a hot topic of ARIN meetings many times. Your point was brought up many times - that position was represented. The process to get a big block is cumbersome...thus verizon went out to the open market to buy space. A notable verizon person attend an arin meeting and openly said so. And that was during late phase 2 or beginning of 3. So it's not that easy for a big company to get a big block. Bob Evans CTO > If you didn't like it, you could have participated in the rule making > where things like this were discussed at length, and voted on by the > "community" (which turned out to be a very few people who gave a shit). > > -- > TTFN, > patrick > > > On Apr 23, 2014, at 10:35, "Paul S." wrote: >> >> Am I the only one who thinks this 'clench' is rather absurd especially >> right after one company pretty much got 1/4th of all remaining address >> space when there's such an insane crunch looming? >> >> Regardless of how large / important they are, that is. >> >> If anything, this is just gonna make things more difficult for smaller >> companies while larger ones roam free. >> >>> On 4/23/2014 ?????? 11:04, John Curran wrote: >>> NANOGers - >>> >>> ARIN's regional IPv4 free pool has reached the equivalent of one /8 >>> of IPv4 space, >>> which means we are approaching runout of IPv4 space availability in >>> this region. >>> (See attached announcement from ARIN regarding occurrence of this >>> event) >>> >>> There are some changes to processing of requests as we enter this >>> final phase, >>> and obviously service providers ought to be thinking about >>> IPv6-based services, >>> if not already in deployment. >>> >>> FYI, >>> /John >>> >>> John Curran >>> President and CEO >>> ARIN >>> >>> Begin forwarded message: >>> >>> From: ARIN > >>> Subject: [arin-announce] ARIN Enters Phase Four of the IPv4 Countdown >>> Plan >>> Date: April 23, 2014 at 10:00:20 AM GMT-3 >>> To: arin-announce at arin.net >>> >>> ARIN is down to its final /8 of available space in its inventory and >>> has moved into Phase Four of its IPv4 Countdown Plan. All IPv4 requests >>> are now subject to Countdown Plan processes, so please review the >>> following details carefully. >>> >>> All IPv4 requests will be processed on a "First in, First out" basis, >>> and all requests of any size will be subject to team review, and >>> requests for /15 or larger will require department director approval. >>> ARIN's resource analysts will respond to tickets as they appear >>> chronologically in the queue. Each ticket response is treated as an >>> individual transaction, so the completion time of a single request may >>> vary based on customer response times and the number of requests >>> waiting in the queue. Because each correspondence will be processed in >>> sequence, it is possible that response times may exceed our usual >>> two-day turnaround. >>> >>> The hold period for returned, reclaimed, and revoked blocks is now >>> reduced to 60 days. All returned, revoked, and reclaimed IPv4 address >>> space will go back into the available pool when the 60 day period has >>> expired. Staff will continue to check routing/filtering on space being >>> reissued and will notify recipients if there are issues. >>> >>> When a request is approved, the recipient will have 60 days to complete >>> payment and/or an RSA. On the 61st day, the address space will be >>> released back to the available pool if payment and RSA are not >>> completed. >>> >>> We encourage you to visit the IPv4 Countdown Phase Four page at: >>> >>> https://www.arin.net/resources/request/countdown_phase4.html >>> >>> ARIN may experience situations where it can no longer fulfill >>> qualifying IPv4 requests due to a lack of inventory of the desired >>> block size. At that time, the requester may opt to accept the largest >>> available block size or they may ask to be placed on the Waiting List >>> for Unmet Requests. Full details about this process are available at: >>> >>> https://www.arin.net/resources/request/waiting_list.html >>> >>> Please contact hostmaster at arin.net or our Help Desk +1.703.227.0660 if >>> you have questions about these procedural changes. >>> >>> Regards, >>> >>> Leslie Nobile >>> Director, Registration Services >>> American Registry for Internet Numbers (ARIN) >>> _______________________________________________ >>> ARIN-Announce >>> You are receiving this message because you are subscribed to >>> the ARIN Announce Mailing List (ARIN-announce at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-announce >>> Please contact info at arin.net if you experience any issues. >>> >> > > From jcurran at arin.net Wed Apr 23 16:05:17 2014 From: jcurran at arin.net (John Curran) Date: Wed, 23 Apr 2014 16:05:17 +0000 Subject: ARIN Enters Phase Four of the IPv4 Countdown Plan In-Reply-To: References: <5357B964.3020601@arin.net> <5357CFA8.10108@winterei.se> <4C955FEC-565C-4938-A6DA-529D5C08EF56@ianai.net> Message-ID: <9CCEFE2E-0B15-49A0-9BC2-F9D7433D7B21@arin.net> On Apr 23, 2014, at 12:13 PM, Bob Evans wrote: > Yes, you could have shown up to discuss, present arguments , vote .... > there many. meetings on this as well as ARIN email discussion threads. All > the hot topics are always presented at nanog/arin meets in an effort to > create community awareness and gather community interest. Bob - Very well said - also, while it is true that IPv4 address allocation and assignment policy may become less relevant over time, it is not at all clear that will be the case with other policies, such as the IPv4 transfer policy. In any case, if you have views on how address space in the region should be administered, please participate in one or more of: - The ARIN ppml mailing list - The ARIN Public Policy Meeting (in-person or remote) - The ARIN Public Policy Consultations held at each NANOG We have nearly a dozen proposed policy changes being considered at the present time, and the time to express support or concern is _now_ (as opposed to after these policies changes have been approved, implemented and are in use.) FYI, /John John Curran President and CEO ARIN From hb-nanog at bsws.de Wed Apr 23 16:47:36 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Wed, 23 Apr 2014 18:47:36 +0200 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> Message-ID: <20140423164736.GD16301@quigon.bsws.de> * Paul WALL [2014-04-22 19:30]: > Both CARP and VRRP use virtual router MAC addresses that start with > 00:00:5e. This organizational unique identifier (OUI) is assigned to > IANA, not OpenBSD or a related project. The CARP authors could have > gotten their own from IEEE. OUIs are not free but the cost is quite > reasonable (and was even more reasonable years ago when this > unfortunate decision was made). we're an open source project, running on a rather small budget almost exclusively from donations, so "quite reasonable" doesn't cut it. > The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, > the CARP folks *also* decided to use 00:01 after they got upset at the > IETF for dissing their slide deck. you're interpreting way too much in here. carp has been based on an earlier, never published vrrp implementatoin we had before realizing the patent problem. i don't remember any discussion about the OUI or, more general, the mac address choice. it's 10 years ago now, so i don't remember every single detail, changing the mac addr has pbly just been forgotten. not at least using sth but 00:01 for the 4th and 5th octet was likely a mistake. changing that now - wether just 4th/5th octet or to an entirely different, donated OUI - wouldn't be easy, unfortunately. acadmic discussion as long as we don't have a suitable OUI anyway. > If either of these decisions had not been made, we would not be having > this discussion today. we weren't really given a choice. as I said before, I'd much prefer we had just been given a multicast address etc. we tried. the IEEE/IETF/IANA processes have been an utter failure in our (limited) experience, not just in this case. might be different if you're $big_vendor with deep pockets, but that doesn't help either. fortunately this obviously isn't a big problem in practice, based on the fact that we don't get any complaints/reports in that direction. still would be way micer if that situation had been created in the first place, but as said - we weren't given that choice. > Nothing personal Henning (and I like what you did with OpenBGPd and > OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a > bunch of other people's, if you publicly admitted the CARP OUI > decision was a huge mistake. huge? nah. mistake? probably. > If your lawyers have advised you not to > apologize because of liability concerns (despite that "no warranty" > bit in the BSD license) it's OK - I completely understand. you live in a bizarre world apparently. but then, that's what the US (dunno wether that is your actual background, sounds that way tho) is when it comes to patents and liability in the eyes of the rest of the world. neither of us can change that, so be it. and just to prevent confusion: I didn't implement most of carp, but was involved, and I wasn't the one dealing with IANA/IETF/whatever either. No pun intended if I mixed up IETF, IANA, IEEE somewhere here, it's not like we create new protocols every other day. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From tglassey at earthlink.net Wed Apr 23 17:10:42 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Wed, 23 Apr 2014 10:10:42 -0700 Subject: US patent 5473599 In-Reply-To: <20140423164736.GD16301@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> Message-ID: <5357F412.6020409@earthlink.net> Henning I understand your work is important - and that its open source but that is part of the problem with global patent law today. No one wants it around when their works are impacted by it. But patent publications are binding under the treaties and in fact CARP clearly is an infringement. The issue is what to do do about it. Todd Glassey On 4/23/2014 9:47 AM, Henning Brauer wrote: > * Paul WALL [2014-04-22 19:30]: >> Both CARP and VRRP use virtual router MAC addresses that start with >> 00:00:5e. This organizational unique identifier (OUI) is assigned to >> IANA, not OpenBSD or a related project. The CARP authors could have >> gotten their own from IEEE. OUIs are not free but the cost is quite >> reasonable (and was even more reasonable years ago when this >> unfortunate decision was made). > we're an open source project, running on a rather small budget almost > exclusively from donations, so "quite reasonable" doesn't cut it. > >> The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, >> the CARP folks *also* decided to use 00:01 after they got upset at the >> IETF for dissing their slide deck. > you're interpreting way too much in here. > carp has been based on an earlier, never published vrrp implementatoin > we had before realizing the patent problem. > i don't remember any discussion about the OUI or, more general, the mac > address choice. it's 10 years ago now, so i don't remember every > single detail, changing the mac addr has pbly just been forgotten. > not at least using sth but 00:01 for the 4th and 5th octet was likely > a mistake. changing that now - wether just 4th/5th octet or to an > entirely different, donated OUI - wouldn't be easy, unfortunately. > acadmic discussion as long as we don't have a suitable OUI anyway. > >> If either of these decisions had not been made, we would not be having >> this discussion today. > we weren't really given a choice. > as I said before, I'd much prefer we had just been given a multicast > address etc. we tried. the IEEE/IETF/IANA processes have been an utter > failure in our (limited) experience, not just in this case. might be > different if you're $big_vendor with deep pockets, but that doesn't > help either. > > fortunately this obviously isn't a big problem in practice, based on > the fact that we don't get any complaints/reports in that direction. > still would be way micer if that situation had been created in the > first place, but as said - we weren't given that choice. > >> Nothing personal Henning (and I like what you did with OpenBGPd and >> OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a >> bunch of other people's, if you publicly admitted the CARP OUI >> decision was a huge mistake. > huge? nah. > mistake? probably. > >> If your lawyers have advised you not to >> apologize because of liability concerns (despite that "no warranty" >> bit in the BSD license) it's OK - I completely understand. > you live in a bizarre world apparently. > but then, that's what the US (dunno wether that is your actual > background, sounds that way tho) is when it comes to patents and > liability in the eyes of the rest of the world. neither of us can > change that, so be it. > > and just to prevent confusion: I didn't implement most of carp, but was > involved, and I wasn't the one dealing with IANA/IETF/whatever either. > No pun intended if I mixed up IETF, IANA, IEEE somewhere here, it's > not like we create new protocols every other day. > -- ------------- Personal Email - Disclaimers Apply From hb-nanog at bsws.de Wed Apr 23 17:20:52 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Wed, 23 Apr 2014 19:20:52 +0200 Subject: US patent 5473599 In-Reply-To: <5357F412.6020409@earthlink.net> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> <5357F412.6020409@earthlink.net> Message-ID: <20140423172051.GB26369@quigon.bsws.de> * TGLASSEY [2014-04-23 19:13]: > in fact CARP clearly is an infringement [of the patent]. that's YOUR analysis, and it contradicts ours and the legal advice we got, so I'll ignore it. Irrelevant anyway, see subject - expired. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From jj.routerguy at gmail.com Wed Apr 23 17:28:09 2014 From: jj.routerguy at gmail.com (John Jackson) Date: Wed, 23 Apr 2014 12:28:09 -0500 Subject: IPv4 Address transfer after company acquisition Message-ID: I have a customer who previously didn't have any IPv4 address space. They recently acquired a competitor that has a /24. Are there any special ARIN rules for this type of transfer? Any pointers, or 'gotchas'? Thanks John From streiner at cluebyfour.org Wed Apr 23 15:29:59 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 23 Apr 2014 11:29:59 -0400 (EDT) Subject: IPv4 Address transfer after company acquisition In-Reply-To: References: Message-ID: On Wed, 23 Apr 2014, John Jackson wrote: > I have a customer who previously didn't have any IPv4 address space. They > recently acquired a competitor that has a /24. > > Are there any special ARIN rules for this type of transfer? > > Any pointers, or 'gotchas'? I'm pretty sure ARIN has the transfer process documented on their website. >From what I remember, ARIN will need to see some documentation of the acquisition, including a letter of agency/authorization from the company that was acquired, on the original company's letterhead. jms From owen at delong.com Wed Apr 23 19:40:29 2014 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Apr 2014 12:40:29 -0700 Subject: IPv4 Address transfer after company acquisition In-Reply-To: References: Message-ID: Without interpretation: Look on the ARIN Website.. Policies->Number Resource Policy Manual You want to read Section 8, specifically section 8.2 Owen On Apr 23, 2014, at 10:28 AM, John Jackson wrote: > I have a customer who previously didn't have any IPv4 address space. They > recently acquired a competitor that has a /24. > > Are there any special ARIN rules for this type of transfer? > > Any pointers, or 'gotchas'? > > Thanks > John From d3e3e3 at gmail.com Wed Apr 23 19:45:35 2014 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 23 Apr 2014 15:45:35 -0400 Subject: US patent 5473599 In-Reply-To: <20140423164736.GD16301@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> Message-ID: Hi, See below On Wed, Apr 23, 2014 at 12:47 PM, Henning Brauer wrote: > * Paul WALL [2014-04-22 19:30]: >> Both CARP and VRRP use virtual router MAC addresses that start with >> 00:00:5e. This organizational unique identifier (OUI) is assigned to >> IANA, not OpenBSD or a related project. The CARP authors could have >> gotten their own from IEEE. OUIs are not free but the cost is quite >> reasonable (and was even more reasonable years ago when this >> unfortunate decision was made). > > we're an open source project, running on a rather small budget almost > exclusively from donations, so "quite reasonable" doesn't cut it. While it is at the discretion of the IEEE Registration Authority, generally the IEEE RA will grant code point for standards use without any fee. While this is not all that clear from their web site, http://standards.ieee.org/develop/regauth/, except for standards use group (multicast) MAC addresses which are only for standards use and for which there is no charge, it is their policy. >> The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, >> the CARP folks *also* decided to use 00:01 after they got upset at the >> IETF for dissing their slide deck. > > you're interpreting way too much in here. > carp has been based on an earlier, never published vrrp implementatoin > we had before realizing the patent problem. > i don't remember any discussion about the OUI or, more general, the mac > address choice. it's 10 years ago now, so i don't remember every > single detail, changing the mac addr has pbly just been forgotten. > not at least using sth but 00:01 for the 4th and 5th octet was likely > a mistake. changing that now - wether just 4th/5th octet or to an > entirely different, donated OUI - wouldn't be easy, unfortunately. > acadmic discussion as long as we don't have a suitable OUI anyway. > >> If either of these decisions had not been made, we would not be having >> this discussion today. > > we weren't really given a choice. > as I said before, I'd much prefer we had just been given a multicast > address etc. we tried. the IEEE/IETF/IANA processes have been an utter > failure in our (limited) experience, not just in this case. might be > different if you're $big_vendor with deep pockets, but that doesn't > help either. That seems like a very scatter-shot claim. The process for applying for MAC addresses under the IANA OUI was regularized in RFC 5342, since updated to and replaced by RFC 7042. See http://www.rfc-editor.org/rfc/rfc7042.txt. Perhaps you were trying before RFC 5342? To get an assignment under IANA it must bet or standard use that is either an IETF standard or related to an IETF standard but it doesn't say what the relationship has to be. It must also be documented in an Internet Draft or an RFC but there is no technical screening for posting an Internet Draft so that doesn't seem like a barrier. It is subject to expert review. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3 at gmail.com >> ... > ... > -- > Henning Brauer, hb at bsws.de, henning at openbsd.org > BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de > Full-Service ISP - Secure Hosting, Mail and DNS Services > Dedicated Servers, Rootservers, Application Hosting From bryan at digitalocean.com Thu Apr 24 05:54:16 2014 From: bryan at digitalocean.com (Bryan Socha) Date: Thu, 24 Apr 2014 01:54:16 -0400 Subject: Phase 4. Message-ID: Whats the big deal???? If your just arin, dont panic. Akamai and digitalocean has been the only people aquire fair priced v4 putside arin. So arin is ending. It doesnt stop anything. be smart 3 usd per ip is fair if dirty. F the auct8ons they are fake and we get the ips lower than op3ning. Icann is the mast 8 class as real? Distribute them , From nanog at deman.com Thu Apr 24 08:29:50 2014 From: nanog at deman.com (Michael DeMan) Date: Thu, 24 Apr 2014 01:29:50 -0700 Subject: nanong list spam filtering Message-ID: <842F7C0E-CA61-4490-B5DF-ECC60D9A25FC@deman.com> Hi All, Sorry being a bit off-topic and having a boring subject, but we really should clean up whatever has been going on with so much spam hitting this mailing list. NO - I am complaining about people who post things I disagree with or on topics I have little interest in, I am tired of the stuff like... subject: Top rated...wireless security cameras--for both indoor & outdoor subject: Save on: Hawaii, vacation packages (classic) subject: Compare: the best, email marketing services subject: Cards reward plans\rates compared(MC-Capital1-Venture-ChaseFreedom-Citicard-BankAmericard-Discover-Visa) ...and what not. Has it always been the policy perhaps that this mailing list does no spam filtering whatsoever? If so that would be understandable. Meanwhile I think would be better for the community if at least some of the most egregious and obvious stuff did not have cpu and network cycles spent forwarding it onwards? As always, I could imagine that although I think this is simple it could be a politically charged debate. Cheers and please fix if possible, - Michael DeMan From nanog at deman.com Thu Apr 24 08:40:59 2014 From: nanog at deman.com (Michael DeMan) Date: Thu, 24 Apr 2014 01:40:59 -0700 Subject: nanong list spam filtering In-Reply-To: <842F7C0E-CA61-4490-B5DF-ECC60D9A25FC@deman.com> References: <842F7C0E-CA61-4490-B5DF-ECC60D9A25FC@deman.com> Message-ID: I take this back. Spam I received was not via anybody sending to/from nanog at nanog.org but rather directly to my subscribed e-mail address. - Mike On Apr 24, 2014, at 1:29 AM, Michael DeMan wrote: > Hi All, > > Sorry being a bit off-topic and having a boring subject, but we really should clean up whatever has been going on with so much spam hitting this mailing list. > > > NO - I am complaining about people who post things I disagree with or on topics I have little interest in, I am tired of the stuff like... > subject: Top rated...wireless security cameras--for both indoor & outdoor > subject: Save on: Hawaii, vacation packages > (classic) subject: Compare: the best, email marketing services > subject: Cards reward plans\rates compared(MC-Capital1-Venture-ChaseFreedom-Citicard-BankAmericard-Discover-Visa) > ...and what not. > > > Has it always been the policy perhaps that this mailing list does no spam filtering whatsoever? If so that would be understandable. > > Meanwhile I think would be better for the community if at least some of the most egregious and obvious stuff did not have cpu and network cycles spent forwarding it onwards? > As always, I could imagine that although I think this is simple it could be a politically charged debate. > > Cheers and please fix if possible, > - Michael DeMan > From jeroen at massar.ch Thu Apr 24 08:46:20 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Thu, 24 Apr 2014 10:46:20 +0200 Subject: nanong list spam filtering In-Reply-To: <842F7C0E-CA61-4490-B5DF-ECC60D9A25FC@deman.com> References: <842F7C0E-CA61-4490-B5DF-ECC60D9A25FC@deman.com> Message-ID: <5358CF5C.6010901@massar.ch> On 2014-04-24 10:29 , Michael DeMan wrote: > Hi All, > > Sorry being a bit off-topic and having a boring subject, but we really should clean up whatever has been going on with so much spam hitting this mailing list. > > > NO - I am complaining about people who post things I disagree with or on topics I have little interest in, I am tired of the stuff like... > subject: Top rated...wireless security cameras--for both indoor & outdoor > subject: Save on: Hawaii, vacation packages > (classic) subject: Compare: the best, email marketing services > subject: Cards reward plans\rates compared(MC-Capital1-Venture-ChaseFreedom-Citicard-BankAmericard-Discover-Visa) > ...and what not. None of that junk in my mailboxes or in: http://mailman.nanog.org/pipermail/nanog/2014-April/thread.html As such, you might want to check headers... The primary filter for spam is that one has to be subscribed (to the right list). This only fails the moment a spammer uses a correct From: header, which happens, sometimes, but very rarely. And if that happens, then your local spamchecker should be more than able to filter that crap out before you see it, especially with such obvious subjects (though you didn't show the headers nor content...). Greets, Jeroen From randy at psg.com Thu Apr 24 10:42:39 2014 From: randy at psg.com (Randy Bush) Date: Thu, 24 Apr 2014 03:42:39 -0700 Subject: Phase 4. In-Reply-To: References: Message-ID: > So arin is ending no. their job is a registrar, a bookkeeping and information function. some day they may get back to that. randy From ahebert at pubnix.net Thu Apr 24 11:13:22 2014 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 24 Apr 2014 07:13:22 -0400 Subject: Phase 4. In-Reply-To: References: Message-ID: <5358F1D2.7020903@pubnix.net> Well, Sorry Bryan, Your post is just to awful to take seriously. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 04/24/14 01:54, Bryan Socha wrote: > Whats the big deal???? If your just arin, dont panic. Akamai and > digitalocean has been the only people aquire fair priced v4 putside > arin. So arin is ending. It doesnt stop anything. be smart 3 usd > per ip is fair if dirty. F the auct8ons they are fake and we get the ips > lower than op3ning. > > Icann is the mast 8 class as real? Distribute them > , > From streiner at cluebyfour.org Thu Apr 24 08:30:05 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 24 Apr 2014 04:30:05 -0400 (EDT) Subject: Phase 4. In-Reply-To: References: Message-ID: On Thu, 24 Apr 2014, Bryan Socha wrote: > Whats the big deal???? If your just arin, dont panic. Akamai and > digitalocean has been the only people aquire fair priced v4 putside > arin. So arin is ending. It doesnt stop anything. be smart 3 usd > per ip is fair if dirty. F the auct8ons they are fake and we get the ips > lower than op3ning. > > Icann is the mast 8 class as real? Distribute them At the risk of feeding the troll, ARIN is not 'ending'. APNIC and RIPE didn't 'end' when they exhausted their supply of IPv4 addresses. Will some people acquire IPv4 addresses on the secondary market? Sure, though there are limits to how small chunks of IPv4 can be sliced up and maintain any realistic hope of global routability. That's something that is *not* dictated by the RIRs. jms From patrick at ianai.net Thu Apr 24 12:15:02 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Apr 2014 08:15:02 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post Message-ID: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Anyone afraid what will happen when companies which have monopolies can charge content providers or guarantee packet loss? In a normal "free market", if two companies with a mutual consumer have a tiff, the consumer decides which to support. Where I live, I have one broadband provider. If they get upset with, say, a streaming provider, I cannot choose another BB company because I like the streaming company. I MUST pick another streaming company, as that is the only thing I can "choose". How is this good for the consumer? How is this good for the market? -- TTFN, patrick http://m.washingtonpost.com/blogs/the-switch/wp/2014/04/23/the-fcc-is-planning-new-net-neutrality-rules-and-they-could-enshrine-pay-for-play/ Composed on a virtual keyboard, please forgive typos. From hb-nanog at bsws.de Thu Apr 24 12:17:34 2014 From: hb-nanog at bsws.de (Henning Brauer) Date: Thu, 24 Apr 2014 14:17:34 +0200 Subject: US patent 5473599 In-Reply-To: References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> Message-ID: <20140424121734.GK27540@quigon.bsws.de> * Donald Eastlake [2014-04-23 21:46]: > The process for applying > for MAC addresses under the IANA OUI was regularized in RFC 5342, > since updated to and replaced by RFC 7042. See > http://www.rfc-editor.org/rfc/rfc7042.txt. Perhaps you were trying > before RFC 5342? very possible. As I have said, I don't have to deal with IETF/IANA/IEEE often - we prefer to implement standards by far. I wasn't the one doing it for carp. We're talking about sth that happened 10 years ago. We ran against walls trying to get a multicast addr, and a protocol number for pfsync. Also as said before, the mac addr bit has pbly just been forgotten. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From clayton at MNSi.Net Thu Apr 24 12:23:37 2014 From: clayton at MNSi.Net (Clayton Zekelman) Date: Thu, 24 Apr 2014 08:23:37 -0400 Subject: Phase 4. In-Reply-To: References: Message-ID: <1398342219_8416@surgemail.mnsi.net> Can someone please check the NANOG mailing list Universal Translator? I think it is broken. At 01:54 AM 24/04/2014, Bryan Socha wrote: >Whats the big deal???? If your just arin, dont panic. Akamai and >digitalocean has been the only people aquire fair priced v4 putside >arin. So arin is ending. It doesnt stop anything. be smart 3 usd >per ip is fair if dirty. F the auct8ons they are fake and we get the ips >lower than op3ning. > >Icann is the mast 8 class as real? Distribute them >, --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jimpop at gmail.com Thu Apr 24 12:28:53 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Thu, 24 Apr 2014 08:28:53 -0400 Subject: Phase 4. In-Reply-To: <1398342219_8416@surgemail.mnsi.net> References: <1398342219_8416@surgemail.mnsi.net> Message-ID: On Thu, Apr 24, 2014 at 8:23 AM, Clayton Zekelman wrote: > > Can someone please check the NANOG mailing list Universal Translator? I > think it is broken. I think you mean a NANOG liver is broken. -Jim P. From adam.vitkovsky at swan.sk Thu Apr 24 13:02:34 2014 From: adam.vitkovsky at swan.sk (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=) Date: Thu, 24 Apr 2014 13:02:34 +0000 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011E80CD@EX01.swan.local> > How is this good for the consumer? How is this good for the market? You are asking a wrong question all they care about is "Where's my money"TM adam From morrowc.lists at gmail.com Thu Apr 24 13:28:28 2014 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Apr 2014 09:28:28 -0400 Subject: Phase 4. In-Reply-To: <5358F1D2.7020903@pubnix.net> References: <5358F1D2.7020903@pubnix.net> Message-ID: On Thu, Apr 24, 2014 at 7:13 AM, Alain Hebert wrote: > Well, > > Sorry Bryan, > > Your post is just to awful to take seriously. I think you mean 'too awful to take seriously'. From Valdis.Kletnieks at vt.edu Thu Apr 24 14:02:48 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Apr 2014 10:02:48 -0400 Subject: Phase 4. In-Reply-To: Your message of "Thu, 24 Apr 2014 01:54:16 -0400." References: Message-ID: <45568.1398348168@turing-police.cc.vt.edu> On Thu, 24 Apr 2014 01:54:16 -0400, Bryan Socha said: > Icann is the mast 8 class as real? Distribute them "Not Even Wrong" -- W. Pauli -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Thu Apr 24 14:27:17 2014 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 24 Apr 2014 14:27:17 +0000 Subject: Phase 4. In-Reply-To: References: <1398342219_8416@surgemail.mnsi.net>, Message-ID: <8eilgo7re2xyo6eja3penwgq.1398349629431@email.android.com> Bryan is accepting bloody Mary donations this morning. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jim Popovitch Date: 04/24/2014 6:30 AM (GMT-07:00) To: Clayton Zekelman Cc: nanog list Subject: Re: Phase 4. On Thu, Apr 24, 2014 at 8:23 AM, Clayton Zekelman wrote: > > Can someone please check the NANOG mailing list Universal Translator? I > think it is broken. I think you mean a NANOG liver is broken. -Jim P. From lazlor at lotaris.org Thu Apr 24 14:49:52 2014 From: lazlor at lotaris.org (Allen Smith) Date: Thu, 24 Apr 2014 08:49:52 -0600 Subject: IPv4 Address transfer after company acquisition In-Reply-To: References: Message-ID: We just had to do something similar for space that we had acquired in an earlier incarnation of our company which was merged/renamed and it was a straightforward process. We just had to provide some documentation. I found the ARIN folk easy to work with on this. On Wed, Apr 23, 2014 at 1:40 PM, Owen DeLong wrote: > Without interpretation: > > Look on the ARIN Website.. > > Policies->Number Resource Policy Manual > > You want to read Section 8, specifically section 8.2 > > Owen > > On Apr 23, 2014, at 10:28 AM, John Jackson wrote: > > > I have a customer who previously didn't have any IPv4 address space. > They > > recently acquired a competitor that has a /24. > > > > Are there any special ARIN rules for this type of transfer? > > > > Any pointers, or 'gotchas'? > > > > Thanks > > John > > > From bob at FiberInternetCenter.com Thu Apr 24 14:53:49 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 24 Apr 2014 07:53:49 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: Gee whiz, why would any network have an issue with this ? After all just about everyone continues to buys Cisco gear. Gear from a router company that decided to compete against it's own customer base. Cisco did when it invested heavily and took stock in one of it's customers, Cogent. Cogent the largest network responsible (for the most part) of lowering the overall bandwidth prices, because it could now afford too. Networks today continue to feed Cisco money (buying their gear) despite the anti-competitive nature of that deal which kindled all this. Still to this day, Cisco fuels Cogent's (anti-competitive) low bandwidth pricing. By handing Cisco dollars, from that day forward, we voted for fewer ISPs & Backbones in the future. Suck in your gut, because, it's to late to cry about it now. This concern is over a decade late. That's how we got to this point. "Cause and Effect - and the Blinders we put on". How can that be fixed ? More government regulations ? Bob Evans CTO > Anyone afraid what will happen when companies which have monopolies can > charge content providers or guarantee packet loss? > > In a normal "free market", if two companies with a mutual consumer have a > tiff, the consumer decides which to support. Where I live, I have one > broadband provider. If they get upset with, say, a streaming provider, I > cannot choose another BB company because I like the streaming company. I > MUST pick another streaming company, as that is the only thing I can > "choose". > > How is this good for the consumer? How is this good for the market? > > -- > TTFN, > patrick > > http://m.washingtonpost.com/blogs/the-switch/wp/2014/04/23/the-fcc-is-planning-new-net-neutrality-rules-and-they-could-enshrine-pay-for-play/ > > > Composed on a virtual keyboard, please forgive typos. > > > From Valdis.Kletnieks at vt.edu Thu Apr 24 14:56:30 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Apr 2014 10:56:30 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: Your message of "Thu, 24 Apr 2014 07:53:49 -0700." References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: <48638.1398351390@turing-police.cc.vt.edu> On Thu, 24 Apr 2014 07:53:49 -0700, "Bob Evans" said: > Gee whiz, why would any network have an issue with this ? Spoken like a true oligarch. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From patrick at ianai.net Thu Apr 24 14:59:52 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Apr 2014 10:59:52 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> I think you and I disagree on the definition of "anti-competitive". But that's fine. There is more than one problem to solve. I just figured the FCC thing was timely and operational. -- TTFN, patrick On Apr 24, 2014, at 10:53 , Bob Evans wrote: > Gee whiz, why would any network have an issue with this ? > > After all just about everyone continues to buys Cisco gear. Gear from a > router company that decided to compete against it's own customer base. > Cisco did when it invested heavily and took stock in one of it's > customers, Cogent. Cogent the largest network responsible (for the most > part) of lowering the overall bandwidth prices, because it could now > afford too. Networks today continue to feed Cisco money (buying their > gear) despite the anti-competitive nature of that deal which kindled all > this. Still to this day, Cisco fuels Cogent's (anti-competitive) low > bandwidth pricing. By handing Cisco dollars, from that day forward, we > voted for fewer ISPs & Backbones in the future. > > Suck in your gut, because, it's to late to cry about it now. This concern > is over a decade late. That's how we got to this point. "Cause and Effect > - and the Blinders we put on". > > How can that be fixed ? More government regulations ? > > Bob Evans > CTO > >> Anyone afraid what will happen when companies which have monopolies can >> charge content providers or guarantee packet loss? >> >> In a normal "free market", if two companies with a mutual consumer have a >> tiff, the consumer decides which to support. Where I live, I have one >> broadband provider. If they get upset with, say, a streaming provider, I >> cannot choose another BB company because I like the streaming company. I >> MUST pick another streaming company, as that is the only thing I can >> "choose". >> >> How is this good for the consumer? How is this good for the market? >> >> -- >> TTFN, >> patrick >> >> http://m.washingtonpost.com/blogs/the-switch/wp/2014/04/23/the-fcc-is-planning-new-net-neutrality-rules-and-they-could-enshrine-pay-for-play/ >> >> >> Composed on a virtual keyboard, please forgive typos. >> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cboyd at gizmopartners.com Thu Apr 24 15:02:33 2014 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 24 Apr 2014 10:02:33 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <48638.1398351390@turing-police.cc.vt.edu> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <48638.1398351390@turing-police.cc.vt.edu> Message-ID: I'd like to propose a new ICMP message type 3 code -- Communication with Destination Network is Financially Prohibited --Chris From bob at FiberInternetCenter.com Thu Apr 24 16:02:45 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Thu, 24 Apr 2014 09:02:45 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <48638.1398351390@turing-police.cc.vt.edu> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <48638.1398351390@turing-police.cc.vt.edu> Message-ID: Valdis, we will give you more time to read the entire post before responding. That way you might not mislabel or misspeak as often. :-) Bob Evans CTO > On Thu, 24 Apr 2014 07:53:49 -0700, "Bob Evans" said: >> Gee whiz, why would any network have an issue with this ? > > Spoken like a true oligarch. :) > From donbrearley at hibbing.edu Thu Apr 24 14:51:55 2014 From: donbrearley at hibbing.edu (Don Brearley) Date: Thu, 24 Apr 2014 09:51:55 -0500 Subject: Phase 4. Message-ID: <5358DEBB020000260003CC23@hibbing.edu> This thread pulled a good chuckle out of me... thanks guys :) Bryan, cheers. :) - Don >>> Warren Bailey 04/24/14 9:21 AM >>> Bryan is accepting bloody Mary donations this morning. Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Jim Popovitch Date: 04/24/2014 6:30 AM (GMT-07:00) To: Clayton Zekelman Cc: nanog list Subject: Re: Phase 4. On Thu, Apr 24, 2014 at 8:23 AM, Clayton Zekelman wrote: > > Can someone please check the NANOG mailing list Universal Translator? I > think it is broken. I think you mean a NANOG liver is broken. -Jim P. From jbates at paradoxnetworks.net Thu Apr 24 21:42:42 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Thu, 24 Apr 2014 16:42:42 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> Message-ID: <53598552.2080800@paradoxnetworks.net> On 4/24/2014 9:59 AM, Patrick W. Gilmore wrote: > I think you and I disagree on the definition of "anti-competitive". > > But that's fine. There is more than one problem to solve. I just figured the FCC thing was timely and operational. > I agree with you, Patrick. Double digit/meg pricing needs to die. I'm not sure that the change really alters backbone policy, but it would definitely open the doors for bad things in the access networks. That being said, only the largest networks could put enough pressure to benefit from it, and some do that currently. I also don't see this as any different than the business model some streaming sites enforce where the ISP must pay for stream access based on their subscribers instead of interested subscribers just paying for an individual account. Fair is fair, and some of the streamers have been hitting ISPs longer. Once again, only the largest streamers can hope to get away with it, and only the largest ISPs can get the low priced deals. In both cases, it's the small ISPs and small content providers that suffer. I don't see the FCC stopping megacorp bullying anytime in the near future. Jack From web at typo.org Thu Apr 24 21:57:49 2014 From: web at typo.org (Wayne E Bouchard) Date: Thu, 24 Apr 2014 14:57:49 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <53598552.2080800@paradoxnetworks.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> Message-ID: <20140424215749.GA39277@wakko.typo.org> My take here is that I'd rather the FCC just leave it alone and see if the market doesn't work it out in some reasonable way. That is, to not even address it in rules, whether accept or prohibit. Just step back and make sure that all you see is dust rising and not smoke. These things take a while to resolve. This issue has been building for a while but hasn't really reached its pinnacle yet so who is to say what things will look like in five years from a business standpoint? To codify something pretty well means you want it to look a particular way or you are accepting a way of being that may or may not be in the interests of those concerned and pretty well ending discussion, negotiation, and experimentation regarding that point. The problem is that all the RBOCs/ILECs/Cable groups seem to be headed in the same direction (and most of them are trying to run their own CDN and force their customers to use it instead of a third party--and running them badly to boot. Sound familiar?) If that were not the case, such a scheme would not be viable since there would always be someone undermining it. (Like OPEC... The price they want is never what they get because some country or another is always selling more than they say they're going to because they want more money, meaning supply is greater than it should be and prices adjust accordingly.) It only takes one or two holdouts to upset the plans of all the rest. *shrug* I'll have to see how these changes are implemented and how things are interpreted before we know what this is going to do to competitveness. -Wayne On Thu, Apr 24, 2014 at 04:42:42PM -0500, Jack Bates wrote: > On 4/24/2014 9:59 AM, Patrick W. Gilmore wrote: > >I think you and I disagree on the definition of "anti-competitive". > > > >But that's fine. There is more than one problem to solve. I just figured > >the FCC thing was timely and operational. > > > I agree with you, Patrick. Double digit/meg pricing needs to die. > > I'm not sure that the change really alters backbone policy, but it would > definitely open the doors for bad things in the access networks. That > being said, only the largest networks could put enough pressure to > benefit from it, and some do that currently. I also don't see this as > any different than the business model some streaming sites enforce where > the ISP must pay for stream access based on their subscribers instead of > interested subscribers just paying for an individual account. Fair is > fair, and some of the streamers have been hitting ISPs longer. Once > again, only the largest streamers can hope to get away with it, and only > the largest ISPs can get the low priced deals. In both cases, it's the > small ISPs and small content providers that suffer. > > I don't see the FCC stopping megacorp bullying anytime in the near future. > > Jack --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From blaine at blaines.net Thu Apr 24 22:43:14 2014 From: blaine at blaines.net (Blaine) Date: Thu, 24 Apr 2014 15:43:14 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: <017301cf600e$93face90$bbf06bb0$@blaines.net> https://petitions.whitehouse.gov/petition/maintain-true-net-neutrality-prote ct-freedom-information-united-states/9sxxdBgy -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Thursday, April 24, 2014 5:15 AM To: North American Operators' Group Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post Anyone afraid what will happen when companies which have monopolies can charge content providers or guarantee packet loss? In a normal "free market", if two companies with a mutual consumer have a tiff, the consumer decides which to support. Where I live, I have one broadband provider. If they get upset with, say, a streaming provider, I cannot choose another BB company because I like the streaming company. I MUST pick another streaming company, as that is the only thing I can "choose". How is this good for the consumer? How is this good for the market? -- TTFN, patrick http://m.washingtonpost.com/blogs/the-switch/wp/2014/04/23/the-fcc-is-planni ng-new-net-neutrality-rules-and-they-could-enshrine-pay-for-play/ Composed on a virtual keyboard, please forgive typos. From mysidia at gmail.com Thu Apr 24 23:07:02 2014 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 24 Apr 2014 18:07:02 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <48638.1398351390@turing-police.cc.vt.edu> Message-ID: On Thu, Apr 24, 2014 at 10:02 AM, Chris Boyd wrote: > I'd like to propose a new ICMP message type 3 code -- > Communication with Destination Network is Financially Prohibited Wait; it should be a new type code message, so the header format/data section can be different. And include in the error response; the 160-bit Bitcoin addresses the user should send the ransom, err, I mean payment to for various drop rates, and a declaration of the amount of total payment that needs to be confirmed on the blockchain per Kilobyte for successful delivery of the payload at the offered service levels :) > --Chris -- -JH From patrick at ianai.net Fri Apr 25 03:23:54 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Apr 2014 23:23:54 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <20140424215749.GA39277@wakko.typo.org> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> Message-ID: <4CB26BD9-13A6-4DB5-8EB0-F986EBE68E73@ianai.net> The invisible hand of the market cannot fix problems when there is a monopoly. Put in economic terms, a player with Market Power is extracting Rents. (Capitalization is intentional.) Regulating monopolies allows a market to work, not the opposite. -- TTFN, patrick On Apr 24, 2014, at 17:57 , Wayne E Bouchard wrote: > My take here is that I'd rather the FCC just leave it alone and see if > the market doesn't work it out in some reasonable way. That is, to not > even address it in rules, whether accept or prohibit. Just step back > and make sure that all you see is dust rising and not smoke. These > things take a while to resolve. This issue has been building for a > while but hasn't really reached its pinnacle yet so who is to say what > things will look like in five years from a business standpoint? To > codify something pretty well means you want it to look a particular > way or you are accepting a way of being that may or may not be in the > interests of those concerned and pretty well ending discussion, > negotiation, and experimentation regarding that point. > > The problem is that all the RBOCs/ILECs/Cable groups seem to be headed > in the same direction (and most of them are trying to run their own > CDN and force their customers to use it instead of a third party--and > running them badly to boot. Sound familiar?) If that were not the > case, such a scheme would not be viable since there would always be > someone undermining it. (Like OPEC... The price they want is never > what they get because some country or another is always selling more > than they say they're going to because they want more money, meaning > supply is greater than it should be and prices adjust accordingly.) It > only takes one or two holdouts to upset the plans of all the rest. > > *shrug* > > I'll have to see how these changes are implemented and how things > are interpreted before we know what this is going to do to > competitveness. > > -Wayne > > On Thu, Apr 24, 2014 at 04:42:42PM -0500, Jack Bates wrote: >> On 4/24/2014 9:59 AM, Patrick W. Gilmore wrote: >>> I think you and I disagree on the definition of "anti-competitive". >>> >>> But that's fine. There is more than one problem to solve. I just figured >>> the FCC thing was timely and operational. >>> >> I agree with you, Patrick. Double digit/meg pricing needs to die. >> >> I'm not sure that the change really alters backbone policy, but it would >> definitely open the doors for bad things in the access networks. That >> being said, only the largest networks could put enough pressure to >> benefit from it, and some do that currently. I also don't see this as >> any different than the business model some streaming sites enforce where >> the ISP must pay for stream access based on their subscribers instead of >> interested subscribers just paying for an individual account. Fair is >> fair, and some of the streamers have been hitting ISPs longer. Once >> again, only the largest streamers can hope to get away with it, and only >> the largest ISPs can get the low priced deals. In both cases, it's the >> small ISPs and small content providers that suffer. >> >> I don't see the FCC stopping megacorp bullying anytime in the near future. >> >> Jack > > --- > Wayne Bouchard > web at typo.org > Network Dude > http://www.typo.org/~web/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From LarrySheldon at cox.net Fri Apr 25 03:38:13 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 24 Apr 2014 22:38:13 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> Message-ID: <5359D8A5.7030107@cox.net> On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: > The invisible hand of the market cannot fix problems when there is a monopoly. > > Put in economic terms, a player with Market Power is extracting Rents. (Capitalization is intentional.) > > Regulating monopolies allows a market to work, not the opposite. > Regulating monopolies protects monopolies from competition. Monopolies can not persist without regulation. A regulated monopoly is a monopoly, with all of the powers granted to monopolies by regulation. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From patrick at ianai.net Fri Apr 25 03:44:48 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Apr 2014 23:44:48 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359D8A5.7030107@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: On Apr 24, 2014, at 23:38 , Larry Sheldon wrote: > On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: >> The invisible hand of the market cannot fix problems when there is a monopoly. >> >> Put in economic terms, a player with Market Power is extracting Rents. (Capitalization is intentional.) >> >> Regulating monopolies allows a market to work, not the opposite. >> > > Regulating monopolies protects monopolies from competition. > > Monopolies can not persist without regulation. You are confused. Unless you are talking about "persist" on a time horizon spanning generations. If so, then nothing can persist, with or without regulation. And more importantly, I am not willing to wait that long for a fix. > A regulated monopoly is a monopoly, with all of the powers granted to monopolies by regulation. Regulations can work to ensure monopolies do not form. This is not supposition, but historical fact. It is an open question whether our current regulator regime is capable of repeating that feat, however. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From andris at hpl.hp.com Fri Apr 25 03:50:42 2014 From: andris at hpl.hp.com (Andris Kalnozols) Date: Thu, 24 Apr 2014 20:50:42 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359D8A5.7030107@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: <5359DB92.5000203@hpl.hp.com> On 4/24/2014 8:38 PM, Larry Sheldon wrote: > On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: >> The invisible hand of the market cannot fix problems when there is a >> monopoly. >> >> Put in economic terms, a player with Market Power is extracting Rents. >> (Capitalization is intentional.) >> >> Regulating monopolies allows a market to work, not the opposite. >> > > Regulating monopolies protects monopolies from competition. > > Monopolies can not persist without regulation. > > A regulated monopoly is a monopoly, with all of the powers granted to > monopolies by regulation. "In theory, there is no difference between theory and practice. In practice, there is." --- Yogi Berra Due to the existence of Regulatory Capture, Mr. Gilmore has a point. From everton.marques at gmail.com Fri Apr 25 04:01:52 2014 From: everton.marques at gmail.com (Everton Marques) Date: Fri, 25 Apr 2014 01:01:52 -0300 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: On Fri, Apr 25, 2014 at 12:44 AM, Patrick W. Gilmore wrote: > On Apr 24, 2014, at 23:38 , Larry Sheldon wrote: > > > > Regulating monopolies protects monopolies from competition. > > > > Monopolies can not persist without regulation. > > You are confused. > I think Mr. Sheldon is pointing out this: --xx-- The biggest myth of all in this regard is the notion that telephone service is a natural monopoly. Economists have taught generations of students that telephone service is a "classic" example of market failure and that government regulation in the "public interest" was necessary. But as Adam D. Thierer recently proved, there is nothing at all "natural" about the telephone monopoly enjoyed by AT&T for so many decades; it was purely a creation of government intervention. Once AT&T's initial patents expired in 1893, dozens of competitors sprung up. "By the end of 1894 over 80 new independent competitors had already grabbed 5 percent of total market share ? after the turn of the century, over 3,000 competitors existed.[55] In some states there were over 200 telephone companies operating simultaneously. By 1907, AT&T's competitors had captured 51 percent of the telephone market and prices were being driven sharply down by the competition. Moreover, there was no evidence of economies of scale, and entry barriers were obviously almost nonexistent, contrary to the standard account of the theory of natural monopoly as applied to the telephone industry. (...) The theory of natural monopoly is an economic fiction. No such thing as a "natural" monopoly has ever existed. The history of the so-called public utility concept is that the late 19th and early 20th century "utilities" competed vigorously and, like all other industries, they did not like competition. They first secured government-sanctioned monopolies, and *then,* with the help of a few influential economists, constructed an *ex* *post* rationalization for their monopoly power. --xx-- The Myth of Natural Monopoly http://mises.org/daily/5266/ From patrick at ianai.net Fri Apr 25 04:09:36 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 25 Apr 2014 00:09:36 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: On Apr 25, 2014, at 00:01 , Everton Marques wrote: > On Fri, Apr 25, 2014 at 12:44 AM, Patrick W. Gilmore wrote: >> On Apr 24, 2014, at 23:38 , Larry Sheldon wrote: >>> Regulating monopolies protects monopolies from competition. >>> >>> Monopolies can not persist without regulation. >> >> You are confused. >> > > I think Mr. Sheldon is pointing out this: That's nice. A bit disingenuous, but nice. To be clear, I have no idea if AT&T was a natural monopoly in the 1890s or not. But the idea that there can be no "natural monopoly" is ludicrous, unless you distort the definition so far out of shape is doesn't resemble anything except a complex syllogism in a textbook. Here in the real world, sometimes there is very clearly an overwhelming preference for a single company / provider / etc. to own a market segment. Pointing out the laws of physics do not prohibit competition does not mean there will be competition. But we can agree to disagree. :) -- TTFN, patrick > --xx-- > The biggest myth of all in this regard is the notion that telephone service > is a natural monopoly. Economists have taught generations of students that > telephone service is a "classic" example of market failure and that > government regulation in the "public interest" was necessary. But as Adam > D. Thierer recently proved, there is nothing at all "natural" about the > telephone monopoly enjoyed by AT&T for so many decades; it was purely a > creation of government intervention. > > Once AT&T's initial patents expired in 1893, dozens of competitors sprung > up. "By the end of 1894 over 80 new independent competitors had already > grabbed 5 percent of total market share ? after the turn of the century, > over 3,000 competitors existed.[55] In > some states there were over 200 telephone companies operating > simultaneously. By 1907, AT&T's competitors had captured 51 percent of the > telephone market and prices were being driven sharply down by the > competition. Moreover, there was no evidence of economies of scale, and > entry barriers were obviously almost nonexistent, contrary to the standard > account of the theory of natural monopoly as applied to the telephone > industry. > (...) > The theory of natural monopoly is an economic fiction. No such thing as a > "natural" monopoly has ever existed. The history of the so-called public > utility concept is that the late 19th and early 20th century "utilities" > competed vigorously and, like all other industries, they did not like > competition. They first secured government-sanctioned monopolies, and > *then,* with the help of a few influential economists, constructed an *ex* > *post* rationalization for their monopoly power. > --xx-- > The Myth of Natural Monopoly > http://mises.org/daily/5266/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From LarrySheldon at cox.net Fri Apr 25 04:16:08 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 24 Apr 2014 23:16:08 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: <5359E188.8020906@cox.net> On 4/24/2014 10:44 PM, Patrick W. Gilmore wrote: > On Apr 24, 2014, at 23:38 , Larry Sheldon > wrote: >> On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: > >>> The invisible hand of the market cannot fix problems when there >>> is a monopoly. >>> >>> Put in economic terms, a player with Market Power is extracting >>> Rents. (Capitalization is intentional.) >>> >>> Regulating monopolies allows a market to work, not the opposite. >> >> Regulating monopolies protects monopolies from competition. >> >> Monopolies can not persist without regulation. > > You are confused. No. I am not. > Unless you are talking about "persist" on a time horizon spanning > generations. A monopoly can persist, as a maximum, as long as regulation protects it. Just look at the words! "Regulated Monopoly" has no definition without a monopoly. If so, then nothing can persist, with or without > regulation. And more importantly, I am not willing to wait that long > for a fix. "fix" is another monopoly preserver. >> A regulated monopoly is a monopoly, with all of the powers granted >> to monopolies by regulation. > > Regulations can work to ensure monopolies do not form. This is not > supposition, but historical fact. There is no case where regulation of monopolies prevented monopolies. The sentence doesn't even make any sense. If that were actually true, there couldn't be any "regulated monopolies" could there? > It is an open question whether our current regulator regime is > capable of repeating that feat, however. There are a number of cases in history where the absence of regulation has prevented monopolies. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From kiriki at streamguys.com Fri Apr 25 04:23:27 2014 From: kiriki at streamguys.com (Kiriki Delany) Date: Thu, 24 Apr 2014 21:23:27 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359E188.8020906@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> Message-ID: <02f601cf603e$1c191b40$544b51c0$@com> Might one example of what Larry is talking about be cable providers? Also telephone companies. They are often awarded exclusive contracts within cities. Do regulations prohibit anyone from becoming a cable company, in addition to capital costs and difficulty of easements? -Kiriki Delany -----Original Message----- From: Larry Sheldon [mailto:LarrySheldon at cox.net] Sent: Thursday, April 24, 2014 9:16 PM To: nanog at nanog.org Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post On 4/24/2014 10:44 PM, Patrick W. Gilmore wrote: > On Apr 24, 2014, at 23:38 , Larry Sheldon > wrote: >> On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: > >>> The invisible hand of the market cannot fix problems when there is a >>> monopoly. >>> >>> Put in economic terms, a player with Market Power is extracting >>> Rents. (Capitalization is intentional.) >>> >>> Regulating monopolies allows a market to work, not the opposite. >> >> Regulating monopolies protects monopolies from competition. >> >> Monopolies can not persist without regulation. > > You are confused. No. I am not. > Unless you are talking about "persist" on a time horizon spanning > generations. A monopoly can persist, as a maximum, as long as regulation protects it. Just look at the words! "Regulated Monopoly" has no definition without a monopoly. If so, then nothing can persist, with or without > regulation. And more importantly, I am not willing to wait that long > for a fix. "fix" is another monopoly preserver. >> A regulated monopoly is a monopoly, with all of the powers granted to >> monopolies by regulation. > > Regulations can work to ensure monopolies do not form. This is not > supposition, but historical fact. There is no case where regulation of monopolies prevented monopolies. The sentence doesn't even make any sense. If that were actually true, there couldn't be any "regulated monopolies" could there? > It is an open question whether our current regulator regime is capable > of repeating that feat, however. There are a number of cases in history where the absence of regulation has prevented monopolies. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Fri Apr 25 04:29:01 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 24 Apr 2014 23:29:01 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: <5359E48D.80504@cox.net> On 4/24/2014 11:01 PM, Everton Marques wrote: > On Fri, Apr 25, 2014 at 12:44 AM, Patrick W. Gilmore wrote: > >> On Apr 24, 2014, at 23:38 , Larry Sheldon wrote: >>> >>> Regulating monopolies protects monopolies from competition. >>> >>> Monopolies can not persist without regulation. >> >> You are confused. >> > > I think Mr. Sheldon is pointing out this: Thank you. [more comment below] > --xx-- > The biggest myth of all in this regard is the notion that telephone service > is a natural monopoly. Economists have taught generations of students that > telephone service is a "classic" example of market failure and that > government regulation in the "public interest" was necessary. But as Adam > D. Thierer recently proved, there is nothing at all "natural" about the > telephone monopoly enjoyed by AT&T for so many decades; it was purely a > creation of government intervention. > > Once AT&T's initial patents expired in 1893, dozens of competitors sprung > up. "By the end of 1894 over 80 new independent competitors had already > grabbed 5 percent of total market share ??? after the turn of the century, > over 3,000 competitors existed.[55] In > some states there were over 200 telephone companies operating > simultaneously. By 1907, AT&T's competitors had captured 51 percent of the > telephone market and prices were being driven sharply down by the > competition. Moreover, there was no evidence of economies of scale, and > entry barriers were obviously almost nonexistent, contrary to the standard > account of the theory of natural monopoly as applied to the telephone > industry. > (...) > The theory of natural monopoly is an economic fiction. No such thing as a > "natural" monopoly has ever existed. The history of the so-called public > utility concept is that the late 19th and early 20th century "utilities" > competed vigorously and, like all other industries, they did not like > competition. They first secured government-sanctioned monopolies, and > *then,* with the help of a few influential economists, constructed an *ex* > *post* rationalization for their monopoly power. > --xx-- > The Myth of Natural Monopoly > http://mises.org/daily/5266/ I don't know what got me to thinking about it earlier today but I recalled when I started at the telephone company in Los Angeles there was a pitch made early on that in earlier days a business in Los Angeles had to have several telephones on desks to be able to talk to all of their customers. Which was true ONLY because regulation required that each telephone line terminate in an instrument owned by the providing company. Absent that one regulation, businesses would have invented multi-line instruments a lot earlier than was the case. There would still be some other problems like interchange traffic between companies, but I suspect that some entrepreneur would have (or maybe did) install two or more switchboards within lord reach of each other. (The high school I went to in the 1950s had a very complete non-Bell System telephone system on-campus. In a small office off the Main Office were two identical cord boards along with placards prohibiting connections between the two boards--which were ignored unless there was a telephone man in the office. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From patrick at ianai.net Fri Apr 25 04:37:40 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 25 Apr 2014 00:37:40 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <02f601cf603e$1c191b40$544b51c0$@com> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> Message-ID: <041060DA-1145-4CC2-897A-0CA217C0FC2F@ianai.net> The fact there are "regulated monopolies" does not mean regulation cannot be used to keep a monopoly from forming. And using a turn of phrase to prove a point of logic and/or history is a pretty sad argument. Yeah, the phrase "regulated monopoly" exists, therefore monopolies can't exist without regulation! Q.E.D. Oh, wait, got my abbreviation wrong, I meant: W.T.F.? Larry is confused. He can claim he is not, but posting to NANOG does not change the facts. Then again, just because I posted to NANOG doesn't prove I'm right either. Worst of all, this thread is pretty non-operational now. So believe as you please. I'm going to believe that the FCC allowing monopolies (regulated or not) to charge content providers as they please will be bad for me and about 300 million other Americans. Besides, what has this to do with my original questions? -- TTFN, patrick On Apr 25, 2014, at 00:23 , Kiriki Delany wrote: > Might one example of what Larry is talking about be cable providers? Also > telephone companies. > > They are often awarded exclusive contracts within cities. > > Do regulations prohibit anyone from becoming a cable company, in addition to > capital costs and difficulty of easements? > > > -Kiriki Delany > > > > > -----Original Message----- > From: Larry Sheldon [mailto:LarrySheldon at cox.net] > Sent: Thursday, April 24, 2014 9:16 PM > To: nanog at nanog.org > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > On 4/24/2014 10:44 PM, Patrick W. Gilmore wrote: >> On Apr 24, 2014, at 23:38 , Larry Sheldon >> wrote: >>> On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: >> >>>> The invisible hand of the market cannot fix problems when there is a >>>> monopoly. >>>> >>>> Put in economic terms, a player with Market Power is extracting >>>> Rents. (Capitalization is intentional.) >>>> >>>> Regulating monopolies allows a market to work, not the opposite. >>> >>> Regulating monopolies protects monopolies from competition. >>> >>> Monopolies can not persist without regulation. >> >> You are confused. > > No. I am not. > >> Unless you are talking about "persist" on a time horizon spanning >> generations. > > A monopoly can persist, as a maximum, as long as regulation protects it. > > Just look at the words! "Regulated Monopoly" has no definition without a > monopoly. > > If so, then nothing can persist, with or without >> regulation. And more importantly, I am not willing to wait that long >> for a fix. > > "fix" is another monopoly preserver. > >>> A regulated monopoly is a monopoly, with all of the powers granted to >>> monopolies by regulation. >> >> Regulations can work to ensure monopolies do not form. This is not >> supposition, but historical fact. > > There is no case where regulation of monopolies prevented monopolies. > The sentence doesn't even make any sense. > > If that were actually true, there couldn't be any "regulated monopolies" > could there? > >> It is an open question whether our current regulator regime is capable >> of repeating that feat, however. > > There are a number of cases in history where the absence of regulation has > prevented monopolies. > > > > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From LarrySheldon at cox.net Fri Apr 25 04:47:48 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 24 Apr 2014 23:47:48 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> Message-ID: <5359E8F4.7030506@cox.net> On 4/24/2014 11:37 PM, Patrick W. Gilmore wrote: > The fact there are "regulated monopolies" does not mean regulation > cannot be used to keep a monopoly from forming. And using a turn of > phrase to prove a point of logic and/or history is a pretty sad > argument. Yeah, the phrase "regulated monopoly" exists, therefore > monopolies can't exist without regulation! Q.E.D. Oh, wait, got my > abbreviation wrong, I meant: W.T.F.? > > Larry is confused. He can claim he is not, but posting to NANOG does > not change the facts. Then again, just because I posted to NANOG > doesn't prove I'm right either. Worst of all, this thread is pretty > non-operational now. > > So believe as you please. I'm going to believe that the FCC allowing > monopolies (regulated or not) to charge content providers as they > please will be bad for me and about 300 million other Americans. > > Besides, what has this to do with my original questions? > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Fri Apr 25 04:57:51 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 24 Apr 2014 23:57:51 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> Message-ID: <5359EB4F.50405@cox.net> I just posted a completely empty message for which I apologize. > Larry is confused. He can claim he is not, but posting to NANOG does > not change the facts. Then again, just because I posted to NANOG > doesn't prove I'm right either. Worst of all, this thread is pretty > non-operational now. In a private message I asked if he could name a single monopoly that existed without regulation to protect its monopoly power. >> So believe as you please. I'm going to believe that the FCC allowing > monopolies (regulated or not) to charge content providers as they > please will be bad for me and about 300 million other Americans. "FCC allowing monopolies" -- suppose the FCC and other regulators and aiders and abettors got out of the the monopoly business? > Besides, what has this to do with my original questions? Which were "Anyone afraid what will happen when companies which have monopolies can charge content providers or guarantee packet loss?" and "How is this good for the consumer?" and "How is this good for the market?" My answer was an attempt to say that if you don't have any government entities allowing and protecting (two pretty much interchangeable terms, I prefer the latter) monopolies the answer to the first question is "Huh? What?" and to the second and third "Best service for the best price is pretty good for everybody. Except the losers that can't rip you off without the FCC protection." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From joe at nethead.com Fri Apr 25 06:39:20 2014 From: joe at nethead.com (Joe Hamelin) Date: Thu, 24 Apr 2014 23:39:20 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <53598552.2080800@paradoxnetworks.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> Message-ID: On Thu, Apr 24, 2014 at 2:42 PM, Jack Bates wrote: I agree with you, Patrick. Double digit/meg pricing needs to die. Hell, I remember back in '98 when it was triple digit, and not small values at that. We've come a long way. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From patrick at ianai.net Fri Apr 25 13:23:20 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 25 Apr 2014 09:23:20 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359EB4F.50405@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> Message-ID: <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> On Apr 25, 2014, at 00:57 , Larry Sheldon wrote: > I just posted a completely empty message for which I apologize. > >> Larry is confused. He can claim he is not, but posting to NANOG does >> not change the facts. Then again, just because I posted to NANOG >> doesn't prove I'm right either. Worst of all, this thread is pretty >> non-operational now. > > In a private message I asked if he could name a single monopoly that existed without regulation to protect its monopoly power. I answered in a private message: Microsoft. Kinda obvious if you think about it for, oh, say, 12 microseconds. > Which were "Anyone afraid what will happen when companies which have monopolies can charge content providers or guarantee packet loss?" and "How is this good for the consumer?" and "How is this good for the market?" > > My answer was an attempt to say that if you don't have any government entities allowing and protecting (two pretty much interchangeable terms, I prefer the latter) monopolies the answer to the first question is "Huh? What?" and to the second and third "Best service for the best price is pretty good for everybody. Except the losers that can't rip you off without the FCC protection." While it is probably true that the gov't had a hand in the fact I have exactly one BB provider at my home, I am not even closed to convinced that a purely open market would not have resulted in the same problem. But thanx for pointing out an answer I probably missed. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jeroen at massar.ch Fri Apr 25 13:45:24 2014 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 25 Apr 2014 15:45:24 +0200 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> Message-ID: <535A66F4.4010001@massar.ch> On 2014-04-25 15:23 , Patrick W. Gilmore wrote: [..] > While it is probably true that the gov't had a hand in the fact I > have exactly one BB provider at my home, I am not even closed to > convinced that a purely open market would not have resulted in the > same problem. But thanx for pointing out an answer I probably > missed. In the Netherlands almost all bigger ISPs (the ones that cover quite a large amount of the effective customer base) are now owned again by the former government-started-then-turned-private ISP who has been buying up various ISPs over the years. Oh, and yes, the Dutch Regulatory organization did not see any problem with this monopoly growing.... All sounds like http://www.youtube.com/watch?v=0ilMx7k7mso right? :) Greets, Jeroen From dtaylor at vocalabs.com Fri Apr 25 14:13:28 2014 From: dtaylor at vocalabs.com (Daniel Taylor) Date: Fri, 25 Apr 2014 09:13:28 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> Message-ID: <535A6D88.60506@vocalabs.com> On 04/25/2014 08:23 AM, Patrick W. Gilmore wrote: > On Apr 25, 2014, at 00:57 , Larry Sheldon wrote: > >> >> In a private message I asked if he could name a single monopoly that existed without regulation to protect its monopoly power. > I answered in a private message: Microsoft. > > Kinda obvious if you think about it for, oh, say, 12 microseconds. > > > DeBeers Diamond cartel, which operated internationally and held an effective monopoly on the diamond market for *decades* was apparently beyond the reach of regulation to either assist or hinder them, and has only recently faded somewhat in the face of competition that they can't reach with their traditional protective tactics. The Standard Oil monopoly was obtained without the special assistance of government as well, though they were broken up by the government. The methods they used should be mandatory study for everyone. The AT&T monopoly position *was* granted (and later revoked) by the government. Net neutrality is an intervention of the government to prevent monopoly forming tactics on the part of major players, so I think it is something worth having. It is not (unfortunately) something that is a natural state for the Internet. -- Daniel Taylor VP Operations Vocal Laboratories, Inc. dtaylor at vocalabs.com http://www.vocalabs.com/ (612)235-5711 From jbates at paradoxnetworks.net Fri Apr 25 14:52:36 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Fri, 25 Apr 2014 09:52:36 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> Message-ID: <535A76B4.8080808@paradoxnetworks.net> On 4/25/2014 8:23 AM, Patrick W. Gilmore wrote: > gulation to protect its monopoly power. > I answered in a private message: Microsoft. > > Kinda obvious if you think about it for, oh, say, 12 microseconds. The government actually had to step in to hinder them, as I recall, though I believe it was pointless. Relatively speaking, Microsoft had a short run monopoly if you want to call it that. They definitely had the market share. With the introduction of the smartphone and the tablet, people have required more versatile applications which tend to work across multiple devices. In this regard, I believe Apple won. Internet growth and consumer education have also altered market share. The money filtering into open source has fueled a lot of growth in software development and allowed a lot more flexibility. The change to OSX and x86 on Apple's part along with google and redhat's efforts have altered the playing field permanently. > >> Which were "Anyone afraid what will happen when companies which have monopolies can charge content providers or guarantee packet loss?" and "How is this good for the consumer?" and "How is this good for the market?" >> >> My answer was an attempt to say that if you don't have any government entities allowing and protecting (two pretty much interchangeable terms, I prefer the latter) monopolies the answer to the first question is "Huh? What?" and to the second and third "Best service for the best price is pretty good for everybody. Except the losers that can't rip you off without the FCC protection." > While it is probably true that the gov't had a hand in the fact I have exactly one BB provider at my home, I am not even closed to convinced that a purely open market would not have resulted in the same problem. But thanx for pointing out an answer I probably missed. > In Oklahoma, I've watched WISPs take money from the various grants for under-served areas. They love to move into small cities and those cities are happy to have them. Their plan is well thought out. They know exactly how fast the telco will move to increase speeds and drop the requirement that you must also pay for a phone line (which the telco was just using to pull in extra money on the backside until the FCC finally changes that funding). The prices suddenly drop in the town. It's not the best service for either party, but it is at least more affordable. The one that pisses me off is when ILECs use grant money strictly to try and wipe out their competition. It creates a very bad environment, where one company must use grants for the same area as another company just to stay competitive. I don't mind all these funds and all, but there needs to be much more oversight on how the funding is used. "underserved" is too broad, and the grants get used in anti-competitive practices against companies that don't pull money from the government. In addition, I too often see companies that have used grants not lower their prices, provide more jobs, or increase their bandwidth offerings. I hear corporate jet fuel is costly, though. We still have huge areas of land that have little or no affordable broadband capability. These are areas that it isn't profitable to buy the equipment to serve and where grant money would do the most good to allow sustainable growth. What I've been pondering is the creation of non-profit ISPs, where the purpose is to actually serve the people who won't make you millions at cost. Jack From bicknell at ufp.org Fri Apr 25 15:00:08 2014 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Apr 2014 10:00:08 -0500 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: References: Message-ID: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> On Apr 23, 2014, at 12:45 AM, Grant Ridder wrote: > Thought i would throw this out there. > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ Curious I unleashed grep on a couple of mailing lists I operate. I turned up one AOL address. I'm not saying my data is representative of the Internet, but I remember a time when they were 50% of the addresses on my mailing lists. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jared at puck.nether.net Fri Apr 25 15:18:35 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 25 Apr 2014 11:18:35 -0400 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> Message-ID: Aol doesn't have a lot of mail users for me anymore either, but I don't have a lot of retail users on my lists. Jared Mauch > On Apr 25, 2014, at 11:00 AM, Leo Bicknell wrote: > > >> On Apr 23, 2014, at 12:45 AM, Grant Ridder wrote: >> >> Thought i would throw this out there. >> http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ > > Curious I unleashed grep on a couple of mailing lists I operate. > > I turned up one AOL address. > > I'm not saying my data is representative of the Internet, but I remember a time > when they were 50% of the addresses on my mailing lists. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > From shrdlu at deaddrop.org Fri Apr 25 15:43:45 2014 From: shrdlu at deaddrop.org (Shrdlu) Date: Fri, 25 Apr 2014 08:43:45 -0700 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> Message-ID: <535A82B1.1050203@deaddrop.org> On 4/25/2014 8:00 AM, Leo Bicknell wrote: > > On Apr 23, 2014, at 12:45 AM, Grant Ridder > wrote: > >> Thought i would throw this out there. > Curious I unleashed grep on a couple of mailing lists I operate. > I turned up one AOL address. > I'm not saying my data is representative of the Internet, but I > remember a time when they were 50% of the addresses on my mailing > lists. I doubt the largest list I manage is representative of anything beyond an insane asylum, but out of 900-950, there are SIX of those laying around. Those are all addresses receiving email (I looked at the logs, just to verify). You just never know. -- If you would know a man, observe how he treats a cat. Age is not an accomplishment, and youth is not a sin. (Robert A. Heinlein, 1907?1988) From royce at techsolvency.com Fri Apr 25 15:59:23 2014 From: royce at techsolvency.com (Royce Williams) Date: Fri, 25 Apr 2014 07:59:23 -0800 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <535A82B1.1050203@deaddrop.org> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> Message-ID: On Fri, Apr 25, 2014 at 7:43 AM, Shrdlu wrote: > On 4/25/2014 8:00 AM, Leo Bicknell wrote: >> >> >> On Apr 23, 2014, at 12:45 AM, Grant Ridder >> wrote: >> >>> Thought i would throw this out there. > >> Curious I unleashed grep on a couple of mailing lists I operate. > >> I turned up one AOL address. > >> I'm not saying my data is representative of the Internet, but I >> remember a time when they were 50% of the addresses on my mailing >> lists. > > I doubt the largest list I manage is representative of anything beyond > an insane asylum, but out of 900-950, there are SIX of those laying > around. Those are all addresses receiving email (I looked at the logs, > just to verify). You just never know. Keep in mind that mailing list membership is heavily dependent on demographics of their common interest. Many mailing lists that folks on this list run themselves are likely to be technical in nature, and therefore less likely to have @aol.com address. On the other hand, I belong to a club for people who collect license plates. They tend to be older. 11% (320 of them) are active AOL users. Royce From jimpop at gmail.com Fri Apr 25 16:00:06 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 25 Apr 2014 12:00:06 -0400 Subject: Yahoo DMARC breakage In-Reply-To: <5355B1FC.70506@meetinghouse.net> References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> <5354649E.9030903@dcrocker.net> <5355B1FC.70506@meetinghouse.net> Message-ID: Just a heads up to interested parties... Google seems to now be bouncing where From: is another gmail account. But it seems to be inconsistent. If you are reading this on a gmail account please let me know. -Jim P. On Mon, Apr 21, 2014 at 8:04 PM, Miles Fidelman wrote: > Elizabeth Zwicky wrote: >> >> >> I believe that our public statements make it clear that we realize that >> significant use cases are broken: >> >> >> http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-p >> rotect-our-users >> >> >> http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what >> -should-senders-do >> >> Elizabeth Zwicky >> > What I do notice as interesting is that yahoo-inc.com and yahoogroups.com > both publish dmarc records with "p=none" > > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From ssaner at hubris.net Fri Apr 25 16:04:59 2014 From: ssaner at hubris.net (Steven Saner) Date: Fri, 25 Apr 2014 11:04:59 -0500 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> Message-ID: <535A87AB.1050601@hubris.net> On 04/25/2014 10:59 AM, Royce Williams wrote: > On Fri, Apr 25, 2014 at 7:43 AM, Shrdlu wrote: >> On 4/25/2014 8:00 AM, Leo Bicknell wrote: >>> >>> >>> On Apr 23, 2014, at 12:45 AM, Grant Ridder >>> wrote: >>> >>>> Thought i would throw this out there. >> >>> Curious I unleashed grep on a couple of mailing lists I operate. >> >>> I turned up one AOL address. >> >>> I'm not saying my data is representative of the Internet, but I >>> remember a time when they were 50% of the addresses on my mailing >>> lists. >> >> I doubt the largest list I manage is representative of anything beyond >> an insane asylum, but out of 900-950, there are SIX of those laying >> around. Those are all addresses receiving email (I looked at the logs, >> just to verify). You just never know. > > Keep in mind that mailing list membership is heavily dependent on > demographics of their common interest. Many mailing lists that folks > on this list run themselves are likely to be technical in nature, and > therefore less likely to have @aol.com address. > > On the other hand, I belong to a club for people who collect license > plates. They tend to be older. 11% (320 of them) are active AOL > users. > > Royce We run several mailing lists for customers. We frequently get feedback reports from AOL saying that the AOL user has flagged the message as spam. So, we remove said user from the list. They then complain that they have been removed and swear that they didn't do it. Anyone have a handle on what this is about? Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From allenmckinleykitchen at gmail.com Fri Apr 25 16:05:44 2014 From: allenmckinleykitchen at gmail.com (Allen McKinley Kitchen (gmail)) Date: Fri, 25 Apr 2014 12:05:44 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359E48D.80504@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E48D.80504@cox.net> Message-ID: <8FB84567-5063-488E-9245-22563DBE7C8B@gmail.com> I beg your indulgence.. On Apr 25, 2014, at 0:29, Larry Sheldon wrote: > ...On 4/24/2014 11:01 PM, Everton Marques wrote: >> On Fri, Apr 25, 2014 at 12:44 AM, Patrick W. Gilmore wrote: >> >>> On Apr 24, 2014, at 23:38 , Larry Sheldon wrote: >>>> >>>> Regulating monopolies protects monopolies from competition. >>>> >>>> Monopolies can not persist without regulation. >>> >>> You are confused. >>> >> >> I think Mr. Sheldon is pointing out this: > > Thank you. > ... > [more comment below] >> --xx-- > ... > I don't know what got me to thinking about it earlier today but I recalled when I started at the telephone company in Los Angeles there was a pitch made early on that in earlier days a business in Los Angeles had to have several telephones on desks to be able to talk to all of their customers. > > Which was true ONLY because regulation required that each telephone line terminate in an instrument owned by the providing company. > The above statement contains an error that obscures the issue. As someone who also recalls this state of affairs, I must point out that it was the respective telcos' "regulation" - not government regulation in any sense - that prohibited any equipment but their own from being attached to their lines. In other words, those telcos were behaving anti-competitively with all the power they could muster to do so (surprise!) and also doing whatever they could to obscure that fact. Regulation was demanded by consumers - in order to protect them from the ridiculous results of this assertion of privilege on the telcos' part. To Mr Sheldon, this resulted in regulation (by government) creating a monopoly. I believe Mr Gilmore might argue that well-crafted regulation requiring interconnectivity as a public good would have prevented both the "need" for monopoly-creating regulation and also would have protected the public from the inherent tendency toward monopoly as vendors do battle to protect their turf rather than provide the best possible outcome for their customers. > Absent that one regulation, businesses would have invented multi-line instruments a lot earlier than was the case. So THIS argument is completely off the mark. In fact, one could say a regulation was needed which would have forbade the telcos' anti-competitive behavior, and then the competitive marketplace could have played out further. Instead, what we got - partly to address some of the other concerns like interconnection - was a set of regulations that favored one (well-connected) vendor, leading to a monopoly. So in some respects, each Mr Sheldon and Mr Gilmore are both right. No surprise there, either, as I have immense respect for both. I tend to lean towards Mr Gilmore's position, though, in that I personally hold that powerful vendors have a natural positive feedback tendency towards monopoly if they can attain it, and regulation that is wisely and truly customer-centered can prevent much damage; I side with Mr Sheldon only insofar as I observe that one tactic of a determined monopolist is to engage compliant regulators to more firmly ensconce them, and I believe that's a Bad Thing. Blessings.. ..Allen Kitchen, Old Guy From cma at cmadams.net Fri Apr 25 16:09:29 2014 From: cma at cmadams.net (Chris Adams) Date: Fri, 25 Apr 2014 11:09:29 -0500 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <535A87AB.1050601@hubris.net> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> <535A87AB.1050601@hubris.net> Message-ID: <20140425160929.GB22922@cmadams.net> Once upon a time, Steven Saner said: > We run several mailing lists for customers. We frequently get feedback > reports from AOL saying that the AOL user has flagged the message as > spam. So, we remove said user from the list. They then complain that > they have been removed and swear that they didn't do it. Anyone have a > handle on what this is about? That has been a problem basically as long as AOL has had the feedback loop. The theory is that some AOL users use "This is spam" as a delete button; apparently at one point the buttons were right next to each other (making it an easy accident). -- Chris Adams From joelja at bogus.com Fri Apr 25 16:11:37 2014 From: joelja at bogus.com (joel jaeggli) Date: Fri, 25 Apr 2014 09:11:37 -0700 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <535A87AB.1050601@hubris.net> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> <535A87AB.1050601@hubris.net> Message-ID: <535A8939.8010905@bogus.com> On 4/25/14, 9:04 AM, Steven Saner wrote: > On 04/25/2014 10:59 AM, Royce Williams wrote: >> On Fri, Apr 25, 2014 at 7:43 AM, Shrdlu wrote: >>> On 4/25/2014 8:00 AM, Leo Bicknell wrote: >>>> >>>> >>>> On Apr 23, 2014, at 12:45 AM, Grant Ridder >>>> wrote: >>>> >>>>> Thought i would throw this out there. >>> >>>> Curious I unleashed grep on a couple of mailing lists I operate. >>> >>>> I turned up one AOL address. >>> >>>> I'm not saying my data is representative of the Internet, but I >>>> remember a time when they were 50% of the addresses on my mailing >>>> lists. >>> >>> I doubt the largest list I manage is representative of anything beyond >>> an insane asylum, but out of 900-950, there are SIX of those laying >>> around. Those are all addresses receiving email (I looked at the logs, >>> just to verify). You just never know. >> >> Keep in mind that mailing list membership is heavily dependent on >> demographics of their common interest. Many mailing lists that folks >> on this list run themselves are likely to be technical in nature, and >> therefore less likely to have @aol.com address. >> >> On the other hand, I belong to a club for people who collect license >> plates. They tend to be older. 11% (320 of them) are active AOL >> users. >> >> Royce > > > We run several mailing lists for customers. We frequently get feedback > reports from AOL saying that the AOL user has flagged the message as > spam. So, we remove said user from the list. They then complain that > they have been removed and swear that they didn't do it. Anyone have a > handle on what this is about? It's a user interface problem. marked messages disappear. aol user employees this in lieu of mailbox filtering. it could have been fixed a decade ago. > Steve > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From jimpop at gmail.com Fri Apr 25 16:12:53 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 25 Apr 2014 12:12:53 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> <5354649E.9030903@dcrocker.net> <5355B1FC.70506@meetinghouse.net> Message-ID: On Fri, Apr 25, 2014 at 12:00 PM, Jim Popovitch wrote: > Just a heads up to interested parties... Google seems to now be > bouncing where From: is another gmail account. But it seems to be > inconsistent. If you are reading this on a gmail account please let > me know. > > -Jim P. A few people have indicated to me that they are NOT seeing issues with GMail. Just to be clear, what I am seeing a pattern of gmail users sending email to mailinglists and every outbound email to other gmail users logs this: Apr 24 18:19:20 svr5 postfix/smtp[32546]: BB2F73F2E3: to=, relay=gmail-smtp-in.l.google.com[74.125.201.109]:25, delay=27, delays=0/27/0.44/0.06, dsn=5.5.1, status=bounced (host gmail-smtp-in.l.google.com[74.125.201.109] said: 530-5.5.1 Authentication Required. Learn more at 530 5.5.1 http://support.google.com/mail/bin/answer.py?answer=14257 hi8sm834730igb.8 - gsmtp (in reply to MAIL FROM command)) It's as though Gmail wants a mailinglist to authenticate to send email to gmail recipients. :-) It's not persistent, it's just happened a few times in past 2 days, generally in the AM. -Jim P. From jimpop at gmail.com Fri Apr 25 16:14:28 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 25 Apr 2014 12:14:28 -0400 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <535A87AB.1050601@hubris.net> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> <535A87AB.1050601@hubris.net> Message-ID: On Fri, Apr 25, 2014 at 12:04 PM, Steven Saner wrote: > We run several mailing lists for customers. We frequently get feedback > reports from AOL saying that the AOL user has flagged the message as > spam. So, we remove said user from the list. They then complain that > they have been removed and swear that they didn't do it. Anyone have a > handle on what this is about? Forged address book spam? AOL's been taking a beating on that front lately. -Jim P. From mfidelman at meetinghouse.net Fri Apr 25 17:35:53 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 25 Apr 2014 13:35:53 -0400 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <20140425160929.GB22922@cmadams.net> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> <535A87AB.1050601@hubris.net> <20140425160929.GB22922@cmadams.net> Message-ID: <535A9CF9.4010803@meetinghouse.net> Chris Adams wrote: > Once upon a time, Steven Saner said: >> We run several mailing lists for customers. We frequently get feedback >> reports from AOL saying that the AOL user has flagged the message as >> spam. So, we remove said user from the list. They then complain that >> they have been removed and swear that they didn't do it. Anyone have a >> handle on what this is about? > That has been a problem basically as long as AOL has had the feedback > loop. The theory is that some AOL users use "This is spam" as a delete > button; apparently at one point the buttons were right next to each > other (making it an easy accident). I still see this one, both accidentally and intentionally (I'm not interested in this topic, so it's spam.) Most of the lists I run are small - parent-teacher organizations, churches, and such - and I generally warn people about hitting the spam button, then I drop them if they do it again. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Fri Apr 25 17:52:00 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 25 Apr 2014 13:52:00 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <8FB84567-5063-488E-9245-22563DBE7C8B@gmail.com> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E48D.80504@cox.net> <8FB84567-5063-488E-9245-22563DBE7C8B@gmail.com> Message-ID: <535AA0C0.2010800@meetinghouse.net> Allen McKinley Kitchen (gmail) wrote: >> ... >> I don't know what got me to thinking about it earlier today but I recalled when I started at the telephone company in Los Angeles there was a pitch made early on that in earlier days a business in Los Angeles had to have several telephones on desks to be able to talk to all of their customers. >> >> Which was true ONLY because regulation required that each telephone line terminate in an instrument owned by the providing company. >> >> >> >> The above statement contains an error that obscures the issue. As someone who also recalls this state of affairs, I must point out that it was the respective telcos' "regulation" - not government regulation in any sense - that prohibited any equipment but their own from being attached to their lines. In other words, those telcos were behaving anti-competitively with all the power they could muster to do so (surprise!) and also doing whatever they could to obscure that fact. >> >> Regulation was demanded by consumers - in order to protect them from the ridiculous results of this assertion of privilege on the telcos' part. To Mr Sheldon, this resulted in regulation (by government) creating a monopoly. I believe Mr Gilmore might argue that well-crafted regulation requiring interconnectivity as a public good would have prevented both the "need" for monopoly-creating regulation and also would have protected the public from the inherent tendency toward monopoly as vendors do battle to protect their turf rather than provide the best possible outcome for their customers. >> Actually, it goes back further than that. In the really early days, in NY, there were lots of phone companies, and a business would have to have one of each to serve all its customers. And long distance was just beginning - expensive, requiring operator intervention - and AT&T long lines wouldn't necessarily connect to non-Bell system players. It was basically a mess. Bell kept buying up lots of other telcos, and integrating them into a more uniform network (remember "The Bell System") - and eventually ran afoul of antitrust issues. Bell went to Congress and proposed a deal - let us buy up everyone, we'll build an integrated system, including interconnection to the independents, and you get to regulate us to balance out our monopoly power. Email provides an interesting contrast. In the early days, the early timesharing vendors sold email as a feature, and the size of their user bases as a competitive advantage. Along came Barry Shein, and the World - pretty much forcing open some limited public access to the early Internet, followed by Compuserve connecting to Internet email, and suddenly market pressure pretty much forced everybody to connect their private mail systems to the Internet. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mikea at mikea.ath.cx Fri Apr 25 17:52:38 2014 From: mikea at mikea.ath.cx (Mike A) Date: Fri, 25 Apr 2014 12:52:38 -0500 Subject: AOL Mail updates DMARC policy to 'reject' In-Reply-To: <535A9CF9.4010803@meetinghouse.net> References: <82D2D8A4-6A2F-4C6E-A4C3-C999DF0D5EAF@ufp.org> <535A82B1.1050203@deaddrop.org> <535A87AB.1050601@hubris.net> <20140425160929.GB22922@cmadams.net> <535A9CF9.4010803@meetinghouse.net> Message-ID: <20140425175238.GA73914@mikea.ath.cx> On Fri, Apr 25, 2014 at 01:35:53PM -0400, Miles Fidelman wrote: > Chris Adams wrote: > >Once upon a time, Steven Saner said: > >>We run several mailing lists for customers. We frequently get feedback > >>reports from AOL saying that the AOL user has flagged the message as > >>spam. So, we remove said user from the list. They then complain that > >>they have been removed and swear that they didn't do it. Anyone have a > >>handle on what this is about? > >That has been a problem basically as long as AOL has had the feedback > >loop. The theory is that some AOL users use "This is spam" as a delete > >button; apparently at one point the buttons were right next to each > >other (making it an easy accident). > > I still see this one, both accidentally and intentionally (I'm not > interested in this topic, so it's spam.) > > Most of the lists I run are small - parent-teacher organizations, churches, > and such - and I generally warn people about hitting the spam button, then I > drop them if they do it again. I see this very frequently -- dozens of times per day -- for all manner of things, including receipts for fairly expensive state government licenses and permits. I can't imagine anyone intentionally marking these as spam, but certainly can see a finger check causing the problem. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From cscora at apnic.net Fri Apr 25 18:12:48 2014 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Apr 2014 04:12:48 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201404251812.s3PICmrl029768@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 26 Apr, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 493063 Prefixes after maximum aggregation: 193477 Deaggregation factor: 2.55 Unique aggregates announced to Internet: 243258 Total ASes present in the Internet Routing Table: 46682 Prefixes per ASN: 10.56 Origin-only ASes present in the Internet Routing Table: 35791 Origin ASes announcing only one prefix: 16372 Transit ASes present in the Internet Routing Table: 6040 Transit-only ASes present in the Internet Routing Table: 171 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1841 Unregistered ASNs in the Routing Table: 464 Number of 32-bit ASNs allocated by the RIRs: 6448 Number of 32-bit ASNs visible in the Routing Table: 4851 Prefixes from 32-bit ASNs in the Routing Table: 16028 Number of bogon 32-bit ASNs visible in the Routing Table: 119 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 439 Number of addresses announced to Internet: 2674874628 Equivalent to 159 /8s, 111 /16s and 89 /24s Percentage of available address space announced: 72.2 Percentage of allocated address space announced: 72.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.2 Total number of prefixes smaller than registry allocations: 171870 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 116858 Total APNIC prefixes after maximum aggregation: 34890 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 119729 Unique aggregates announced from the APNIC address blocks: 50015 APNIC Region origin ASes present in the Internet Routing Table: 4919 APNIC Prefixes per ASN: 24.34 APNIC Region origin ASes announcing only one prefix: 1227 APNIC Region transit ASes present in the Internet Routing Table: 855 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 918 Number of APNIC addresses announced to Internet: 731520128 Equivalent to 43 /8s, 154 /16s and 28 /24s Percentage of available APNIC address space announced: 85.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 168391 Total ARIN prefixes after maximum aggregation: 83324 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 169871 Unique aggregates announced from the ARIN address blocks: 79347 ARIN Region origin ASes present in the Internet Routing Table: 16229 ARIN Prefixes per ASN: 10.47 ARIN Region origin ASes announcing only one prefix: 6102 ARIN Region transit ASes present in the Internet Routing Table: 1669 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 91 Number of ARIN addresses announced to Internet: 1074255232 Equivalent to 64 /8s, 7 /16s and 213 /24s Percentage of available ARIN address space announced: 56.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 123498 Total RIPE prefixes after maximum aggregation: 62495 RIPE Deaggregation factor: 1.98 Prefixes being announced from the RIPE address blocks: 127840 Unique aggregates announced from the RIPE address blocks: 80671 RIPE Region origin ASes present in the Internet Routing Table: 17683 RIPE Prefixes per ASN: 7.23 RIPE Region origin ASes announcing only one prefix: 8293 RIPE Region transit ASes present in the Internet Routing Table: 2857 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 53 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2693 Number of RIPE addresses announced to Internet: 657666948 Equivalent to 39 /8s, 51 /16s and 51 /24s Percentage of available RIPE address space announced: 95.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 196608-202239 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 55855 Total LACNIC prefixes after maximum aggregation: 10052 LACNIC Deaggregation factor: 5.56 Prefixes being announced from the LACNIC address blocks: 62175 Unique aggregates announced from the LACNIC address blocks: 28563 LACNIC Region origin ASes present in the Internet Routing Table: 2090 LACNIC Prefixes per ASN: 29.75 LACNIC Region origin ASes announcing only one prefix: 548 LACNIC Region transit ASes present in the Internet Routing Table: 431 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 26 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 1125 Number of LACNIC addresses announced to Internet: 157874816 Equivalent to 9 /8s, 104 /16s and 250 /24s Percentage of available LACNIC address space announced: 94.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 262144-263679 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 12331 Total AfriNIC prefixes after maximum aggregation: 2679 AfriNIC Deaggregation factor: 4.60 Prefixes being announced from the AfriNIC address blocks: 13009 Unique aggregates announced from the AfriNIC address blocks: 4295 AfriNIC Region origin ASes present in the Internet Routing Table: 714 AfriNIC Prefixes per ASN: 18.22 AfriNIC Region origin ASes announcing only one prefix: 202 AfriNIC Region transit ASes present in the Internet Routing Table: 149 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 24 Number of AfriNIC addresses announced to Internet: 53239808 Equivalent to 3 /8s, 44 /16s and 96 /24s Percentage of available AfriNIC address space announced: 52.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2953 11591 922 Korea Telecom 17974 2798 903 78 PT Telekomunikasi Indonesia 7545 2214 320 117 TPG Telecom Limited 4755 1850 396 198 TATA Communications formerly 9829 1622 1288 35 National Internet Backbone 9583 1334 103 545 Sify Limited 9498 1254 314 83 BHARTI Airtel Ltd. 7552 1219 1082 13 Viettel Corporation 4808 1209 2151 355 CNCGROUP IP network China169 24560 1126 385 175 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3063 2937 134 Cox Communications Inc. 6389 2984 3688 53 BellSouth.net Inc. 1785 2196 699 133 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 20115 1705 1690 566 Charter Communications 4323 1628 1073 407 tw telecom holdings, inc. 701 1481 11158 750 MCI Communications Services, 30036 1400 303 542 Mediacom Communications Corp 6983 1325 800 307 ITC^Deltacom 22561 1299 401 230 CenturyTel Internet Holdings, Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 34984 1668 264 277 TELLCOM ILETISIM HIZMETLERI A 8402 1596 544 16 OJSC "Vimpelcom" 20940 1312 502 989 Akamai International B.V. 13188 1049 100 28 TOV "Bank-Inform" 31148 1018 45 19 Freenet Ltd. 8551 923 370 40 Bezeq International-Ltd 6849 827 359 29 JSC "Ukrtelecom" 6830 764 2329 424 Liberty Global Operations B.V 12479 720 797 56 France Telecom Espana SA 9198 572 344 25 JSC Kazakhtelecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3699 1955 99 NET Servi?os de Comunica??o S 10620 2844 459 199 Telmex Colombia S.A. 18881 1931 972 21 Global Village Telecom 7303 1754 1174 229 Telecom Argentina S.A. 8151 1394 2943 400 Uninet S.A. de C.V. 6503 1154 434 60 Axtel, S.A.B. de C.V. 7738 914 1754 40 Telemar Norte Leste S.A. 27947 868 114 50 Telconet S.A 11830 844 364 15 Instituto Costarricense de El 26615 843 2325 35 Tim Celular S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1634 240 6 Sudanese Mobile Telephone (ZA 24863 954 280 26 Link Egypt (Link.NET) 6713 614 722 28 Office National des Postes et 8452 569 958 13 TE-AS 24835 304 144 9 Vodafone Data 36992 275 783 24 ETISALAT MISR 3741 248 921 209 Internet Solutions 29571 230 22 23 Cote d'Ivoire Telecom 37054 228 20 9 Data Telecom Service 29975 192 668 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 3699 1955 99 NET Servi?os de Comunica??o S 22773 3063 2937 134 Cox Communications Inc. 6389 2984 3688 53 BellSouth.net Inc. 4766 2953 11591 922 Korea Telecom 10620 2844 459 199 Telmex Colombia S.A. 17974 2798 903 78 PT Telekomunikasi Indonesia 7545 2214 320 117 TPG Telecom Limited 1785 2196 699 133 PaeTec Communications, Inc. 18566 2047 379 178 MegaPath Corporation 18881 1931 972 21 Global Village Telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2984 2931 BellSouth.net Inc. 22773 3063 2929 Cox Communications Inc. 17974 2798 2720 PT Telekomunikasi Indonesia 10620 2844 2645 Telmex Colombia S.A. 7545 2214 2097 TPG Telecom Limited 1785 2196 2063 PaeTec Communications, Inc. 4766 2953 2031 Korea Telecom 18881 1931 1910 Global Village Telecom 18566 2047 1869 MegaPath Corporation 4755 1850 1652 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65456 PRIVATE 5.109.32.0/19 23456 32bit Transition AS 65456 PRIVATE 5.109.96.0/19 23456 32bit Transition AS 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio 46473 UNALLOCATED 8.27.122.0/24 12180 Internap Network Ser 46473 UNALLOCATED 8.27.124.0/24 12180 Internap Network Ser 22511 UNALLOCATED 8.28.225.0/24 2828 XO Communications 22511 UNALLOCATED 8.36.68.0/24 2828 XO Communications Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 >>UNKNOWN<< 41.73.1.0/24 37004 >>UNKNOWN<< 41.73.2.0/24 37004 >>UNKNOWN<< 41.73.10.0/24 37004 >>UNKNOWN<< 41.73.11.0/24 37004 >>UNKNOWN<< 41.73.12.0/24 37004 >>UNKNOWN<< 41.73.13.0/24 37004 >>UNKNOWN<< 41.73.14.0/24 37004 >>UNKNOWN<< 41.73.15.0/24 37004 >>UNKNOWN<< 41.73.16.0/24 37004 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:12 /10:31 /11:90 /12:256 /13:480 /14:961 /15:1682 /16:12952 /17:6824 /18:11580 /19:24248 /20:33938 /21:36684 /22:53119 /23:46191 /24:261776 /25:797 /26:943 /27:404 /28:13 /29:20 /30:7 /31:1 /32:38 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 22773 2306 3063 Cox Communications Inc. 18566 2002 2047 MegaPath Corporation 6389 1694 2984 BellSouth.net Inc. 36998 1599 1634 Sudanese Mobile Telephone (ZA 8402 1275 1596 OJSC "Vimpelcom" 30036 1237 1400 Mediacom Communications Corp 11492 1190 1234 CABLE ONE, INC. 1785 1162 2196 PaeTec Communications, Inc. 6983 1042 1325 ITC^Deltacom 34984 1030 1668 TELLCOM ILETISIM HIZMETLERI A Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1024 2:696 3:3 4:15 5:973 6:19 8:733 12:1851 13:4 14:987 15:13 16:2 17:31 18:21 20:36 23:807 24:1747 25:1 27:1777 31:1452 32:40 33:2 34:5 36:132 37:1891 38:949 39:6 40:196 41:3187 42:249 44:10 46:2145 47:18 49:694 50:921 52:12 54:47 55:5 57:28 58:1228 59:603 60:398 61:1545 62:1233 63:1987 64:4375 65:2278 66:4148 67:2062 68:1034 69:3285 70:865 71:452 72:2025 74:2616 75:312 76:418 77:1515 78:964 79:710 80:1306 81:1150 82:738 83:755 84:716 85:1260 86:470 87:1188 88:524 89:1803 90:140 91:5725 92:684 93:1715 94:2049 95:1473 96:547 97:348 98:1082 99:48 100:54 101:782 103:4688 105:534 106:172 107:564 108:577 109:2089 110:985 111:1288 112:645 113:844 114:898 115:1116 116:1057 117:926 118:1411 119:1341 120:375 121:802 122:1970 123:1286 124:1397 125:1398 128:642 129:312 130:346 131:659 132:393 133:162 134:335 135:74 136:256 137:322 138:352 139:170 140:211 141:368 142:570 143:422 144:505 145:100 146:597 147:453 148:925 149:347 150:169 151:634 152:422 153:218 154:270 155:481 156:337 157:341 158:244 159:894 160:337 161:483 162:1349 163:218 164:688 165:613 166:279 167:610 168:1028 169:124 170:1386 171:191 172:22 173:1643 174:699 175:607 176:1372 177:2882 178:1963 179:591 180:1724 181:1110 182:1551 183:514 184:705 185:1544 186:2737 187:1497 188:1930 189:1479 190:7445 191:213 192:7222 193:5486 194:4038 195:3495 196:1402 197:1122 198:5022 199:5588 200:6220 201:2642 202:8964 203:8988 204:4646 205:2720 206:2942 207:2940 208:3990 209:3735 210:3106 211:1675 212:2192 213:2049 214:917 215:84 216:5454 217:1682 218:569 219:316 220:1276 221:598 222:350 223:579 End of report From tdurack at gmail.com Fri Apr 25 18:59:58 2014 From: tdurack at gmail.com (Tim Durack) Date: Fri, 25 Apr 2014 14:59:58 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack wrote: > Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no > such thing.) > > How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter > receive side might be doable?) > > -- > Tim:> > > p.s. Before you ask, DTAG Terastream has got me thinking... > As a follow up, there are lots of people willing to sell various flavours of DWDM optics, but as I suspected, there is no such thing as a coherent/tuned/filtered receive 10GigE DWDM optic. All 10GigE optics are wide-band receive. However, you can get inline optical filters, Santec OFM-15 for example. Investigating... -- Tim:> From cidr-report at potaroo.net Fri Apr 25 22:00:00 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Apr 2014 22:00:00 GMT Subject: The Cidr Report Message-ID: <201404252200.s3PM0041030660@wattle.apnic.net> This report has been generated at Fri Apr 25 21:13:54 2014 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/2.0 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 18-04-14 499254 282312 19-04-14 499492 282427 20-04-14 499557 282428 21-04-14 499371 282193 22-04-14 499156 282325 23-04-14 499260 282597 24-04-14 499642 282663 25-04-14 500177 282878 AS Summary 46910 Number of ASes in routing system 19117 Number of ASes announcing only one prefix 3731 Largest number of prefixes announced by an AS AS28573: NET Servi?os de Comunica??o S.A.,BR 119976960 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 25Apr14 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 500075 282843 217232 43.4% All ASes AS28573 3731 380 3351 89.8% NET Servi?os de Comunica??o S.A.,BR AS6389 2983 58 2925 98.1% BELLSOUTH-NET-BLK - BellSouth.net Inc.,US AS17974 2799 251 2548 91.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID AS4766 2953 931 2022 68.5% KIXS-AS-KR Korea Telecom,KR AS18881 1932 37 1895 98.1% Global Village Telecom,BR AS1785 2196 490 1706 77.7% AS-PAETEC-NET - PaeTec Communications, Inc.,US AS10620 2844 1349 1495 52.6% Telmex Colombia S.A.,CO AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath Corporation,US AS36998 1634 161 1473 90.1% SDN-MOBITEL,SD AS22773 3057 1587 1470 48.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US AS4323 2937 1516 1421 48.4% TWTC - tw telecom holdings, inc.,US AS7303 1757 457 1300 74.0% Telecom Argentina S.A.,AR AS4755 1850 583 1267 68.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN AS7545 2228 1072 1156 51.9% TPG-INTERNET-AP TPG Telecom Limited,AU AS7552 1220 107 1113 91.2% VIETEL-AS-AP Viettel Corporation,VN AS22561 1301 241 1060 81.5% AS22561 - CenturyTel Internet Holdings, Inc.,US AS6983 1326 314 1012 76.3% ITCDELTA - Earthlink, Inc.,US AS9829 1622 708 914 56.4% BSNL-NIB National Internet Backbone,IN AS24560 1126 295 831 73.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services,IN AS4808 1209 391 818 67.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN AS18101 945 187 758 80.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI,IN AS8151 1407 656 751 53.4% Uninet S.A. de C.V.,MX AS4788 1030 281 749 72.7% TMNET-AS-AP TM Net, Internet Service Provider,MY AS701 1482 751 731 49.3% UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US AS7738 914 184 730 79.9% Telemar Norte Leste S.A.,BR AS26615 843 113 730 86.6% Tim Celular S.A.,BR AS855 756 57 699 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc.,CA AS4780 1037 370 667 64.3% SEEDNET Digital United Inc.,TW AS6147 780 113 667 85.5% Telefonica del Peru S.A.A.,PE AS9808 996 330 666 66.9% CMNET-GD Guangdong Mobile Communication Co.Ltd.,CN Total 52942 14535 38407 72.5% Top 30 total Possible Bogus Routes 27.100.7.0/24 AS56096 41.73.1.0/24 AS37004 -Reserved AS-,ZZ 41.73.2.0/24 AS37004 -Reserved AS-,ZZ 41.73.10.0/24 AS37004 -Reserved AS-,ZZ 41.73.11.0/24 AS37004 -Reserved AS-,ZZ 41.73.12.0/24 AS37004 -Reserved AS-,ZZ 41.73.13.0/24 AS37004 -Reserved AS-,ZZ 41.73.14.0/24 AS37004 -Reserved AS-,ZZ 41.73.15.0/24 AS37004 -Reserved AS-,ZZ 41.73.16.0/24 AS37004 -Reserved AS-,ZZ 41.73.18.0/24 AS37004 -Reserved AS-,ZZ 41.73.20.0/24 AS37004 -Reserved AS-,ZZ 41.73.21.0/24 AS37004 -Reserved AS-,ZZ 41.76.48.0/21 AS36969 MTL-AS,MW 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US 41.78.236.0/24 AS37290 -Reserved AS-,ZZ 41.78.237.0/24 AS37290 -Reserved AS-,ZZ 41.78.238.0/24 AS37290 -Reserved AS-,ZZ 41.78.239.0/24 AS37290 -Reserved AS-,ZZ 41.190.72.0/24 AS37451 CongoTelecom,CG 41.190.73.0/24 AS37451 CongoTelecom,CG 41.190.74.0/24 AS37451 CongoTelecom,CG 41.190.75.0/24 AS37451 CongoTelecom,CG 41.191.108.0/22 AS37004 -Reserved AS-,ZZ 41.191.108.0/24 AS37004 -Reserved AS-,ZZ 41.191.109.0/24 AS37004 -Reserved AS-,ZZ 41.191.110.0/24 AS37004 -Reserved AS-,ZZ 41.191.111.0/24 AS37004 -Reserved AS-,ZZ 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US 63.247.0.0/24 AS27609 -Reserved AS-,ZZ 63.247.1.0/24 AS27609 -Reserved AS-,ZZ 63.247.2.0/24 AS27609 -Reserved AS-,ZZ 63.247.3.0/24 AS27609 -Reserved AS-,ZZ 63.247.4.0/24 AS27609 -Reserved AS-,ZZ 63.247.5.0/24 AS27609 -Reserved AS-,ZZ 63.247.6.0/24 AS27609 -Reserved AS-,ZZ 63.247.7.0/24 AS27609 -Reserved AS-,ZZ 63.247.8.0/24 AS27609 -Reserved AS-,ZZ 63.247.9.0/24 AS27609 -Reserved AS-,ZZ 63.247.10.0/24 AS27609 -Reserved AS-,ZZ 63.247.11.0/24 AS27609 -Reserved AS-,ZZ 63.247.13.0/24 AS27609 -Reserved AS-,ZZ 63.247.14.0/24 AS27609 -Reserved AS-,ZZ 63.247.15.0/24 AS27609 -Reserved AS-,ZZ 63.247.16.0/24 AS27609 -Reserved AS-,ZZ 63.247.17.0/24 AS27609 -Reserved AS-,ZZ 63.247.18.0/24 AS27609 -Reserved AS-,ZZ 63.247.19.0/24 AS27609 -Reserved AS-,ZZ 63.247.20.0/24 AS27609 -Reserved AS-,ZZ 63.247.21.0/24 AS27609 -Reserved AS-,ZZ 63.247.22.0/24 AS27609 -Reserved AS-,ZZ 63.247.23.0/24 AS27609 -Reserved AS-,ZZ 63.247.24.0/24 AS27609 -Reserved AS-,ZZ 63.247.25.0/24 AS27609 -Reserved AS-,ZZ 63.247.26.0/24 AS27609 -Reserved AS-,ZZ 63.247.27.0/24 AS27609 -Reserved AS-,ZZ 63.247.28.0/24 AS27609 -Reserved AS-,ZZ 63.247.29.0/24 AS27609 -Reserved AS-,ZZ 64.25.16.0/23 AS19535 -Reserved AS-,ZZ 64.25.20.0/24 AS19535 -Reserved AS-,ZZ 64.25.21.0/24 AS19535 -Reserved AS-,ZZ 64.25.22.0/24 AS19535 -Reserved AS-,ZZ 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US 64.111.160.0/20 AS40551 -Reserved AS-,ZZ 64.111.160.0/24 AS40551 -Reserved AS-,ZZ 64.111.161.0/24 AS40551 -Reserved AS-,ZZ 64.111.162.0/24 AS40551 -Reserved AS-,ZZ 64.111.167.0/24 AS40551 -Reserved AS-,ZZ 64.111.169.0/24 AS40551 -Reserved AS-,ZZ 64.111.170.0/24 AS40551 -Reserved AS-,ZZ 64.111.171.0/24 AS40551 -Reserved AS-,ZZ 64.111.172.0/24 AS40551 -Reserved AS-,ZZ 64.111.173.0/24 AS40551 -Reserved AS-,ZZ 64.111.174.0/24 AS40551 -Reserved AS-,ZZ 64.111.175.0/24 AS40551 -Reserved AS-,ZZ 64.119.240.0/22 AS26072 -Reserved AS-,ZZ 64.119.240.0/23 AS26072 -Reserved AS-,ZZ 64.119.242.0/23 AS26072 -Reserved AS-,ZZ 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US 66.55.96.0/23 AS17203 -Reserved AS-,ZZ 66.55.98.0/24 AS17203 -Reserved AS-,ZZ 66.55.99.0/24 AS17203 -Reserved AS-,ZZ 66.55.100.0/22 AS17203 -Reserved AS-,ZZ 66.55.102.0/23 AS17203 -Reserved AS-,ZZ 66.55.104.0/21 AS17203 -Reserved AS-,ZZ 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US 74.112.100.0/22 AS16764 -Reserved AS-,ZZ 74.113.200.0/23 AS46939 -Reserved AS-,ZZ 74.114.52.0/22 AS40818 -Reserved AS-,ZZ 74.114.52.0/23 AS40818 -Reserved AS-,ZZ 74.114.52.0/24 AS40818 -Reserved AS-,ZZ 74.114.53.0/24 AS40818 -Reserved AS-,ZZ 74.114.54.0/23 AS40818 -Reserved AS-,ZZ 74.114.54.0/24 AS40818 -Reserved AS-,ZZ 74.114.55.0/24 AS40818 -Reserved AS-,ZZ 74.115.124.0/23 AS46540 -Reserved AS-,ZZ 74.118.132.0/22 AS5117 -Reserved AS-,ZZ 74.119.236.0/23 AS26368 -Reserved AS-,ZZ 74.119.239.0/24 AS26368 -Reserved AS-,ZZ 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US 77.243.80.0/24 AS42597 -Reserved AS-,ZZ 77.243.81.0/24 AS42597 -Reserved AS-,ZZ 77.243.88.0/24 AS42597 -Reserved AS-,ZZ 77.243.91.0/24 AS42597 -Reserved AS-,ZZ 77.243.94.0/24 AS42597 -Reserved AS-,ZZ 77.243.95.0/24 AS42597 -Reserved AS-,ZZ 80.250.32.0/22 AS37106 ODUA-AS,NG 85.202.160.0/20 AS44404 -Reserved AS-,ZZ 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 91.197.36.0/22 AS43359 -Reserved AS-,ZZ 91.199.90.0/24 AS44330 -Reserved AS-,ZZ 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT 91.229.182.0/24 AS56960 -Reserved AS-,ZZ 91.229.186.0/24 AS56967 -Reserved AS-,ZZ 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ 93.190.10.0/24 AS47254 -Reserved AS-,ZZ 95.215.140.0/22 AS48949 -Reserved AS-,ZZ 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP 103.244.236.0/22 AS58794 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN 162.247.180.0/22 AS23175 POGOZONE - PogoZone,US 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US 172.85.0.0/24 AS29571 CITelecom-AS,CI 172.85.1.0/24 AS29571 CITelecom-AS,CI 172.85.2.0/24 AS29571 CITelecom-AS,CI 172.85.3.0/24 AS29571 CITelecom-AS,CI 172.86.0.0/24 AS29571 CITelecom-AS,CI 172.86.1.0/24 AS29571 CITelecom-AS,CI 172.86.2.0/24 AS29571 CITelecom-AS,CI 172.87.0.0/24 AS29571 CITelecom-AS,CI 172.88.0.0/24 AS29571 CITelecom-AS,CI 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ 185.55.100.0/22 AS12843 TELEMAXX TelemaxX Telekommunikation GmbH,DE 185.55.120.0/22 AS21385 TNIB Trusted Network GmbH,DE 185.55.124.0/22 AS8365 MANDA Man-da.de GmbH,DE 185.55.128.0/22 AS12573 WIDEXS WideXS B.V.,NL 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US 192.75.23.0/24 AS2579 -Reserved AS-,ZZ 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US 192.154.32.0/19 AS81 NCREN - MCNC,US 192.154.64.0/19 AS81 NCREN - MCNC,US 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US 193.9.59.0/24 AS1257 TELE2,SE 193.16.106.0/24 AS31539 -Reserved AS-,ZZ 193.16.145.0/24 AS31392 -Reserved AS-,ZZ 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI 193.22.224.0/20 AS3322 -Reserved AS-,ZZ 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB 193.84.187.0/24 AS16276 OVH OVH SAS,FR 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 193.243.166.0/24 AS44093 -Reserved AS-,ZZ 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 194.126.219.0/24 AS34545 -Reserved AS-,ZZ 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE 194.165.26.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU 194.165.27.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO 195.39.252.0/23 AS29004 -Reserved AS-,ZZ 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE 195.234.156.0/24 AS25028 -Reserved AS-,ZZ 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 196.2.224.0/22 AS24863 LINKdotNET-AS,EG 196.3.182.0/24 AS37004 -Reserved AS-,ZZ 196.3.183.0/24 AS37004 -Reserved AS-,ZZ 196.13.201.0/24 AS2018 TENET-1,ZA 196.13.202.0/24 AS2018 TENET-1,ZA 196.13.203.0/24 AS2018 TENET-1,ZA 196.13.204.0/24 AS2018 TENET-1,ZA 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US 196.45.0.0/21 AS26625 -Reserved AS-,ZZ 196.45.10.0/24 AS26625 -Reserved AS-,ZZ 196.216.129.0/24 AS36886 -Reserved AS-,ZZ 196.216.130.0/24 AS36886 -Reserved AS-,ZZ 196.216.131.0/24 AS36886 -Reserved AS-,ZZ 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US 198.72.78.0/23 AS3967 -Reserved AS-,ZZ 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US 199.30.138.0/24 AS23319 -Reserved AS-,ZZ 199.30.139.0/24 AS23319 -Reserved AS-,ZZ 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA 199.87.166.0/24 AS26368 -Reserved AS-,ZZ 199.87.167.0/24 AS26368 -Reserved AS-,ZZ 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US 199.102.73.0/24 AS26368 -Reserved AS-,ZZ 199.116.200.0/21 AS22830 -Reserved AS-,ZZ 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK 202.58.113.0/24 AS19161 -Reserved AS-,ZZ 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN 203.142.219.0/24 AS45149 203.189.116.0/22 AS45606 203.189.116.0/24 AS45606 203.189.117.0/24 AS45606 203.189.118.0/24 AS45606 203.189.119.0/24 AS45606 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US 204.10.94.0/23 AS30097 NUWAVE - NuWave,US 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US 204.16.96.0/24 AS19972 -Reserved AS-,ZZ 204.16.97.0/24 AS19972 -Reserved AS-,ZZ 204.16.98.0/24 AS19972 -Reserved AS-,ZZ 204.16.99.0/24 AS19972 -Reserved AS-,ZZ 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US 208.75.152.0/21 AS32146 -Reserved AS-,ZZ 208.76.20.0/24 AS31812 -Reserved AS-,ZZ 208.76.21.0/24 AS31812 -Reserved AS-,ZZ 208.77.164.0/24 AS22659 -Reserved AS-,ZZ 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US 208.84.232.0/24 AS33131 -Reserved AS-,ZZ 208.84.234.0/24 AS33131 -Reserved AS-,ZZ 208.84.237.0/24 AS33131 -Reserved AS-,ZZ 208.84.238.0/24 AS33131 -Reserved AS-,ZZ 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US 209.234.112.0/23 AS32252 -Reserved AS-,ZZ 209.234.114.0/23 AS32252 -Reserved AS-,ZZ 209.234.116.0/24 AS32252 -Reserved AS-,ZZ 209.234.117.0/24 AS32252 -Reserved AS-,ZZ 209.234.118.0/24 AS32252 -Reserved AS-,ZZ 209.234.119.0/24 AS32252 -Reserved AS-,ZZ 209.234.120.0/24 AS32252 -Reserved AS-,ZZ 209.234.121.0/24 AS32252 -Reserved AS-,ZZ 209.234.122.0/24 AS32252 -Reserved AS-,ZZ 212.119.32.0/19 AS12550 -Reserved AS-,ZZ 213.184.64.0/24 AS13071 -Reserved AS-,ZZ 213.184.65.0/24 AS13071 -Reserved AS-,ZZ 213.184.66.0/24 AS13071 -Reserved AS-,ZZ 213.184.67.0/24 AS13071 -Reserved AS-,ZZ 213.184.68.0/24 AS13071 -Reserved AS-,ZZ 213.184.69.0/24 AS13071 -Reserved AS-,ZZ 213.184.70.0/24 AS13071 -Reserved AS-,ZZ 213.184.71.0/24 AS13071 -Reserved AS-,ZZ 213.184.72.0/24 AS13071 -Reserved AS-,ZZ 213.184.73.0/24 AS13071 -Reserved AS-,ZZ 213.184.74.0/24 AS13071 -Reserved AS-,ZZ 213.184.75.0/24 AS13071 -Reserved AS-,ZZ 213.184.76.0/24 AS13071 -Reserved AS-,ZZ 213.184.77.0/24 AS13071 -Reserved AS-,ZZ 213.184.78.0/24 AS13071 -Reserved AS-,ZZ 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US 216.24.176.0/20 AS19401 -Reserved AS-,ZZ 216.24.188.0/24 AS19401 -Reserved AS-,ZZ 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US 216.203.80.0/20 AS27021 -Reserved AS-,ZZ 216.203.80.0/21 AS27021 -Reserved AS-,ZZ 216.203.87.0/24 AS27021 -Reserved AS-,ZZ 216.203.88.0/21 AS27021 -Reserved AS-,ZZ 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Apr 25 22:00:02 2014 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Apr 2014 22:00:02 GMT Subject: BGP Update Report Message-ID: <201404252200.s3PM02IF030676@wattle.apnic.net> BGP Update Report Interval: 17-Apr-14 -to- 24-Apr-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7029 155458 6.5% 953.7 -- WINDSTREAM - Windstream Communications Inc,US 2 - AS9829 94290 3.9% 95.9 -- BSNL-NIB National Internet Backbone,IN 3 - AS29571 84780 3.5% 357.7 -- CITelecom-AS,CI 4 - AS701 80802 3.4% 3.6 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US 5 - AS48159 32471 1.4% 156.1 -- TIC-AS Telecommunication Infrastructure Company,IR 6 - AS8402 32099 1.3% 20.2 -- CORBINA-AS OJSC "Vimpelcom",RU 7 - AS28885 22555 0.9% 154.5 -- OMANTEL-NAP-AS OmanTel NAP,OM 8 - AS4538 20545 0.8% 56.8 -- ERX-CERNET-BKB China Education and Research Network Center,CN 9 - AS41691 19909 0.8% 829.5 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS17557 19518 0.8% 271.1 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 11 - AS2167 18493 0.8% 3698.6 -- HPES - Hewlett-Packard Company,US 12 - AS44375 17121 0.7% 248.1 -- AISDP ASMANFARAZ SEPAHAN ISDP (PJS),IR 13 - AS14259 16339 0.7% 1815.4 -- Gtd Internet S.A.,CL 14 - AS4775 14810 0.6% 308.5 -- GLOBE-TELECOM-AS Globe Telecoms,PH 15 - AS28573 14355 0.6% 12.7 -- NET Servi?os de Comunica??o S.A.,BR 16 - AS38264 14116 0.6% 50.2 -- WATEEN-IMS-PK-AS-AP National WiMAX/IMS environment,PK 17 - AS25184 14068 0.6% 104.2 -- AFRANET AFRANET Co. Tehran, Iran,IR 18 - AS64777 13146 0.6% 2.0 -- -Private Use AS-,ZZ 19 - AS35819 12403 0.5% 27.9 -- MOBILY-AS Etihad Etisalat Company (Mobily),SA 20 - AS28178 12123 0.5% 673.5 -- Networld Provedor e Servicos de Internet Ltda,BR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS18135 8658 0.4% 8658.0 -- BTV BTV Cable television,JP 2 - AS34635 6899 0.3% 6899.0 -- LIBERTY-AS Liberty Poland S.A.,PL 3 - AS54465 6814 0.3% 6814.0 -- QPM-AS-1 - QuickPlay Media Inc.,US 4 - AS2167 18493 0.8% 3698.6 -- HPES - Hewlett-Packard Company,US 5 - AS6629 9483 0.4% 1896.6 -- NOAA-AS - NOAA,US 6 - AS21840 3791 0.2% 1895.5 -- SAGONET-TPA - Sago Networks,US 7 - AS38909 5634 0.2% 1878.0 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 8 - AS14259 16339 0.7% 1815.4 -- Gtd Internet S.A.,CL 9 - AS2 1387 0.1% 2313.0 -- UDEL-DCN - University of Delaware,US 10 - AS3 1380 0.1% 1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 11 - AS33643 1327 0.1% 1327.0 -- JELLYBELLY - Jelly Belly Candy Company,US 12 - AS60345 1183 0.1% 1183.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 13 - AS62892 1098 0.1% 1098.0 -- TW-EIS - Turner Broadcasting System, Inc.,US 14 - AS7029 155458 6.5% 953.7 -- WINDSTREAM - Windstream Communications Inc,US 15 - AS41691 19909 0.8% 829.5 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 16 - AS32244 2860 0.1% 715.0 -- LIQUID-WEB-INC - Liquid Web, Inc.,US 17 - AS28178 12123 0.5% 673.5 -- Networld Provedor e Servicos de Internet Ltda,BR 18 - AS2134 4000 0.2% 666.7 -- GSVNET-AS GS Virtual Network Produban,ES 19 - AS30127 650 0.0% 650.0 -- ISC-F-AS - Internet Systems Consortium, Inc.,US 20 - AS4847 7389 0.3% 615.8 -- CNIX-AP China Networks Inter-Exchange,CN TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 89.221.206.0/24 19824 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 2 - 121.52.144.0/24 19796 0.8% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 3 - 87.250.97.0/24 10052 0.4% AS35567 -- DASTO-BOSNIA-AS DASTO semtel d.o.o.,BA 4 - 192.58.232.0/24 9474 0.4% AS6629 -- NOAA-AS - NOAA,US 5 - 42.83.48.0/20 8658 0.3% AS18135 -- BTV BTV Cable television,JP 6 - 205.247.12.0/24 8005 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 7 - 120.28.62.0/24 7774 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 8 - 50.96.132.0/24 7570 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 9 - 115.170.128.0/17 7317 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange,CN 10 - 194.126.221.0/24 6899 0.3% AS34635 -- LIBERTY-AS Liberty Poland S.A.,PL 11 - 206.152.15.0/24 6814 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 12 - 222.127.0.0/24 6584 0.3% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms,PH 13 - 166.149.142.0/24 6103 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US AS8039 -- CCC-ASN-1 - Cinergy Communications,US 14 - 210.4.14.0/24 5618 0.2% AS38909 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 15 - 67.140.240.0/20 5242 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 16 - 67.141.226.0/24 5218 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 17 - 67.141.236.0/24 5211 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 18 - 71.28.104.0/21 4838 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 19 - 71.29.39.0/24 4835 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US 20 - 71.29.61.0/24 4834 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc,US Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From bedard.phil at gmail.com Fri Apr 25 22:12:50 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Fri, 25 Apr 2014 18:12:50 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: What are you trying to do? Why do you need the receive side to be tuned to a specific narrowband wavelength? Coherent doesn't really make sense in 10G becaue 10G long-haul is still on/off keyed and doesn't care about phase. Coherent detectors are needed where phase of the signal is important like long-haul 100G where multiple analog photonic signals are mixed on the transmit side. It also requires DSPs to process the received information. You aren't going to put a DSP inside a SFP+ cage. With CFP2/CFP4/QSFP28 the optics vendors would like people to start building the DSP onto line cards, whether it be a router or transport shelf, because there just isn't the packaging room to make it happen. Terastream today doesn't use integrated router optics, they use Cisco's nV-Optical solution. The connection between the router and transport shelf is still gray optics, but the system is managed as a single logical entity, with a 1:1 correlation between router port and transponder. You "tune" the wavelength on the router because of the 1:1 correlation. Terastream just uses passive DWDM muxes/demuxes, also part of the same Cisco transport solution, and Cisco VOAs/amps. -Phil On 4/25/14, 2:59 PM, "Tim Durack" wrote: >On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack wrote: > >> Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding >>no >> such thing.) >> >> How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter >> receive side might be doable?) >> >> -- >> Tim:> >> >> p.s. Before you ask, DTAG Terastream has got me thinking... >> > >As a follow up, there are lots of people willing to sell various flavours >of DWDM optics, but as I suspected, there is no such thing as a >coherent/tuned/filtered receive 10GigE DWDM optic. All 10GigE optics are >wide-band receive. However, you can get inline optical filters, Santec >OFM-15 for example. Investigating... > >-- >Tim:> From mehmet at akcin.net Fri Apr 25 22:23:07 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 25 Apr 2014 15:23:07 -0700 Subject: NANOG 61 Bellevue - DNS Track Message-ID: Hello everyone, As a Washington State resident, I look forward to seeing all of you in beautiful Bellevue, WA for NANOG 61. I am trying to organize the DNS Track and as usual we would like to make this very attractive. If you are interested in presenting in DNS Track please contact me directly (off-list ). Best regards Mehmet From tdurack at gmail.com Fri Apr 25 22:44:08 2014 From: tdurack at gmail.com (Tim Durack) Date: Fri, 25 Apr 2014 18:44:08 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: I'm trying to build "colorless" "directionless" with passive power couplers/splitters plus EDFA. DTAG are doing it with 100G. I think it's doable with 10G. Will see. Interesting experiment either way, right? (I'm betting DTAG would use integrated pluggables if they could. They don't appear to be fans of traditional systems.) On Friday, April 25, 2014, Phil Bedard wrote: > What are you trying to do? Why do you need the receive side to be tuned > to a specific narrowband wavelength? Coherent doesn't really make sense > in 10G becaue 10G long-haul is still on/off keyed and doesn't care about > phase. Coherent detectors are needed where phase of the signal is > important like long-haul 100G where multiple analog photonic signals are > mixed on the transmit side. It also requires DSPs to process the received > information. You aren't going to put a DSP inside a SFP+ cage. With > CFP2/CFP4/QSFP28 the optics vendors would like people to start building > the DSP onto line cards, whether it be a router or transport shelf, > because there just isn't the packaging room to make it happen. > > Terastream today doesn't use integrated router optics, they use Cisco's > nV-Optical solution. The connection between the router and transport shelf > is still gray optics, but the system is managed as a single logical > entity, with a 1:1 correlation between router port and transponder. You > "tune" the wavelength on the router because of the 1:1 correlation. > Terastream just uses passive DWDM muxes/demuxes, also part of the same > Cisco transport solution, and Cisco VOAs/amps. > > -Phil > > > > On 4/25/14, 2:59 PM, "Tim Durack" > > wrote: > > >On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack > > wrote: > > > >> Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding > >>no > >> such thing.) > >> > >> How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter > >> receive side might be doable?) > >> > >> -- > >> Tim:> > >> > >> p.s. Before you ask, DTAG Terastream has got me thinking... > >> > > > >As a follow up, there are lots of people willing to sell various flavours > >of DWDM optics, but as I suspected, there is no such thing as a > >coherent/tuned/filtered receive 10GigE DWDM optic. All 10GigE optics are > >wide-band receive. However, you can get inline optical filters, Santec > >OFM-15 for example. Investigating... > > > >-- > >Tim:> > > > -- Tim:> From LarrySheldon at cox.net Fri Apr 25 22:47:01 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 25 Apr 2014 17:47:01 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> Message-ID: <535AE5E5.7050108@cox.net> On 4/25/2014 8:23 AM, Patrick W. Gilmore wrote: > On Apr 25, 2014, at 00:57 , Larry Sheldon > wrote: > >> I just posted a completely empty message for which I apologize. >> >>> Larry is confused. He can claim he is not, but posting to NANOG >>> does not change the facts. Then again, just because I posted to >>> NANOG doesn't prove I'm right either. Worst of all, this thread >>> is pretty non-operational now. >> >> In a private message I asked if he could name a single monopoly >> that existed without regulation to protect its monopoly power. > > I answered in a private message: Microsoft. > > Kinda obvious if you think about it for, oh, say, 12 microseconds. "OK, so you are a troll. Microsoft is among the most heavily protected-by-regulation companies I can think of. Have you ever seen their patent collection? Can you guess at the size of their infringement-enforcement staff? Do you have any idea how many court-room hours are spent each day protecting their monopoly?" -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Fri Apr 25 23:08:06 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 25 Apr 2014 18:08:06 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> Message-ID: <535AEAD6.7040401@cox.net> On 4/25/2014 9:13 AM, Daniel Taylor wrote: > DeBeers Diamond cartel, which operated internationally and held an > effective monopoly on the diamond market for *decades* was apparently > beyond the reach of regulation to either assist or hinder them, and has > only recently faded somewhat in the face of competition that they can't > reach with their traditional protective tactics. It was governments that aided and abetted their enforcements in what would have been felonies for anybody else. > The Standard Oil monopoly was obtained without the special assistance of > government as well, though they were broken up by the government. The > methods they used should be mandatory study for everyone. Standard Oil was not a monopoly in every economist's mind. They were guilty of providing good products and services at reasonable prices. > The AT&T monopoly position *was* granted (and later revoked) by the > government. > Net neutrality is an intervention of the government to prevent monopoly > forming tactics on the part of major players, so I think it is something > worth having. It is not (unfortunately) something that is a natural > state for the Internet. Net neutrality is an intervention of the government to protect the monopoly tactics on the part of major players. With this, on the assumption that I will again be tossed off for "Off Topic discussions", I am out. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jimpop at gmail.com Fri Apr 25 23:09:00 2014 From: jimpop at gmail.com (Jim Popovitch) Date: Fri, 25 Apr 2014 19:09:00 -0400 Subject: Yahoo DMARC breakage In-Reply-To: References: <5345831B.4030705@dcrocker.net> <20140410030056.GB3886@dyn.com> <5354649E.9030903@dcrocker.net> <5355B1FC.70506@meetinghouse.net> Message-ID: On Fri, Apr 25, 2014 at 12:12 PM, Jim Popovitch wrote: > On Fri, Apr 25, 2014 at 12:00 PM, Jim Popovitch wrote: >> Just a heads up to interested parties... Google seems to now be >> bouncing where From: is another gmail account. But it seems to be >> inconsistent. If you are reading this on a gmail account please let >> me know. >> >> -Jim P. > > A few people have indicated to me that they are NOT seeing issues with > GMail. Just to be clear, what I am seeing a pattern of gmail users > sending email to mailinglists and every outbound email to other gmail > users logs this: > > Apr 24 18:19:20 svr5 postfix/smtp[32546]: BB2F73F2E3: > to=, > relay=gmail-smtp-in.l.google.com[74.125.201.109]:25, delay=27, > delays=0/27/0.44/0.06, dsn=5.5.1, status=bounced (host > gmail-smtp-in.l.google.com[74.125.201.109] said: 530-5.5.1 > Authentication Required. Learn more at 530 5.5.1 > http://support.google.com/mail/bin/answer.py?answer=14257 > hi8sm834730igb.8 - gsmtp (in reply to MAIL FROM command)) > > It's as though Gmail wants a mailinglist to authenticate to send email > to gmail recipients. :-) > > It's not persistent, it's just happened a few times in past 2 days, > generally in the AM. And it just happened again. Can someone from Google please tell me what to do when your inbound MX (port 25!) tells me to authenticate mailinglist traffic to your clients. Who's credentials should Mailman use? lol. Apr 25 22:22:23 svr5 postfix/smtp[1544]: 9CFA73F5BF: to=<*********@icaro.com.br>, relay=aspmx.l.google.com[74.125.201.109]:25, delay=167, delays=0/167/0.51/0.06, dsn=5.5.1, status=bounced (host aspmx.l.google.com[74.125.201.109] said: 530-5.5.1 Authentication Required. Learn more at 530 5.5.1 http://support.google.com/mail/bin/answer.py?answer=14257 m1sm33010igx.13 - gsmtp (in reply to MAIL FROM command)) -Jim P. From hslabbert at stargate.ca Fri Apr 25 23:16:11 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Fri, 25 Apr 2014 23:16:11 +0000 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535AEAD6.7040401@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <6FFC4911-E184-4620-B48C-7CFC2E89B22E@ianai.net> ,<535AEAD6.7040401@cox.net> Message-ID: <3397D91B-8043-4499-9DBB-08709C49E993@stargate.ca> > Net neutrality is an intervention of the government to protect the > monopoly tactics on the part of major players. I'm confused. Can you elaborate on how net neutrality would protect major players? Do you mean major content providers? Major broadband providers? -- Hugo > On Apr 25, 2014, at 16:08, "Larry Sheldon" wrote: > >> On 4/25/2014 9:13 AM, Daniel Taylor wrote: >> >> DeBeers Diamond cartel, which operated internationally and held an >> effective monopoly on the diamond market for *decades* was apparently >> beyond the reach of regulation to either assist or hinder them, and has >> only recently faded somewhat in the face of competition that they can't >> reach with their traditional protective tactics. > > It was governments that aided and abetted their enforcements in what > would have been felonies for anybody else. > >> The Standard Oil monopoly was obtained without the special assistance of >> government as well, though they were broken up by the government. The >> methods they used should be mandatory study for everyone. > > Standard Oil was not a monopoly in every economist's mind. They were > guilty of providing good products and services at reasonable prices. > >> The AT&T monopoly position *was* granted (and later revoked) by the >> government. > >> Net neutrality is an intervention of the government to prevent monopoly >> forming tactics on the part of major players, so I think it is something >> worth having. It is not (unfortunately) something that is a natural >> state for the Internet. > > Net neutrality is an intervention of the government to protect the > monopoly tactics on the part of major players. > > With this, on the assumption that I will again be tossed off for "Off > Topic discussions", I am out. > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From patrick at ianai.net Fri Apr 25 23:36:30 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 25 Apr 2014 19:36:30 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535AE5E5.7050108@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535AE5E5.7050108@cox.net> Message-ID: I'm afraid we will have to agree to disagree. If you think things like "patent enforcement" == "government protected monopoly", we are at an impasse. I guess having the police keep people from breaking into their offices and stealing their computers is another form of government medaling we would all be better off without? -- TTFN, patrick On Apr 25, 2014, at 18:47 , Larry Sheldon wrote: > On 4/25/2014 8:23 AM, Patrick W. Gilmore wrote: >> On Apr 25, 2014, at 00:57 , Larry Sheldon >> wrote: >> >>> I just posted a completely empty message for which I apologize. >>> >>>> Larry is confused. He can claim he is not, but posting to NANOG >>>> does not change the facts. Then again, just because I posted to >>>> NANOG doesn't prove I'm right either. Worst of all, this thread >>>> is pretty non-operational now. >>> >>> In a private message I asked if he could name a single monopoly >>> that existed without regulation to protect its monopoly power. >> >> I answered in a private message: Microsoft. >> >> Kinda obvious if you think about it for, oh, say, 12 microseconds. > > "OK, so you are a troll. > > Microsoft is among the most heavily protected-by-regulation companies I > can think of. > > Have you ever seen their patent collection? Can you guess at the size > of their infringement-enforcement staff? Do you have any idea how many > court-room hours are spent each day protecting their monopoly?" > > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From patrick at ianai.net Sat Apr 26 00:03:44 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 25 Apr 2014 20:03:44 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <201404252200.s3PM0041030660@wattle.apnic.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> Message-ID: <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> > 25-04-14 500177 282878 Half a million prefixes. 'Wow .. just wow.' There was a time when even I would have laughed at the thought of 500K. Just a "round number", but a milestone nonetheless. I checked, back in 2004, a little under 10 years ago, I posted this to NANOG: Patrick W Gilmore | 5 Nov 14:39 2004 On Nov 5, 2004, at 6:00 AM, cidr-report potaroo.net wrote: > Recent Table History > Date Prefixes CIDR Agg [...] > 05-11-04 156315 103781 Well, we broke 150K prefixes - and without someone deaggregating the classical B space. :) Impressive. Remember when the 'Net was supposed to have fallen over before now? Pat yourselves on the back everyone, you did the impossible. Congratulations are in order. I think congratulations are still in order, but frankly, I am less impressed with getting to 500 than 150. The equipment today just seems to be better able to handle it (even with the Sup720-pocolypse), which is a good thing given our possible de-aggregate future. Anyway, congratulations everyone. The Internet is such an important part of not just our lives, but literally the whole planet - every industry, every country, every economy, every, uh, everything. And as sappy as it sounds, it has made an immeasurable number of people's lives better. Hopefully people won't take this the wrong way: I am proud of all of you. Keep up the good work. -- TTFN, patrick On Apr 25, 2014, at 18:00 , cidr-report at potaroo.net wrote: > This report has been generated at Fri Apr 25 21:13:54 2014 AEST. > The report analyses the BGP Routing Table of AS2.0 router > and generates a report on aggregation potential within the table. > > Check http://www.cidr-report.org/2.0 for a current version of this report. > > Recent Table History > Date Prefixes CIDR Agg > 18-04-14 499254 282312 > 19-04-14 499492 282427 > 20-04-14 499557 282428 > 21-04-14 499371 282193 > 22-04-14 499156 282325 > 23-04-14 499260 282597 > 24-04-14 499642 282663 > 25-04-14 500177 282878 > > > AS Summary > 46910 Number of ASes in routing system > 19117 Number of ASes announcing only one prefix > 3731 Largest number of prefixes announced by an AS > AS28573: NET Servi?os de Comunica??o S.A.,BR > 119976960 Largest address span announced by an AS (/32s) > AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN > > > Aggregation Summary > The algorithm used in this report proposes aggregation only > when there is a precise match using the AS path, so as > to preserve traffic transit policies. Aggregation is also > proposed across non-advertised address space ('holes'). > > --- 25Apr14 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > > Table 500075 282843 217232 43.4% All ASes > > AS28573 3731 380 3351 89.8% NET Servi?os de Comunica??o > S.A.,BR > AS6389 2983 58 2925 98.1% BELLSOUTH-NET-BLK - > BellSouth.net Inc.,US > AS17974 2799 251 2548 91.0% TELKOMNET-AS2-AP PT > Telekomunikasi Indonesia,ID > AS4766 2953 931 2022 68.5% KIXS-AS-KR Korea Telecom,KR > AS18881 1932 37 1895 98.1% Global Village Telecom,BR > AS1785 2196 490 1706 77.7% AS-PAETEC-NET - PaeTec > Communications, Inc.,US > AS10620 2844 1349 1495 52.6% Telmex Colombia S.A.,CO > AS18566 2047 565 1482 72.4% MEGAPATH5-US - MegaPath > Corporation,US > AS36998 1634 161 1473 90.1% SDN-MOBITEL,SD > AS22773 3057 1587 1470 48.1% ASN-CXA-ALL-CCI-22773-RDC - > Cox Communications Inc.,US > AS4323 2937 1516 1421 48.4% TWTC - tw telecom holdings, > inc.,US > AS7303 1757 457 1300 74.0% Telecom Argentina S.A.,AR > AS4755 1850 583 1267 68.5% TATACOMM-AS TATA > Communications formerly VSNL > is Leading ISP,IN > AS7545 2228 1072 1156 51.9% TPG-INTERNET-AP TPG Telecom > Limited,AU > AS7552 1220 107 1113 91.2% VIETEL-AS-AP Viettel > Corporation,VN > AS22561 1301 241 1060 81.5% AS22561 - CenturyTel Internet > Holdings, Inc.,US > AS6983 1326 314 1012 76.3% ITCDELTA - Earthlink, Inc.,US > AS9829 1622 708 914 56.4% BSNL-NIB National Internet > Backbone,IN > AS24560 1126 295 831 73.8% AIRTELBROADBAND-AS-AP Bharti > Airtel Ltd., Telemedia > Services,IN > AS4808 1209 391 818 67.7% CHINA169-BJ CNCGROUP IP > network China169 Beijing > Province Network,CN > AS18101 945 187 758 80.2% RELIANCE-COMMUNICATIONS-IN > Reliance Communications > Ltd.DAKC MUMBAI,IN > AS8151 1407 656 751 53.4% Uninet S.A. de C.V.,MX > AS4788 1030 281 749 72.7% TMNET-AS-AP TM Net, Internet > Service Provider,MY > AS701 1482 751 731 49.3% UUNET - MCI Communications > Services, Inc. d/b/a Verizon > Business,US > AS7738 914 184 730 79.9% Telemar Norte Leste S.A.,BR > AS26615 843 113 730 86.6% Tim Celular S.A.,BR > AS855 756 57 699 92.5% CANET-ASN-4 - Bell Aliant > Regional Communications, > Inc.,CA > AS4780 1037 370 667 64.3% SEEDNET Digital United Inc.,TW > AS6147 780 113 667 85.5% Telefonica del Peru S.A.A.,PE > AS9808 996 330 666 66.9% CMNET-GD Guangdong Mobile > Communication Co.Ltd.,CN > > Total 52942 14535 38407 72.5% Top 30 total > > > Possible Bogus Routes > > 27.100.7.0/24 AS56096 > 41.73.1.0/24 AS37004 -Reserved AS-,ZZ > 41.73.2.0/24 AS37004 -Reserved AS-,ZZ > 41.73.10.0/24 AS37004 -Reserved AS-,ZZ > 41.73.11.0/24 AS37004 -Reserved AS-,ZZ > 41.73.12.0/24 AS37004 -Reserved AS-,ZZ > 41.73.13.0/24 AS37004 -Reserved AS-,ZZ > 41.73.14.0/24 AS37004 -Reserved AS-,ZZ > 41.73.15.0/24 AS37004 -Reserved AS-,ZZ > 41.73.16.0/24 AS37004 -Reserved AS-,ZZ > 41.73.18.0/24 AS37004 -Reserved AS-,ZZ > 41.73.20.0/24 AS37004 -Reserved AS-,ZZ > 41.73.21.0/24 AS37004 -Reserved AS-,ZZ > 41.76.48.0/21 AS36969 MTL-AS,MW > 41.78.120.0/23 AS22351 INTELSAT-1 - INTELSAT GLOBAL SERVICE CORPORATION,US > 41.78.236.0/24 AS37290 -Reserved AS-,ZZ > 41.78.237.0/24 AS37290 -Reserved AS-,ZZ > 41.78.238.0/24 AS37290 -Reserved AS-,ZZ > 41.78.239.0/24 AS37290 -Reserved AS-,ZZ > 41.190.72.0/24 AS37451 CongoTelecom,CG > 41.190.73.0/24 AS37451 CongoTelecom,CG > 41.190.74.0/24 AS37451 CongoTelecom,CG > 41.190.75.0/24 AS37451 CongoTelecom,CG > 41.191.108.0/22 AS37004 -Reserved AS-,ZZ > 41.191.108.0/24 AS37004 -Reserved AS-,ZZ > 41.191.109.0/24 AS37004 -Reserved AS-,ZZ > 41.191.110.0/24 AS37004 -Reserved AS-,ZZ > 41.191.111.0/24 AS37004 -Reserved AS-,ZZ > 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV,NL > 63.247.0.0/19 AS226 LOS-NETTOS-AS - Los Nettos,US > 63.247.0.0/24 AS27609 -Reserved AS-,ZZ > 63.247.1.0/24 AS27609 -Reserved AS-,ZZ > 63.247.2.0/24 AS27609 -Reserved AS-,ZZ > 63.247.3.0/24 AS27609 -Reserved AS-,ZZ > 63.247.4.0/24 AS27609 -Reserved AS-,ZZ > 63.247.5.0/24 AS27609 -Reserved AS-,ZZ > 63.247.6.0/24 AS27609 -Reserved AS-,ZZ > 63.247.7.0/24 AS27609 -Reserved AS-,ZZ > 63.247.8.0/24 AS27609 -Reserved AS-,ZZ > 63.247.9.0/24 AS27609 -Reserved AS-,ZZ > 63.247.10.0/24 AS27609 -Reserved AS-,ZZ > 63.247.11.0/24 AS27609 -Reserved AS-,ZZ > 63.247.13.0/24 AS27609 -Reserved AS-,ZZ > 63.247.14.0/24 AS27609 -Reserved AS-,ZZ > 63.247.15.0/24 AS27609 -Reserved AS-,ZZ > 63.247.16.0/24 AS27609 -Reserved AS-,ZZ > 63.247.17.0/24 AS27609 -Reserved AS-,ZZ > 63.247.18.0/24 AS27609 -Reserved AS-,ZZ > 63.247.19.0/24 AS27609 -Reserved AS-,ZZ > 63.247.20.0/24 AS27609 -Reserved AS-,ZZ > 63.247.21.0/24 AS27609 -Reserved AS-,ZZ > 63.247.22.0/24 AS27609 -Reserved AS-,ZZ > 63.247.23.0/24 AS27609 -Reserved AS-,ZZ > 63.247.24.0/24 AS27609 -Reserved AS-,ZZ > 63.247.25.0/24 AS27609 -Reserved AS-,ZZ > 63.247.26.0/24 AS27609 -Reserved AS-,ZZ > 63.247.27.0/24 AS27609 -Reserved AS-,ZZ > 63.247.28.0/24 AS27609 -Reserved AS-,ZZ > 63.247.29.0/24 AS27609 -Reserved AS-,ZZ > 64.25.16.0/23 AS19535 -Reserved AS-,ZZ > 64.25.20.0/24 AS19535 -Reserved AS-,ZZ > 64.25.21.0/24 AS19535 -Reserved AS-,ZZ > 64.25.22.0/24 AS19535 -Reserved AS-,ZZ > 64.25.27.0/24 AS7046 RFC2270-UUNET-CUSTOMER - MCI Communications Services, Inc. d/b/a Verizon Business,US > 64.111.160.0/20 AS40551 -Reserved AS-,ZZ > 64.111.160.0/24 AS40551 -Reserved AS-,ZZ > 64.111.161.0/24 AS40551 -Reserved AS-,ZZ > 64.111.162.0/24 AS40551 -Reserved AS-,ZZ > 64.111.167.0/24 AS40551 -Reserved AS-,ZZ > 64.111.169.0/24 AS40551 -Reserved AS-,ZZ > 64.111.170.0/24 AS40551 -Reserved AS-,ZZ > 64.111.171.0/24 AS40551 -Reserved AS-,ZZ > 64.111.172.0/24 AS40551 -Reserved AS-,ZZ > 64.111.173.0/24 AS40551 -Reserved AS-,ZZ > 64.111.174.0/24 AS40551 -Reserved AS-,ZZ > 64.111.175.0/24 AS40551 -Reserved AS-,ZZ > 64.119.240.0/22 AS26072 -Reserved AS-,ZZ > 64.119.240.0/23 AS26072 -Reserved AS-,ZZ > 64.119.242.0/23 AS26072 -Reserved AS-,ZZ > 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 65.75.216.0/23 AS10494 AAI - Accurate Automation, Inc.,US > 65.75.217.0/24 AS10494 AAI - Accurate Automation, Inc.,US > 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global,US > 66.55.96.0/23 AS17203 -Reserved AS-,ZZ > 66.55.98.0/24 AS17203 -Reserved AS-,ZZ > 66.55.99.0/24 AS17203 -Reserved AS-,ZZ > 66.55.100.0/22 AS17203 -Reserved AS-,ZZ > 66.55.102.0/23 AS17203 -Reserved AS-,ZZ > 66.55.104.0/21 AS17203 -Reserved AS-,ZZ > 66.180.64.0/21 AS32558 ZEUTER - Zeuter Development Corporation,CA > 66.187.240.0/20 AS14552 ACS-SOUTHEASTDATACENTER - Affiliated Computer Services, Inc.,US > 66.205.224.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks,US > 66.254.188.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 67.21.144.0/22 AS174 COGENT-174 - Cogent Communications,US > 67.21.148.0/22 AS174 COGENT-174 - Cogent Communications,US > 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.,IT > 72.19.0.0/19 AS16526 BIRCH-TELECOM - Birch Telecom, Inc.,US > 74.112.100.0/22 AS16764 -Reserved AS-,ZZ > 74.113.200.0/23 AS46939 -Reserved AS-,ZZ > 74.114.52.0/22 AS40818 -Reserved AS-,ZZ > 74.114.52.0/23 AS40818 -Reserved AS-,ZZ > 74.114.52.0/24 AS40818 -Reserved AS-,ZZ > 74.114.53.0/24 AS40818 -Reserved AS-,ZZ > 74.114.54.0/23 AS40818 -Reserved AS-,ZZ > 74.114.54.0/24 AS40818 -Reserved AS-,ZZ > 74.114.55.0/24 AS40818 -Reserved AS-,ZZ > 74.115.124.0/23 AS46540 -Reserved AS-,ZZ > 74.118.132.0/22 AS5117 -Reserved AS-,ZZ > 74.119.236.0/23 AS26368 -Reserved AS-,ZZ > 74.119.239.0/24 AS26368 -Reserved AS-,ZZ > 74.121.24.0/22 AS36263 FORONA - Forona Technologies, Inc.,US > 77.243.80.0/24 AS42597 -Reserved AS-,ZZ > 77.243.81.0/24 AS42597 -Reserved AS-,ZZ > 77.243.88.0/24 AS42597 -Reserved AS-,ZZ > 77.243.91.0/24 AS42597 -Reserved AS-,ZZ > 77.243.94.0/24 AS42597 -Reserved AS-,ZZ > 77.243.95.0/24 AS42597 -Reserved AS-,ZZ > 80.250.32.0/22 AS37106 ODUA-AS,NG > 85.202.160.0/20 AS44404 -Reserved AS-,ZZ > 91.193.60.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.195.66.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 91.197.36.0/22 AS43359 -Reserved AS-,ZZ > 91.199.90.0/24 AS44330 -Reserved AS-,ZZ > 91.199.185.0/24 AS29076 CITYTELECOM-AS Filanco LTD,RU > 91.209.115.0/24 AS31103 KEYWEB-AS Keyweb AG,DE > 91.214.65.0/24 AS30822 MAGEAL-AS Private Enterprise Mageal,LT > 91.229.182.0/24 AS56960 -Reserved AS-,ZZ > 91.229.186.0/24 AS56967 -Reserved AS-,ZZ > 91.239.157.0/24 AS24958 TBSH The Bunker Secure Hosting Limited,GB > 91.245.224.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.232.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.240.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 91.245.248.0/21 AS39906 COPROSYS CoProSys a.s.,CZ > 93.190.10.0/24 AS47254 -Reserved AS-,ZZ > 95.215.140.0/22 AS48949 -Reserved AS-,ZZ > 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. ,AU > 103.17.108.0/23 AS56301 MN-NDC-MN National Data Center building,MN > 103.31.236.0/22 AS17941 BIT-ISLE Bit-isle Co.,Ltd.,JP > 103.244.236.0/22 AS58794 > 103.247.52.0/23 AS4725 ODN SOFTBANK TELECOM Corp.,JP > 110.76.128.0/22 AS13308 ENPL-PROD-AS-AP eintellego Networks Pty Ltd,AU > 110.232.188.0/22 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK > 116.206.72.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.85.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 116.206.103.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP,IN > 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street,CN > 124.64.0.0/10 AS4847 CNIX-AP China Networks Inter-Exchange,CN > 162.247.180.0/22 AS23175 POGOZONE - PogoZone,US > 163.47.23.0/24 AS2907 SINET-AS Research Organization of Information and Systems, National Institute of Informatics,JP > 166.93.0.0/16 AS23537 CRITIGEN - Micro Source, Inc.,US > 172.85.0.0/24 AS29571 CITelecom-AS,CI > 172.85.1.0/24 AS29571 CITelecom-AS,CI > 172.85.2.0/24 AS29571 CITelecom-AS,CI > 172.85.3.0/24 AS29571 CITelecom-AS,CI > 172.86.0.0/24 AS29571 CITelecom-AS,CI > 172.86.1.0/24 AS29571 CITelecom-AS,CI > 172.86.2.0/24 AS29571 CITelecom-AS,CI > 172.87.0.0/24 AS29571 CITelecom-AS,CI > 172.88.0.0/24 AS29571 CITelecom-AS,CI > 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group),CN > 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 176.111.168.0/22 AS50586 MACROSOLUTIONS MacroSolution SRL,RO > 176.124.32.0/19 AS39906 COPROSYS CoProSys a.s.,CZ > 185.55.100.0/22 AS12843 TELEMAXX TelemaxX Telekommunikation GmbH,DE > 185.55.120.0/22 AS21385 TNIB Trusted Network GmbH,DE > 185.55.124.0/22 AS8365 MANDA Man-da.de GmbH,DE > 185.55.128.0/22 AS12573 WIDEXS WideXS B.V.,NL > 190.3.160.0/21 AS27975 SYNAPSIS COLOMBIA SAS,CO > 190.107.238.0/24 AS27765 TRANSNEXA S.A. E.M.A.,EC > 190.124.252.0/22 AS7303 Telecom Argentina S.A.,AR > 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc,US > 192.25.10.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.11.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.13.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.25.14.0/24 AS5714 HPES - Hewlett-Packard Company,US > 192.75.23.0/24 AS2579 -Reserved AS-,ZZ > 192.75.239.0/24 AS23498 CDSI - Cogeco Data Services LP,CA > 192.84.24.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.101.72.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.104.61.0/24 AS1785 AS-PAETEC-NET - PaeTec Communications, Inc.,US > 192.124.252.0/22 AS680 DFN Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.,DE > 192.131.233.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 192.149.81.0/24 AS14454 PERIMETER-ESECURITY - Perimeter eSecurity,US > 192.154.32.0/19 AS81 NCREN - MCNC,US > 192.154.64.0/19 AS81 NCREN - MCNC,US > 192.166.32.0/20 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 192.241.20.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.241.21.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.245.195.0/24 AS7381 SUNGARDRS - SunGard Availability Services LP,US > 192.252.252.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc.,US > 193.9.59.0/24 AS1257 TELE2,SE > 193.16.106.0/24 AS31539 -Reserved AS-,ZZ > 193.16.145.0/24 AS31392 -Reserved AS-,ZZ > 193.22.86.0/24 AS24751 MULTIFI-AS Jakobstadsnejdens Telefon Ab,FI > 193.22.224.0/20 AS3322 -Reserved AS-,ZZ > 193.22.238.0/23 AS62383 LDS-AS Lambrechts Data Services VOF,BE > 193.26.213.0/24 AS31641 BYTEL-AS Bytel Ltd,GB > 193.28.14.0/24 AS34309 LINK11 Link11 GmbH,DE > 193.33.6.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.33.252.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.46.200.0/24 AS34243 WEBAGE Web Age Ltd,GB > 193.84.187.0/24 AS16276 OVH OVH SAS,FR > 193.93.6.0/23 AS35559 SOMEADDRESS Someaddress Networks Ltd,GB > 193.109.217.0/24 AS13069 DATAGUARD DataGuard AS,NO > 193.111.229.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.149.2.0/23 AS15919 INTERHOST Servicios de Hosting en Internet S.A.,ES > 193.160.16.0/22 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.161.157.0/24 AS2116 ASN-CATCHCOM Broadnet AS,NO > 193.164.152.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.178.196.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 193.186.193.0/24 AS158 ERI-AS - Ericsson Network Systems, Inc.,US > 193.186.199.0/24 AS8437 UTA-AS Tele2 Telecommunication GmbH,AT > 193.188.252.0/24 AS8697 JTC-AS8697 Jordan Telecommunications Company,JO > 193.200.244.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.201.244.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.245.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.201.246.0/24 AS702 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 193.202.8.0/21 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.202.9.0/24 AS6824 HERMES-NETWORK Hermes Telecom International Ltd,GB > 193.223.103.0/24 AS3248 SIL-AT Tele2 Telecommunication GmbH,AT > 193.227.109.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.227.236.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 193.243.166.0/24 AS44093 -Reserved AS-,ZZ > 194.0.116.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.0.117.0/24 AS21437 AVITI-AS Aviti ltd.,UA > 194.6.252.0/24 AS21202 DCSNET-AS Bredband2 AB,SE > 194.9.8.0/23 AS2863 SPRITELINK Centor AB,SE > 194.9.8.0/24 AS2863 SPRITELINK Centor AB,SE > 194.33.11.0/24 AS8943 JUMP Jump Networks Ltd.,GB > 194.49.17.0/24 AS13135 CREW-AS Wieske's Crew GmbH,DE > 194.60.88.0/21 AS5089 NTL Virgin Media Limited,GB > 194.63.152.0/22 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.79.36.0/22 AS3257 TINET-BACKBONE Tinet SpA,DE > 194.88.6.0/24 AS35093 RO-HTPASSPORT HighTech Passport Ltd SUA California San Jose SUCURSALA BUCURESTI ROMANIA,RO > 194.88.226.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.99.67.0/24 AS9083 CARPENET carpeNet Information Technologies GmbH,DE > 194.113.27.0/24 AS12518 SHLINK SHLINK Internet Service,DE > 194.126.152.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 194.126.219.0/24 AS34545 -Reserved AS-,ZZ > 194.126.233.0/24 AS31235 SKIWEBCENTER-AS SKIWEBCENTER SARL,FR > 194.150.214.0/23 AS30880 SPACEDUMP-AS SpaceDump IT AB,SE > 194.156.179.0/24 AS3209 VODANET Vodafone GmbH,DE > 194.165.26.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU > 194.165.27.0/24 AS47381 DOCLERWEB-AS DoclerWeb Kft.,HU > 194.180.25.0/24 AS21358 ATOS-ORIGIN-DE-AS Atos Information Technology GmbH,DE > 194.187.24.0/22 AS8856 UKRNET UkrNet Ltd,UA > 194.213.8.0/24 AS42845 BRETAGNETELECOM BRETAGNE TELECOM SAS,FR > 195.8.48.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.48.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.8.119.0/24 AS34304 TEENTELECOM Teen Telecom SRL,RO > 195.39.252.0/23 AS29004 -Reserved AS-,ZZ > 195.42.232.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH,DE > 195.47.242.0/24 AS9050 RTD ROMTELECOM S.A,RO > 195.85.194.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.85.201.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.90.98.0/23 AS57511 OVALTECH-AS OvalTech Internet Ltd,GB > 195.110.0.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.114.14.0/23 AS31554 ALTFEL SC Almsoft Computers SRL,RO > 195.128.240.0/23 AS21202 DCSNET-AS Bredband2 AB,SE > 195.149.119.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.189.174.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.216.234.0/24 AS31309 NMV-AS New Media Ventures BVBA,BE > 195.234.156.0/24 AS25028 -Reserved AS-,ZZ > 195.242.182.0/24 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 195.244.18.0/23 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 196.2.224.0/22 AS24863 LINKdotNET-AS,EG > 196.3.182.0/24 AS37004 -Reserved AS-,ZZ > 196.3.183.0/24 AS37004 -Reserved AS-,ZZ > 196.13.201.0/24 AS2018 TENET-1,ZA > 196.13.202.0/24 AS2018 TENET-1,ZA > 196.13.203.0/24 AS2018 TENET-1,ZA > 196.13.204.0/24 AS2018 TENET-1,ZA > 196.22.8.0/24 AS27822 Emerging Markets Communications de Argentina S.R.L,AR > 196.22.11.0/24 AS16422 NEWSKIES-NETWORKS - New Skies Satellites, Inc.,US > 196.45.0.0/21 AS26625 -Reserved AS-,ZZ > 196.45.10.0/24 AS26625 -Reserved AS-,ZZ > 196.216.129.0/24 AS36886 -Reserved AS-,ZZ > 196.216.130.0/24 AS36886 -Reserved AS-,ZZ > 196.216.131.0/24 AS36886 -Reserved AS-,ZZ > 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc.,US > 198.72.78.0/23 AS3967 -Reserved AS-,ZZ > 198.74.11.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.13.0/24 AS14573 KEYSPANENERGY-NE1 - Keyspan Energy,US > 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services,US > 198.97.72.0/21 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.192.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 198.161.239.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited,CA > 198.163.215.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.163.216.0/24 AS6327 SHAW - Shaw Communications Inc.,CA > 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 198.176.208.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US > 198.176.209.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US > 198.176.210.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US > 198.176.211.0/24 AS4318 FMI-NET-AS - Freeport McMoRan Copper & Gold Inc.,US > 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services,HK > 198.252.165.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.166.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.167.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.168.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 198.252.169.0/24 AS20115 CHARTER-NET-HKY-NC - Charter Communications,US > 199.30.138.0/24 AS23319 -Reserved AS-,ZZ > 199.30.139.0/24 AS23319 -Reserved AS-,ZZ > 199.30.143.0/24 AS8100 IPTELLIGENT - IPTelligent LLC,US > 199.68.72.0/24 AS174 COGENT-174 - Cogent Communications,US > 199.85.9.0/24 AS852 ASN852 - TELUS Communications Inc.,CA > 199.87.166.0/24 AS26368 -Reserved AS-,ZZ > 199.87.167.0/24 AS26368 -Reserved AS-,ZZ > 199.88.52.0/22 AS17018 QTS-SACRAMENTO-1 - Quality Investment Properties Sacramento, LLC,US > 199.91.240.0/21 AS174 COGENT-174 - Cogent Communications,US > 199.102.73.0/24 AS26368 -Reserved AS-,ZZ > 199.116.200.0/21 AS22830 -Reserved AS-,ZZ > 199.120.150.0/24 AS30036 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp,US > 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center,US > 200.1.112.0/24 AS29754 GO2TEL - GO2TEL.COM INC.,US > 200.58.248.0/21 AS27849 > 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.,KR > 202.53.138.0/24 AS4058 CITICTEL-CPC-AS4058 CITIC Telecom International CPC Limited,HK > 202.58.113.0/24 AS19161 -Reserved AS-,ZZ > 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network,CN > 202.158.251.0/24 AS9255 CONNECTPLUS-AS Singapore Telecom,SG > 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.,IN > 203.142.219.0/24 AS45149 > 203.189.116.0/22 AS45606 > 203.189.116.0/24 AS45606 > 203.189.117.0/24 AS45606 > 203.189.118.0/24 AS45606 > 203.189.119.0/24 AS45606 > 203.191.56.0/21 AS38042 INCOMNET-MONGOLIA-AS-AP Incomnet LLC, Mongolia, VSAT and Wireless service,MN > 204.10.88.0/21 AS3356 LEVEL3 - Level 3 Communications, Inc.,US > 204.10.94.0/23 AS30097 NUWAVE - NuWave,US > 204.15.208.0/22 AS13706 COMPLETEWEBNET - CompleteWeb.Net LLC,US > 204.16.96.0/24 AS19972 -Reserved AS-,ZZ > 204.16.97.0/24 AS19972 -Reserved AS-,ZZ > 204.16.98.0/24 AS19972 -Reserved AS-,ZZ > 204.16.99.0/24 AS19972 -Reserved AS-,ZZ > 204.69.144.0/24 AS27283 RJF-INTERNET - Raymond James Financial, Inc.,US > 204.106.16.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 204.187.11.0/24 AS51113 ELEKTA-AS Elekta,GB > 204.225.173.0/24 AS6407 PRIMUS-AS6407 - Primus Telecommunications Canada Inc.,CA > 205.159.44.0/24 AS40157 ADESA-CORP-AS - ADESA Corp,US > 205.207.66.0/24 AS15290 ALLST-15290 - Allstream Corp.,CA > 205.211.160.0/24 AS30045 UHN-ASN - University Health Network,CA > 206.81.112.0/20 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company,US > 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 207.2.120.0/21 AS6221 USCYBERSITES - US Cybersites, Inc,US > 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc,US > 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc,US > 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.,US > 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.,US > 207.254.128.0/21 AS30689 FLOW-NET - FLOW,JM > 207.254.128.0/24 AS30689 FLOW-NET - FLOW,JM > 207.254.136.0/21 AS30689 FLOW-NET - FLOW,JM > 208.67.132.0/22 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business,US > 208.68.180.0/22 AS4323 TWTC - tw telecom holdings, inc.,US > 208.69.192.0/23 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.69.195.0/24 AS6461 ABOVENET - Abovenet Communications, Inc,US > 208.74.224.0/22 AS174 COGENT-174 - Cogent Communications,US > 208.75.152.0/21 AS32146 -Reserved AS-,ZZ > 208.76.20.0/24 AS31812 -Reserved AS-,ZZ > 208.76.21.0/24 AS31812 -Reserved AS-,ZZ > 208.77.164.0/24 AS22659 -Reserved AS-,ZZ > 208.77.166.0/24 AS4323 TWTC - tw telecom holdings, inc.,US > 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC,US > 208.84.232.0/24 AS33131 -Reserved AS-,ZZ > 208.84.234.0/24 AS33131 -Reserved AS-,ZZ > 208.84.237.0/24 AS33131 -Reserved AS-,ZZ > 208.84.238.0/24 AS33131 -Reserved AS-,ZZ > 208.85.116.0/23 AS25956 ALPHEUS - Alpheus Data Services, L.L.C.,US > 208.85.212.0/22 AS32618 ADKNO-KC - Adknowledge, Inc.,US > 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc.,US > 209.177.64.0/20 AS6461 ABOVENET - Abovenet Communications, Inc,US > 209.193.112.0/20 AS209 ASN-QWEST - Qwest Communications Company, LLC,US > 209.209.51.0/24 AS18687 MPOWER-2 - MPOWER COMMUNICATIONS CORP.,US > 209.212.63.0/24 AS16467 ASN-NEXTWEB-R1 - Nextweb, Inc,US > 209.234.112.0/23 AS32252 -Reserved AS-,ZZ > 209.234.114.0/23 AS32252 -Reserved AS-,ZZ > 209.234.116.0/24 AS32252 -Reserved AS-,ZZ > 209.234.117.0/24 AS32252 -Reserved AS-,ZZ > 209.234.118.0/24 AS32252 -Reserved AS-,ZZ > 209.234.119.0/24 AS32252 -Reserved AS-,ZZ > 209.234.120.0/24 AS32252 -Reserved AS-,ZZ > 209.234.121.0/24 AS32252 -Reserved AS-,ZZ > 209.234.122.0/24 AS32252 -Reserved AS-,ZZ > 212.119.32.0/19 AS12550 -Reserved AS-,ZZ > 213.184.64.0/24 AS13071 -Reserved AS-,ZZ > 213.184.65.0/24 AS13071 -Reserved AS-,ZZ > 213.184.66.0/24 AS13071 -Reserved AS-,ZZ > 213.184.67.0/24 AS13071 -Reserved AS-,ZZ > 213.184.68.0/24 AS13071 -Reserved AS-,ZZ > 213.184.69.0/24 AS13071 -Reserved AS-,ZZ > 213.184.70.0/24 AS13071 -Reserved AS-,ZZ > 213.184.71.0/24 AS13071 -Reserved AS-,ZZ > 213.184.72.0/24 AS13071 -Reserved AS-,ZZ > 213.184.73.0/24 AS13071 -Reserved AS-,ZZ > 213.184.74.0/24 AS13071 -Reserved AS-,ZZ > 213.184.75.0/24 AS13071 -Reserved AS-,ZZ > 213.184.76.0/24 AS13071 -Reserved AS-,ZZ > 213.184.77.0/24 AS13071 -Reserved AS-,ZZ > 213.184.78.0/24 AS13071 -Reserved AS-,ZZ > 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc.,US > 216.24.176.0/20 AS19401 -Reserved AS-,ZZ > 216.24.188.0/24 AS19401 -Reserved AS-,ZZ > 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC,US > 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.,US > 216.170.96.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.101.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.104.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.170.105.0/24 AS4565 MEGAPATH2-US - MegaPath Networks Inc.,US > 216.203.80.0/20 AS27021 -Reserved AS-,ZZ > 216.203.80.0/21 AS27021 -Reserved AS-,ZZ > 216.203.87.0/24 AS27021 -Reserved AS-,ZZ > 216.203.88.0/21 AS27021 -Reserved AS-,ZZ > 216.203.95.0/24 AS53490 MEDPLUS - MedPlus, Inc.,US > 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC.,US > > > Please see http://www.cidr-report.org for the full report > > ------------------------------------ > Copies of this report are mailed to: > nanog at nanog.org > eof-list at ripe.net > apops at apops.net > routing-wg at ripe.net > afnog at afnog.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mfidelman at meetinghouse.net Sat Apr 26 03:16:58 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 25 Apr 2014 23:16:58 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535AE5E5.7050108@cox.net> Message-ID: <535B252A.2060703@meetinghouse.net> Patrick W. Gilmore wrote: > I'm afraid we will have to agree to disagree. If you think things like "patent enforcement" == "government protected monopoly", we are at an impasse. > Well, leaving aside what one thinks of patents and copyrights - a "government protected monopoly" is EXACTLY what a patent is, by definition: "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;" Or do you have some different definition of "exclusive Right?" But we digress. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From swmike at swm.pp.se Sat Apr 26 04:00:03 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 26 Apr 2014 06:00:03 +0200 (CEST) Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: On Fri, 25 Apr 2014, Phil Bedard wrote: > What are you trying to do? Why do you need the receive side to be tuned > to a specific narrowband wavelength? Because he doesn't want to use filters. A coherent receiver s like a FM radio, you can tune what it listens so. So if you send it all waves the receiver can decide what to listen to. > Coherent doesn't really make sense in 10G becaue 10G long-haul is still > on/off keyed and doesn't care about phase. Coherent detectors are needed > where phase of the signal is important like long-haul 100G where > multiple analog photonic signals are mixed on the transmit side. It > also requires DSPs to process the received information. You aren't going > to put a DSP inside a SFP+ cage. With CFP2/CFP4/QSFP28 the optics > vendors would like people to start building the DSP onto line cards, > whether it be a router or transport shelf, because there just isn't the > packaging room to make it happen. If you're today building a new DWDM system, putting in dispersion compensation isn't something you want to do really. Having pluggable coherent 10G would make a lot of sense for some. > Terastream today doesn't use integrated router optics, they use Cisco's > nV-Optical solution. The connection between the router and transport > shelf is still gray optics, but the system is managed as a single > logical entity, with a 1:1 correlation between router port and > transponder. You "tune" the wavelength on the router because of the 1:1 > correlation. Terastream just uses passive DWDM muxes/demuxes, also part > of the same Cisco transport solution, and Cisco VOAs/amps. That is correct, but the plan is to have integrated optics. It just isn't available yet. The plan is to make 100G so cheap you can use it everywhere, which includes actually having a royalty free standard for 100G including FEC. Ask your router vendor to support http://www.stupi.se/Standards/ -- Mikael Abrahamsson email: swmike at swm.pp.se From eric.oosting at gmail.com Sat Apr 26 04:03:55 2014 From: eric.oosting at gmail.com (Eric Oosting) Date: Sat, 26 Apr 2014 00:03:55 -0400 Subject: NANOG Mail Server Maintenance In-Reply-To: <1572796038.653231.1397926518720.JavaMail.zimbra@merit.edu> References: <113813365.653074.1397925450270.JavaMail.zimbra@merit.edu> <1572796038.653231.1397926518720.JavaMail.zimbra@merit.edu> Message-ID: As a reminder, this work will begin in approximately 6 hours. -e On Sat, Apr 19, 2014 at 12:55 PM, Larry J. Blunk wrote: > > Greetings, > The NANOG Mail server will be transitioning to a > new system next Saturday, April 26th. The maintenance > window for this transition will be from > 10:00 - 10:30 UTC. This will impact the main NANOG > list and associated lists hosted on mailman.nanog.org. > The addresses for the server will be changing, but they > will remain within the same prefixes (50.31.151.64/28 > and 2001:1838:2001:8::/64). > > Regards, > Larry Blunk > NANOG Communications Committee > > From nanog at studio442.com.au Sat Apr 26 04:52:34 2014 From: nanog at studio442.com.au (Julien Goodwin) Date: Sat, 26 Apr 2014 14:52:34 +1000 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: Message-ID: <535B3B92.7040106@studio442.com.au> On 26/04/14 14:00, Mikael Abrahamsson wrote: > On Fri, 25 Apr 2014, Phil Bedard wrote: > >> What are you trying to do? Why do you need the receive side to be tuned >> to a specific narrowband wavelength? > > Because he doesn't want to use filters. A coherent receiver s like a FM > radio, you can tune what it listens so. So if you send it all waves the > receiver can decide what to listen to. But you'd never send it all the waves anyway, that's far too much loss across the band. ROADMs already solve this problem, and are available at the module level (how practically available and usable I've no idea, never needed to try). From swmike at swm.pp.se Sat Apr 26 06:02:12 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 26 Apr 2014 08:02:12 +0200 (CEST) Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: <535B3B92.7040106@studio442.com.au> References: <535B3B92.7040106@studio442.com.au> Message-ID: On Sat, 26 Apr 2014, Julien Goodwin wrote: > But you'd never send it all the waves anyway, that's far too much loss > across the band. Please elaborate. > ROADMs already solve this problem, and are available at the module level > (how practically available and usable I've no idea, never needed to try). Compare the price of a ROADM and a 50%/50% light splitter. Which one do you think is the cheapest and also operationally most reliable? -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at studio442.com.au Sat Apr 26 06:09:22 2014 From: nanog at studio442.com.au (Julien Goodwin) Date: Sat, 26 Apr 2014 16:09:22 +1000 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: <535B3B92.7040106@studio442.com.au> Message-ID: <535B4D92.2020703@studio442.com.au> On 26/04/14 16:02, Mikael Abrahamsson wrote: > On Sat, 26 Apr 2014, Julien Goodwin wrote: > >> But you'd never send it all the waves anyway, that's far too much loss >> across the band. > > Please elaborate. At 3dB loss per split you'd very quickly need additional amplification, at which point the ROADM is cheaper. A static split can do the 80 waves in much less than the ~20dB a power split would need, and > >> ROADMs already solve this problem, and are available at the module level >> (how practically available and usable I've no idea, never needed to try). > > Compare the price of a ROADM and a 50%/50% light splitter. Which one do > you think is the cheapest and also operationally most reliable? Not disagreeing, I'd go with dumb static optics, nearly all the "reconfigurable" optic selling points don't seem to translate into actual operational benefits. From ljb at merit.edu Sat Apr 26 05:29:53 2014 From: ljb at merit.edu (Larry J. Blunk) Date: Sat, 26 Apr 2014 06:29:53 -0400 (EDT) Subject: NANOG Mail Server Maintenance In-Reply-To: <1044153321.304142.1398508153043.JavaMail.zimbra@merit.edu> Message-ID: <2009473315.304150.1398508193414.JavaMail.zimbra@merit.edu> Greetings, NANOG Mail Server Maintenance is now complete. Regards, Larry Blunk NANOG Communications Committee From tdurack at gmail.com Sat Apr 26 06:17:15 2014 From: tdurack at gmail.com (Tim Durack) Date: Sat, 26 Apr 2014 07:17:15 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: <535B4D92.2020703@studio442.com.au> References: <535B3B92.7040106@studio442.com.au> <535B4D92.2020703@studio442.com.au> Message-ID: Will need amplification anyway for almost any realistic topology. For those who don't understand what or why, please read the Terastream PDF and watch the video several times, then tell me it's not a great idea :-) On Saturday, April 26, 2014, Julien Goodwin wrote: > On 26/04/14 16:02, Mikael Abrahamsson wrote: > > On Sat, 26 Apr 2014, Julien Goodwin wrote: > > > >> But you'd never send it all the waves anyway, that's far too much loss > >> across the band. > > > > Please elaborate. > > At 3dB loss per split you'd very quickly need additional amplification, > at which point the ROADM is cheaper. A static split can do the 80 waves > in much less than the ~20dB a power split would need, and > > > > >> ROADMs already solve this problem, and are available at the module level > >> (how practically available and usable I've no idea, never needed to > try). > > > > Compare the price of a ROADM and a 50%/50% light splitter. Which one do > > you think is the cheapest and also operationally most reliable? > > Not disagreeing, I'd go with dumb static optics, nearly all the > "reconfigurable" optic selling points don't seem to translate into > actual operational benefits. > > -- Tim:> From bedard.phil at gmail.com Sat Apr 26 16:07:33 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sat, 26 Apr 2014 12:07:33 -0400 Subject: Pluggable Coherent DWDM 10Gig In-Reply-To: References: <535B3B92.7040106@studio442.com.au> <535B4D92.2020703@studio442.com.au> Message-ID: I'm a big fan of the Terastream setup and have done a lot of research into it, it makes sense if the density and bandwidth needs are fairly low and the distances not so great. Terastream also makes use of a LOT of raw fiber which most do not really have access to. Right now only one router vendor supports 100G DWDM. We will soon see DWDM CFP available, although the density is going to be at best half what you'd get out of using CFP2/CPAK. I'm intrigued by Oclaro since they say they have already been able to do it in CFP2, and have an implementation to do 200G via a CFP2, albeit via proprietary modulation... DTAG has done a lot of work with various vendors for interoperable long-haul 100G which is important. Unfortunately many of the transport vendors are now focused on other things now like flexgrid, flex spectrum, MacPHY (variable rate Ethernet), superchannels, 400G, etc. It's important they be pointed in the "standards" direction for those things otherwise we will be left with lots of non-interoperable implementations like we have always had. -Phil On 4/26/14, 7:17 AM, "Tim Durack" wrote: >Will need amplification anyway for almost any realistic topology. > >For those who don't understand what or why, please read the Terastream PDF >and watch the video several times, then tell me it's not a great idea :-) > >On Saturday, April 26, 2014, Julien Goodwin >wrote: > >> On 26/04/14 16:02, Mikael Abrahamsson wrote: >> > On Sat, 26 Apr 2014, Julien Goodwin wrote: >> > >> >> But you'd never send it all the waves anyway, that's far too much >>loss >> >> across the band. >> > >> > Please elaborate. >> >> At 3dB loss per split you'd very quickly need additional amplification, >> at which point the ROADM is cheaper. A static split can do the 80 waves >> in much less than the ~20dB a power split would need, and >> >> > >> >> ROADMs already solve this problem, and are available at the module >>level >> >> (how practically available and usable I've no idea, never needed to >> try). >> > >> > Compare the price of a ROADM and a 50%/50% light splitter. Which one >>do >> > you think is the cheapest and also operationally most reliable? >> >> Not disagreeing, I'd go with dumb static optics, nearly all the >> "reconfigurable" optic selling points don't seem to translate into >> actual operational benefits. >> >> > >-- >Tim:> From hank at efes.iucc.ac.il Sat Apr 26 18:05:28 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 26 Apr 2014 21:05:28 +0300 Subject: The Cidr Report In-Reply-To: <201404252200.s3PM0041030660@wattle.apnic.net> Message-ID: <5.1.1.6.2.20140426210411.0549a1f8@efes.iucc.ac.il> At 22:00 25/04/2014 +0000, cidr-report at potaroo.net wrote: >This report has been generated at Fri Apr 25 21:13:54 2014 AEST. >The report analyses the BGP Routing Table of AS2.0 router >and generates a report on aggregation potential within the table. > >Check http://www.cidr-report.org/2.0 for a current version of this report. > >Recent Table History > Date Prefixes CIDR Agg > 18-04-14 499254 282312 > 19-04-14 499492 282427 > 20-04-14 499557 282428 > 21-04-14 499371 282193 > 22-04-14 499156 282325 > 23-04-14 499260 282597 > 24-04-14 499642 282663 > 25-04-14 500177 282878 Historic event - 500K prefixes on the Internet. -Hank From seth.mos at dds.nl Sat Apr 26 19:11:44 2014 From: seth.mos at dds.nl (Seth Mos) Date: Sat, 26 Apr 2014 21:11:44 +0200 Subject: The Cidr Report In-Reply-To: <5.1.1.6.2.20140426210411.0549a1f8@efes.iucc.ac.il> References: <5.1.1.6.2.20140426210411.0549a1f8@efes.iucc.ac.il> Message-ID: <25FC66F4-6BDF-4585-85A2-CA046ACF5F5B@dds.nl> Op 26 apr. 2014, om 20:05 heeft Hank Nussbacher het volgende geschreven: > At 22:00 25/04/2014 +0000, cidr-report at potaroo.net wrote: >> This report has been generated at Fri Apr 25 21:13:54 2014 AEST. >> The report analyses the BGP Routing Table of AS2.0 router >> and generates a report on aggregation potential within the table. >> >> Check http://www.cidr-report.org/2.0 for a current version of this report. >> >> Recent Table History >> Date Prefixes CIDR Agg >> 18-04-14 499254 282312 >> 19-04-14 499492 282427 >> 20-04-14 499557 282428 >> 21-04-14 499371 282193 >> 22-04-14 499156 282325 >> 23-04-14 499260 282597 >> 24-04-14 499642 282663 >> 25-04-14 500177 282878 > > Historic event - 500K prefixes on the Internet. And now we wait for everything to fall over at 512k ;) From deepak at ai.net Sat Apr 26 19:19:43 2014 From: deepak at ai.net (Deepak Jain) Date: Sat, 26 Apr 2014 19:19:43 +0000 Subject: The Cidr Report In-Reply-To: <25FC66F4-6BDF-4585-85A2-CA046ACF5F5B@dds.nl> References: <5.1.1.6.2.20140426210411.0549a1f8@efes.iucc.ac.il> <25FC66F4-6BDF-4585-85A2-CA046ACF5F5B@dds.nl> Message-ID: > > Historic event - 500K prefixes on the Internet. > And now we wait for everything to fall over at 512k ;) Based on a quick plot graph on the CIDR report, it looks like we are adding 6,000 prefixes a month, or thereabouts. So platforms that break at 512K die in two months or less? Sup720s may need to be reconfigured/rebooted, etc. Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack). Best, Deepak From owen at delong.com Sat Apr 26 20:01:27 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Apr 2014 13:01:27 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359D8A5.7030107@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: <52FCA1E4-68A4-4513-8607-EF6DD01A5741@delong.com> On Apr 24, 2014, at 8:38 PM, Larry Sheldon wrote: > On 4/24/2014 10:23 PM, Patrick W. Gilmore wrote: >> The invisible hand of the market cannot fix problems when there is a monopoly. >> >> Put in economic terms, a player with Market Power is extracting Rents. (Capitalization is intentional.) >> >> Regulating monopolies allows a market to work, not the opposite. >> > > Regulating monopolies protects monopolies from competition. > > Monopolies can not persist without regulation. This is absolutely false. Regulating monopolies CAN protect monopolies, but that’s not always the outcome. Monopolies absolutely can persist without regulation. Except in the most highly dense population areas, there is not a sufficient market to support the deployment of more than one copy of a given media type to that population. As a result, there is, in most places, a natural monopoly in each media type, whether that’s electrical, water, cable, twisted pair, fiber, etc. > A regulated monopoly is a monopoly, with all of the powers granted to monopolies by regulation. Yes, but an unregulated monopoly is a monopoly without constraints imposed by regulation. Owen From owen at delong.com Sat Apr 26 20:11:12 2014 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Apr 2014 13:11:12 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359EB4F.50405@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> Message-ID: <33CD70F8-A9C3-4C77-A39E-ECC2E07C5842@delong.com> On Apr 24, 2014, at 9:57 PM, Larry Sheldon wrote: > I just posted a completely empty message for which I apologize. > >> Larry is confused. He can claim he is not, but posting to NANOG does >> not change the facts. Then again, just because I posted to NANOG >> doesn't prove I'm right either. Worst of all, this thread is pretty >> non-operational now. > > In a private message I asked if he could name a single monopoly that existed without regulation to protect its monopoly power. In my neighborhood, Comcast has a monopoly on coax cable tv and HFC internet services. There are no regulations that support that monopoly. Another company could, theoretically, apply, receive permits, and build out a second cable system if they wanted to. However, the population density is such that even if that company captured 50% of the market, it would merely make the market economically unviable for both companies. In such instances, you do indeed have “natural monopolies” which are an economic construct, not a regulatory artifact. >> Besides, what has this to do with my original questions? > > Which were "Anyone afraid what will happen when companies which have monopolies can charge content providers or guarantee packet loss?" and "How is this good for the consumer?" and "How is this good for the market?" > > My answer was an attempt to say that if you don't have any government entities allowing and protecting (two pretty much interchangeable terms, I prefer the latter) monopolies the answer to the first question is "Huh? What?" and to the second and third "Best service for the best price is pretty good for everybody. Except the losers that can't rip you off without the FCC protection.” How, exactly, are the governments protecting the monopolies of ILECs and Cable companies? It seems to me that it’s more a case of those monopolies persisting because the non-regulatory (largely economic) barriers to competition are large enough that they prevent viable competitors from forming. Allowing those unregulated monopolies to subsequently leverage that into a “content protection racket” is the internet equivalent of turning a regulatory blind eye to more traditional forms of extortion. So, no, eliminating the government’s protection of monopolies (wherever you think that is occurring) will not solve the more general problem of monopolies that are a problem without government protection. Owen From nick at foobar.org Sat Apr 26 20:55:51 2014 From: nick at foobar.org (Nick Hilliard) Date: Sat, 26 Apr 2014 21:55:51 +0100 Subject: US patent 5473599 In-Reply-To: <20140423164736.GD16301@quigon.bsws.de> References: <5356279F.8020405@foobar.org> <20140422103133.GL18864@quigon.bsws.de> <20140422151122.GN1206@quigon.bsws.de> <20140423164736.GD16301@quigon.bsws.de> Message-ID: <535C1D57.2040506@foobar.org> On 23/04/2014 17:47, Henning Brauer wrote: > fortunately this obviously isn't a big problem in practice, based on > the fact that we don't get any complaints/reports in that direction. > still would be way micer if that situation had been created in the > first place, but as said - we weren't given that choice. the situation was created by the openbsd team, not the ieee, the ietf or iana. You squatted on an existing oui assignment used by an equivalent protocol and in doing this, you created a long term problem with no possible solution other than to change carp to use its own dedicated range instead of someone else's. You had every choice in the world about what range to use and even if you didn't have the $2500 at the time to register a perpetual OUI assignment, almost any other OUI in existence would have been less detrimental to users than the one you chose. The openbsd foundation raised $153,000 this year. Why not invest $2500 of this and fix the problem? Nick From LarrySheldon at cox.net Sat Apr 26 23:08:40 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 26 Apr 2014 18:08:40 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> Message-ID: <535C3C78.5080006@cox.net> On 4/26/2014 3:01 PM, Owen DeLong wrote: > On Apr 24, 2014, at 8:38 PM, Larry Sheldon > wrote: >> Monopolies can not persist without regulation. > > This is absolutely false. Regulating monopolies CAN protect > monopolies, but that’s not always the outcome. > > Monopolies absolutely can persist without regulation. Except in the > most highly dense population areas, there is not a sufficient market > to support the deployment of more than one copy of a given media type > to that population. As a result, there is, in most places, a natural > monopoly in each media type, whether that’s electrical, water, cable, > twisted pair, fiber, etc. Sounds like the market at work, not monopoly power......I've never heard the term "monopoly" used where the market contains all the players that want to play. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Sat Apr 26 23:10:59 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 26 Apr 2014 18:10:59 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> Message-ID: <535C3D03.8050404@cox.net> On 4/26/2014 3:11 PM, Owen DeLong wrote: > In my neighborhood, Comcast has a monopoly on coax cable tv and HFC > internet services. There are no regulations that support that > monopoly. Another company could, theoretically, apply, receive > permits, Wait! What? Like if I want to build a pipeline to compete with your friends railroad? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From LarrySheldon at cox.net Sat Apr 26 23:58:53 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 26 Apr 2014 18:58:53 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> Message-ID: <535C483D.4060800@cox.net> h/t Suresh Ramasubramanian FCC throws in the towel on net neutrality http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ Forward! On to the next windmill, Sancho! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From randy at psg.com Sun Apr 27 01:47:21 2014 From: randy at psg.com (Randy Bush) Date: Sat, 26 Apr 2014 18:47:21 -0700 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: References: Message-ID: > I am trying to organize the DNS Track and as usual we would like to > make this very attractive. mehmet, i know you're an engineer. screw attractive. how about technically informative and meaty? randy From james.cutler at consultant.com Sun Apr 27 01:56:11 2014 From: james.cutler at consultant.com (James R Cutler) Date: Sat, 26 Apr 2014 21:56:11 -0400 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: References: Message-ID: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> Randy, To an engineer, that _IS_ attractive. Jim On Apr 26, 2014, at 9:47 PM, Randy Bush wrote: >> I am trying to organize the DNS Track and as usual we would like to >> make this very attractive. > > mehmet, i know you're an engineer. screw attractive. how about > technically informative and meaty? > > randy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 243 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mehmet at akcin.net Sun Apr 27 01:59:16 2014 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 26 Apr 2014 18:59:16 -0700 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> References: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> Message-ID: DNS is Sexy, y'all know it. Mehmet > On Apr 26, 2014, at 18:56, James R Cutler wrote: > > Randy, > > To an engineer, that _IS_ attractive. > > Jim > > On Apr 26, 2014, at 9:47 PM, Randy Bush wrote: > >>> I am trying to organize the DNS Track and as usual we would like to >>> make this very attractive. >> >> mehmet, i know you're an engineer. screw attractive. how about >> technically informative and meaty? >> >> randy > From randy at psg.com Sun Apr 27 02:00:11 2014 From: randy at psg.com (Randy Bush) Date: Sat, 26 Apr 2014 19:00:11 -0700 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> References: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> Message-ID: jim, > To an engineer, that _IS_ attractive. i am an occasional engineer. i find the recent gl1tz!ficat!on of nanog, the mass of committees and important positions, ... disgusting. randy From randy at psg.com Sun Apr 27 02:00:38 2014 From: randy at psg.com (Randy Bush) Date: Sat, 26 Apr 2014 19:00:38 -0700 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> References: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> Message-ID: jim, > To an engineer, that _IS_ attractive. i am an occasional engineer. i find the recent gl1tz!ficat!on of nanog, the mass of committees and important positions, ... embarrassing. randy From randy at psg.com Sun Apr 27 02:01:21 2014 From: randy at psg.com (Randy Bush) Date: Sat, 26 Apr 2014 19:01:21 -0700 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: References: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> Message-ID: > DNS is Sexy, y'all know it. no wonder dns geeks seem to have a low birth rate From LarrySheldon at cox.net Sun Apr 27 02:11:07 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 26 Apr 2014 21:11:07 -0500 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: References: Message-ID: <535C673B.6040707@cox.net> On 4/26/2014 8:56 PM, James R Cutler wrote: > To an engineer, that _IS_ attractive. Amen. Also to engineer wannabees. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From ryanczak at gmail.com Sun Apr 27 03:09:23 2014 From: ryanczak at gmail.com (Matt Ryanczak) Date: Sat, 26 Apr 2014 20:09:23 -0700 Subject: NANOG 61 Bellevue - DNS Track In-Reply-To: References: <0E5518CA-B2BC-4A77-9E53-ED55A787FBB9@consultant.com> Message-ID: <535C74E3.7030105@gmail.com> On 4/26/14, 7:00 PM, Randy Bush wrote: > i am an occasional engineer. i find the recent gl1tz!ficat!on of nanog, > the mass of committees and important positions, ... disgusting. Some people would call that community participation. Perhaps a side effect of the split from merit and nanog's continuing evolution? From hslabbert at stargate.ca Sun Apr 27 05:56:11 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Sun, 27 Apr 2014 05:56:11 +0000 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535C483D.4060800@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> ,<535C483D.4060800@cox.net> Message-ID: Okay, I'm not as seasoned as a big chunk of this list, but please correct me if I'm wrong in finding this article a crock of crap. With Comcast/Netflix being in the mix and by association Cogent in the background of that there's obviously room for some heated opinions, but here goes anyway... >A long, long time ago when the Internet was young and few, if any had thought >to make a profit off it, an unofficial system developed among the network >providers who carried the traffic: You carry my traffic and I'll carry yours >and we don't need money to change hands. This system has collapsed under >modern realities. I wasn't aware that settlement-free peering had "collapsed". Not saying it's the "only way", but "she ain't dead yet". Seltzer uses that to set up balanced ratios as the secret sauce that makes settlement-free peering viable: "The old system made sense when the amount of traffic each network was sending to the other was roughly equivalent." ...and since Netflix sends Comcast more than it gets, therefor Netflix needs to buck up: "Of course Netflix should pay network providers in order to get the huge amounts of bandwidth they require in order to reach their customers with sufficient quality." But this isn't talking about transit; this is about Comcast as an edge network in this context and Netflix as a content provider sending to Comcast users the traffic that they requested. Is there really anything more nuanced here than: 1. Comcast sells connectivity to their end users and sizes their network according to an oversubscription ratio they're happy with. (Nothing wrong here; oversubscription is a fact of life). 2. Bandwidth-heavy applications like Netflix enter the market. 3. Comcast's customers start using these bandwidth-heavy applications and suck in more data than Comcast was betting on. 4. Comcast has to upgrade connectivity, e.g. at peering points with the heavy inbound traffic sources, accordingly in order to satisfy their customers' usage. How is this *not* Comcast's problem? If my users are requesting more traffic than I banked on, how is it not my responsibility to ensure I have capacity to handle that? I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. Am I missing something? Overall it seems like a bad (and very public) precedent & shift towards double dipping, and the pay-for-play bits in the bastardized "Open Internet" rules don't help on that front. Now, Comcast is free to leverage their customers as bargaining chips to try to extract payments, and Randy's line of encouraging his competitors to do this sort thing seems fitting here. Basically this doesn't harm me directly at this point. Considering the lack of broadband options for large parts of the US, though, it seems that end users are getting the short end of the stick without any real recourse while that plays out. -- Hugo ________________________________________ From: NANOG on behalf of Larry Sheldon Sent: Saturday, April 26, 2014 4:58 PM To: nanog at nanog.org Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post h/t Suresh Ramasubramanian FCC throws in the towel on net neutrality http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ Forward! On to the next windmill, Sancho! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jnanog at gmail.com Sun Apr 27 06:05:24 2014 From: jnanog at gmail.com (Rick Astley) Date: Sun, 27 Apr 2014 02:05:24 -0400 Subject: What Net Neutrality should and should not cover Message-ID: Without the actual proposal being published for review its hard to know the specifics but it appears that it prohibits blocking and last mile tinkering of traffic (#1). What this means to me is ISP's can't block access to a specific website like alibaba and demand ransom from subscribers to access it again. I do not know if this provision would also include prohibiting intentionally throttling traffic on a home by home basis (#2) and holding services to the same kind of random is also prohibited but I think this too would be a far practice to prohibit. Bits are bits. >From the routers article ( http://www.reuters.com/article/2014/04/23/us-usa-fcc-internet-idUSBREA3M1H020140423) and elsewhere it seems what the proposal does not outlaw is paid peering and perhaps use of QoS on networks. #3 On paid peering: I think this is where people start to disagree but I don't see what should be criminal about paid peering agreements. More specifically, I see serious problems once you outlaw paid peering and then look at the potential repercussions that would have. Clearly it would not be fair to for only the largest content providers to be legally mandated as settlement free peers because that would leave smaller competitors out in the cold. The only fair way to outlaw paid peering would be to do it across the board for all companies big and small. This would be everyone from major content providers to my uncle to sells hand runs a website to sell hand crafted chairs. This would have major sweeping repercussions for the Internet as we know it over night. I think it makes sense to allow companies to work it out as long as the prices charged aren't unreasonably high based on market prices for data. This means if 2 ISP's with similar networks want to be settlement free they can. If ISP's want to charge for transit they can, and if ISP's want to charge CDN's to deliver data they can. Typically the company with the disproportional amount of costs of carrying the traffic would charge the other company but really it should be up to the companies involved to decide. Based on the post by Tom Wheeler from the FCC ( http://www.fcc.gov/blog/setting-record-straight-fcc-s-open-internet-rules ) it sounds like if this pricing is "commercially unreasonable" (ie extortion) they will step in. Again I think this is fair. #4 On QoS (ie fast lane?): In some of the articles I skimmed there was a lot of talk about fast lane traffic but what this sounds like today would be known as QoS and classification marking that would really only become a factor under instances of congestion. The tech bloggers and journalists all seems to be unanimously opposed to this but I admit I am sort of scratching my head at the outrage over something that has been in prevalent use on many major networks for several years. I don't see this as the end of the Internet as we know it that now seems to essentially be popular opinion on the issue. Numerous businesses are using QoS to protect things like voice traffic and business critical or emergency traffic from being impacted in a failure scenario. In modern day hyper converged networks where pretty soon even mobile voice traffic could be VoIP over a data network prohibiting the use of all QoS seems irresponsible. The larger question is, is it fair for ISP's to charge people to be in a priority other than "best effort"? To answer a question with a question, if an ISP is using a priority other than "best effort" for some of its own traffic is it fair if a peer with a competing service is only best effort delivery? This is sort of akin to Comcast not counting its own video service against the ~250G/month cap of subscribers but counting off network traffic against it. In theory if some of an ISP's own services are able to use higher than best effort priority the same should be available to the business they are selling service to. If they go completely out of their way to intentionally congest the network to force people into needing a higher than best effort classification I would think it should fall into what the FCC calls "commercially unreasonable" and thus be considered a violation. So again, I think this is fair. I have numbered the items I mentioned from 1-4 being #1. Blocking #2. per household (last mile) rate limiting of a service (though rate limiting at all anywhere should probably be up for discussion so #2.5) #3. The legality of paid peering #4. The legality of QoS (unless fast lane is something else I don't understand). Feel free to augment the list. From jnanog at gmail.com Sun Apr 27 06:23:46 2014 From: jnanog at gmail.com (Rick Astley) Date: Sun, 27 Apr 2014 02:23:46 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> Message-ID: >How is this *not* Comcast's problem? If my users are requesting more traffic than I banked on, how is it not my responsibility to ensure I have capacity to handle that? I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. Am I missing something? Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that point of congestion is the links between Netflix and Comcast then Netflix would be on the hook to ensure they have enough capacity to Comcast to get the data at least gets TO the Comcast network. The argument at hand is if Comcast permitted to charge them for the links to get to their network or should they be free/settlement free. I think it should be OK to charge for those links as long as its a fair market rate and the price doesn't basically amount to extortion. Sadly the numbers are not public so I couldn't tell you one way or the other aside from I disagree with the position Netflix seems to be taking that they simply must be free. Once that traffic is given directly to comcast no other party receives payment for delivering it so there is no double billing. This diagram best describes the relationship (ignoring pricing): http://www.digitalsociety.org/files/gou/free-and-paid-peering.png "Content provider" would be Netflix and Comcast would be Broadband ISP 1. On Sun, Apr 27, 2014 at 1:56 AM, Hugo Slabbert wrote: > Okay, I'm not as seasoned as a big chunk of this list, but please correct > me if I'm wrong in finding this article a crock of crap. With > Comcast/Netflix being in the mix and by association Cogent in the > background of that there's obviously room for some heated opinions, but > here goes anyway... > > >A long, long time ago when the Internet was young and few, if any had > thought > >to make a profit off it, an unofficial system developed among the network > >providers who carried the traffic: You carry my traffic and I'll carry > yours > >and we don't need money to change hands. This system has collapsed under > >modern realities. > > I wasn't aware that settlement-free peering had "collapsed". Not saying > it's the "only way", but "she ain't dead yet". > > Seltzer uses that to set up balanced ratios as the secret sauce that makes > settlement-free peering viable: > "The old system made sense when the amount of traffic each network was > sending to the other was roughly equivalent." > > ...and since Netflix sends Comcast more than it gets, therefor Netflix > needs to buck up: > "Of course Netflix should pay network providers in order to get the huge > amounts of bandwidth they require in order to reach their customers with > sufficient quality." > > But this isn't talking about transit; this is about Comcast as an edge > network in this context and Netflix as a content provider sending to > Comcast users the traffic that they requested. Is there really anything > more nuanced here than: > > 1. Comcast sells connectivity to their end users and sizes their network > according to an oversubscription ratio they're happy with. (Nothing wrong > here; oversubscription is a fact of life). > 2. Bandwidth-heavy applications like Netflix enter the market. > 3. Comcast's customers start using these bandwidth-heavy applications and > suck in more data than Comcast was betting on. > 4. Comcast has to upgrade connectivity, e.g. at peering points with the > heavy inbound traffic sources, accordingly in order to satisfy their > customers' usage. > > How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I have > capacity to handle that? I have gear; you have gear. I upgrade or add > ports on my side; you upgrade or add ports on your side. Am I missing > something? > > Overall it seems like a bad (and very public) precedent & shift towards > double dipping, and the pay-for-play bits in the bastardized "Open > Internet" rules don't help on that front. Now, Comcast is free to leverage > their customers as bargaining chips to try to extract payments, and Randy's > line of encouraging his competitors to do this sort thing seems fitting > here. Basically this doesn't harm me directly at this point. Considering > the lack of broadband options for large parts of the US, though, it seems > that end users are getting the short end of the stick without any real > recourse while that plays out. > > -- > Hugo > > ________________________________________ > From: NANOG on behalf of Larry Sheldon < > LarrySheldon at cox.net> > Sent: Saturday, April 26, 2014 4:58 PM > To: nanog at nanog.org > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > h/t Suresh Ramasubramanian > > FCC throws in the towel on net neutrality > > http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ > > Forward! On to the next windmill, Sancho! > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From hslabbert at stargate.ca Sun Apr 27 06:58:53 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Sun, 27 Apr 2014 06:58:53 +0000 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> , Message-ID: <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> > ...but if that point of congestion is the links between Netflix and Comcast... Which, from the outside, does appear to have been the case. > ...then Netflix would be on the hook to ensure they have enough capacity to Comcast to get the data at least gets TO the Comcast network. Which I don't believe was a problem? Again, outside looking in, but the appearances seemed to indicate that Comcast was refusing to upgrade capacity/ports, whereas I didn't see anything indicating that Netflix was doing the same. So: > I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. > The argument at hand is if Comcast permitted to charge them for the links to get to their network or should they be free/settlement free. I think it should be OK to charge for those links as long as its a fair market rate and the price doesn't basically amount to extortion. Are we talking here about transport between Netflix's POPs and Comcast's? I definitely don't expect Comcast to foot the bill for transport between the two, and if Netflix was asking for that I'm with you that would be out of line. If there are existing exchange points, though, would it not be reasonable to expect each side to up their capacity at those points? > Once that traffic is given directly to comcast no other party receives payment for delivering it so there is no double billing. The "double-dip" reference was to charging both the content provider and the ISP's own customer to deliver the same bits. If the traffic from Netflix was via Netflix's transit provider and Comcast then again was looking to bill Netflix to accept the traffic, we'd hit double billing. I guess that's the question here: If additional transport directly been POPs of the two parties was needed, somebody has to pay for the links. Releases around the deal seemed to indicate that the peering was happening at IXs (haven't checked this thoroughly), so at that point it would seem reasonable for each party to handle their own capacity to the peering points and call it even. No? -- Hugo ________________________________ From: Rick Astley Sent: Saturday, April 26, 2014 11:23 PM To: Hugo Slabbert Cc: nanog at nanog.org Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post >How is this *not* Comcast's problem? If my users are requesting more traffic than I banked on, how is it not my responsibility to ensure I have capacity to handle that? I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. Am I missing something? Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that point of congestion is the links between Netflix and Comcast then Netflix would be on the hook to ensure they have enough capacity to Comcast to get the data at least gets TO the Comcast network. The argument at hand is if Comcast permitted to charge them for the links to get to their network or should they be free/settlement free. I think it should be OK to charge for those links as long as its a fair market rate and the price doesn't basically amount to extortion. Sadly the numbers are not public so I couldn't tell you one way or the other aside from I disagree with the position Netflix seems to be taking that they simply must be free. Once that traffic is given directly to comcast no other party receives payment for delivering it so there is no double billing. This diagram best describes the relationship (ignoring pricing): http://www.digitalsociety.org/files/gou/free-and-paid-peering.png "Content provider" would be Netflix and Comcast would be Broadband ISP 1. On Sun, Apr 27, 2014 at 1:56 AM, Hugo Slabbert > wrote: Okay, I'm not as seasoned as a big chunk of this list, but please correct me if I'm wrong in finding this article a crock of crap. With Comcast/Netflix being in the mix and by association Cogent in the background of that there's obviously room for some heated opinions, but here goes anyway... >A long, long time ago when the Internet was young and few, if any had thought >to make a profit off it, an unofficial system developed among the network >providers who carried the traffic: You carry my traffic and I'll carry yours >and we don't need money to change hands. This system has collapsed under >modern realities. I wasn't aware that settlement-free peering had "collapsed". Not saying it's the "only way", but "she ain't dead yet". Seltzer uses that to set up balanced ratios as the secret sauce that makes settlement-free peering viable: "The old system made sense when the amount of traffic each network was sending to the other was roughly equivalent." ...and since Netflix sends Comcast more than it gets, therefor Netflix needs to buck up: "Of course Netflix should pay network providers in order to get the huge amounts of bandwidth they require in order to reach their customers with sufficient quality." But this isn't talking about transit; this is about Comcast as an edge network in this context and Netflix as a content provider sending to Comcast users the traffic that they requested. Is there really anything more nuanced here than: 1. Comcast sells connectivity to their end users and sizes their network according to an oversubscription ratio they're happy with. (Nothing wrong here; oversubscription is a fact of life). 2. Bandwidth-heavy applications like Netflix enter the market. 3. Comcast's customers start using these bandwidth-heavy applications and suck in more data than Comcast was betting on. 4. Comcast has to upgrade connectivity, e.g. at peering points with the heavy inbound traffic sources, accordingly in order to satisfy their customers' usage. How is this *not* Comcast's problem? If my users are requesting more traffic than I banked on, how is it not my responsibility to ensure I have capacity to handle that? I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. Am I missing something? Overall it seems like a bad (and very public) precedent & shift towards double dipping, and the pay-for-play bits in the bastardized "Open Internet" rules don't help on that front. Now, Comcast is free to leverage their customers as bargaining chips to try to extract payments, and Randy's line of encouraging his competitors to do this sort thing seems fitting here. Basically this doesn't harm me directly at this point. Considering the lack of broadband options for large parts of the US, though, it seems that end users are getting the short end of the stick without any real recourse while that plays out. -- Hugo ________________________________________ From: NANOG > on behalf of Larry Sheldon > Sent: Saturday, April 26, 2014 4:58 PM To: nanog at nanog.org Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post h/t Suresh Ramasubramanian FCC throws in the towel on net neutrality http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ Forward! On to the next windmill, Sancho! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From Trelane at trelane.net Sun Apr 27 07:21:50 2014 From: Trelane at trelane.net (Andrew D Kirch) Date: Sun, 27 Apr 2014 03:21:50 -0400 Subject: Phase 4. In-Reply-To: References: Message-ID: <1B339973-F63A-494D-9F41-49CA0550D8A1@trelane.net> Wow, I wish I could incoherent this typely! Andrew Sent from my iPad > On Apr 24, 2014, at 1:54 AM, "Bryan Socha" wrote: > > > Whats the big deal???? If your just arin, dont panic. Akamai and > digitalocean has been the only people aquire fair priced v4 putside > arin. So arin is ending. It doesnt stop anything. be smart 3 usd > per ip is fair if dirty. F the auct8ons they are fake and we get the ips > lower than op3ning. > > Icann is the mast 8 class as real? Distribute them > , > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4569 / Virus Database: 3882/7361 - Release Date: 04/18/14 From mpalmer at hezmatt.org Sun Apr 27 08:19:05 2014 From: mpalmer at hezmatt.org (Matt Palmer) Date: Sun, 27 Apr 2014 18:19:05 +1000 Subject: Phase 4. In-Reply-To: <1B339973-F63A-494D-9F41-49CA0550D8A1@trelane.net> References: <1B339973-F63A-494D-9F41-49CA0550D8A1@trelane.net> Message-ID: <20140427081905.GT7092@hezmatt.org> On Sun, Apr 27, 2014 at 03:21:50AM -0400, Andrew D Kirch wrote: > > On Apr 24, 2014, at 1:54 AM, "Bryan Socha" wrote: > > Whats the big deal???? If your just arin, dont panic. Akamai and > > digitalocean has been the only people aquire fair priced v4 putside > > arin. So arin is ending. It doesnt stop anything. be smart 3 usd > > per ip is fair if dirty. F the auct8ons they are fake and we get the ips > > lower than op3ning. > > > > Icann is the mast 8 class as real? Distribute them > > Wow, I wish I could incoherent this typely! Keep drinking. You'll get there eventually. - Matt (who recommends *not* posting drunk from a work e-mail address) From ler762 at gmail.com Sun Apr 27 13:47:29 2014 From: ler762 at gmail.com (Lee) Date: Sun, 27 Apr 2014 09:47:29 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535C483D.4060800@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> Message-ID: On 4/26/14, Larry Sheldon wrote: > h/t Suresh Ramasubramanian > > FCC throws in the towel on net neutrality > > http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ Why isn't it as simple as I'm paying my ISP to deliver the bits to me and Netflix is paying their [cdn?] provider to deliver the bits to me. Netflix is already paying their provider to deliver the bits to me, so why do they have to also pay my ISP to deliver the bits to me? It seems the FCC is on a roll - not only giving up on net neutrality but building up the local monopoly: http://transition.fcc.gov/Daily_Releases/Daily_Business/2014/db0423/DOC-326703A1.txt "The concept of targeting subsidies for broadband and voice service to pockets of rural America where they are needed most is central to the FCC's 2011 reforms. Later this year, "price cap" carriers will be given the opportunity to accept Connect America Fund support in high cost areas based on detailed local cost estimates, calculated by a cost model. Incumbent carriers must choose to accept or decline the offer of support for all entire high-cost locations they serve in a given state; if they decline, the subsidies will be made available to other providers, awarded through a Phase II competitive bidding process." Why do the incumbent carriers get the right of first refusal for subsidies? They're the ones that haven't served their local population so it seems like they should be the *last* to be offered subsidies. Lee > Forward! On to the next windmill, Sancho! > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > From nick at pelagiris.org Sun Apr 27 14:04:41 2014 From: nick at pelagiris.org (Nick B) Date: Sun, 27 Apr 2014 10:04:41 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: The current scandal is not about peering, it is last mile ISP double dipping. Nick On Apr 27, 2014 2:05 AM, "Rick Astley" wrote: > Without the actual proposal being published for review its hard to know the > specifics but it appears that it prohibits blocking and last mile tinkering > of traffic (#1). What this means to me is ISP's can't block access to a > specific website like alibaba and demand ransom from subscribers to access > it again. I do not know if this provision would also include prohibiting > intentionally throttling traffic on a home by home basis (#2) and holding > services to the same kind of random is also prohibited but I think this too > would be a far practice to prohibit. Bits are bits. > > From the routers article ( > > http://www.reuters.com/article/2014/04/23/us-usa-fcc-internet-idUSBREA3M1H020140423 > ) > and elsewhere it seems what the proposal does not outlaw is paid > peering > and perhaps use of QoS on networks. > > #3 On paid peering: > I think this is where people start to disagree but I don't see what should > be criminal about paid peering agreements. More specifically, I see serious > problems once you outlaw paid peering and then look at the potential > repercussions that would have. Clearly it would not be fair to for only the > largest content providers to be legally mandated as settlement free peers > because that would leave smaller competitors out in the cold. The only fair > way to outlaw paid peering would be to do it across the board for all > companies big and small. This would be everyone from major content > providers to my uncle to sells hand runs a website to sell hand crafted > chairs. This would have major sweeping repercussions for the Internet as we > know it over night. > > I think it makes sense to allow companies to work it out as long as the > prices charged aren't unreasonably high based on market prices for data. > This means if 2 ISP's with similar networks want to be settlement free they > can. If ISP's want to charge for transit they can, and if ISP's want to > charge CDN's to deliver data they can. Typically the company with the > disproportional amount of costs of carrying the traffic would charge the > other company but really it should be up to the companies involved to > decide. Based on the post by Tom Wheeler from the FCC ( > http://www.fcc.gov/blog/setting-record-straight-fcc-s-open-internet-rules) > it sounds like if this pricing is "commercially unreasonable" (ie > extortion) they will step in. Again I think this is fair. > > > #4 On QoS (ie fast lane?): > In some of the articles I skimmed there was a lot of talk about fast lane > traffic but what this sounds like today would be known as QoS and > classification marking that would really only become a factor under > instances of congestion. The tech bloggers and journalists all seems to be > unanimously opposed to this but I admit I am sort of scratching my head at > the outrage over something that has been in prevalent use on many major > networks for several years. I don't see this as the end of the Internet as > we know it that now seems to essentially be popular opinion on the issue. > Numerous businesses are using QoS to protect things like voice traffic and > business critical or emergency traffic from being impacted in a failure > scenario. In modern day hyper converged networks where pretty soon even > mobile voice traffic could be VoIP over a data network prohibiting the use > of all QoS seems irresponsible. > > The larger question is, is it fair for ISP's to charge people to be in a > priority other than "best effort"? To answer a question with a question, > if an ISP is using a priority other than "best effort" for some of its own > traffic is it fair if a peer with a competing service is only best effort > delivery? This is sort of akin to Comcast not counting its own video > service against the ~250G/month cap of subscribers but counting off network > traffic against it. In theory if some of an ISP's own services are able to > use higher than best effort priority the same should be available to the > business they are selling service to. If they go completely out of their > way to intentionally congest the network to force people into needing a > higher than best effort classification I would think it should fall into > what the FCC calls "commercially unreasonable" and thus be considered a > violation. So again, I think this is fair. > > I have numbered the items I mentioned from 1-4 being > #1. Blocking > #2. per household (last mile) rate limiting of a service (though rate > limiting at all anywhere should probably be up for discussion so #2.5) > #3. The legality of paid peering > #4. The legality of QoS (unless fast lane is something else I don't > understand). > > Feel free to augment the list. > From jnanog at gmail.com Sun Apr 27 15:45:04 2014 From: jnanog at gmail.com (Rick Astley) Date: Sun, 27 Apr 2014 11:45:04 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> Message-ID: If it were through a switch at the exchange it would be on each of them to individually upgrade their capacity to it but at the capacities they are at it they are beyond what would make sense financially to go over an exchange switch so they would connect directly instead. It's likely more along the lines of needing several 100G ports as Netflix is over 30% of peak usage traffic in North America: "Netflix (31.6%) holds its ground as the leading downstream application in North America and together with YouTube (18.6%) accounts for over 50% of downstream traffic on fixed networks." (source https://www.sandvine.com/trends/global-internet-phenomena/ ) That amount of data is massive scale. I don't see it as double dipping because each party is buying the pipe they are using. I am buying a 15Mbps pipe to my home but just because we are communicating over the Internet doesn't mean the money I am paying covers the cost of your connection too. You must still buy your own pipe in the same way Netflix would. I covered this scenario in more detail in my post "What Net Neutrality should and should not cover" but if you expand on the assumption that paying for an internet connection also pays for the direct connection of every party who you exchange traffic with then you have a scenario where only half the people connected to the Internet should have to pay at all for their connection because any scenario where people simply buy their own pipe would be considered "double billing". The cost for residential broadband is high enough in the US without a policy like that in place. If there is one policy that would keep poor families from being able to afford broadband it would be that one. On Sun, Apr 27, 2014 at 2:58 AM, Hugo Slabbert wrote: > > > ...but if that point of congestion is the links between Netflix and > Comcast... > > Which, from the outside, does appear to have been the case. > > > ...then Netflix would be on the hook to ensure they have enough capacity > to Comcast to get the data at least gets TO the Comcast network. > > Which I don't believe was a problem? Again, outside looking in, but the > appearances seemed to indicate that Comcast was refusing to upgrade > capacity/ports, whereas I didn't see anything indicating that Netflix was > doing the same. So: > > I have gear; you have gear. I upgrade or add ports on my side; you > upgrade or add ports on your side. > > > > The argument at hand is if Comcast permitted to charge them for the > links to get to their network or should they be free/settlement free. I > think it should be OK to charge for those links as long as its a fair > market rate and the price doesn't basically amount to extortion. > > Are we talking here about transport between Netflix's POPs and Comcast's? > I definitely don't expect Comcast to foot the bill for transport between > the two, and if Netflix was asking for that I'm with you that would be out > of line. If there are existing exchange points, though, would it not be > reasonable to expect each side to up their capacity at those points? > > > > Once that traffic is given directly to comcast no other party receives > payment for delivering it so there is no double billing. > > The "double-dip" reference was to charging both the content provider and > the ISP's own customer to deliver the same bits. If the traffic from > Netflix was via Netflix's transit provider and Comcast then again was > looking to bill Netflix to accept the traffic, we'd hit double billing. > > I guess that's the question here: If additional transport directly been > POPs of the two parties was needed, somebody has to pay for the links. > Releases around the deal seemed to indicate that the peering was happening > at IXs (haven't checked this thoroughly), so at that point it would seem > reasonable for each party to handle their own capacity to the peering > points and call it even. No? > > -- > Hugo > > ________________________________ > From: Rick Astley > Sent: Saturday, April 26, 2014 11:23 PM > To: Hugo Slabbert > Cc: nanog at nanog.org > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > >How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I have > capacity to handle that? I have gear; you have gear. I upgrade or add > ports on my side; you upgrade or add ports on your side. Am I missing > something? > > Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that > point of congestion is the links between Netflix and Comcast then Netflix > would be on the hook to ensure they have enough capacity to Comcast to get > the data at least gets TO the Comcast network. The argument at hand is if > Comcast permitted to charge them for the links to get to their network or > should they be free/settlement free. I think it should be OK to charge for > those links as long as its a fair market rate and the price doesn't > basically amount to extortion. Sadly the numbers are not public so I > couldn't tell you one way or the other aside from I disagree with the > position Netflix seems to be taking that they simply must be free. Once > that traffic is given directly to comcast no other party receives payment > for delivering it so there is no double billing. > > This diagram best describes the relationship (ignoring pricing): > http://www.digitalsociety.org/files/gou/free-and-paid-peering.png > > "Content provider" would be Netflix and Comcast would be Broadband ISP 1. > > > > > On Sun, Apr 27, 2014 at 1:56 AM, Hugo Slabbert > wrote: > Okay, I'm not as seasoned as a big chunk of this list, but please correct > me if I'm wrong in finding this article a crock of crap. With > Comcast/Netflix being in the mix and by association Cogent in the > background of that there's obviously room for some heated opinions, but > here goes anyway... > > >A long, long time ago when the Internet was young and few, if any had > thought > >to make a profit off it, an unofficial system developed among the network > >providers who carried the traffic: You carry my traffic and I'll carry > yours > >and we don't need money to change hands. This system has collapsed under > >modern realities. > > I wasn't aware that settlement-free peering had "collapsed". Not saying > it's the "only way", but "she ain't dead yet". > > Seltzer uses that to set up balanced ratios as the secret sauce that makes > settlement-free peering viable: > "The old system made sense when the amount of traffic each network was > sending to the other was roughly equivalent." > > ...and since Netflix sends Comcast more than it gets, therefor Netflix > needs to buck up: > "Of course Netflix should pay network providers in order to get the huge > amounts of bandwidth they require in order to reach their customers with > sufficient quality." > > But this isn't talking about transit; this is about Comcast as an edge > network in this context and Netflix as a content provider sending to > Comcast users the traffic that they requested. Is there really anything > more nuanced here than: > > 1. Comcast sells connectivity to their end users and sizes their network > according to an oversubscription ratio they're happy with. (Nothing wrong > here; oversubscription is a fact of life). > 2. Bandwidth-heavy applications like Netflix enter the market. > 3. Comcast's customers start using these bandwidth-heavy applications and > suck in more data than Comcast was betting on. > 4. Comcast has to upgrade connectivity, e.g. at peering points with the > heavy inbound traffic sources, accordingly in order to satisfy their > customers' usage. > > How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I have > capacity to handle that? I have gear; you have gear. I upgrade or add > ports on my side; you upgrade or add ports on your side. Am I missing > something? > > Overall it seems like a bad (and very public) precedent & shift towards > double dipping, and the pay-for-play bits in the bastardized "Open > Internet" rules don't help on that front. Now, Comcast is free to leverage > their customers as bargaining chips to try to extract payments, and Randy's > line of encouraging his competitors to do this sort thing seems fitting > here. Basically this doesn't harm me directly at this point. Considering > the lack of broadband options for large parts of the US, though, it seems > that end users are getting the short end of the stick without any real > recourse while that plays out. > > -- > Hugo > > ________________________________________ > From: NANOG > on > behalf of Larry Sheldon >> > Sent: Saturday, April 26, 2014 4:58 PM > To: nanog at nanog.org > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > h/t Suresh Ramasubramanian > > FCC throws in the towel on net neutrality > > http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ > > Forward! On to the next windmill, Sancho! > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > From j at arpa.com Sun Apr 27 16:37:12 2014 From: j at arpa.com (jamie rishaw) Date: Sun, 27 Apr 2014 11:37:12 -0500 Subject: Phase 4. In-Reply-To: References: Message-ID: I can has test fore able two post too this list ?????? On Thu, Apr 24, 2014 at 12:54 AM, Bryan Socha wrote: > Whats the big deal???? If your just arin, dont panic. Akamai and > digitalocean has been the only people aquire fair priced v4 putside > arin. So arin is ending. It doesnt stop anything. be smart 3 usd > per ip is fair if dirty. F the auct8ons they are fake and we get the ips > lower than op3ning. > > Icann is the mast 8 class as real? Distribute them > , -- jamie rishaw // .com.arpa at j <- reverse it. ish. "Reality defeats prejudice." - Rep. Barney Frank From jnanog at gmail.com Sun Apr 27 16:57:40 2014 From: jnanog at gmail.com (Rick Astley) Date: Sun, 27 Apr 2014 12:57:40 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: I wish you would expand on that to help me understand where you are coming from but what I pay my ISP for is simply a pipe, I don't know how it would make sense logically to assume that every entity I communicate with on the Internet must be able to connect for free because I am covering the tab as a subscriber. I am not talking about JUST Netflix here as they are a large company more capable than some smaller ones at buying their own pipes out to the world. It would be sort of the same concept of my grandmother calling my cell phone yet we both need to pay for our individual phone lines to at least reach the carrier tasked with connecting our call. Even if my grandmother calls a business, that business have phone lines they pay for. Technically this would be double dipping but it's been the norm for a very long time. Now if we will lets talk about where this concept falls apart. Pretend I run a lemonade stand and my ISP offers to give it free Internet access, how generous of them! I then meet a businessman from town who is complaining about what it costs him to connect to the Internet because he has a lot of equipment that serves data to people all over the place. I see this as an opportunity to make more money and I say "hey, they don't charge me at all for Internet access I will make you a deal, I will connect your equipment to them for 1/3 what you are paying today". "Good deal" says the businessman. I eagerly ride my bicycle home, pick up my phone, call my ISP and tell them the news "Hey, thanks for the free service but I need you to upgrade my connection x5 because I decided to do content delivery for the businesses in town". "Oh hell no says my ISP, that was not at all the agreement, your lemonade stand is still free but if you want us to carry the extra traffic you have to buy more ports the same as everyone else". I didn't build a successful lemonade stand because I take being treated like this sitting down! Our now much larger volume of traffic is slow to the ISP and they are refusing to upgrade it for free, so I call up the media and have them run a story about how the ISP is intentionally limiting our traffic and they simply need to upgrade it for free. People are already paying for the Internet, if they don't give me my free ride they are double dipping! Public opinion is in, that mean ISP should be giving me my free access but the reality of the situation is perhaps a bit different. My lemonade stand pulled a coup when it became a content provider and demanded a free ride, and railroading my ISP for it in the media was probably a dishonest thing to do. I reluctantly agree to pay them for ports for content I am delivering but "local businessman" from my town has tasted blood and he's not done yet "Who else has a lemonade stand with free Internet?!" he proclaims. I changed some names to protect the Innocent :) On Sun, Apr 27, 2014 at 10:04 AM, Nick B wrote: > The current scandal is not about peering, it is last mile ISP double > dipping. > Nick > On Apr 27, 2014 2:05 AM, "Rick Astley" wrote: > >> Without the actual proposal being published for review its hard to know >> the >> specifics but it appears that it prohibits blocking and last mile >> tinkering >> of traffic (#1). What this means to me is ISP's can't block access to a >> specific website like alibaba and demand ransom from subscribers to access >> it again. I do not know if this provision would also include prohibiting >> intentionally throttling traffic on a home by home basis (#2) and holding >> services to the same kind of random is also prohibited but I think this >> too >> would be a far practice to prohibit. Bits are bits. >> >> From the routers article ( >> >> http://www.reuters.com/article/2014/04/23/us-usa-fcc-internet-idUSBREA3M1H020140423 >> ) >> and elsewhere it seems what the proposal does not outlaw is paid >> peering >> and perhaps use of QoS on networks. >> >> #3 On paid peering: >> I think this is where people start to disagree but I don't see what should >> be criminal about paid peering agreements. More specifically, I see >> serious >> problems once you outlaw paid peering and then look at the potential >> repercussions that would have. Clearly it would not be fair to for only >> the >> largest content providers to be legally mandated as settlement free peers >> because that would leave smaller competitors out in the cold. The only >> fair >> way to outlaw paid peering would be to do it across the board for all >> companies big and small. This would be everyone from major content >> providers to my uncle to sells hand runs a website to sell hand crafted >> chairs. This would have major sweeping repercussions for the Internet as >> we >> know it over night. >> >> I think it makes sense to allow companies to work it out as long as the >> prices charged aren't unreasonably high based on market prices for data. >> This means if 2 ISP's with similar networks want to be settlement free >> they >> can. If ISP's want to charge for transit they can, and if ISP's want to >> charge CDN's to deliver data they can. Typically the company with the >> disproportional amount of costs of carrying the traffic would charge the >> other company but really it should be up to the companies involved to >> decide. Based on the post by Tom Wheeler from the FCC ( >> http://www.fcc.gov/blog/setting-record-straight-fcc-s-open-internet-rules) >> it sounds like if this pricing is "commercially unreasonable" (ie >> extortion) they will step in. Again I think this is fair. >> >> >> #4 On QoS (ie fast lane?): >> In some of the articles I skimmed there was a lot of talk about fast lane >> traffic but what this sounds like today would be known as QoS and >> classification marking that would really only become a factor under >> instances of congestion. The tech bloggers and journalists all seems to be >> unanimously opposed to this but I admit I am sort of scratching my head at >> the outrage over something that has been in prevalent use on many major >> networks for several years. I don't see this as the end of the Internet as >> we know it that now seems to essentially be popular opinion on the issue. >> Numerous businesses are using QoS to protect things like voice traffic and >> business critical or emergency traffic from being impacted in a failure >> scenario. In modern day hyper converged networks where pretty soon even >> mobile voice traffic could be VoIP over a data network prohibiting the use >> of all QoS seems irresponsible. >> >> The larger question is, is it fair for ISP's to charge people to be in a >> priority other than "best effort"? To answer a question with a question, >> if an ISP is using a priority other than "best effort" for some of its own >> traffic is it fair if a peer with a competing service is only best effort >> delivery? This is sort of akin to Comcast not counting its own video >> service against the ~250G/month cap of subscribers but counting off >> network >> traffic against it. In theory if some of an ISP's own services are able to >> use higher than best effort priority the same should be available to the >> business they are selling service to. If they go completely out of their >> way to intentionally congest the network to force people into needing a >> higher than best effort classification I would think it should fall into >> what the FCC calls "commercially unreasonable" and thus be considered a >> violation. So again, I think this is fair. >> >> I have numbered the items I mentioned from 1-4 being >> #1. Blocking >> #2. per household (last mile) rate limiting of a service (though rate >> limiting at all anywhere should probably be up for discussion so #2.5) >> #3. The legality of paid peering >> #4. The legality of QoS (unless fast lane is something else I don't >> understand). >> >> Feel free to augment the list. >> > From bzs at world.std.com Sun Apr 27 17:44:46 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 27 Apr 2014 13:44:46 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535C3C78.5080006@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> Message-ID: <21341.16910.961998.901650@world.std.com> What are any of you talking about? Have you even bothered to read for example the wikipedia article on "monopoly" or are you so solipsistic that you just make up the entire universe in your head? Do you also pontificate on quantum physics and neurosurgery when the urge strikes you??? Sorry but this discussion is so, uneducated, usage of terms which are not as they are defined in the English or any other language, etc. But what do you think about the FCC's efforts in regard to "net neutrality"? Do you agree with CNBC's assessment that the internet has a "fast lane" and up until now FCC regulations prevented consumers and content providers from using it under the guise of "net neutrality". Do you believe there's anything at stake here for you beyond just nattering about your own personal and peculiar notion of what a "monopoly" is? Does that really matter to any of this? I almost believe that this entire flame war on the definition of monopoly is being fanned by sockpuppets whose job it is to make sure no one here talks about net neutrality in any effective or at least meaningful way. http://www.cnbc.com/id/101607254 F.C.C., in 'Net Neutrality' Turnaround, Plans to Allow Fast Lane The Federal Communications Commission will propose new rules that allow Internet service providers to offer a faster lane through which to send video and other content to consumers, as long as a content company is willing to pay for it, according to people briefed on the proposals. ... Would someone please define this "fast lane" for me? That would be a really good start. Preferably the managers of that fast lane because they surely must be on this list...no? P.S. CNBC is owned by Comcast (or more specifically NBC Universal, which is owned by Comcast.) -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bill at herrin.us Sun Apr 27 17:56:30 2014 From: bill at herrin.us (William Herrin) Date: Sun, 27 Apr 2014 13:56:30 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: On Sun, Apr 27, 2014 at 2:05 AM, Rick Astley wrote: > #3 On paid peering: > I think this is where people start to disagree but I don't see what should > be criminal about paid peering agreements. More specifically, I see serious > problems once you outlaw paid peering and then look at the potential > repercussions that would have. Double-billing Rick. It's just that simple. Paid peering means you're deliberately billing two customers for the same byte -- the peer and the downstream. And not merely incidental to ordinary service - the peer specifically connects to gain access to customers who already pay you and no one else. Where those two customers have divergent interests, you have to pick which one you'll serve even as you continue to bill both. That's a corrupt practice. What sort of corrupt practice? You might, for example, degrade your residential customers' speed to the part of the Internet housing a company you think should pay you for peering. Or permit the link to deteriorate while energetically upgrading others to keep pace with the times. Same difference. This doesn't have to be true. You could bill downstreams for consumption and exclude the paid peering from that calculation. But you don't do that. And you aren't planning to. > #4 On QoS (ie fast lane?): > In some of the articles I skimmed there was a lot of talk about fast lane > traffic but what this sounds like today would be known as QoS and > classification marking that would really only become a factor under > instances of congestion. The tech bloggers and journalists all seems to be > unanimously opposed to this but I admit I am sort of scratching my head at > the outrage over something that has been in prevalent use on many major > networks for several years. It's prevalent on private work networks and users hate it. It generally disables activities the network owners don't approve of while engaging in doubletalk about how they're OK with it. Users don't want to see this migrate outward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bedard.phil at gmail.com Sun Apr 27 18:07:51 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Sun, 27 Apr 2014 14:07:51 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <21341.16910.961998.901650@world.std.com> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <21341.16910.961998.901650@world.std.com> Message-ID: The "Fast Lane" perhaps starts as not counting traffic against metered byte caps, similar to what ATT did on their mobile network. If the content/service provider is willing to pay the provider, then the users may not pay overage fees or get nasty letters anymore when they exceed data caps. The second and more contentious part of it is using QoS to guarantee the content/service provider's traffic is delivered, at the expense of traffic from those who aren't paying. So if Netflix decides to pay and Amazon Prime doesn't, well Netflix will make it to your house and Prime might not. Right now everyone's traffic gets dropped equally. :) (Well more Netflix because there is a lot more of it). -Phil (all opinions are my personal opinions) On 4/27/14, 1:44 PM, "Barry Shein" wrote: > >What are any of you talking about? Have you even bothered to read for >example the wikipedia article on "monopoly" or are you so solipsistic >that you just make up the entire universe in your head? Do you also >pontificate on quantum physics and neurosurgery when the urge strikes >you??? > >Sorry but this discussion is so, uneducated, usage of terms which are >not as they are defined in the English or any other language, etc. > > > >But what do you think about the FCC's efforts in regard to "net >neutrality"? > > > >Do you agree with CNBC's assessment that the internet has a "fast >lane" and up until now FCC regulations prevented consumers and content >providers from using it under the guise of "net neutrality". > >Do you believe there's anything at stake here for you beyond just >nattering about your own personal and peculiar notion of what a >"monopoly" is? Does that really matter to any of this? > >I almost believe that this entire flame war on the definition of >monopoly is being fanned by sockpuppets whose job it is to make sure >no one here talks about net neutrality in any effective or at least >meaningful way. > > http://www.cnbc.com/id/101607254 > > F.C.C., in 'Net Neutrality' Turnaround, > Plans to Allow Fast Lane > > The Federal Communications Commission will propose new rules that > allow Internet service providers to offer a faster lane through > which to send video and other content to consumers, as long as a > content company is willing to pay for it, according to people > briefed on the proposals. > > ... > >Would someone please define this "fast lane" for me? That would be a >really good start. Preferably the managers of that fast lane because >they surely must be on this list...no? > > >P.S. CNBC is owned by Comcast (or more specifically NBC Universal, >which is owned by Comcast.) > >-- > -Barry Shein > >The World | bzs at TheWorld.com | >http://www.TheWorld.com >Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >Canada >Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bob at FiberInternetCenter.com Sun Apr 27 18:26:30 2014 From: bob at FiberInternetCenter.com (Bob Evans) Date: Sun, 27 Apr 2014 11:26:30 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <21341.16910.961998.901650@world.std.com> Message-ID: <9380a4ba02d0715ca95eff64fdfef924.squirrel@66.201.44.180> Everyone interested in how this plays out today, can read Bill Norton's Internet Peering book. While some say situations "didn't happen this way or it happened that way" doesn't really matter. What is clear and matters is the tactics/leverage backbones and networks use against each other in trading traffic are very real and explained well. These situations are one of the reasons I helped Coresite (AKA old CRGwest) build Any2 Peering. Amazon now has a kindle edition of the latest for just $10. Paper version is like $50-$100. The 2014 Internet Peering Playbook: Connecting to the Core of the Internet [Kindle Edition] William B. Norton (Author). Bob Evans CTO Fiber Internet Center Fiber International MTI Corporation > The "Fast Lane" perhaps starts as not counting traffic against metered > byte caps, similar to what ATT did on their mobile network. If the > content/service provider is willing to pay the provider, then the users > may not pay overage fees or get nasty letters anymore when they exceed > data caps. The second and more contentious part of it is using QoS to > guarantee the content/service provider's traffic is delivered, at the > expense of traffic from those who aren't paying. So if Netflix decides to > pay and Amazon Prime doesn't, well Netflix will make it to your house and > Prime might not. Right now everyone's traffic gets dropped equally. :) > (Well more Netflix because there is a lot more of it). > > > -Phil (all opinions are my personal opinions) > > > > > On 4/27/14, 1:44 PM, "Barry Shein" wrote: > >> >>What are any of you talking about? Have you even bothered to read for >>example the wikipedia article on "monopoly" or are you so solipsistic >>that you just make up the entire universe in your head? Do you also >>pontificate on quantum physics and neurosurgery when the urge strikes >>you??? >> >>Sorry but this discussion is so, uneducated, usage of terms which are >>not as they are defined in the English or any other language, etc. >> >> >> >>But what do you think about the FCC's efforts in regard to "net >>neutrality"? >> >> >> >>Do you agree with CNBC's assessment that the internet has a "fast >>lane" and up until now FCC regulations prevented consumers and content >>providers from using it under the guise of "net neutrality". >> >>Do you believe there's anything at stake here for you beyond just >>nattering about your own personal and peculiar notion of what a >>"monopoly" is? Does that really matter to any of this? >> >>I almost believe that this entire flame war on the definition of >>monopoly is being fanned by sockpuppets whose job it is to make sure >>no one here talks about net neutrality in any effective or at least >>meaningful way. >> >> http://www.cnbc.com/id/101607254 >> >> F.C.C., in 'Net Neutrality' Turnaround, >> Plans to Allow Fast Lane >> >> The Federal Communications Commission will propose new rules that >> allow Internet service providers to offer a faster lane through >> which to send video and other content to consumers, as long as a >> content company is willing to pay for it, according to people >> briefed on the proposals. >> >> ... >> >>Would someone please define this "fast lane" for me? That would be a >>really good start. Preferably the managers of that fast lane because >>they surely must be on this list...no? >> >> >>P.S. CNBC is owned by Comcast (or more specifically NBC Universal, >>which is owned by Comcast.) >> >>-- >> -Barry Shein >> >>The World | bzs at TheWorld.com | >>http://www.TheWorld.com >>Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, >>Canada >>Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > > > From tore at fud.no Sun Apr 27 18:40:34 2014 From: tore at fud.no (Tore Anderson) Date: Sun, 27 Apr 2014 20:40:34 +0200 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: <535D4F22.80202@fud.no> * William Herrin > On Sun, Apr 27, 2014 at 2:05 AM, Rick Astley wrote: >> #3 On paid peering: >> I think this is where people start to disagree but I don't see what should >> be criminal about paid peering agreements. More specifically, I see serious >> problems once you outlaw paid peering and then look at the potential >> repercussions that would have. > > Double-billing Rick. It's just that simple. Paid peering means you're > deliberately billing two customers for the same byte -- the peer and > the downstream. And not merely incidental to ordinary service - the > peer specifically connects to gain access to customers who already pay > you and no one else. Where those two customers have divergent > interests, you have to pick which one you'll serve even as you > continue to bill both. That's a corrupt practice. It's not "just that simple". If for example you asks for a peering with me, the first thing I'll do is to take a close look at how the traffic between our two networks is currently being routed. If I see that I have no monetary or technical gain from setting up that peering with you, perhaps because the traffic is currently flowing via an already existing peering of mine (with your upstream, say), or via a transit port of mine that's not exceeding its CDR, then I'd probably want you to at cover my costs of setting up that peering before accepting, at the very least. Even if I was exceeding the CDR on my transit ports, it's not at all certain that accepting a peering with you would even be a break-even proposition for me. Keep in mind that unlike routers and line cards, IP transit service *is* dirt cheap these days. So no, refusing a peering or requiring the would-be peer to pay for the privilege isn't *necessarily* "corrupt practice". It Depends. Tore From mpetach at netflight.com Sun Apr 27 18:44:34 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 27 Apr 2014 11:44:34 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: On Thu, Apr 24, 2014 at 5:15 AM, Patrick W. Gilmore wrote: > Anyone afraid what will happen when companies which have monopolies can > charge content providers or guarantee packet loss? > > In a normal "free market", if two companies with a mutual consumer have a > tiff, the consumer decides which to support. Where I live, I have one > broadband provider. If they get upset with, say, a streaming provider, I > cannot choose another BB company because I like the streaming company. I > MUST pick another streaming company, as that is the only thing I can > "choose". > [I speak only for myself here; any use of the word "we" should be taken to represent only my sense of inclusion with the rest of humanity, and not with any commercial entity or organization. Any other characterization of the following words is patently incorrect, and grounds for possible actions, up to and including litigation. Please don't be an ass, and quote me out of context, or as representing something I'm not. Original post edited slightly, with specific entity names replaced with variables; you may do your own substitution back into the variables as you feel appropriate. --MNP] What if we turn the picture around slightly, and look at it like the negotiations between broadcast networks and cable companies? 2010's battle between Fox television and cablevision comes to mind, where the content holder blacked out access to their content for specific cable companies unless they agree to pay the demanded fees. It would be interesting to have seen $content_CEO take a hard line stance; it wouldn't be hard to send a BGP feed to video streaming servers, and if the requestor's IP was from a prefix seen behind AS$foo, put up a message informing the subscriber that their access to $company's content would cease on such-and-such a date, due to $BB_provider's unwillingness to agree to increase interconnect capacity, and that if subscribers wished to continue to see $company's content, they should consider switching to a different network provider. Basically, follow the same model News Corp used against Cablevision, Viacom used against Time Warner, or Disney used against Cablevision. How long would $BB_provider be able to hold out against the howls of its users, if there was a scrolling banner across the top of the screen during their favorite show, or favorite movie alerting them that they would soon be unable to see that content unless they switched to a different service provider? It's easy to forget that the sword can be swung both ways. Right now, $BB_provider is swinging the sharp edge at $content; but $content is not without its own influence in the market, and could swing the sword the other way, cutting back at $BB_provider. Yes, it comes at some great risk to $content, in terms of potential customer loss; but no great wins come without great risks (unless you cheat, and use the government to get you a big win at no risk--but none of us like that model). I think it's high time for content players to flex their power, and push back on the eyeball networks that attempt to use their customer base as hostages to extract additional revenue from the content being requested by their users. If the content providers simply make it clearly visible to the end users that they cannot watch the requested content on that network, or that they can only watch in reduced resolution from that network, it will have a two-fold effect: a) traffic volume from the content provider to the contentious network will be reduced, limiting the need for the upgrades in the first place, and b) customers of the provider will be informed of their status as hostage cannon fodder on the battlefield, allowing them to vote with their wallets. One could potentially even insert suggestions for alternate connectivity options they might consider into the content feed, to help the users vote with their wallets more easily. Or, provide the phone number of the local municipal office that granted the franchise rights to the BB provider, along with instructions on what to say when calling ("Hi--I'm a registered voter in your district. If you'd like to get re-elected next term, you need to repeal the cable franchise agreement with broadband provider such-and-so, as their monopolistic practices are hampering my ability to freely choose what content I can consume.") We're not powerless in this fight. We often take a victim mindset, and look for some other entity to rescue us; but that's not the right way to thrive. Instead of thinking that we're weak, we're victims, and can't protect ourselves, or that we need some other big, strong entity to shelter and protect us, we need to realize that we *are* strong. We *are* capable of standing up and fighting back. We *do* have power, and can say no to the bullies. They want us to feel we have no say in the matter, that we cannot survive without protection. But they are wrong. We are strong. We are capable. We *can* fight back. For example, in Patrick's case (he being a Bostonian still, I believe), the municipal cable office responsible for the cable franchises in the city are handled by: http://www.cityofboston.gov/contact/?id=35 > > How is this good for the consumer? How is this good for the market? > > -- > TTFN, > patrick > > > http://m.washingtonpost.com/blogs/the-switch/wp/2014/04/23/the-fcc-is-planning-new-net-neutrality-rules-and-they-could-enshrine-pay-for-play/ > > > Composed on a virtual keyboard, please forgive typos. > > > I don't think it's good for the consumer or the market; but I also don't think it's just up to the government to step in and try to protect the consumer and the market. There's a lot we can do to shape the outcome, if we just step up to the plate and make our voices (and our wallets) heard. We are not victims. We *are* the market. Never forget; we have given them the power they currently have. And that means we can take it away again. It won't be easy. It won't be painless. But it *can* be done. Matt From bzs at world.std.com Sun Apr 27 19:02:51 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 27 Apr 2014 15:02:51 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: <21341.21595.606722.604991@world.std.com> On April 27, 2014 at 10:04 nick at pelagiris.org (Nick B) wrote: > The current scandal is not about peering, it is last mile ISP double > dipping. I'd characterize it as an attempt to charge content providers for access to last mile customers, where those are two different companies. Which isn't really different from what you said, just phrased a little differently. But more importantly I think it's an attempt to impose a Cable TV (sat tv, whatever) business model on the internet. That is, with CATV companies like HBO have to pay companies like Comcast for access to their cable subscribers. Since they grew up together it's all fairly symbiotic though we do see flare-ups like when Time-Warner decided to block CBS over "access" fees. Not clear how that would work if imposed on the internet space. Maybe get ready for basic, premium, and gold internet, gold includes Netflix streaming AND Amazon shopping! Something like that. What I'm more, or just as, concerned about is the end of just putting up a web site and hoping people come to it w/o a lot of capital. That is, launching a new web site becoming similar to launching a new cable TV channel (i.e., coordinating with and paying/licensing with the last-mile provider(s)) rather than whipping together some HTML and hoping for the best, etc. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mpetach at netflight.com Sun Apr 27 19:06:26 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 27 Apr 2014 12:06:26 -0700 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: On Sun, Apr 27, 2014 at 9:57 AM, Rick Astley wrote: [...] > It would be sort of the same concept of my grandmother > calling my cell phone yet we both need to pay for our individual phone > lines to at least reach the carrier tasked with connecting our call. Even > if my grandmother calls a business, that business have phone lines they pay > for. Technically this would be double dipping but it's been the norm for a > very long time. > Hi Rick, It's slightly worse than that. Allow me to expand your metaphor just a little bit. You pay for a phone connection to provider X. Your grandmother pays for a connection to provider Y. The connection between provider X and provider Y is handled by long-distance carrier Z. Provider X decides they don't like carrier Z, and won't add more capacity with carrier Z. Your grandmother tries to call you; but due to the lack of capacity between carrier Z and provider X, she gets an "all circuits are busy" message over and over again. Provider X tells provider Y that if wants to get its calls through, it will have to pay additional $$s *beyond* what it already pays to carrier Z, in order to connect to provider X so that those calls can go through. Provider Y is concerned that your poor grandmother may have a stroke due to all the stress and worry that she is undergoing, due to not being able to reach you on the telephone. So, with a heavy heart, they agree to pay provider X to connect additional circuits to provider Y, at a much higher cost. To avoid having to go bankrupt paying those additional costs, provider Y has to raise the cost for your poor grandmother's phone service. In order to pay the increased costs, she is forced to go without afternoon tea on weekends. And there is much sadness in the universe. That's where we are today. The content providers and the eyeball networks used to be just fine being connected through intermediate carriers. But now the eyeball networks are refusing to increase capacity with the intermediate carriers, telling content providers that they either need to pay additional money to connect directly to the eyeball networks, or deal with congestion ("all circuits busy" recordings for their customers). Nobody's asking for a free ride (well, other than $low_cost_transit_carrier, but I'm leaving them out of this discussion)--what they're objecting to is having to pay for their upstream transit circuits, and then *also pay additional money to bypass congestion, and talk to specific eyeball networks.* Hopefully that clarifies the situation a bit more. ^_^ Thanks! Matt From streiner at cluebyfour.org Sun Apr 27 16:23:27 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 27 Apr 2014 12:23:27 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> Message-ID: On Sun, 27 Apr 2014, Rick Astley wrote: > That amount of data is massive scale. I don't see it as double dipping > because each party is buying the pipe they are using. I am buying a 15Mbps > pipe to my home but just because we are communicating over the Internet > doesn't mean the money I am paying covers the cost of your connection too. > You must still buy your own pipe in the same way Netflix would. I covered > this scenario in more detail in my post "What Net Neutrality should and > should not cover" but if you expand on the assumption that paying for an > internet connection also pays for the direct connection of every party who > you exchange traffic with then you have a scenario where only half the > people connected to the Internet should have to pay at all for their > connection because any scenario where people simply buy their own pipe > would be considered "double billing". The size of the pipes involved doesn't change the fundamental premise that double-dipping is involved. Comcast, et al want to be paid twice for the same traffic. The money I pay Verizon every month for my Fios connection, by itself, doesn't pay for the rest of their network, but take the millions of Fios customers as a whole, and the revenue stream is significant. We'll leave the government-mandated revenue stream out of the equation for now. Just about every ISP, and certainly all of the big ones, practice statistical multiplexing - there is always some amount of oversubscription at play. Add up the subscription speeds of every Fios customer, and the total ingress/egress capacity of Verizon's network, and the two numbers will not be equal - not by a long shot. While 100G linecards and optics are still very expensive, those costs will come down over time. Even at that, the cost of adding a 100G link between Big Network A and Big Network B is at most pennies per customer. jms From owen at delong.com Sun Apr 27 20:21:55 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Apr 2014 13:21:55 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535C3C78.5080006@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> Message-ID: On Apr 26, 2014, at 4:08 PM, Larry Sheldon wrote: > On 4/26/2014 3:01 PM, Owen DeLong wrote: >> On Apr 24, 2014, at 8:38 PM, Larry Sheldon >> wrote: > >>> Monopolies can not persist without regulation. >> >> This is absolutely false. Regulating monopolies CAN protect >> monopolies, but that’s not always the outcome. >> >> Monopolies absolutely can persist without regulation. Except in the >> most highly dense population areas, there is not a sufficient market >> to support the deployment of more than one copy of a given media type >> to that population. As a result, there is, in most places, a natural >> monopoly in each media type, whether that’s electrical, water, cable, >> twisted pair, fiber, etc. > > Sounds like the market at work, not monopoly power......I've never heard the term "monopoly" used where the market contains all the players that want to play. It doesn’t. What it contains is all the players that can afford to play. When the number of players that can afford to play==1 that’s pretty much the definition of monopoly. If you want to try and pervert the term to meet your previous (bizarre) claims, then I’m sure you can do enough dancing around the dictionary to eventually arrive at your chosen destination. However, Patrick and I are more concerned with the actual outcome for consumers (including ourselves) than with the sophistry required to engage in the discussion you appear to want to have. Owen From owen at delong.com Sun Apr 27 20:27:29 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Apr 2014 13:27:29 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535C483D.4060800@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> Message-ID: <9E474C19-68D7-47CE-BE73-DB851AD1A905@delong.com> The comments on the article are FAR more useful than the article itself. Owen On Apr 26, 2014, at 4:58 PM, Larry Sheldon wrote: > h/t Suresh Ramasubramanian > > FCC throws in the towel on net neutrality > > http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ > > Forward! On to the next windmill, Sancho! > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) From johnl at iecc.com Sun Apr 27 20:30:05 2014 From: johnl at iecc.com (John Levine) Date: 27 Apr 2014 20:30:05 -0000 Subject: What Net Neutrality should and should not cover In-Reply-To: <21341.21595.606722.604991@world.std.com> Message-ID: <20140427203005.4853.qmail@joyce.lan> >That is, with CATV companies like HBO have to pay companies like >Comcast for access to their cable subscribers. Well, no. According to Time-Warner's 2013 annual report, cable companies paid T-W $4.89 billion for access to HBO and Cinemax. No video provider pays for access to cable. The cruddy ones like home shopping and 24/7 religion have small over the air stations and use the must-carry rule, everyone else gets paid something, in the case of ESPN quite a lot. There's a reason that T-W bought HBO and Comcast bought NBC, to capture all that money they'd been paying out. There's two separate issues here: one is that the Internet is a terrible way to deliver video. The Internet part of your cable connection is about 4 channels out of 500, and each of the other 496 is streaming high quality video. That little bit of Internet is designed for transactions (DNS, IM) and file transfer (mail and web), not streaming, so when you do stream it is jittery and lossy. Furthermore, nobody uses multicasting, if 400 customers on the same cable system are watching Game of Thrones, there's 400 copies of it cluttering up the tubes. In a non-stupid world, the cable companies would do video on demand through some combination of content caches at the head end or, for popular stuff, encrypted midnight downloads to your DVR, and the cablecos would split the revenue with content backends like Netflix. But this world is mostly stupid, the cable companies never got VOD, so you have companies like Netflix filling the gap with pessimized technology. (I do see that starting tomorrow, there will be a Netflix channel on three small cablecos including RCN, delivered via TiVo, although it's not clear if the delivery channel will change.) The other issue is that due to regulatory failure, cable companies are an oligopoly, and in most areas a local monopoly, so Comcast has the muscle to shake down Internet video providers. That's not a technical problem, it's a political one. In Europe, where DSL is a lot faster than here, carriage and content are separate and there are a zillion DSL providers. We could do that here if the FCC weren't so spineless. R's, John From bedard.phil at gmail.com Sun Apr 27 21:24:28 2014 From: bedard.phil at gmail.com (bedard.phil at gmail.com) Date: Sun, 27 Apr 2014 17:24:28 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: <20140427203005.4853.qmail@joyce.lan> References: <21341.21595.606722.604991@world.std.com> <20140427203005.4853.qmail@joyce.lan> Message-ID: <535d759b.445aec0a.4946.3e64@mx.google.com> At some point some the MSOs and telcos tried selling CDN to the streaming video people and they didn't want to partake. It was cheaper for them to keep streaming it off 3rd party CDNs. There are also some weird (dumb) legal/contractual issues around Netflix (or some other video provider) negotiated content residing on a box or even within a datacenter of another company who also has contracts with the content owner. All cable VOD for some time has been a distributed CDN albeit proprietary and ultimately delivered via QAMs, and still unicast. There are caches in headends and even further down in the access networks. The next generation of that is HTTP based though so any normal HTTP cache can be used. Comcast has contributed a bit to Apache Traffic Server as it plays a part in their next-gen video service delivery. I'd love to see wholesale networks. We saw that with DSL in the US quite a bit but eventually it all died out, and I highly doubt the ones running the networks would have allowed video services. All IP will happen on cable and once that happens most of the barriers to wholesale go away. So in 15 years things may be different. :) Phil -----Original Message----- From: "John Levine" Sent: ‎4/‎27/‎2014 4:33 PM To: "nanog at nanog.org" Subject: Re: What Net Neutrality should and should not cover >That is, with CATV companies like HBO have to pay companies like >Comcast for access to their cable subscribers. Well, no. According to Time-Warner's 2013 annual report, cable companies paid T-W $4.89 billion for access to HBO and Cinemax. No video provider pays for access to cable. The cruddy ones like home shopping and 24/7 religion have small over the air stations and use the must-carry rule, everyone else gets paid something, in the case of ESPN quite a lot. There's a reason that T-W bought HBO and Comcast bought NBC, to capture all that money they'd been paying out. There's two separate issues here: one is that the Internet is a terrible way to deliver video. The Internet part of your cable connection is about 4 channels out of 500, and each of the other 496 is streaming high quality video. That little bit of Internet is designed for transactions (DNS, IM) and file transfer (mail and web), not streaming, so when you do stream it is jittery and lossy. Furthermore, nobody uses multicasting, if 400 customers on the same cable system are watching Game of Thrones, there's 400 copies of it cluttering up the tubes. In a non-stupid world, the cable companies would do video on demand through some combination of content caches at the head end or, for popular stuff, encrypted midnight downloads to your DVR, and the cablecos would split the revenue with content backends like Netflix. But this world is mostly stupid, the cable companies never got VOD, so you have companies like Netflix filling the gap with pessimized technology. (I do see that starting tomorrow, there will be a Netflix channel on three small cablecos including RCN, delivered via TiVo, although it's not clear if the delivery channel will change.) The other issue is that due to regulatory failure, cable companies are an oligopoly, and in most areas a local monopoly, so Comcast has the muscle to shake down Internet video providers. That's not a technical problem, it's a political one. In Europe, where DSL is a lot faster than here, carriage and content are separate and there are a zillion DSL providers. We could do that here if the FCC weren't so spineless. R's, John From jra at baylink.com Sun Apr 27 22:00:53 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Apr 2014 18:00:53 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: Message-ID: <18037687.2301.1398636053796.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Chris Boyd" > I'd like to propose a new ICMP message type 3 code -- > > Communication with Destination Network is Financially Prohibited There is a SIP error that amounts to this; 480, I think. Though, of course, when I had a carrier who wouldn't complete calls cause they didn't like my balance, did they *use* that code? No, of course not. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Sun Apr 27 22:12:06 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Apr 2014 18:12:06 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <33CD70F8-A9C3-4C77-A39E-ECC2E07C5842@delong.com> Message-ID: <32192551.2305.1398636726909.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > In my neighborhood, Comcast has a monopoly on coax cable tv and HFC > internet services. There are no regulations that support that > monopoly. Another company could, theoretically, apply, receive > permits, and build out a second cable system if they wanted to. > However, the population density is such that even if that company > captured 50% of the market, it would merely make the market > economically unviable for both companies. > > In such instances, you do indeed have “natural monopolies” which are > an economic construct, not a regulatory artifact. And if this were not true, Verizon wouldn't have agitated to get it made illegal in 19 states for the local municipality to be the owner of that "natural monopoly" transport network; see also my month long thread on that topic and it's second and third order resultants in late 2012. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Sun Apr 27 22:15:21 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Apr 2014 18:15:21 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: Message-ID: <10215814.2307.1398636921832.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Hugo Slabbert" > But this isn't talking about transit; this is about Comcast as an edge > network in this context and Netflix as a content provider sending to > Comcast users the traffic that they requested. Is there really > anything more nuanced here than: > > 1. Comcast sells connectivity to their end users and sizes their > network according to an oversubscription ratio they're happy with. > (Nothing wrong here; oversubscription is a fact of life). > 2. Bandwidth-heavy applications like Netflix enter the market. > 3. Comcast's customers start using these bandwidth-heavy applications > and suck in more data than Comcast was betting on. > 4. Comcast has to upgrade connectivity, e.g. at peering points with > the heavy inbound traffic sources, accordingly in order to satisfy > their customers' usage. You may be new here, but I'm not, and I read it exactly the same way. > How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I > have capacity to handle that? I have gear; you have gear. I upgrade or > add ports on my side; you upgrade or add ports on your side. Am I > missing something? It is absolutely the problem of the eyeball carrier who gambled on a given oversubscription ratio and discovered that it's called gambling because sometimes, you lose. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Sun Apr 27 22:18:04 2014 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Apr 2014 18:18:04 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> Message-ID: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Hugo Slabbert" > I guess that's the question here: If additional transport directly > been POPs of the two parties was needed, somebody has to pay for the > links. Releases around the deal seemed to indicate that the peering > was happening at IXs (haven't checked this thoroughly), so at that > point it would seem reasonable for each party to handle their own > capacity to the peering points and call it even. No? And the answer is: at whose instance (to use an old Bell term) is that traffic moving. The answer is "at the instance of the eyeball's customers". So there's no call for the eyeball to charge the provider for it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From owen at delong.com Mon Apr 28 00:05:03 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Apr 2014 17:05:03 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> Message-ID: On Apr 26, 2014, at 11:23 PM, Rick Astley wrote: >> How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I have > capacity to handle that? I have gear; you have gear. I upgrade or add > ports on my side; you upgrade or add ports on your side. Am I missing > something? > > Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that > point of congestion is the links between Netflix and Comcast then Netflix > would be on the hook to ensure they have enough capacity to Comcast to get > the data at least gets TO the Comcast network. The argument at hand is if > Comcast permitted to charge them for the links to get to their network or > should they be free/settlement free. I think it should be OK to charge for > those links as long as its a fair market rate and the price doesn't > basically amount to extortion. Sadly the numbers are not public so I > couldn't tell you one way or the other aside from I disagree with the > position Netflix seems to be taking that they simply must be free. Once > that traffic is given directly to comcast no other party receives payment > for delivering it so there is no double billing. Beyond that, there’s a more subtle argument also going on about whether $EYEBALL_PROVIDER can provide favorable network access to $CONTENT_A and less favorable network access to $CONTENT_B as a method for encouraging subscribers to select $CONTENT_A over $CONTENT_B by affecting the relative performance. This becomes much stickier when you face the reality that in many places, $EYEBALL_PROVIDER has an effective monopoly as the only player choosing to offer services at a useful level of bandwidth/etc. (If that). Owen From bzs at world.std.com Mon Apr 28 01:03:59 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 27 Apr 2014 21:03:59 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <21341.16910.961998.901650@world.std.com> Message-ID: <21341.43263.28735.71504@world.std.com> Well, that's a metaphorical use of "fast lane" which is fine but I think the PR spin by CNBC was to actually give listeners the impression that they'd get faster service (e.g., on streaming video) now that this nasty FCC rule was out of the way. On April 27, 2014 at 14:07 bedard.phil at gmail.com (Phil Bedard) wrote: > The "Fast Lane" perhaps starts as not counting traffic against metered > byte caps, similar to what ATT did on their mobile network. If the > content/service provider is willing to pay the provider, then the users > may not pay overage fees or get nasty letters anymore when they exceed > data caps. The second and more contentious part of it is using QoS to > guarantee the content/service provider's traffic is delivered, at the > expense of traffic from those who aren't paying. So if Netflix decides to > pay and Amazon Prime doesn't, well Netflix will make it to your house and > Prime might not. Right now everyone's traffic gets dropped equally. :) > (Well more Netflix because there is a lot more of it). > > > -Phil (all opinions are my personal opinions) > > > > > On 4/27/14, 1:44 PM, "Barry Shein" wrote: > > > > >What are any of you talking about? Have you even bothered to read for > >example the wikipedia article on "monopoly" or are you so solipsistic > >that you just make up the entire universe in your head? Do you also > >pontificate on quantum physics and neurosurgery when the urge strikes > >you??? > > > >Sorry but this discussion is so, uneducated, usage of terms which are > >not as they are defined in the English or any other language, etc. > > > > > > > >But what do you think about the FCC's efforts in regard to "net > >neutrality"? > > > > > > > >Do you agree with CNBC's assessment that the internet has a "fast > >lane" and up until now FCC regulations prevented consumers and content > >providers from using it under the guise of "net neutrality". > > > >Do you believe there's anything at stake here for you beyond just > >nattering about your own personal and peculiar notion of what a > >"monopoly" is? Does that really matter to any of this? > > > >I almost believe that this entire flame war on the definition of > >monopoly is being fanned by sockpuppets whose job it is to make sure > >no one here talks about net neutrality in any effective or at least > >meaningful way. > > > > http://www.cnbc.com/id/101607254 > > > > F.C.C., in 'Net Neutrality' Turnaround, > > Plans to Allow Fast Lane > > > > The Federal Communications Commission will propose new rules that > > allow Internet service providers to offer a faster lane through > > which to send video and other content to consumers, as long as a > > content company is willing to pay for it, according to people > > briefed on the proposals. > > > > ... > > > >Would someone please define this "fast lane" for me? That would be a > >really good start. Preferably the managers of that fast lane because > >they surely must be on this list...no? > > > > > >P.S. CNBC is owned by Comcast (or more specifically NBC Universal, > >which is owned by Comcast.) > > > >-- > > -Barry Shein > > > >The World | bzs at TheWorld.com | > >http://www.TheWorld.com > >Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > >Canada > >Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Mon Apr 28 01:37:52 2014 From: bzs at world.std.com (Barry Shein) Date: Sun, 27 Apr 2014 21:37:52 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: <20140427203005.4853.qmail@joyce.lan> References: <21341.21595.606722.604991@world.std.com> <20140427203005.4853.qmail@joyce.lan> Message-ID: <21341.45296.546196.660882@world.std.com> I agree with all this, even the parts that disagree with me. -b On April 27, 2014 at 20:30 johnl at iecc.com (John Levine) wrote: > >That is, with CATV companies like HBO have to pay companies like > >Comcast for access to their cable subscribers. > > Well, no. According to Time-Warner's 2013 annual report, cable > companies paid T-W $4.89 billion for access to HBO and Cinemax. No > video provider pays for access to cable. The cruddy ones like home > shopping and 24/7 religion have small over the air stations and use > the must-carry rule, everyone else gets paid something, in the case of > ESPN quite a lot. There's a reason that T-W bought HBO and Comcast > bought NBC, to capture all that money they'd been paying out. > > There's two separate issues here: one is that the Internet is a > terrible way to deliver video. The Internet part of your cable > connection is about 4 channels out of 500, and each of the other 496 > is streaming high quality video. That little bit of Internet is > designed for transactions (DNS, IM) and file transfer (mail and web), > not streaming, so when you do stream it is jittery and lossy. > Furthermore, nobody uses multicasting, if 400 customers on the same > cable system are watching Game of Thrones, there's 400 copies of it > cluttering up the tubes. > > In a non-stupid world, the cable companies would do video on demand > through some combination of content caches at the head end or, for > popular stuff, encrypted midnight downloads to your DVR, and the > cablecos would split the revenue with content backends like Netflix. > But this world is mostly stupid, the cable companies never got VOD, so > you have companies like Netflix filling the gap with pessimized > technology. (I do see that starting tomorrow, there will be a Netflix > channel on three small cablecos including RCN, delivered via TiVo, > although it's not clear if the delivery channel will change.) > > The other issue is that due to regulatory failure, cable companies are > an oligopoly, and in most areas a local monopoly, so Comcast has the > muscle to shake down Internet video providers. That's not a technical > problem, it's a political one. In Europe, where DSL is a lot faster > than here, carriage and content are separate and there are a zillion > DSL providers. We could do that here if the FCC weren't so spineless. > > R's, > John From gih at apnic.net Mon Apr 28 02:33:05 2014 From: gih at apnic.net (Geoff Huston) Date: Mon, 28 Apr 2014 12:33:05 +1000 Subject: The Cidr Report In-Reply-To: References: <5.1.1.6.2.20140426210411.0549a1f8@efes.iucc.ac.il> <25FC66F4-6BDF-4585-85A2-CA046ACF5F5B@dds.nl> Message-ID: On 27 Apr 2014, at 5:19 am, Deepak Jain wrote: > >>> Historic event - 500K prefixes on the Internet. > >> And now we wait for everything to fall over at 512k ;) > > Based on a quick plot graph on the CIDR report, it looks like we are adding 6,000 prefixes a month, or thereabouts. So platforms that break at 512K die in two months or less? Sup720s may need to be reconfigured/rebooted, etc. > > Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack). > > > Check out pages 30 and 34 of http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf - a presentation I gave on predictions of BGP table size at NANOG 60 in February of this year. Geoff From mike at mtcc.com Mon Apr 28 02:33:30 2014 From: mike at mtcc.com (Michael Thomas) Date: Sun, 27 Apr 2014 19:33:30 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> Message-ID: <535DBDFA.405@mtcc.com> On 04/27/2014 05:05 PM, Owen DeLong wrote: > Beyond that, there’s a more subtle argument also going on about > whether $EYEBALL_PROVIDER can provide favorable network access to > $CONTENT_A and less favorable network access to $CONTENT_B as a method > for encouraging subscribers to select $CONTENT_A over $CONTENT_B by > affecting the relative performance. This becomes much stickier when > you face the reality that in many places, $EYEBALL_PROVIDER has an > effective monopoly as the only player choosing to offer services at a > useful level of bandwidth/etc. (If that). Isn't this all predicated that our crappy last mile providers continue with their crappy last mile service that is shameful for a supposed first world country? Cue up Randy on why this is all such a painful joke. Mike From goemon at anime.net Mon Apr 28 01:59:44 2014 From: goemon at anime.net (goemon at anime.net) Date: Sun, 27 Apr 2014 18:59:44 -0700 (PDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> Message-ID: If the carriers now get to play packet favoritism and pay-for-play, they should lose common carrier protections. -Dan From LarrySheldon at cox.net Mon Apr 28 02:56:58 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 27 Apr 2014 21:56:58 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> Message-ID: <535DC37A.50707@cox.net> On 4/27/2014 8:59 PM, goemon at anime.net wrote: > If the carriers now get to play packet favoritism and pay-for-play, they > should lose common carrier protections. I didn't think the Internet providers were common carriers. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From owen at delong.com Mon Apr 28 02:57:44 2014 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Apr 2014 19:57:44 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> Message-ID: And Carterphone should apply to cellular networks, but I am not holding my breath. Owen On Apr 27, 2014, at 6:59 PM, goemon at anime.net wrote: > If the carriers now get to play packet favoritism and pay-for-play, they should lose common carrier protections. > > -Dan From jnanog at gmail.com Mon Apr 28 03:07:55 2014 From: jnanog at gmail.com (Rick Astley) Date: Sun, 27 Apr 2014 23:07:55 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535DBDFA.405@mtcc.com> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> Message-ID: >Isn't this all predicated that our crappy last mile providers continue with their crappy last mile If you think prices for residential broadband are bad now if you passed a law that says all content providers big and small must have settlement free access to the Internet paid for by residential subscribers what do you think it would do to the price of broadband? On Sun, Apr 27, 2014 at 10:33 PM, Michael Thomas wrote: > On 04/27/2014 05:05 PM, Owen DeLong wrote: > >> Beyond that, there’s a more subtle argument also going on about whether >> $EYEBALL_PROVIDER can provide favorable network access to $CONTENT_A and >> less favorable network access to $CONTENT_B as a method for encouraging >> subscribers to select $CONTENT_A over $CONTENT_B by affecting the relative >> performance. This becomes much stickier when you face the reality that in >> many places, $EYEBALL_PROVIDER has an effective monopoly as the only player >> choosing to offer services at a useful level of bandwidth/etc. (If that). >> > > > Isn't this all predicated that our crappy last mile providers continue > with their crappy last mile > service that is shameful for a supposed first world country? > > Cue up Randy on why this is all such a painful joke. > > Mike > From hslabbert at stargate.ca Mon Apr 28 03:52:19 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Mon, 28 Apr 2014 03:52:19 +0000 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local>, Message-ID: <6c7607db2d5c4ad398edba13f7a7373f@STCOEX01.stargate.local> Apologies that I dropped offlist as I was out for the day. I think the bulk of my thoughts on this have already been covered by others since, including e.g. Matt's poor grandmother and her phone dilemma in the "What Net Neutrality should and should not cover" thread. Basically I think we're on the same page for the most part, with maybe some misunderstandings between us. > I covered this scenario in more detail in my post "What Net Neutrality should and should not cover" but if you expand on the assumption that paying for an internet connection also pays for the direct connection of every party who you exchange traffic with then you have a scenario where only half the people connected to the Internet should have to pay at all for their connection because any scenario where people simply buy their own pipe would be considered "double billing". I don't think anyone on the Netflix^H^H^H^H^H^H $ContentProvider side of this was saying that $ContentProvider should get everything handed to them on a silver platter. $ContentProvider pays for transit sufficient to handle the traffic that their customers request. $EyeballNetwork's customers pay it for internet access, i.e. to deliver the content that they request, e.g. from $ContentProvider. That covers both directions here. Links between $ContentProvider's transit provider and $EyeballNetwork were getting congested, and $EyeballNetwork refuses to upgrade capacity. Where we were getting into the double-dip was $EyeballNetwork saying to $ContentProvide: "Hey, we know you already pay for transit, but you're gonna have to pay us as well if you want us to actually accept the traffic our customers requested". The alternate arrangement between $ContentProvider and $EyeballNetwork seems to be private peering, where again it would seem to be fair for each side to bring the needed transport and ports to peering points. In recent history, though, it seems that $EyeballNetwork came out ahead in that agreement somehow. Now, Tore brought up a good point on paid peering in cases where e.g. $EyeballNetwork is already exchanging traffic with $ContentProvider through existing peering or below their CDR on existing transit, and indeed it seems that was the case for $EyeballNetwork via peering with $CheapTransitProvider that $ContentProvider was using. But it seems that $EyeballNetwork was having a pissing match with $CheapTransitProvider and refusing to upgrade ports. "Okay", says $ContentProvider. "How about we just peer directly." "Sounds great," says $EyeballNetwork. "Since we have to allocate capacity for this discrete from our existing peering capacity, you'll need to foot the bill for that." "Huh?" says $ContentProvider. "This could have been fixed by you increasing your peering capacity to match the traffic volume your users are requesting, but you didn't want to do that because of your tiff with $CheapTransitProvider. Tell me again why we're paying for your side of this *in addition* to our own when we're only going this route because of a decision *you* made?" "Because you need to reach our customers, and we're the only path to them, so we have leverage." *blank stare* "So you're willing to give your customers crappy service because your customers don't have alternate options and you think we need this more than you do?" "That's a possibility." "I hate you." "I know; sign here please." But, again, this is outside looking in. For now, I'll pick up a copy of Bill Norton's Internet Peering book as per Bob's suggestion, for some light Sunday night reading. Cheers, -- Hugo ________________________________ From: Rick Astley Sent: Sunday, April 27, 2014 8:45 AM To: Hugo Slabbert Cc: nanog at nanog.org Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post If it were through a switch at the exchange it would be on each of them to individually upgrade their capacity to it but at the capacities they are at it they are beyond what would make sense financially to go over an exchange switch so they would connect directly instead. It's likely more along the lines of needing several 100G ports as Netflix is over 30% of peak usage traffic in North America: "Netflix (31.6%) holds its ground as the leading downstream application in North America and together with YouTube (18.6%) accounts for over 50% of downstream traffic on fixed networks." (source https://www.sandvine.com/trends/global-internet-phenomena/ ) That amount of data is massive scale. I don't see it as double dipping because each party is buying the pipe they are using. I am buying a 15Mbps pipe to my home but just because we are communicating over the Internet doesn't mean the money I am paying covers the cost of your connection too. You must still buy your own pipe in the same way Netflix would. I covered this scenario in more detail in my post "What Net Neutrality should and should not cover" but if you expand on the assumption that paying for an internet connection also pays for the direct connection of every party who you exchange traffic with then you have a scenario where only half the people connected to the Internet should have to pay at all for their connection because any scenario where people simply buy their own pipe would be considered "double billing". The cost for residential broadband is high enough in the US without a policy like that in place. If there is one policy that would keep poor families from being able to afford broadband it would be that one. On Sun, Apr 27, 2014 at 2:58 AM, Hugo Slabbert > wrote: > ...but if that point of congestion is the links between Netflix and Comcast... Which, from the outside, does appear to have been the case. > ...then Netflix would be on the hook to ensure they have enough capacity to Comcast to get the data at least gets TO the Comcast network. Which I don't believe was a problem? Again, outside looking in, but the appearances seemed to indicate that Comcast was refusing to upgrade capacity/ports, whereas I didn't see anything indicating that Netflix was doing the same. So: > I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. > The argument at hand is if Comcast permitted to charge them for the links to get to their network or should they be free/settlement free. I think it should be OK to charge for those links as long as its a fair market rate and the price doesn't basically amount to extortion. Are we talking here about transport between Netflix's POPs and Comcast's? I definitely don't expect Comcast to foot the bill for transport between the two, and if Netflix was asking for that I'm with you that would be out of line. If there are existing exchange points, though, would it not be reasonable to expect each side to up their capacity at those points? > Once that traffic is given directly to comcast no other party receives payment for delivering it so there is no double billing. The "double-dip" reference was to charging both the content provider and the ISP's own customer to deliver the same bits. If the traffic from Netflix was via Netflix's transit provider and Comcast then again was looking to bill Netflix to accept the traffic, we'd hit double billing. I guess that's the question here: If additional transport directly been POPs of the two parties was needed, somebody has to pay for the links. Releases around the deal seemed to indicate that the peering was happening at IXs (haven't checked this thoroughly), so at that point it would seem reasonable for each party to handle their own capacity to the peering points and call it even. No? -- Hugo ________________________________ From: Rick Astley > Sent: Saturday, April 26, 2014 11:23 PM To: Hugo Slabbert Cc: nanog at nanog.org Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post >How is this *not* Comcast's problem? If my users are requesting more traffic than I banked on, how is it not my responsibility to ensure I have capacity to handle that? I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. Am I missing something? Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that point of congestion is the links between Netflix and Comcast then Netflix would be on the hook to ensure they have enough capacity to Comcast to get the data at least gets TO the Comcast network. The argument at hand is if Comcast permitted to charge them for the links to get to their network or should they be free/settlement free. I think it should be OK to charge for those links as long as its a fair market rate and the price doesn't basically amount to extortion. Sadly the numbers are not public so I couldn't tell you one way or the other aside from I disagree with the position Netflix seems to be taking that they simply must be free. Once that traffic is given directly to comcast no other party receives payment for delivering it so there is no double billing. This diagram best describes the relationship (ignoring pricing): http://www.digitalsociety.org/files/gou/free-and-paid-peering.png "Content provider" would be Netflix and Comcast would be Broadband ISP 1. On Sun, Apr 27, 2014 at 1:56 AM, Hugo Slabbert >> wrote: Okay, I'm not as seasoned as a big chunk of this list, but please correct me if I'm wrong in finding this article a crock of crap. With Comcast/Netflix being in the mix and by association Cogent in the background of that there's obviously room for some heated opinions, but here goes anyway... >A long, long time ago when the Internet was young and few, if any had thought >to make a profit off it, an unofficial system developed among the network >providers who carried the traffic: You carry my traffic and I'll carry yours >and we don't need money to change hands. This system has collapsed under >modern realities. I wasn't aware that settlement-free peering had "collapsed". Not saying it's the "only way", but "she ain't dead yet". Seltzer uses that to set up balanced ratios as the secret sauce that makes settlement-free peering viable: "The old system made sense when the amount of traffic each network was sending to the other was roughly equivalent." ...and since Netflix sends Comcast more than it gets, therefor Netflix needs to buck up: "Of course Netflix should pay network providers in order to get the huge amounts of bandwidth they require in order to reach their customers with sufficient quality." But this isn't talking about transit; this is about Comcast as an edge network in this context and Netflix as a content provider sending to Comcast users the traffic that they requested. Is there really anything more nuanced here than: 1. Comcast sells connectivity to their end users and sizes their network according to an oversubscription ratio they're happy with. (Nothing wrong here; oversubscription is a fact of life). 2. Bandwidth-heavy applications like Netflix enter the market. 3. Comcast's customers start using these bandwidth-heavy applications and suck in more data than Comcast was betting on. 4. Comcast has to upgrade connectivity, e.g. at peering points with the heavy inbound traffic sources, accordingly in order to satisfy their customers' usage. How is this *not* Comcast's problem? If my users are requesting more traffic than I banked on, how is it not my responsibility to ensure I have capacity to handle that? I have gear; you have gear. I upgrade or add ports on my side; you upgrade or add ports on your side. Am I missing something? Overall it seems like a bad (and very public) precedent & shift towards double dipping, and the pay-for-play bits in the bastardized "Open Internet" rules don't help on that front. Now, Comcast is free to leverage their customers as bargaining chips to try to extract payments, and Randy's line of encouraging his competitors to do this sort thing seems fitting here. Basically this doesn't harm me directly at this point. Considering the lack of broadband options for large parts of the US, though, it seems that end users are getting the short end of the stick without any real recourse while that plays out. -- Hugo ________________________________________ From: NANOG >> on behalf of Larry Sheldon >> Sent: Saturday, April 26, 2014 4:58 PM To: nanog at nanog.org> Subject: Re: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post h/t Suresh Ramasubramanian FCC throws in the towel on net neutrality http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ Forward! On to the next windmill, Sancho! -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From jnanog at gmail.com Mon Apr 28 04:17:07 2014 From: jnanog at gmail.com (Rick Astley) Date: Mon, 28 Apr 2014 00:17:07 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: >Double-billing Rick. It's just that simple. Paid peering means you're deliberately billing two customers for the same byte I think this statement is a little short sighted if not a bit naive. What both parties are sold is a pipe that carries data. A subscriber has one, Netflix has one. They are different bandwidths, at different locations, and have different costs. Where your statement is short sighted I already explained partly in saying its too difficult to decide who gets a free ride and who gets the bill so I challenge you to propose an actual policy that prohibits charging for peering that doesn't have major unintended consequences. All in all I am sort of disappointed to find so few rational opinions around here. One of the few decent articles I have read on it is here: http://blog.streamingmedia.com/2014/02/media-botching-coverage-netflix-comcast-deal-getting-basics-wrong.html I think if you make a law that says all content providers big and small get free pipes and the residential subscribers of broadband must pay the tab the cost of broadband in the US compared to the rest of the world skyrocket. I also think the practice of paying an intermediary ISP a per Mbps rate in order to get to a last mile ISP over a settlement free agreement is also a bit disingenuous in cases where the amount of traffic is sufficient enough to fill multiple links. Theoretically there are many times where the intermediary ISP can hand off the traffic to a last mile ISP in exactly the same building they received it in so they have very few of the costs of actually delivering the traffic yet are the only party receiving money from the content provider for delivery. This arrangement makes sense when the traffic to the last mile ISP is a percentage of one link but after enough links are involved the intermediary ISP is serving no real other purpose than as a loophole used to circumvent paid peering fees (right or wrong). I think if paid peering were made illegal overnight for companies big or small the landscape of the Internet would be completely redrawn and not for the better. I honestly think what last mile ISP's should do in this situation is to offer to provide transit for content delivery for a low cost. They generally have available outbound capacity to other networks and they can play the "settlement free only" card back at some of the companies they are in dispute with. If nothing else it would result in having similar traffic profiles and settlement free would start to make more sense so everybody wins. On Sun, Apr 27, 2014 at 1:56 PM, William Herrin wrote: > On Sun, Apr 27, 2014 at 2:05 AM, Rick Astley wrote: > > #3 On paid peering: > > I think this is where people start to disagree but I don't see what > should > > be criminal about paid peering agreements. More specifically, I see > serious > > problems once you outlaw paid peering and then look at the potential > > repercussions that would have. > > Double-billing Rick. It's just that simple. Paid peering means you're > deliberately billing two customers for the same byte -- the peer and > the downstream. And not merely incidental to ordinary service - the > peer specifically connects to gain access to customers who already pay > you and no one else. Where those two customers have divergent > interests, you have to pick which one you'll serve even as you > continue to bill both. That's a corrupt practice. > > What sort of corrupt practice? You might, for example, degrade your > residential customers' speed to the part of the Internet housing a > company you think should pay you for peering. Or permit the link to > deteriorate while energetically upgrading others to keep pace with the > times. Same difference. > > This doesn't have to be true. You could bill downstreams for > consumption and exclude the paid peering from that calculation. But > you don't do that. And you aren't planning to. > > > > #4 On QoS (ie fast lane?): > > In some of the articles I skimmed there was a lot of talk about fast lane > > traffic but what this sounds like today would be known as QoS and > > classification marking that would really only become a factor under > > instances of congestion. The tech bloggers and journalists all seems to > be > > unanimously opposed to this but I admit I am sort of scratching my head > at > > the outrage over something that has been in prevalent use on many major > > networks for several years. > > It's prevalent on private work networks and users hate it. It > generally disables activities the network owners don't approve of > while engaging in doubletalk about how they're OK with it. Users don't > want to see this migrate outward. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From hslabbert at stargate.ca Mon Apr 28 04:31:37 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Mon, 28 Apr 2014 04:31:37 +0000 Subject: What Net Neutrality should and should not cover In-Reply-To: References: , Message-ID: <1bc147bd4c894fde87721dbf5f4a4fb1@STCOEX01.stargate.local> >> #4 On QoS (ie fast lane?): >> In some of the articles I skimmed there was a lot of talk about fast lane >> traffic but what this sounds like today would be known as QoS and >> classification marking that would really only become a factor under >> instances of congestion. The tech bloggers and journalists all seems to be >> unanimously opposed to this but I admit I am sort of scratching my head at >> the outrage over something that has been in prevalent use on many major >> networks for several years. > >It's prevalent on private work networks and users hate it. It >generally disables activities the network owners don't approve of >while engaging in doubletalk about how they're OK with it. Users don't >want to see this migrate outward. > >Regards, >Bill Herrin A couple of things come into play here, I think: 1. Prevalence of congestion on shared-bandwidth media, e.g. cable. 2. Who controls the QoS? A thumbsuck seems to indicate that #1 is high or at least significant enough to cause user-visible impact in e.g. places where cable internet providers in the US don't face any real competition. So, QoS measures can come into play in those locales/situations. For #2: QoS is good. Deciding which traffic gets passed and which dropped in congestion is, in and of itself, a good ability to have and can be a great value-added service. "You want to run VoIP on the same line as your regular data but want to ensure your VoIP traffic gets through? No problem: Here's our QoS-Extraordinaire service!" The concern comes from the direction the rules seem to be taking on this in shifting control/input on how QoS is applied from (a) just ensuring network-control doesn't get drowned out and (b) a value-add service where the customer picks their traffic prioritization, to an external party paying for preferred access to the BB-provider's customers. As a customer of BB-provider, this means that someone else now has control over how my packets get delivered based on a deal they cut with BB-provider. It's not about helping the end-user: It's about enriching BB-provider. It's another situation of opening up a two-sided market and fostering a situation where established players on the content side who can afford to pay BB-providers A through ZZ get beneficial treatment and there can be a larger barrier to entry to the markets occupied by those players. Yes, QoS should only come into play where congestion is involved. But, from experience we can see there are ways to let BE traffic degrade to affect e.g. latency-sensitive traffic without having to actively throttle it. Sure: the "commercially unreasonable" clauses *should* protect against that to a degree, but that's a very vague definition that creates a lot more regulatory overhead. Rather than saying "you're not allowed to accept payment to prioritize one content provider's traffic over another's," the FCC would now have to investigate this situations on a case by case basis to determine if a specific situation is "commercially unreasonable". So; basically, how much confidence do we have in the FCC's capacity/competence in enforcement of those types of regulations? We could also tack on that this could create a "barn door" situation, where lax or vague rules go into effect, "the market decides", and then we have a helluva time trying to stuff the cat back in the bag because at that point this type of preferential treatment would already be an established/common practice. -- Hugo Network Specialist Phone: 604.606.4448 Email: hslabbert at stargate.ca Stargate Connections Inc. http://www.stargate.ca ________________________________________ From: NANOG on behalf of William Herrin Sent: Sunday, April 27, 2014 10:56 AM To: Rick Astley Cc: NANOG Operators' Group Subject: Re: What Net Neutrality should and should not cover On Sun, Apr 27, 2014 at 2:05 AM, Rick Astley wrote: > #3 On paid peering: > I think this is where people start to disagree but I don't see what should > be criminal about paid peering agreements. More specifically, I see serious > problems once you outlaw paid peering and then look at the potential > repercussions that would have. Double-billing Rick. It's just that simple. Paid peering means you're deliberately billing two customers for the same byte -- the peer and the downstream. And not merely incidental to ordinary service - the peer specifically connects to gain access to customers who already pay you and no one else. Where those two customers have divergent interests, you have to pick which one you'll serve even as you continue to bill both. That's a corrupt practice. What sort of corrupt practice? You might, for example, degrade your residential customers' speed to the part of the Internet housing a company you think should pay you for peering. Or permit the link to deteriorate while energetically upgrading others to keep pace with the times. Same difference. This doesn't have to be true. You could bill downstreams for consumption and exclude the paid peering from that calculation. But you don't do that. And you aren't planning to. > #4 On QoS (ie fast lane?): > In some of the articles I skimmed there was a lot of talk about fast lane > traffic but what this sounds like today would be known as QoS and > classification marking that would really only become a factor under > instances of congestion. The tech bloggers and journalists all seems to be > unanimously opposed to this but I admit I am sort of scratching my head at > the outrage over something that has been in prevalent use on many major > networks for several years. It's prevalent on private work networks and users hate it. It generally disables activities the network owners don't approve of while engaging in doubletalk about how they're OK with it. Users don't want to see this migrate outward. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jnanog at gmail.com Mon Apr 28 04:57:06 2014 From: jnanog at gmail.com (Rick Astley) Date: Mon, 28 Apr 2014 00:57:06 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <6c7607db2d5c4ad398edba13f7a7373f@STCOEX01.stargate.local> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> <6c7607db2d5c4ad398edba13f7a7373f@STCOEX01.stargate.local> Message-ID: Here is a quote I made in the other thread around the same time you were sending this: "I also think the practice of paying an intermediary ISP a per Mbps rate in order to get to a last mile ISP over a settlement free agreement is also a bit disingenuous in cases where the amount of traffic is sufficient enough to fill multiple links. Theoretically there are many times where the intermediary ISP can hand off the traffic to a last mile ISP in exactly the same building they received it in so they have very few of the costs of actually delivering the traffic yet are the only party receiving money from the content provider for delivery. This arrangement makes sense when the traffic to the last mile ISP is a percentage of one link but after enough links are involved the intermediary ISP is serving no real other purpose than as a loophole used to circumvent paid peering fees (right or wrong)." I think we are in agreement that $EyeballNetwork's customers pay it for internet access and $ContentProvider should pay for their own pipes. But where we diverge is with $CheapTransitProvider. At least for the purpose of traffic following the path of $ContentProvider > $CheapTransitProvider > $EyeballNetwork's because there is so much traffic involved the only real purpose of the relationship with $CheapTransitProvider is a loophole to get around paying $EyeballNetwork. They are able to charge ridiculously low delivery prices because traffic is only on their network for just long enough to say it touched and should now be considered settlement free. It's little more than a cheap trick and it makes them sort of the Cash4Gold of the Internet. I can completely understand why $EyeballNetwork would tell $CheapTransitProvider they no longer choose to have a settlement free agreement and they must buy future ports. On Sun, Apr 27, 2014 at 11:52 PM, Hugo Slabbert wrote: > Apologies that I dropped offlist as I was out for the day. I think the > bulk of my thoughts on this have already been covered by others since, > including e.g. Matt's poor grandmother and her phone dilemma in the "What > Net Neutrality should and should not cover" thread. > > Basically I think we're on the same page for the most part, with maybe > some misunderstandings between us. > > > I covered this scenario in more detail in my post "What Net Neutrality > should and should not cover" but if you expand on the assumption that > paying for an internet connection also pays for the direct connection of > every party who you exchange traffic with then you have a scenario where > only half the people connected to the Internet should have to pay at all > for their connection because any scenario where people simply buy their own > pipe would be considered "double billing". > > I don't think anyone on the Netflix^H^H^H^H^H^H $ContentProvider side of > this was saying that $ContentProvider should get everything handed to them > on a silver platter. $ContentProvider pays for transit sufficient to > handle the traffic that their customers request. $EyeballNetwork's > customers pay it for internet access, i.e. to deliver the content that they > request, e.g. from $ContentProvider. That covers both directions here. > Links between $ContentProvider's transit provider and $EyeballNetwork were > getting congested, and $EyeballNetwork refuses to upgrade capacity. Where > we were getting into the double-dip was $EyeballNetwork saying to > $ContentProvide: "Hey, we know you already pay for transit, but you're > gonna have to pay us as well if you want us to actually accept the traffic > our customers requested". > > The alternate arrangement between $ContentProvider and $EyeballNetwork > seems to be private peering, where again it would seem to be fair for each > side to bring the needed transport and ports to peering points. In recent > history, though, it seems that $EyeballNetwork came out ahead in that > agreement somehow. Now, Tore brought up a good point on paid peering in > cases where e.g. $EyeballNetwork is already exchanging traffic with > $ContentProvider through existing peering or below their CDR on existing > transit, and indeed it seems that was the case for $EyeballNetwork via > peering with $CheapTransitProvider that $ContentProvider was using. But it > seems that $EyeballNetwork was having a pissing match with > $CheapTransitProvider and refusing to upgrade ports. > > "Okay", says $ContentProvider. "How about we just peer directly." > "Sounds great," says $EyeballNetwork. "Since we have to allocate capacity > for this discrete from our existing peering capacity, you'll need to foot > the bill for that." > "Huh?" says $ContentProvider. "This could have been fixed by you > increasing your peering capacity to match the traffic volume your users are > requesting, but you didn't want to do that because of your tiff with > $CheapTransitProvider. Tell me again why we're paying for your side of > this *in addition* to our own when we're only going this route because of a > decision *you* made?" > "Because you need to reach our customers, and we're the only path to them, > so we have leverage." > *blank stare* > "So you're willing to give your customers crappy service because your > customers don't have alternate options and you think we need this more than > you do?" > "That's a possibility." > "I hate you." > "I know; sign here please." > > But, again, this is outside looking in. For now, I'll pick up a copy of > Bill Norton's Internet Peering book as per Bob's suggestion, for some light > Sunday night reading. > > Cheers, > > -- > Hugo > > ________________________________ > From: Rick Astley > Sent: Sunday, April 27, 2014 8:45 AM > To: Hugo Slabbert > Cc: nanog at nanog.org > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > If it were through a switch at the exchange it would be on each of them to > individually upgrade their capacity to it but at the capacities they are at > it they are beyond what would make sense financially to go over an exchange > switch so they would connect directly instead. It's likely more along the > lines of needing several 100G ports as Netflix is over 30% of peak usage > traffic in North America: > > "Netflix (31.6%) holds its ground as the leading downstream application in > North America and together with YouTube (18.6%) accounts for over 50% of > downstream traffic on fixed networks." (source > https://www.sandvine.com/trends/global-internet-phenomena/ ) > > That amount of data is massive scale. I don't see it as double dipping > because each party is buying the pipe they are using. I am buying a 15Mbps > pipe to my home but just because we are communicating over the Internet > doesn't mean the money I am paying covers the cost of your connection too. > You must still buy your own pipe in the same way Netflix would. I covered > this scenario in more detail in my post "What Net Neutrality should and > should not cover" but if you expand on the assumption that paying for an > internet connection also pays for the direct connection of every party who > you exchange traffic with then you have a scenario where only half the > people connected to the Internet should have to pay at all for their > connection because any scenario where people simply buy their own pipe > would be considered "double billing". > > The cost for residential broadband is high enough in the US without a > policy like that in place. If there is one policy that would keep poor > families from being able to afford broadband it would be that one. > > > > > > On Sun, Apr 27, 2014 at 2:58 AM, Hugo Slabbert > wrote: > > > ...but if that point of congestion is the links between Netflix and > Comcast... > > Which, from the outside, does appear to have been the case. > > > ...then Netflix would be on the hook to ensure they have enough capacity > to Comcast to get the data at least gets TO the Comcast network. > > Which I don't believe was a problem? Again, outside looking in, but the > appearances seemed to indicate that Comcast was refusing to upgrade > capacity/ports, whereas I didn't see anything indicating that Netflix was > doing the same. So: > > I have gear; you have gear. I upgrade or add ports on my side; you > upgrade or add ports on your side. > > > > The argument at hand is if Comcast permitted to charge them for the > links to get to their network or should they be free/settlement free. I > think it should be OK to charge for those links as long as its a fair > market rate and the price doesn't basically amount to extortion. > > Are we talking here about transport between Netflix's POPs and Comcast's? > I definitely don't expect Comcast to foot the bill for transport between > the two, and if Netflix was asking for that I'm with you that would be out > of line. If there are existing exchange points, though, would it not be > reasonable to expect each side to up their capacity at those points? > > > > Once that traffic is given directly to comcast no other party receives > payment for delivering it so there is no double billing. > > The "double-dip" reference was to charging both the content provider and > the ISP's own customer to deliver the same bits. If the traffic from > Netflix was via Netflix's transit provider and Comcast then again was > looking to bill Netflix to accept the traffic, we'd hit double billing. > > I guess that's the question here: If additional transport directly been > POPs of the two parties was needed, somebody has to pay for the links. > Releases around the deal seemed to indicate that the peering was happening > at IXs (haven't checked this thoroughly), so at that point it would seem > reasonable for each party to handle their own capacity to the peering > points and call it even. No? > > -- > Hugo > > ________________________________ > From: Rick Astley > > Sent: Saturday, April 26, 2014 11:23 PM > To: Hugo Slabbert > Cc: nanog at nanog.org > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > >How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I have > capacity to handle that? I have gear; you have gear. I upgrade or add > ports on my side; you upgrade or add ports on your side. Am I missing > something? > > Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that > point of congestion is the links between Netflix and Comcast then Netflix > would be on the hook to ensure they have enough capacity to Comcast to get > the data at least gets TO the Comcast network. The argument at hand is if > Comcast permitted to charge them for the links to get to their network or > should they be free/settlement free. I think it should be OK to charge for > those links as long as its a fair market rate and the price doesn't > basically amount to extortion. Sadly the numbers are not public so I > couldn't tell you one way or the other aside from I disagree with the > position Netflix seems to be taking that they simply must be free. Once > that traffic is given directly to comcast no other party receives payment > for delivering it so there is no double billing. > > This diagram best describes the relationship (ignoring pricing): > http://www.digitalsociety.org/files/gou/free-and-paid-peering.png > > "Content provider" would be Netflix and Comcast would be Broadband ISP 1. > > > > > On Sun, Apr 27, 2014 at 1:56 AM, Hugo Slabbert hslabbert at stargate.ca>>> wrote: > Okay, I'm not as seasoned as a big chunk of this list, but please correct > me if I'm wrong in finding this article a crock of crap. With > Comcast/Netflix being in the mix and by association Cogent in the > background of that there's obviously room for some heated opinions, but > here goes anyway... > > >A long, long time ago when the Internet was young and few, if any had > thought > >to make a profit off it, an unofficial system developed among the network > >providers who carried the traffic: You carry my traffic and I'll carry > yours > >and we don't need money to change hands. This system has collapsed under > >modern realities. > > I wasn't aware that settlement-free peering had "collapsed". Not saying > it's the "only way", but "she ain't dead yet". > > Seltzer uses that to set up balanced ratios as the secret sauce that makes > settlement-free peering viable: > "The old system made sense when the amount of traffic each network was > sending to the other was roughly equivalent." > > ...and since Netflix sends Comcast more than it gets, therefor Netflix > needs to buck up: > "Of course Netflix should pay network providers in order to get the huge > amounts of bandwidth they require in order to reach their customers with > sufficient quality." > > But this isn't talking about transit; this is about Comcast as an edge > network in this context and Netflix as a content provider sending to > Comcast users the traffic that they requested. Is there really anything > more nuanced here than: > > 1. Comcast sells connectivity to their end users and sizes their network > according to an oversubscription ratio they're happy with. (Nothing wrong > here; oversubscription is a fact of life). > 2. Bandwidth-heavy applications like Netflix enter the market. > 3. Comcast's customers start using these bandwidth-heavy applications and > suck in more data than Comcast was betting on. > 4. Comcast has to upgrade connectivity, e.g. at peering points with the > heavy inbound traffic sources, accordingly in order to satisfy their > customers' usage. > > How is this *not* Comcast's problem? If my users are requesting more > traffic than I banked on, how is it not my responsibility to ensure I have > capacity to handle that? I have gear; you have gear. I upgrade or add > ports on my side; you upgrade or add ports on your side. Am I missing > something? > > Overall it seems like a bad (and very public) precedent & shift towards > double dipping, and the pay-for-play bits in the bastardized "Open > Internet" rules don't help on that front. Now, Comcast is free to leverage > their customers as bargaining chips to try to extract payments, and Randy's > line of encouraging his competitors to do this sort thing seems fitting > here. Basically this doesn't harm me directly at this point. Considering > the lack of broadband options for large parts of the US, though, it seems > that end users are getting the short end of the stick without any real > recourse while that plays out. > > -- > Hugo > > ________________________________________ > From: NANOG >>> on > behalf of Larry Sheldon >>> > Sent: Saturday, April 26, 2014 4:58 PM > To: nanog at nanog.org nanog at nanog.org>> > Subject: Re: The FCC is planning new net neutrality rules. And they could > enshrine pay-for-play. - The Washington Post > > h/t Suresh Ramasubramanian > > FCC throws in the towel on net neutrality > > http://www.zdnet.com/fcc-throws-in-the-towel-on-net-neutrality-7000028770/ > > Forward! On to the next windmill, Sancho! > -- > Requiescas in pace o email Two identifying characteristics > of System Administrators: > Ex turpi causa non oritur actio Infallibility, and the ability to > learn from their mistakes. > (Adapted from Stephen Pinker) > > > From andy at nosignal.org Mon Apr 28 07:27:38 2014 From: andy at nosignal.org (Andy Davidson) Date: Mon, 28 Apr 2014 07:27:38 +0000 Subject: We hit half-million: The Cidr Report In-Reply-To: <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> Message-ID: Hi, Patrick wrote: > > 25-04-14 500177 282878 > I think congratulations are still in order, but frankly, > I am less impressed with getting to 500 than 150. [...] > Anyway, congratulations everyone. .... now aggregate it back down again, please. :-) (If only) Andy From mpetach at netflight.com Mon Apr 28 08:25:21 2014 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 28 Apr 2014 01:25:21 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> <6c7607db2d5c4ad398edba13f7a7373f@STCOEX01.stargate.local> Message-ID: On Sun, Apr 27, 2014 at 9:57 PM, Rick Astley wrote: > Here is a quote I made in the other thread around the same time you were > sending this: > > "I also think the practice of paying an intermediary ISP a per Mbps rate in > order to get to a last mile ISP over a settlement free agreement is also a > bit disingenuous in cases where the amount of traffic is sufficient enough > to fill multiple links. Theoretically there are many times where the > intermediary ISP can hand off the traffic to a last mile ISP in exactly the > same building they received it in so they have very few of the costs of > actually delivering the traffic yet are the only party receiving money from > the content provider for delivery. This arrangement makes sense when the > traffic to the last mile ISP is a percentage of one link but after enough > links are involved the intermediary ISP is serving no real other purpose > than as a loophole used to circumvent paid peering fees (right or wrong)." > But that scenario only applies where the content network has carried the traffic to the same building as the eyeball network, such that it really does just go from the content provider, into the cheapTransit router, and then right back out to the eyeball network. At that point, the content provider and eyeball network are paying roughly commensurate amounts for their infrastructure costs; the content provider to get the data to that common location, and the eyeball network to get it from that location back to the customers who requested it. I'm not sure why you think it's a loophole of any sort; if anything, it's an anti-loophole, as the most efficient answer would be for the content network and eyeball network to directly interconnect, having each hauled circuits to this point in common--but instead, due to policies, an intermediary is forced into the picture. And your understanding of transit seems to be tenuous at best. You say "are the only party receiving money from the content provider for delivery" as though it's a bad thing, or some unusual circumstance. This is exactly what transit is. I pay an upstream provider to carry my route advertisements and bits to the rest of the world, regardless of how near or far it is. You do the same thing as a broadband customer; you pay one provider for access, regardless of how many content providers you pull down content from. It sounds like you would advocate a model where every content source pays every eyeball network that requests its content, and every broadband subscriber pays to every network it requests content from, rather than the current model of paying one upstream transit provider for connectivity to the rest of the internet. Is that really the case? Is that really what you're advocating for? > > I think we are in agreement that $EyeballNetwork's customers pay it for > internet access and $ContentProvider should pay for their own pipes. But > where we diverge is with $CheapTransitProvider. > OK, how about we substitute "NotSoCheapTransitProvider" into the equation. Now, does that make the situation any different in your eyes? Or do you still feel that fundamentally transit is only something that eyeball networks can pay for, that content networks must not pay a single upstream, but must instead pay every eyeball network separately, regardless of how inefficient and expensive that would be? > > At least for the purpose of traffic following the path of $ContentProvider > > $CheapTransitProvider > $EyeballNetwork's because there is so much > traffic involved the only real purpose of the relationship with > $CheapTransitProvider is a loophole to get around paying $EyeballNetwork. > They are able to charge ridiculously low delivery prices because traffic is > only on their network for just long enough to say it touched and should now > be considered settlement free. It's little more than a cheap trick and it > makes them sort of the Cash4Gold of the Internet. I can completely > understand why $EyeballNetwork would tell $CheapTransitProvider they no > longer choose to have a settlement free agreement and they must buy future > ports. > And in that model, I think it would be entirely correct for the content provider to either deny access to their content for users of ExtortionistEyeballNetwork, or to charge them additional for access to the content, to offset the increased costs of paying for the ports to that network. After all, unlike your flawed traffic flow, it's not the content network pushing bits at the eyeball network; it's the eyeball network sucking the bits down from the content provider. If the eyeball network feels that volume of traffic is problematic for them, such that they can't afford to augment capacity, the clear answer is for the content providers to help out the poor, congested eyeball networks by reducing the bitrate of content so that those links won't be congested anymore. Serve up HD streams to networks that work cooperatively to augment capacity for their users; for networks that won't cover their share of the costs of augmenting, simply serve lower and lower bitrate streams to fit within the available link capacity, with a little banner across the top alerting the consumer that their experience is degraded due to their provider not adequately installing infrastructure to handle the consumer's requested traffic. From jfmezei_nanog at vaxination.ca Mon Apr 28 09:03:31 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 28 Apr 2014 05:03:31 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5359EB4F.50405@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> Message-ID: <535E1963.9010105@vaxination.ca> On 14-04-25 00:57, Larry Sheldon wrote: > In a private message I asked if he could name a single monopoly that > existed without regulation to protect its monopoly power. Egg of Chicken question. Did regulation arise because of marker failure (monopoly, duopoly), did did regulation create monopolies ? When cable cos started in canada (TV only), they went to the CRTC, as part of obtaining their broadcasting licenses and demanded they be granted monopoly status for the areas they served. So fairly quickly, the country was carved up into different territories, each served by a single cable company (a couple of exceptions for border cases etc). residential telephone was almost always a monopoly. There may have been many different telcos, but each operated as the incumbent in its town. The bigger guys ended up gobbling most of them over the years. The probvlem of net neutrality does not reside in the "internet" itself. The transit industry is a functioning markletplace with many competitors and dynamic pricing pushing pricing towards costs. The problem resides in the last mile which is controlled by incumbents. The problem is that telcos and cablecos are becoming undifferentiated. Cablecos offer telephony, and telcos offer TV distribution. The difference is that not all telcos have advances and those still stuck with old DSL are becoming irrelevant, leaving only a monopoly cableco to serve customers. And whenever 100% of facilities based last mile providers are more interested in protecting their legacy TV assets, you get problems with net neutrality, just as Comcast is doing to Netflix. For large ISPs, Netflix provides caching appliances that can be inside their network, so it is not a question of transit costs. It has everything to do with a company that is heavily involved in TV, and which controls the ISP market is such a large areas of USA wanting to replace lost TV revenus by billing whoever is stealing those revenus. In other words, they use their market power to hurt competitors. While the FCC is getting the news, this should have gone to the FTC because it is clearly an anti-competitive and predatory measure that proves Comcast is using its market power to hurt competitors. As a side note in Canada, the "Competition Bureau" (FTC in USA) is getting involved with CRTC (FCC in USA) and submits into processes with arguments on competition. When there is a clear case of abuse of marlet power and anti-competive practices, (such as Comcast vs Netflix) then government intervention is not only warranted, it is essential. From jfmezei_nanog at vaxination.ca Mon Apr 28 09:29:54 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 28 Apr 2014 05:29:54 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> Message-ID: <535E1F92.60609@vaxination.ca> On 14-04-27 02:23, Rick Astley wrote: > Sort of yes, it's Comcasts problem to upgrade subscriber lines but if that > point of congestion is the links between Netflix and Comcast then Netflix > would be on the hook to ensure they have enough capacity to Comcast to get > the data at least gets TO the Comcast network. Netflix has no business paying Comcast. It offers caching appliances, and CDN distribution which can be either inside Comcast's network, or close enough to peer with. So Netflix not only pays for its own connection to the internet, but also manages to pay for transit right up to major ISPs. Comcast has no business billing its suppliers. It is in business to bill its retail customers. Now, if Netflix were to charge more to Comcast customers and make a note of this before every program starts "you are paying more because you are on Comcast", you might see Comcast rethink its anti-competitive practice. From jfmezei_nanog at vaxination.ca Mon Apr 28 09:32:46 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 28 Apr 2014 05:32:46 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> , <4d90fb0ff0f6425c86b6198319163200@STCOEX01.stargate.local> Message-ID: <535E203E.2010100@vaxination.ca> On 14-04-27 02:58, Hugo Slabbert wrote: > > Which I don't believe was a problem? Again, outside looking in, but the appearances seemed to indicate that Comcast was refusing to upgrade capacity/ports, whereas I didn't see anything indicating that Netflix was doing the same. So: Funny how that problem was magically solved so rapidly the minute the deal was inked. Seems to me like Comcast was rate limiting IP ranges and removed the rate limit once the deal was inked. This was all about politics/business, not about network management. Also interesting how other ISPs have no problem with Netflix. From ops.lists at gmail.com Mon Apr 28 09:34:43 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 28 Apr 2014 15:04:43 +0530 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535E1F92.60609@vaxination.ca> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535E1F92.60609@vaxination.ca> Message-ID: So L3 and earlier, cogent peer settlement free with Comcast and Netflix maxes out these peerings while they're there. What then? On 28-Apr-2014 3:02 pm, "Jean-Francois Mezei" wrote: > On 14-04-27 02:23, Rick Astley wrote: > > > Sort of yes, it's Comcasts problem to upgrade subscriber lines but if > that > > point of congestion is the links between Netflix and Comcast then Netflix > > would be on the hook to ensure they have enough capacity to Comcast to > get > > the data at least gets TO the Comcast network. > > Netflix has no business paying Comcast. It offers caching appliances, > and CDN distribution which can be either inside Comcast's network, or > close enough to peer with. So Netflix not only pays for its own > connection to the internet, but also manages to pay for transit right up > to major ISPs. > > Comcast has no business billing its suppliers. It is in business to bill > its retail customers. > > Now, if Netflix were to charge more to Comcast customers and make a note > of this before every program starts "you are paying more because you are > on Comcast", you might see Comcast rethink its anti-competitive practice. > > > From brandon at rd.bbc.co.uk Mon Apr 28 09:45:56 2014 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Mon, 28 Apr 2014 10:45:56 +0100 (BST) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post Message-ID: <201404280945.KAA28354@sunf10.rd.bbc.co.uk> > $ContentProvider pays for transit sufficient to handle the traffic > that their customers request. $EyeballNetwork's customers pay it for > internet access, i.e. to deliver the content that they request, e.g. > from $ContentProvider. That covers both directions here But isn't the whole picture, there are other factors such as $ContentProvider has to cover the cost of content, selling it vs their competitors (as unlike $EyeballNetwork the $Customer has a choice of who to use, and as everything on the net is free they may have a hard time living off their paywall) Even if a CDN cost $ContentProvider the exact same as $EyeballNetwork thinks it should cost to deliver, $EyeballNetwork would still want to be the one paid instead. Who decides if $EyeballNetwork price is reasonable? There is no incentive for them to be efficient, there is no competition - this is partly why provider CDNs have failed, once you put your 50% of internet traffic on their CDN they will not maintain their links to other CDNs at similar capacity so you can never go back, prices will stay high The point of having disruptive technolgy and business models is that they will disrupt and take us to a new, hopefully better, place. No opt out if you happen to be the disruptee. $EyeballNetwork should take care, if $ContentProvider is 50% of their traffic and are being charged lots then $ContentProvider may decide they can do the job better themselves and take over as $EyeballNetwork (such as google fibre). Monopolies who want to remain one should not incentivise new competitors. While this is all open to be gamed disputes over perceived inequality result leaving a mess so I can see why the FCC may decide there is no solution other than let the market decide. brandon From streiner at cluebyfour.org Mon Apr 28 08:38:23 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 28 Apr 2014 04:38:23 -0400 (EDT) Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: On Mon, 28 Apr 2014, Rick Astley wrote: >> Double-billing Rick. It's just that simple. Paid peering means you're deliberately > billing two customers for the same byte > > Where your statement is short sighted I already explained partly in saying > its too difficult to decide who gets a free ride and who gets the bill so I > challenge you to propose an actual policy that prohibits charging for > peering that doesn't have major unintended consequences. All in all I am > sort of disappointed to find so few rational opinions around here. One of > the few decent articles I have read on it is here: > http://blog.streamingmedia.com/2014/02/media-botching-coverage-netflix-comcast-deal-getting-basics-wrong.html > > I think if you make a law that says all content providers big and small get > free pipes and the residential subscribers of broadband must pay the tab > the cost of broadband in the US compared to the rest of the world > skyrocket. No one is suggesting that all content providers get a 'free ride', let alone a legally-mandated free ride. Giving last-mile providers an implicit (if not explicit) OK to bill providers whose content happens to be popular with the last-mile providers' customers sets a horrible precedent. Content providers have infrastructure costs, just like last-mile ISPs. Your arguments seem to ignore that minor point. Those cost cover different things than what a last-mile ISP would need to cover, but they have costs nonetheless. They either pay other providers to haul their bits to other networks or they build infrastructure to locations that allow them to peer with providers. That could be to a mutually-agreed meet point for private peering, or it could be to an exchange point to peer with other providers who have a presence at the same exchange point. Look at the Peering DB. In general, you will see that content networks have more open peering policies than eyeball networks. It's in their best interests to get as topologically close to their consumers as possible. Some transit networks do the same, but that's a much more variable picture. jms From ffo at sesp.ch Mon Apr 28 11:56:37 2014 From: ffo at sesp.ch (Florian Forster) Date: Mon, 28 Apr 2014 13:56:37 +0200 Subject: Phase 4. In-Reply-To: References: Message-ID: > > I can has test fore able two post too this list ?????? Haha ymmd really ;-) On 27 April 2014 18:37, jamie rishaw wrote: > I can has test fore able two post too this list ?????? > > On Thu, Apr 24, 2014 at 12:54 AM, Bryan Socha > wrote: > > Whats the big deal???? If your just arin, dont panic. Akamai > and > > digitalocean has been the only people aquire fair priced v4 putside > > arin. So arin is ending. It doesnt stop anything. be smart 3 usd > > per ip is fair if dirty. F the auct8ons they are fake and we get the ips > > lower than op3ning. > > > > Icann is the mast 8 class as real? Distribute them > > , > > > > -- > jamie rishaw // .com.arpa at j <- reverse it. ish. > > "Reality defeats prejudice." - Rep. Barney Frank > From mfidelman at meetinghouse.net Mon Apr 28 12:19:24 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 28 Apr 2014 08:19:24 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535DC37A.50707@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <535DC37A.50707@cox.net> Message-ID: <535E474C.7080105@meetinghouse.net> Larry Sheldon wrote: > On 4/27/2014 8:59 PM, goemon at anime.net wrote: >> If the carriers now get to play packet favoritism and pay-for-play, they >> should lose common carrier protections. > > I didn't think the Internet providers were common carriers. > They're not - but that can (and IMHO should) be changed. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From owen at delong.com Mon Apr 28 12:24:54 2014 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Apr 2014 05:24:54 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535E1963.9010105@vaxination.ca> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535E1963.9010105@vaxination.ca> Message-ID: <5E7F8485-1516-45CD-A05C-9BC5FB6DBE76@delong.com> > For large ISPs, Netflix provides caching appliances that can be inside > their network, so it is not a question of transit costs. It has > everything to do with a company that is heavily involved in TV, and > which controls the ISP market is such a large areas of USA wanting to > replace lost TV revenus by billing whoever is stealing those revenus. The use of the word stealing here is offensive and inaccurate. It implies a sense of entitlement to those revenues which is, IMHO, absurd. It’s like political candidates who complain about third party candidates “stealing their votes”. The votes don’t belong to the candidates, they belong to the voters. If $CABLECO wants to preserve their television revenues, they should do so by providing a competitive product that is attractive to customers. If another company is able to provide a more attractive product, then that’s how competition and a free market is supposed to work. What is absolutely contrary to the public interest is allowing $CABLECO to leverage their position as a monopoly or oligopoly ISP to create an operational disadvantage in access for that competing product. The so-called “internet fast lane” is a euphemism for allowing $CABLECO to put competing video products into a newly developed slow-lane while limiting the existing path to their own products and those content providers that are able to and choose to pay these additional fees. Once you follow the money trail to its logical conclusion, at its heart, it’s the epitome of the kind of anti-competitive practices the Sherman act was intended to prevent. > In other words, they use their market power to hurt competitors. While > the FCC is getting the news, this should have gone to the FTC because it > is clearly an anti-competitive and predatory measure that proves Comcast > is using its market power to hurt competitors. This isn’t limited to $CABLECO. While they’re at the front of this effort, reality is that if it succeeds, incumbents of all flavors will start using this tactic to improve their revenues to the detriment of consumers. Owen From niels=nanog at bakker.net Mon Apr 28 13:05:24 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 28 Apr 2014 15:05:24 +0200 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> Message-ID: <20140428130524.GK36211@burnout.tpb.net> >>Isn't this all predicated that our crappy last mile providers >>continue with their crappy last mile * jnanog at gmail.com (Rick Astley) [Mon 28 Apr 2014, 05:08 CEST]: >If you think prices for residential broadband are bad now if you >passed a law that says all content providers big and small must have >settlement free access to the Internet paid for by residential >subscribers what do you think it would do to the price of broadband? Lower it? Right now broadband providers pay a transit provider who then get paid by content providers to carry the bits, generally because broadband providers don't want to think about running IP networks because they their skills lie more in the television part of RF networks. Content providers are offering to take out that middleman, bringing everybody's cost down. Some broadband providers think they deserve more of a free ride than others. It also happens that those broadband providers are generally already more expensive than their competitors. -- Niels. -- From kristopher.doyen at gmail.com Mon Apr 28 13:22:06 2014 From: kristopher.doyen at gmail.com (Kristopher Doyen) Date: Mon, 28 Apr 2014 09:22:06 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: On Apr 28, 2014 7:37 AM, "Justin M. Streiner" wrote: > > On Mon, 28 Apr 2014, Rick Astley wrote: > >>> Double-billing Rick. It's just that simple. Paid peering means you're deliberately >> >> billing two customers for the same byte >> >> Where your statement is short sighted I already explained partly in saying >> its too difficult to decide who gets a free ride and who gets the bill so I >> challenge you to propose an actual policy that prohibits charging for >> peering that doesn't have major unintended consequences. All in all I am >> sort of disappointed to find so few rational opinions around here. One of >> the few decent articles I have read on it is here: >> http://blog.streamingmedia.com/2014/02/media-botching-coverage-netflix-comcast-deal-getting-basics-wrong.html >> >> I think if you make a law that says all content providers big and small get >> free pipes and the residential subscribers of broadband must pay the tab >> the cost of broadband in the US compared to the rest of the world >> skyrocket. > > > No one is suggesting that all content providers get a 'free ride', let alone a legally-mandated free ride. Giving last-mile providers an implicit (if not explicit) OK to bill providers whose content happens to be popular with the last-mile providers' customers sets a horrible precedent. > > Content providers have infrastructure costs, just like last-mile ISPs. Your arguments seem to ignore that minor point. Those cost cover different things than what a last-mile ISP would need to cover, but they have costs nonetheless. They either pay other providers to haul their bits to other networks or they build infrastructure to locations that allow them to peer with providers. That could be to a mutually-agreed meet point for private peering, or it could be to an exchange point to peer with other providers who have a presence at the same exchange point. > > Look at the Peering DB. In general, you will see that content networks have more open peering policies than eyeball networks. It's in their best interests to get as topologically close to their consumers as possible. Some transit networks do the same, but that's a much more variable picture. > > jms I'm sorry but all this talk of lemonade stands and metaphors is giving me a headache. It really is a simple case of supply and demand. You have four actors who may or may not be the same entity ( example: transit provider who is also your isp ). 1) User Who shops around to get the best isp who has the access he wants at the best price. This user does not need to know about transit and peering agreements because if they can not get their content they should, in a perfect world, choose an ISP who will. 2) ISP - For User / Content provider An ISP should recognize the needs of their customers and seek out the best relationships that will keep their customers paying them. These relationships should be formed out of mutual self interest either for pay or swap arrangements. The ISP should terminate / form new relationships with other providers that are in the best interest of their customers because their business should depend on being the best ISP available and keeping their customer's happy. 3) Transit provider A transit provider who may or may not be one or both of the ISPs of a user or content provider. Should form as many interesting and useful relationships to make themselves attractive to other providers. If they aren't providing competitive offers no ISP or other provider would want to make arrangements with them and their business fails. 4) Content provider These are the people who have what the users want. Their offerings compel users to sign up to ISPs which pay for transit who allow access to content. Content providers should partner themselves with the best ISP(s) or transit providers that give their content the largest reach to the most users at the best price. Content providers should use their content and money to make the best arrangements for their business or it dies. They should not have to worry about being strong armed for being successful because the market should be self adjusting. Example: if transfer fees go up and a better contract can't be sourced or arranged either the content provider re-thinks their pricing model or their business dies and should die since it would no longer be sustainable. In all cases each actor is paying their way making relationships that are best for their business with the immediate link or links in the chain of communication for delivering content. At this point we have to assume it is cost prohibitive for all content providers to form direct end to end relationships with all or majority of all users. Unfortunately this nice friendly free market of opportunity isn't true and because of that you now have actors starting to abuse their position. Which based on history shouldn't be a real shock. In an alarmingly high number of cases a user only has one high speed ISP to choose from. This allows that ISP to play a game of chicken with everyone. Since users have lost the right to choose, because of reasons outside of their control, we are all going to if not already suffering. These type of single ISP only use cases leads to hard to prove artificial limitations that lead to arguments that go no where. Example: users who report Netflix has poor quality of service on their open ISP connection but good quality of service on a VPN running over that same connection because the VPN's ISP is running their business correctly. When last mile ISPs no longer have pressure or over-sight to maintain a business model that puts user's needs first, because a happy user is a returning user, you now have an entity who will do anything for a dollar as long as it can't be proved illegal for the moment. It also completely removes any incentive to upgrade as such ISP's real product transforms from the internet connectivity they provide their users to the now locked in users themselves. I would not be surprised if more money is now being spent maintaining/ supporting anti-competitive legislation than on network and infrastructure upgrades/costs. Transit providers, content providers, and other ISPs should be scared because if this goes on much longer you will now have the digital equivalent of the mutually assured destruction (MAD) policy which in the end everyone loses. Some points I want to make very clear: 1) Everyone SHOULD pay but no one should be forced to pay twice and their should be some anti-competitive checks/balance like we have for other areas of our lives. 2) Last mile ISPs should absolutely use their user base as a bargaining device only as long as they don't damage or reduce their primary goal which is to provide said users with internet connectivity. 3) In this day of technology and innovation there should be no reason why a user can't have choices. Plenty of regions have found a way to share. At the very least local government should work with their population to find a solution that suits their needs first and not only a private for-profit entity. This may be through offering incentives, fair access policies, or even full blown installs that anyone can offer service over. -Kris From ops.lists at gmail.com Mon Apr 28 13:23:00 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 28 Apr 2014 18:53:00 +0530 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <20140428130524.GK36211@burnout.tpb.net> References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> Message-ID: On Mon, Apr 28, 2014 at 6:35 PM, Niels Bakker wrote: > * jnanog at gmail.com (Rick Astley) [Mon 28 Apr 2014, 05:08 CEST]: >> >> If you think prices for residential broadband are bad now if you passed a >> law that says all content providers big and small must have settlement free > > Lower it? > > Right now broadband providers pay a transit provider who then get paid > by content providers to carry the bits, generally because broadband > providers don't want to think about running IP networks because they > their skills lie more in the television part of RF networks. People are never gonna give this thread up, I see. Easily one of the longest threads in recent nanog history and I'm starting to see points rehashed and strawmen trotted out. Comcast sells wholesale transit - http://www.comcast.com/dedicatedinternet/?SCRedirect=true And it has a settlement free peering policy - with a stated requirement that traffic exchanged be symmetrical. http://www.comcast.com/peering > Applicant must maintain a traffic scale between its network and > Comcast that enables a general balance of inbound versus > outbound traffic. The network cost burden for carrying traffic > between networks shall be similar to justify SFI Now, that big elephant in the room taken into account, where do the middlemen come in here? --srs From mvoity at uvm.edu Mon Apr 28 13:45:41 2014 From: mvoity at uvm.edu (Michael T. Voity) Date: Mon, 28 Apr 2014 09:45:41 -0400 Subject: altdb Message-ID: <535E5B85.7060601@uvm.edu> I hate to ask via this route... Could someone from altdb.net please contact me off list? Thanks, -Mike -- Michael T. Voity Network Engineer University of Vermont From bedard.phil at gmail.com Mon Apr 28 13:55:49 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 28 Apr 2014 09:55:49 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <20140428130524.GK36211@burnout.tpb.net> References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> Message-ID: MSOs run expansive IP networks today, including national dark fiber DWDM networks. They all have way more people with IP expertise than they do RF expertise. Even modern STBs use IP for many functions since they require 2-way communication, the last hold-out is your traditional TV delivery. Even then most of the MSOs have IPTV installations in at least some markets. That pendulum tipped a long long time ago now. Level3 actually had to pay Comcast the last time this all came around. They gained Netflix as a customer, the ratios of traffic a "transit" provider was sending to Comcast because way out of balance, and Level3 succumbed and paid. Mainly since most of the traffic wasn't "transit" traffic, it was Netflix traffic coming off Level3 CDNs. Transit providers have "double-dipped" forever when it comes to ingress/egress traffic to their own customers. -Phil On 4/28/14, 9:05 AM, "Niels Bakker" wrote: >>>Isn't this all predicated that our crappy last mile providers >>>continue with their crappy last mile > >* jnanog at gmail.com (Rick Astley) [Mon 28 Apr 2014, 05:08 CEST]: >>If you think prices for residential broadband are bad now if you >>passed a law that says all content providers big and small must have >>settlement free access to the Internet paid for by residential >>subscribers what do you think it would do to the price of broadband? > >Lower it? > >Right now broadband providers pay a transit provider who then get paid >by content providers to carry the bits, generally because broadband >providers don't want to think about running IP networks because they >their skills lie more in the television part of RF networks. > >Content providers are offering to take out that middleman, bringing >everybody's cost down. Some broadband providers think they deserve >more of a free ride than others. It also happens that those broadband >providers are generally already more expensive than their competitors. > > > -- Niels. > >-- From tglassey at earthlink.net Mon Apr 28 14:08:55 2014 From: tglassey at earthlink.net (TGLASSEY) Date: Mon, 28 Apr 2014 07:08:55 -0700 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: <535E60F7.8080906@earthlink.net> On 4/27/2014 9:57 AM, Rick Astley wrote: > I wish you would expand on that to help me understand where you are coming > from but what I pay my ISP for is simply a pipe, I don't know how it would > make sense logically to assume that every entity I communicate with on the > Internet must be able to connect for free because I am covering the tab as > a subscriber. 0) No you're not. What you are covering is a percentage of the aggregate use model - the problem is what happens when you using 3% of your local end-node service capability run into the other 300 people who want to do the same. The use fees dont cover the bulk transit that is generally controlled through backhaul agreements so... > I am not talking about JUST Netflix here as they are a large > company more capable than some smaller ones at buying their own pipes out > to the world. 1) The pipe issue is that of the last mile providers and not Netflix. The issue is the failure of the IETF to put controls in place which address this. > It would be sort of the same concept of my grandmother > calling my cell phone yet we both need to pay for our individual phone > lines to at least reach the carrier tasked with connecting our call. Even > if my grandmother calls a business, that business have phone lines they pay > for. Technically this would be double dipping but it's been the norm for a > very long time. How so? You are paying for the individual routing of data to that independent end node per the contract. If Grandma's cell and yours was covered under the same use contracts or shared minutes contract then that would make sense but otherwise they are independent services and whether that person is family or not they are a separate account - and billing. Hence 2 bills there. 2) The idea pertains to the concept that "everyone has a digital persona and that persona is legally real", i.e. it has similar rights to their physical persona. In places like France this is now law. > > Now if we will lets talk about where this concept falls apart. Pretend I > run a lemonade stand and my ISP offers to give it free Internet access, how > generous of them! I then meet a businessman from town who is complaining > about what it costs him to connect to the Internet because he has a lot of > equipment that serves data to people all over the place. I see this as an > opportunity to make more money and I say "hey, they don't charge me at all > for Internet access I will make you a deal, I will connect your equipment > to them for 1/3 what you are paying today". "Good deal" says the > businessman. I eagerly ride my bicycle home, pick up my phone, call my ISP > and tell them the news "Hey, thanks for the free service but I need you to > upgrade my connection x5 because I decided to do content delivery for the > businesses in town". "Oh hell no says my ISP, that was not at all the > agreement, your lemonade stand is still free but if you want us to carry > the extra traffic you have to buy more ports the same as everyone else". 3) So the other issue is the Use Contract you have most likely has a no-commercial or minimum commercial use clause in the licensing agreement. Likely also a no-resale as a service as well in the same agreement so what they actually say is "How long have you been doing this?" and you reply you have been testing it for a month now. So they send you a bill and when you as the Lemonade stand operator get it and choke, and then call them - they say "have you read the no resale clause in the contract?" and its over. > I > didn't build a successful lemonade stand because I take being treated like > this sitting down! Our now much larger volume of traffic is slow to the ISP > and they are refusing to upgrade it for free, so I call up the media and > have them run a story about how the ISP is intentionally limiting our > traffic and they simply need to upgrade it for free. 4) Yes you do - and you scream how this is also racial profiling because anyone who hates lemonade is unAmerican or un-something. > People are already > paying for the Internet, if they don't give me my free ride they are double > dipping! How so - how are people already paying for the service you are now talking about selling which you are taking from someone else in violation of their provisioning agreement? > > Public opinion is in, that mean ISP should be giving me my free access but > the reality of the situation is perhaps a bit different. My lemonade stand > pulled a coup when it became a content provider and demanded a free ride, > and railroading my ISP for it in the media was probably a dishonest thing > to do. How so? Again - your stand is a bandwidth thief and your business is breaking the terms of its end-user agreement with the ISP as well. > I reluctantly agree to pay them for ports for content I am > delivering but "local businessman" from my town has tasted blood and he's > not done yet "Who else has a lemonade stand with free Internet?!" he > proclaims. > > I changed some names to protect the Innocent :) > > > On Sun, Apr 27, 2014 at 10:04 AM, Nick B wrote: > >> The current scandal is not about peering, it is last mile ISP double >> dipping. >> Nick >> On Apr 27, 2014 2:05 AM, "Rick Astley" wrote: >> >>> Without the actual proposal being published for review its hard to know >>> the >>> specifics but it appears that it prohibits blocking and last mile >>> tinkering >>> of traffic (#1). What this means to me is ISP's can't block access to a >>> specific website like alibaba and demand ransom from subscribers to access >>> it again. I do not know if this provision would also include prohibiting >>> intentionally throttling traffic on a home by home basis (#2) and holding >>> services to the same kind of random is also prohibited but I think this >>> too >>> would be a far practice to prohibit. Bits are bits. >>> >>> From the routers article ( >>> >>> http://www.reuters.com/article/2014/04/23/us-usa-fcc-internet-idUSBREA3M1H020140423 >>> ) >>> and elsewhere it seems what the proposal does not outlaw is paid >>> peering >>> and perhaps use of QoS on networks. >>> >>> #3 On paid peering: >>> I think this is where people start to disagree but I don't see what should >>> be criminal about paid peering agreements. More specifically, I see >>> serious >>> problems once you outlaw paid peering and then look at the potential >>> repercussions that would have. Clearly it would not be fair to for only >>> the >>> largest content providers to be legally mandated as settlement free peers >>> because that would leave smaller competitors out in the cold. The only >>> fair >>> way to outlaw paid peering would be to do it across the board for all >>> companies big and small. This would be everyone from major content >>> providers to my uncle to sells hand runs a website to sell hand crafted >>> chairs. This would have major sweeping repercussions for the Internet as >>> we >>> know it over night. >>> >>> I think it makes sense to allow companies to work it out as long as the >>> prices charged aren't unreasonably high based on market prices for data. >>> This means if 2 ISP's with similar networks want to be settlement free >>> they >>> can. If ISP's want to charge for transit they can, and if ISP's want to >>> charge CDN's to deliver data they can. Typically the company with the >>> disproportional amount of costs of carrying the traffic would charge the >>> other company but really it should be up to the companies involved to >>> decide. Based on the post by Tom Wheeler from the FCC ( >>> http://www.fcc.gov/blog/setting-record-straight-fcc-s-open-internet-rules) >>> it sounds like if this pricing is "commercially unreasonable" (ie >>> extortion) they will step in. Again I think this is fair. >>> >>> >>> #4 On QoS (ie fast lane?): >>> In some of the articles I skimmed there was a lot of talk about fast lane >>> traffic but what this sounds like today would be known as QoS and >>> classification marking that would really only become a factor under >>> instances of congestion. The tech bloggers and journalists all seems to be >>> unanimously opposed to this but I admit I am sort of scratching my head at >>> the outrage over something that has been in prevalent use on many major >>> networks for several years. I don't see this as the end of the Internet as >>> we know it that now seems to essentially be popular opinion on the issue. >>> Numerous businesses are using QoS to protect things like voice traffic and >>> business critical or emergency traffic from being impacted in a failure >>> scenario. In modern day hyper converged networks where pretty soon even >>> mobile voice traffic could be VoIP over a data network prohibiting the use >>> of all QoS seems irresponsible. >>> >>> The larger question is, is it fair for ISP's to charge people to be in a >>> priority other than "best effort"? To answer a question with a question, >>> if an ISP is using a priority other than "best effort" for some of its own >>> traffic is it fair if a peer with a competing service is only best effort >>> delivery? This is sort of akin to Comcast not counting its own video >>> service against the ~250G/month cap of subscribers but counting off >>> network >>> traffic against it. In theory if some of an ISP's own services are able to >>> use higher than best effort priority the same should be available to the >>> business they are selling service to. If they go completely out of their >>> way to intentionally congest the network to force people into needing a >>> higher than best effort classification I would think it should fall into >>> what the FCC calls "commercially unreasonable" and thus be considered a >>> violation. So again, I think this is fair. >>> >>> I have numbered the items I mentioned from 1-4 being >>> #1. Blocking >>> #2. per household (last mile) rate limiting of a service (though rate >>> limiting at all anywhere should probably be up for discussion so #2.5) >>> #3. The legality of paid peering >>> #4. The legality of QoS (unless fast lane is something else I don't >>> understand). >>> >>> Feel free to augment the list. >>> > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4570 / Virus Database: 3920/7404 - Release Date: 04/27/14 > > -- ------------- Personal Email - Disclaimers Apply From bedard.phil at gmail.com Mon Apr 28 14:18:25 2014 From: bedard.phil at gmail.com (Phil Bedard) Date: Mon, 28 Apr 2014 10:18:25 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> Message-ID: On 4/28/14, 9:23 AM, "Suresh Ramasubramanian" wrote: > >And it has a settlement free peering policy - with a stated >requirement that traffic exchanged be symmetrical. > >http://www.comcast.com/peering > >> Applicant must maintain a traffic scale between its network and >> Comcast that enables a general balance of inbound versus >> outbound traffic. The network cost burden for carrying traffic >> between networks shall be similar to justify SFI > >Now, that big elephant in the room taken into account, where do the >middlemen come in here? People seem to forget what Comcast is doing is nothing new. People have been paying for unbalanced peering for as long as peering has been around. It's a little different because Netflix doesn't have an end network customer to bill to recoup those charges, they have customers on someone else's network. It's not like all broadband providers are anti-Netflix, some are even starting to include NF as an app on their STB. There are also many who do peer with Netflix settlement-free even with very unbalanced ratios. The key in the future is moving the bandwidth closer to the users, and we will see more edge caching exist either within the broadband provider facilities or at more localized 3rd party datacenters. Phil From niels=nanog at bakker.net Mon Apr 28 14:24:17 2014 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 28 Apr 2014 16:24:17 +0200 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> Message-ID: <20140428142417.GL36211@burnout.tpb.net> * ops.lists at gmail.com (Suresh Ramasubramanian) [Mon 28 Apr 2014, 15:27 CEST]: >Comcast sells wholesale transit - >http://www.comcast.com/dedicatedinternet/?SCRedirect=true > >And it has a settlement free peering policy - with a stated >requirement that traffic exchanged be symmetrical. How is that possibly realistic? They have 22 million customers (soon to become 29) with wildly asymmetrical connections and a very typical consumption pattern. Should Netflix change its apps that they upload an equal amount of bandwidth back to Netflix's servers to balance this out? That way lies madness. SBC had a much saner policy, from their 2006 SFI peering guidelines document: "No requirement for a balanced traffic exchange ratio due primarily to the asymmetric nature of current broadband metallic transmission systems such as ADSL and cable modems." (Then AT&T happened.) >Now, that big elephant in the room taken into account, where do the >middlemen come in here? Middlemen as in transit providers? The world is larger than Comcast's coverage area so there is a very good market for your middlemen. -- Niels. -- From Valdis.Kletnieks at vt.edu Mon Apr 28 14:28:28 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Apr 2014 10:28:28 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: Your message of "Mon, 28 Apr 2014 07:08:55 -0700." <535E60F7.8080906@earthlink.net> References: <535E60F7.8080906@earthlink.net> Message-ID: <207161.1398695308@turing-police.cc.vt.edu> On Mon, 28 Apr 2014 07:08:55 -0700, TGLASSEY said: > 1) The pipe issue is that of the last mile providers and not > Netflix. The issue is the failure of the IETF to put controls in place > which address this. It's totally unclear to me that the IETF is the one who failed to put controls in place. If they were able to mandate anything, BCP38 wouldn't be an issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From jbates at paradoxnetworks.net Mon Apr 28 15:34:04 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Mon, 28 Apr 2014 10:34:04 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> Message-ID: <535E74EC.7050905@paradoxnetworks.net> On 4/28/2014 9:18 AM, Phil Bedard wrote: > People seem to forget what Comcast is doing is nothing new. People have > been paying for unbalanced peering for as long as peering has been around. > It's a little different because Netflix doesn't have an end network > customer to bill to recoup those charges, they have customers on someone > else's network. Yeah. It's a scam. Comcast can't do balanced peering. Their customers are not symmetrical. > It's not like all broadband providers are anti-Netflix, some are even > starting to include NF as an app on their STB. There are also many who do > peer with Netflix settlement-free even with very unbalanced ratios. The > key in the future is moving the bandwidth closer to the users, and we will > see more edge caching exist either within the broadband provider > facilities or at more localized 3rd party datacenters. > > Netflix is happy to assist with caching. The thing is, Comcast doesn't care about that. What they care about is that their last mile is getting saturated and they have to pay money to upgrade it. Costs are being shoved onto netflix and similar to justify that. This is compared to the small ISP who is just happy to get a peering or cache to save money only on their transit fees. Jack From dougb at dougbarton.us Mon Apr 28 15:37:43 2014 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 28 Apr 2014 08:37:43 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <10215814.2307.1398636921832.JavaMail.root@benjamin.baylink.com> References: <10215814.2307.1398636921832.JavaMail.root@benjamin.baylink.com> Message-ID: <535E75C7.3090207@dougbarton.us> On 04/27/2014 03:15 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Hugo Slabbert" > >> But this isn't talking about transit; this is about Comcast as an edge >> network in this context and Netflix as a content provider sending to >> Comcast users the traffic that they requested. Is there really >> anything more nuanced here than: >> >> 1. Comcast sells connectivity to their end users and sizes their >> network according to an oversubscription ratio they're happy with. >> (Nothing wrong here; oversubscription is a fact of life). >> 2. Bandwidth-heavy applications like Netflix enter the market. >> 3. Comcast's customers start using these bandwidth-heavy applications >> and suck in more data than Comcast was betting on. >> 4. Comcast has to upgrade connectivity, e.g. at peering points with >> the heavy inbound traffic sources, accordingly in order to satisfy >> their customers' usage. > > You may be new here, but I'm not, and I read it exactly the same way. > >> How is this *not* Comcast's problem? If my users are requesting more >> traffic than I banked on, how is it not my responsibility to ensure I >> have capacity to handle that? I have gear; you have gear. I upgrade or >> add ports on my side; you upgrade or add ports on your side. Am I >> missing something? > > It is absolutely the problem of the eyeball carrier who gambled on a > given oversubscription ratio and discovered that it's called gambling > because sometimes, you lose. +1 What I don't understand is why Netflix et al are not doing a PR campaign to explain this to the end users. Doug From bedard.phil at gmail.com Mon Apr 28 15:56:55 2014 From: bedard.phil at gmail.com (bedard.phil at gmail.com) Date: Mon, 28 Apr 2014 11:56:55 -0400 Subject: The FCC is planning new net neutrality rules. And they couldenshrine pay-for-play. - The Washington Post In-Reply-To: <535E74EC.7050905@paradoxnetworks.net> References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> <535E74EC.7050905@paradoxnetworks.net> Message-ID: <535e7a52.c647ec0a.4095.ffffbb4d@mx.google.com> If it was Netflix connected to say Cogent and Comcast connected to Level3 you would have the same unbalanced ratios between Cogent/Level3 for the same reasons. Level3 would likely be wanting compensation from Cogent for it... It is such a large amount of bandwidth these days it's not made up by other traffic. I am not saying any of it is right, but precedents in the past have led to this. Phil -----Original Message----- From: "Jack Bates" Sent: ‎4/‎28/‎2014 11:34 AM To: "Phil Bedard" ; "Suresh Ramasubramanian" ; "nanog at nanog.org" Subject: Re: The FCC is planning new net neutrality rules. And they couldenshrine pay-for-play. - The Washington Post On 4/28/2014 9:18 AM, Phil Bedard wrote: > People seem to forget what Comcast is doing is nothing new. People have > been paying for unbalanced peering for as long as peering has been around. > It's a little different because Netflix doesn't have an end network > customer to bill to recoup those charges, they have customers on someone > else's network. Yeah. It's a scam. Comcast can't do balanced peering. Their customers are not symmetrical. > It's not like all broadband providers are anti-Netflix, some are even > starting to include NF as an app on their STB. There are also many who do > peer with Netflix settlement-free even with very unbalanced ratios. The > key in the future is moving the bandwidth closer to the users, and we will > see more edge caching exist either within the broadband provider > facilities or at more localized 3rd party datacenters. > > Netflix is happy to assist with caching. The thing is, Comcast doesn't care about that. What they care about is that their last mile is getting saturated and they have to pay money to upgrade it. Costs are being shoved onto netflix and similar to justify that. This is compared to the small ISP who is just happy to get a peering or cache to save money only on their transit fees. Jack From hslabbert at stargate.ca Mon Apr 28 16:29:13 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Mon, 28 Apr 2014 09:29:13 -0700 Subject: The FCC is planning new net neutrality rules. And they couldenshrine pay-for-play. - The Washington Post In-Reply-To: <535e7a52.c647ec0a.4095.ffffbb4d@mx.google.com> References: <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> <535E74EC.7050905@paradoxnetworks.net> <535e7a52.c647ec0a.4095.ffffbb4d@mx.google.com> Message-ID: <20140428162913.GB23471@stargate.ca> >If it was Netflix connected to say Cogent and Comcast connected to Level3 you >would have the same unbalanced ratios between Cogent/Level3 for the same >reasons. Level3 would likely be wanting compensation from Cogent for it... ...and that would be fine as at that point we're talking about traffic exchanged between two transit providers, i.e. Level3 providing transit for Comcast and Cogent providing transit for Netflix. Settlement free peering and traffic ratios between transit AS's for these two respective parties is a different ball of wax from those some concepts in direct peering between the content provider and eyeball network. Comcast is the destination network for the traffic; they're not providing transit services to Netflix. Comcast needs to accept the Netflix traffic that Comcast's customers are requesting *somehow*; I don't see why they get to charge Netflix for a private peering relationship that's beneficial to both sides. -- Hugo On Mon 2014-Apr-28 08:56:55 -0700, bedard.phil at gmail.com wrote: >If it was Netflix connected to say Cogent and Comcast connected to Level3 you would have the same unbalanced ratios between Cogent/Level3 for the same reasons. Level3 would likely be wanting compensation from Cogent for it... It is such a large amount of bandwidth these days it's not made up by other traffic. > >I am not saying any of it is right, but precedents in the past have led to this. > >Phil > >-----Original Message----- >From: "Jack Bates" >Sent: ‎4/‎28/‎2014 11:34 AM >To: "Phil Bedard" ; "Suresh Ramasubramanian" ; "nanog at nanog.org" >Subject: Re: The FCC is planning new net neutrality rules. And they couldenshrine pay-for-play. - The Washington Post > >On 4/28/2014 9:18 AM, Phil Bedard wrote: >> People seem to forget what Comcast is doing is nothing new. People have >> been paying for unbalanced peering for as long as peering has been around. >> It's a little different because Netflix doesn't have an end network >> customer to bill to recoup those charges, they have customers on someone >> else's network. >Yeah. It's a scam. Comcast can't do balanced peering. Their customers >are not symmetrical. > >> It's not like all broadband providers are anti-Netflix, some are even >> starting to include NF as an app on their STB. There are also many who do >> peer with Netflix settlement-free even with very unbalanced ratios. The >> key in the future is moving the bandwidth closer to the users, and we will >> see more edge caching exist either within the broadband provider >> facilities or at more localized 3rd party datacenters. >> >> >Netflix is happy to assist with caching. The thing is, Comcast doesn't >care about that. What they care about is that their last mile is getting >saturated and they have to pay money to upgrade it. Costs are being >shoved onto netflix and similar to justify that. > >This is compared to the small ISP who is just happy to get a peering or >cache to save money only on their transit fees. > > >Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From lowen at pari.edu Mon Apr 28 17:05:06 2014 From: lowen at pari.edu (Lamar Owen) Date: Mon, 28 Apr 2014 13:05:06 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> References: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> Message-ID: <535E8A42.2090207@pari.edu> On 04/27/2014 06:18 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Hugo Slabbert" >> I guess that's the question here: If additional transport directly >> been POPs of the two parties was needed, somebody has to pay for the >> links. > And the answer is: at whose instance (to use an old Bell term) is that > traffic moving. > > The answer is "at the instance of the eyeball's customers". > > So there's no call for the eyeball to charge the provider for it. > > Now, Jay, I don't often disagree with you, but today it occurred to me the business case here (I've had to put on my businessman's hat far too frequently lately, in dealing with trying to make a data center operation profitable, or at least break-even). This should be taken more as a 'devil's advocate' post more than anything else, and if I missed someone else in the thread making the same point, my apologies to the Department of Redundancy Department. Sure, the content provider is paying for their transit, and the eyeball customer is paying for their transit. But the content provider is further charging the eyeball's customer for the content, and thus is making money off of the eyeball network's pipes. Think like a businessman for a moment instead of like an operator. Now, I can either think of it as double dipping, or I can think of it as getting a piece of the action. (One of my favorite ST:TOS episodes, by the way). The network op in me thinks double-dipping; the businessman in me (hey, gotta make a living, no?) thinks I need to get a piece of that profit, since that profit cannot be made without my last-mile network, and I'm willing to 'leverage' that if need be. How many mail-order outfits won't charge for a customer list? Well, in this case it's actual connectivity to customers, not just a customer list. The argument about traffic congestion is just a strawman, disguising the real, profit-sharing, motive. From streiner at cluebyfour.org Mon Apr 28 14:09:41 2014 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 28 Apr 2014 10:09:41 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they couldenshrine pay-for-play. - The Washington Post In-Reply-To: <20140428162913.GB23471@stargate.ca> References: <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> <535E74EC.7050905@paradoxnetworks.net> <535e7a52.c647ec0a.4095.ffffbb4d@mx.google.com> <20140428162913.GB23471@stargate.ca> Message-ID: On Mon, 28 Apr 2014, Hugo Slabbert wrote: > Comcast is the destination network for the traffic; they're not providing > transit services to Netflix. Comcast needs to accept the Netflix traffic > that Comcast's customers are requesting *somehow*; I don't see why they get > to charge Netflix for a private peering relationship that's beneficial to > both sides. If done on a cost-recovery basis (alternating or otherwise), the net cost to both providers should be small, well within the of the boundaries of a standard cost of doing business. That argument also seems to be overlooked by people in the "Yes, $ISP should be able to charge both customers and content providers for the same traffic" camp. jms From bzs at world.std.com Mon Apr 28 17:32:42 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 28 Apr 2014 13:32:42 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535DC37A.50707@cox.net> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <535DC37A.50707@cox.net> Message-ID: <21342.37050.572200.930890@world.std.com> On April 27, 2014 at 21:56 LarrySheldon at cox.net (Larry Sheldon) wrote: > On 4/27/2014 8:59 PM, goemon at anime.net wrote: > > If the carriers now get to play packet favoritism and pay-for-play, they > > should lose common carrier protections. > > I didn't think the Internet providers were common carriers. Here we go again! There is more than one commonly used meaning for "common carriers". There is a Communications Common Carrier as defined in the US Communications Act of 1934 regulated under the FCC and as subsequently amended by...blah blah blah. And there is the much older common law usage which can apply to trains, planes, taxis, delivery services, stagecoaches, etc which basically recognizes that in general many services engaged in "COMMON CARRIAGE". They can't be assumed to know what (or who for that matter) they are carrying for a fee -- when they don't. Obviously if one can prove they did or should have known that's an exception. So therefore shouldn't be assumed responsible for the contents if illegal or whatever. And not dragged into civil lawsuits if, e.g., someone claims that carrying the package caused harm unless perhaps the carrier threw it at the head of the recipient in which case they'd probably be culpable. Another requirement of a common law common carrier is that they provide their service to the public without discrimination other than ability to pay and whatever reasonable rules apply to everyone -- e.g., package can't be dripping liquid or weigh more than someone's "before" picture in a nutrisystem ad. The details of that of course have been beaten to a fine powder in court cases and subsequent law and regulation. SOOOOO...an ISP (et al) can be considered a common law Common Carrier without being a Common Carrier as defined in the Comm Act 1934 (and subsequent, Telecom Act 1996, etc.) ISPs don't in general have knowledge of the contents of the data they carry except when you can prove that they did which is generally assumed to be the exception or as a result of being served proper notice. But I thought we agreed on all those terms in 1991 on the com-priv list? :-) IANAL, if you mistake what I said for legal advice or accuracy you are your own fool. But I don't have to be an animal expert to point out y'all don't know the difference between a dog and a cat. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mfidelman at meetinghouse.net Mon Apr 28 17:44:42 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 28 Apr 2014 13:44:42 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <21342.37050.572200.930890@world.std.com> References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <535DC37A.50707@cox.net> <21342.37050.572200.930890@world.std.com> Message-ID: <535E938A.8040908@meetinghouse.net> Barry Shein wrote: > On April 27, 2014 at 21:56 LarrySheldon at cox.net (Larry Sheldon) wrote: > > On 4/27/2014 8:59 PM, goemon at anime.net wrote: > > > If the carriers now get to play packet favoritism and pay-for-play, they > > > should lose common carrier protections. > > > > I didn't think the Internet providers were common carriers. > > Here we go again! > > There is more than one commonly used meaning for "common carriers". > > There is a Communications Common Carrier as defined in the US > Communications Act of 1934 regulated under the FCC and as subsequently > amended by...blah blah blah. > > And there is the much older common law usage which can apply to > trains, planes, taxis, delivery services, stagecoaches, etc which > basically recognizes that in general many services engaged in "COMMON > CARRIAGE". Common AND civil law, and the context within which the 1934 act defines telecommunications carriers. > Another requirement of a common law common carrier is that they > provide their service to the public without discrimination other than > ability to pay and whatever reasonable rules apply to everyone -- > e.g., package can't be dripping liquid or weigh more than someone's > "before" picture in a nutrisystem ad. The details of that of course > have been beaten to a fine powder in court cases and subsequent law > and regulation. > > SOOOOO...an ISP (et al) can be considered a common law Common Carrier > without being a Common Carrier as defined in the Comm Act 1934 (and > subsequent, Telecom Act 1996, etc.) And that is the key to all this bunkum about "network neutrality" - it's an issue only because the FCC has made the choice not to treat ISPs (or more precisely IP transport providers) as common carriers, but as "information service providers." The recent Supreme Court decisions seems to have implied that the FCC has the power to, under current law, to define IP carriers as common carriers, and impose the obligations of common carriage on them. (Note that this does NOT immediately imply that the FCC would have to apply all the regulations and procedures typically associates with, say, telephone carriers.) All the FCC really has to do is promulgate a rule saying "IP transport is common carriage" - and network neutrality would become a non-issue. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jbaldwin at antinode.net Mon Apr 28 10:33:25 2014 From: jbaldwin at antinode.net (James Baldwin) Date: Mon, 28 Apr 2014 05:33:25 -0500 Subject: Bouygues Telecom Message-ID: Does anyone have a network engineering contact at Bouygues Telecom? It appears they are unable to route to SunGard EU space. James Baldwin From bzs at world.std.com Mon Apr 28 18:14:44 2014 From: bzs at world.std.com (Barry Shein) Date: Mon, 28 Apr 2014 14:14:44 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: <21342.39572.591252.237834@world.std.com> I think the problem is simply a lack of competition and the rise of, in effect, vertical trusts. That is, content providers also controlling last-mile services. What exists is rife with conflict of interest and unfair market power. Particularly in that wire-plants are generally protected monopolies or small-N oligopolies. The wire-plant* operators and content providers need to be separated and competition needs to be mandated by allowing easy and fair access to wire-plants. Wire-plant operators should be closely regulated. Content providers should not, in general, be regulated. * Which of course may not involve any actual wires but it's a term of art, L1/L2 if you prefer. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jbates at paradoxnetworks.net Mon Apr 28 18:23:57 2014 From: jbates at paradoxnetworks.net (Jack Bates) Date: Mon, 28 Apr 2014 13:23:57 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535E8A42.2090207@pari.edu> References: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> <535E8A42.2090207@pari.edu> Message-ID: <535E9CBD.2030405@paradoxnetworks.net> On 4/28/2014 12:05 PM, Lamar Owen wrote: > > Now, I can either think of it as double dipping, or I can think of it > as getting a piece of the action. (One of my favorite ST:TOS episodes, > by the way). The network op in me thinks double-dipping; the > businessman in me (hey, gotta make a living, no?) thinks I need to get > a piece of that profit, since that profit cannot be made without my > last-mile network, and I'm willing to 'leverage' that if need be. How > many mail-order outfits won't charge for a customer list? Well, in > this case it's actual connectivity to customers, not just a customer > list. The argument about traffic congestion is just a strawman, > disguising the real, profit-sharing, motive. > However, as a cable company, comcast must pay content providers for video. In addition, they may be losing more video subscribers due to netflix. In reality, Netflix is direct competition to Comcast's video branch. Jack From lowen at pari.edu Mon Apr 28 18:34:03 2014 From: lowen at pari.edu (Lamar Owen) Date: Mon, 28 Apr 2014 14:34:03 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535E9CBD.2030405@paradoxnetworks.net> References: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> Message-ID: <535E9F1B.6060403@pari.edu> On 04/28/2014 02:23 PM, Jack Bates wrote: > On 4/28/2014 12:05 PM, Lamar Owen wrote: >> >> Now, I can either think of it as double dipping, or I can think of it >> as getting a piece of the action.... > > However, as a cable company, comcast must pay content providers for > video. In addition, they may be losing more video subscribers due to > netflix. In reality, Netflix is direct competition to Comcast's video > branch. > > That's exactly right. But it somehow sounds better to blame it on the bandwidth consumed. From mfidelman at meetinghouse.net Mon Apr 28 19:07:13 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 28 Apr 2014 15:07:13 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535E9CBD.2030405@paradoxnetworks.net> References: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> <535E8A42.2090207@pari.edu> <535E9CBD.2030405@paradoxnetworks.net> Message-ID: <535EA6E1.3050400@meetinghouse.net> Jack Bates wrote: > On 4/28/2014 12:05 PM, Lamar Owen wrote: >> >> Now, I can either think of it as double dipping, or I can think of it >> as getting a piece of the action. (One of my favorite ST:TOS >> episodes, by the way). The network op in me thinks double-dipping; >> the businessman in me (hey, gotta make a living, no?) thinks I need >> to get a piece of that profit, since that profit cannot be made >> without my last-mile network, and I'm willing to 'leverage' that if >> need be. How many mail-order outfits won't charge for a customer >> list? Well, in this case it's actual connectivity to customers, not >> just a customer list. The argument about traffic congestion is just >> a strawman, disguising the real, profit-sharing, motive. >> > > However, as a cable company, comcast must pay content providers for > video. In addition, they may be losing more video subscribers due to > netflix. In reality, Netflix is direct competition to Comcast's video > branch. Which is why many policy oriented folks urge "separation of content from carriage" - i.e., you can't be in both businesses, or at least there needs to be a "Chinese wall" between the two businesses - otherwise the edge providers have both an inherent conflict of interest and a position that allows for monopoly abuse. The original FCC Computer Inquiry II proscribed just such a separation for the Internet business - but defined the line as being between local loop (e.g., copper) and "information services" - and defined IP transport as an "information service." Great if you're trying to protect the nascent Internet carriers from abuse by Ma Bell (though just try to buy an unbundled local loop these days); not so great for protecting Internet content providers from broadband carriers. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Mon Apr 28 19:13:12 2014 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 28 Apr 2014 15:13:12 -0400 Subject: What Net Neutrality should and should not cover In-Reply-To: <21342.39572.591252.237834@world.std.com> References: <21342.39572.591252.237834@world.std.com> Message-ID: <535EA848.3050201@meetinghouse.net> Barry Shein wrote: > I think the problem is simply a lack of competition and the rise of, > in effect, vertical trusts. That is, content providers also > controlling last-mile services. > > What exists is rife with conflict of interest and unfair market > power. Particularly in that wire-plants are generally protected > monopolies or small-N oligopolies. > > The wire-plant* operators and content providers need to be separated > and competition needs to be mandated by allowing easy and fair access > to wire-plants. > > Wire-plant operators should be closely regulated. Content providers > should not, in general, be regulated. > > > * Which of course may not involve any actual wires but it's a term of > art, L1/L2 if you prefer. I kind of think Layer 3 - metropolitan area IP carriage seems to be where the issues converge. Somehow the notion of multiple IP providers, operating across unbundled fiber, doesn't seem to work out in practice. Yes, there are a few municipal networks that provide Ethernet VPNs as the basic block of unbundled service - with multiple players providing various Internet (IP), video, and voice services on their own VPNs; and there are some networks, particularly in Canada, where the unit of unbundling is a wavelength, on a common fiber/conduit plant; but in most cases, economies of scale seem to dictate a single IP-layer fabric for a geographic area. (Think campus and enterprise networks.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From hslabbert at stargate.ca Mon Apr 28 19:30:14 2014 From: hslabbert at stargate.ca (Hugo Slabbert) Date: Mon, 28 Apr 2014 12:30:14 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <535E8A42.2090207@pari.edu> References: <28726072.2309.1398637084729.JavaMail.root@benjamin.baylink.com> <535E8A42.2090207@pari.edu> Message-ID: <20140428193014.GA3580@stargate.ca> >The network op in me thinks double-dipping; the businessman >in me (hey, gotta make a living, no?) thinks I need to get a piece of >that profit, since that profit cannot be made without my last-mile >network, and I'm willing to 'leverage' that if need be. ...which turns the eyeball network provider into a gatekeeper. I think the clearest comment on this so far has been from Kristopher Doyen in the "What Net Neutrality should and should not cover" thread, which goes into players abusing their position in the market to extract additional revenue with stuff like this. Packets are packets are packets; aside from a sense of entitlement, why should the eyeball network provider get "a piece of the action" simply because the packets are revenue-generating for a 3rd party? This incurs a massive additional barrier to entry for any business that depends on the internet for their income, as now their revenue has to not only cover their own overhead and profits but also need to fund additional profits for ANY eyeball network provider that believes they're entitled to a "piece of the action". Why should I subsidize your business? E.g. I sell a widget on my website. An eyeball network provider's customer visits my website to purchase some widgets. "Hey", says eyeball network operator, "you're making money off of packets traversing my network! Pay up!" I know I've shifted this a bit from revenue-generating streaming content to a generic e-commerce situation, but how is that different except for the scale of traffic? If the eyeball network provider sees fit to charge Netflix $x/Gbps because of the $y/Gbps that Netflix is making from that traffic, the call on when to charge rests solely with the eyeball network operator. If my widget ecommerce store makes $1000y/Gbps because the traffic is small but revenue high, getting "a piece of the action" could mean $1000x/Gbps because there is more value "per packet". -- Hugo On Mon 2014-Apr-28 10:05:06 -0700, Lamar Owen wrote: >On 04/27/2014 06:18 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Hugo Slabbert" >>> I guess that's the question here: If additional transport directly >>> been POPs of the two parties was needed, somebody has to pay for the >>> links. >> And the answer is: at whose instance (to use an old Bell term) is that >> traffic moving. >> >> The answer is "at the instance of the eyeball's customers". >> >> So there's no call for the eyeball to charge the provider for it. >> >> > >Now, Jay, I don't often disagree with you, but today it occurred to me >the business case here (I've had to put on my businessman's hat far too >frequently lately, in dealing with trying to make a data center >operation profitable, or at least break-even). This should be taken >more as a 'devil's advocate' post more than anything else, and if I >missed someone else in the thread making the same point, my apologies to >the Department of Redundancy Department. > >Sure, the content provider is paying for their transit, and the eyeball >customer is paying for their transit. But the content provider is >further charging the eyeball's customer for the content, and thus is >making money off of the eyeball network's pipes. Think like a >businessman for a moment instead of like an operator. > >Now, I can either think of it as double dipping, or I can think of it as >getting a piece of the action. (One of my favorite ST:TOS episodes, by >the way). The network op in me thinks double-dipping; the businessman >in me (hey, gotta make a living, no?) thinks I need to get a piece of >that profit, since that profit cannot be made without my last-mile >network, and I'm willing to 'leverage' that if need be. How many >mail-order outfits won't charge for a customer list? Well, in this case >it's actual connectivity to customers, not just a customer list. The >argument about traffic congestion is just a strawman, disguising the >real, profit-sharing, motive. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From jfmezei_nanog at vaxination.ca Mon Apr 28 20:41:41 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 28 Apr 2014 16:41:41 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <5359D8A5.7030107@cox.net> <5359E188.8020906@cox.net> <02f601cf603e$1c191b40$544b51c0$@com> <5359EB4F.50405@cox.net> <535C483D.4060800@cox.net> <535DBDFA.405@mtcc.com> <20140428130524.GK36211@burnout.tpb.net> Message-ID: <535EBD05.8060106@vaxination.ca> On 14-04-28 09:23, Suresh Ramasubramanian wrote: > Comcast sells wholesale transit - > http://www.comcast.com/dedicatedinternet/?SCRedirect=true > > And it has a settlement free peering policy - with a stated > requirement that traffic exchanged be symmetrical. Analysing the effects of vertical integration is often best done by running structural separation scenarios. Netflix does not give content to Comcast-transit, it gives it to Comcast-ISP, this is especially true of cases where a network cache server is installed inside Comcast-ISP network. If Comcast-ISP told Netflix to install cache servers at one location, and then Comcast-ISP uses Comcast-transit to distribute content to all the cities it serves, it should be Comcast-ISP paying Comcast-transit for that service. It could just as well have installed the netflix appliance in every major city and not have to purchase transit from Comcast-transit. From robert at tarrall.org Mon Apr 28 22:37:00 2014 From: robert at tarrall.org (Robert Tarrall) Date: Mon, 28 Apr 2014 16:37:00 -0600 Subject: What Net Neutrality should and should not cover In-Reply-To: References: Message-ID: On Mon, Apr 28, 2014 at 7:22 AM, Kristopher Doyen < kristopher.doyen at gmail.com> wrote: > When last mile ISPs no longer have pressure or over-sight to maintain a > business model that puts user's needs first, because a happy user is a > returning user, you now have an entity who will do anything for a dollar as > long as it can't be proved illegal for the moment. [...] > I think Kristopher's email was a fantastic description of the situation, but I'd like to make one minor correction: "you now have an entity who will do anything for a dollar" full stop. Recent US antitrust litigation has tended towards penalties like "promise to stop doing that, and make sure the lawyers get paid." (Sometimes the initial penalty is much higher, but it gets reduced on appeal.) Nobody goes to jail and the financial penalties don't threaten the profits gained from the illegal behavior. If a corporation stands to make a few extra billion dollars a year from illegal behavior... their "worst case" outcome is they're fined $100 million and told to cut it out... and there's a good chance they can postpone this outcome by spending $18.8 million a year on lobbying... you do the math (because they certainly have). (All numbers made up except the $18.8MM which is in fact what Comcast spent on lobbying last year.) -Robert.- From cboyd at gizmopartners.com Mon Apr 28 23:41:29 2014 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 28 Apr 2014 18:41:29 -0500 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> Message-ID: On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote: > .... now aggregate it back down again, please. :-) I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. --Chris From LarrySheldon at cox.net Tue Apr 29 00:37:35 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 28 Apr 2014 19:37:35 -0500 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> <05E1CB77-1363-4C43-9298-A81512D79644@ianai.net> <53598552.2080800@paradoxnetworks.net> <20140424215749.GA39277@wakko.typo.org> <5359D8A5.7030107@cox.net> <535C3C78.5080006@cox.net> <535DC37A.50707@cox.net> Message-ID: <535EF44F.7090004@cox.net> On 4/28/2014 12:32 PM, Barry Shein wrote: > > On April 27, 2014 at 21:56 LarrySheldon at cox.net (Larry Sheldon) wrote: > > On 4/27/2014 8:59 PM, goemon at anime.net wrote: > > > If the carriers now get to play packet favoritism and pay-for-play, they > > > should lose common carrier protections. > > > > I didn't think the Internet providers were common carriers. > > Here we go again! > > There is more than one commonly used meaning for "common carriers". Please list only the meanings that involve "protections" that should be removed. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From patrick at ianai.net Tue Apr 29 01:59:43 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 28 Apr 2014 21:59:43 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> Message-ID: Composed on a virtual keyboard, please forgive typos. > On Apr 28, 2014, at 19:41, Chris Boyd wrote: > > >> On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote: >> >> .... now aggregate it back down again, please. :-) > > I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. -- TTFN, patrick From Valdis.Kletnieks at vt.edu Tue Apr 29 02:39:09 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Apr 2014 22:39:09 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: Your message of "Mon, 28 Apr 2014 21:59:43 -0400." References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> Message-ID: <3883.1398739149@turing-police.cc.vt.edu> On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: > > On Apr 28, 2014, at 19:41, Chris Boyd wrote: > > I'm in the middle of a physical move. I promise I'll take the 3 deagg'd > > /24s out as soon as I can. > Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table > would drop precipitously. We all have to do our part. Do we have a handle on what percent of the de-aggrs are legitimate attempts at TE, and what percent are just whoopsies that should be re-aggregated? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From Cliff.Bowles at apollo.edu Mon Apr 28 20:18:35 2014 From: Cliff.Bowles at apollo.edu (Cliff Bowles) Date: Mon, 28 Apr 2014 13:18:35 -0700 Subject: Question for service providers regarding tenant use of public IPv4 on your infrastructure Message-ID: <1A5C3257AD8D4946A4B497A6FAF501743C4F511F32@EXCH07-01.apollogrp.edu> (accidentally sent this to nanog-request earlier, sorry if there is a double post) We are an enterprise and we do not yet have a sophisticated service-provider model yet for billing, capacity-management, or infrastructure consumption. We have a few vBlocks that we consume internally for IT/business needs. Recently, the decision was made to start offering our infrastructure to partner businesses to deploy their apps on, which will then be made available to their customers. The ingress/egress, the virtualization and even the orchestration part are essentially covered. We've tackled the security part as well. However, we have some tenants that want to egress to the internet locally rather than backhaul the traffic to their premise. Naturally, we could ask each tenant to provide their own internet for this, but the business wants to explore a dedicated, customer-only internet and chargeback/showback. My question is: how are cloud providers handling the use of their IP space when they don't have full control over what their tenants are doing? More specifically, if you own a large block of IPs, how do you prevent business impact (or other tenant impact) if one tenant does something that causes an upstream ISP to blacklist/block? We don't want to put more controls in path between the tenant and the internet, we just want to know how to manage upstream relations. I've heard that some ISPs don't block a specific IP when they see malicious behavior; they do a WHOIS and block the whole range. That would, of course, impact multiple tenants. I'm guessing Amazon and other similar providers have some arrangements with peering ISPs and law-enforcement to ensure that there is consultation before action is taken? Or do ISPs put some level of security between their tenants and the internet to prevent this? I've been told that the majority do not have any intelligent filtering beyond bogon-lists. I'd imagine that would cause huge operational overhead and frustrate the tenants. If you've tackled this issue as part of your business, I'd appreciate any feedback. Thanks in advance. CWB ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. From rdobbins at arbor.net Tue Apr 29 03:35:43 2014 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 29 Apr 2014 03:35:43 +0000 Subject: Question for service providers regarding tenant use of public IPv4 on your infrastructure In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C4F511F32@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C4F511F32@EXCH07-01.apollogrp.edu> Message-ID: <74316354-38B7-4043-A699-7A3545003F2B@arbor.net> On Apr 28, 2014, at 3:18 PM, Cliff Bowles wrote: > Or do ISPs put some level of security between their tenants and the internet to prevent this? I've been told that the majority do not have any intelligent filtering beyond bogon-lists. Flow telemetry export/collection/analysis for detection/classification/traceback (there are several open-source tools), S/RTBH or flowspec to squelch outbound badness. Plus all the usual BCPs: ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From cgucker at onesc.net Tue Apr 29 04:45:41 2014 From: cgucker at onesc.net (Charles Gucker) Date: Tue, 29 Apr 2014 00:45:41 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <3883.1398739149@turing-police.cc.vt.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> Message-ID: On Mon, Apr 28, 2014 at 10:39 PM, wrote: > On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: > > > On Apr 28, 2014, at 19:41, Chris Boyd wrote: > > > I'm in the middle of a physical move. I promise I'll take the 3 > deagg'd > > > /24s out as soon as I can. > > Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the > table > > would drop precipitously. We all have to do our part. > > Do we have a handle on what percent of the de-aggrs are legitimate attempts > at TE, and what percent are just whoopsies that should be re-aggregated? > And of those TE routes, how many can be suppressed by way of BGP Communities with their respective upstream providers ... charles From gih at apnic.net Tue Apr 29 07:31:31 2014 From: gih at apnic.net (Geoff Huston) Date: Tue, 29 Apr 2014 17:31:31 +1000 Subject: We hit half-million: The Cidr Report In-Reply-To: <3883.1398739149@turing-police.cc.vt.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> Message-ID: <9BD28641-5B59-4C88-BD76-97F4E3BFA570@apnic.net> On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks at vt.edu wrote: > On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: >>> On Apr 28, 2014, at 19:41, Chris Boyd wrote: >>> I'm in the middle of a physical move. I promise I'll take the 3 deagg'd >>> /24s out as soon as I can. >> Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table >> would drop precipitously. We all have to do our part. > > Do we have a handle on what percent of the de-aggrs are legitimate attempts > at TE, and what percent are just whoopsies that should be re-aggregated? > I made a shot at such a number in a presentation to NANOG in Feb this year (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) If you assume that Traffic Engineering more specifics share a common origin AS with the covering aggregate, then around 26% of more specifics are TE advertisements. This number (as a percentage) has gwon by 5% over the past three years If you assume that Hole Punching more specifics are more specifics that use a different origin AS, then these account for 30% of the more specifics in today's routing table. This number has fallen by 5% over the past three years. The remainder of the prefixes (45%) shares the same origin AS and the same path. The could be TE prefixes, but as they are identical to their covering aggregate its hard to appreciate exactly what the engineering intent may be. I could make a wild guess and call these 45% of more specifics to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. Interestingly, it's the hole punching more specifics that are less stable, and the senseless routing vandalism more specifics that are more stable than the average. thanks, Geoff From brak at gameservers.com Tue Apr 29 16:13:27 2014 From: brak at gameservers.com (Brian Rak) Date: Tue, 29 Apr 2014 12:13:27 -0400 Subject: Question for service providers regarding tenant use of public IPv4 on your infrastructure In-Reply-To: <1A5C3257AD8D4946A4B497A6FAF501743C4F511F32@EXCH07-01.apollogrp.edu> References: <1A5C3257AD8D4946A4B497A6FAF501743C4F511F32@EXCH07-01.apollogrp.edu> Message-ID: <535FCFA7.7050408@gameservers.com> On 4/28/2014 4:18 PM, Cliff Bowles wrote: > (accidentally sent this to nanog-request earlier, sorry if there is a double post) > > We are an enterprise and we do not yet have a sophisticated service-provider model yet for billing, capacity-management, or infrastructure consumption. We have a few vBlocks that we consume internally for IT/business needs. Recently, the decision was made to start offering our infrastructure to partner businesses to deploy their apps on, which will then be made available to their customers. > > The ingress/egress, the virtualization and even the orchestration part are essentially covered. We've tackled the security part as well. However, we have some tenants that want to egress to the internet locally rather than backhaul the traffic to their premise. Naturally, we could ask each tenant to provide their own internet for this, but the business wants to explore a dedicated, customer-only internet and chargeback/showback. > > My question is: how are cloud providers handling the use of their IP space when they don't have full control over what their tenants are doing? More specifically, if you own a large block of IPs, how do you prevent business impact (or other tenant impact) if one tenant does something that causes an upstream ISP to blacklist/block? We don't want to put more controls in path between the tenant and the internet, we just want to know how to manage upstream relations. If you're allocating individual customers their own subnets, make sure you report these allocations to ARIN (via SWIP). This will make the whois results more accurate, so you'll hopefully just end up with the individual customer getting blacklisted, rather then your entire range. Make sure you actually respond to abuse complaints in a timely fashion. If you're actually responsive to abuse complaints, it's a lot less likely you'll end up with all of your subnets blacklisted. > I'm guessing Amazon and other similar providers have some arrangements with peering ISPs and law-enforcement to ensure that there is consultation before action is taken? I doubt it. Most of Amazon's EC2 IP ranges are on various blacklists. There's really no feasible way for them to keep all their IPs off blacklists, so I suspect they've just given up trying. > Or do ISPs put some level of security between their tenants and the internet to prevent this? I've been told that the majority do not have any intelligent filtering beyond bogon-lists. I'd imagine that would cause huge operational overhead and frustrate the tenants. You should try to block whatever abuse you can, especially if you're going to be offering 'cloud' servers to the public. Get some routine security scans going (start off with the basics, look for open resolvers, vulnerable NTP servers, open chargen servers, SNMP servers with default communities) and alert your customers whenever you detect something. It should go without saying, but make sure your users cannot spoof IP addresses. From patrick at ianai.net Tue Apr 29 16:22:36 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 29 Apr 2014 12:22:36 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <9BD28641-5B59-4C88-BD76-97F4E3BFA570@apnic.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> <9BD28641-5B59-4C88-BD76-97F4E3BFA570@apnic.net> Message-ID: > The remainder of the prefixes (45%) shares the same origin AS and the same path. > The could be TE prefixes, but as they are identical to their covering > aggregate its hard to appreciate exactly what the engineering intent may be. I could > make a wild guess and call these 45% of more specifics to be an act of senseless routing > vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?" The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston wrote: > > On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks at vt.edu wrote: > >> On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: >>>> On Apr 28, 2014, at 19:41, Chris Boyd wrote: >>>> I'm in the middle of a physical move. I promise I'll take the 3 deagg'd >>>> /24s out as soon as I can. >>> Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table >>> would drop precipitously. We all have to do our part. >> >> Do we have a handle on what percent of the de-aggrs are legitimate attempts >> at TE, and what percent are just whoopsies that should be re-aggregated? >> > > I made a shot at such a number in a presentation to NANOG in Feb this year > (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) > > > If you assume that Traffic Engineering more specifics share a common origin AS with the > covering aggregate, then around 26% of more specifics are TE advertisements. This > number (as a percentage) has gwon by 5% over the past three years > > > If you assume that Hole Punching more specifics are more specifics that use a different > origin AS, then these account for 30% of the more specifics in today's routing table. > This number has fallen by 5% over the past three years. > > The remainder of the prefixes (45%) shares the same origin AS and the same path. > The could be TE prefixes, but as they are identical to their covering > aggregate its hard to appreciate exactly what the engineering intent may be. I could > make a wild guess and call these 45% of more specifics to be an act of senseless routing > vandalism. ( :-) ) This number has been steady as a % for the past three years. > > Interestingly, it's the hole punching more specifics that are less stable, and the > senseless routing vandalism more specifics that are more stable than the average. > > thanks, > Geoff From kate at quadranet.com Tue Apr 29 16:29:28 2014 From: kate at quadranet.com (Kate Gerry) Date: Tue, 29 Apr 2014 09:29:28 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> <9BD28641-5B59-4C88-BD76-97F4E3BFA570@apnic.net> Message-ID: <4B4120B1642DCF48ACA84E4F82C8E1F6015574F881F3@EXCH> Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. -- Kate Gerry Network Manager kate at quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on:   -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore Sent: Tuesday, April 29, 2014 9:23 AM To: NANOG list Subject: Re: We hit half-million: The Cidr Report > The remainder of the prefixes (45%) shares the same origin AS and the same path. > The could be TE prefixes, but as they are identical to their covering > aggregate its hard to appreciate exactly what the engineering intent > may be. I could make a wild guess and call these 45% of more specifics > to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. This could easily be TE, and a type of TE which would be trivially fixed. Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE. Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?" The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".) This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. Who will be the first to pull back a few prefixes? -- TTFN, patrick On Apr 29, 2014, at 03:31 , Geoff Huston wrote: > > On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks at vt.edu wrote: > >> On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: >>>> On Apr 28, 2014, at 19:41, Chris Boyd wrote: >>>> I'm in the middle of a physical move. I promise I'll take the 3 >>>> deagg'd /24s out as soon as I can. >>> Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the >>> table would drop precipitously. We all have to do our part. >> >> Do we have a handle on what percent of the de-aggrs are legitimate >> attempts at TE, and what percent are just whoopsies that should be re-aggregated? >> > > I made a shot at such a number in a presentation to NANOG in Feb this > year > (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) > > > If you assume that Traffic Engineering more specifics share a common > origin AS with the covering aggregate, then around 26% of more > specifics are TE advertisements. This number (as a percentage) has > gwon by 5% over the past three years > > > If you assume that Hole Punching more specifics are more specifics > that use a different origin AS, then these account for 30% of the more specifics in today's routing table. > This number has fallen by 5% over the past three years. > > The remainder of the prefixes (45%) shares the same origin AS and the same path. > The could be TE prefixes, but as they are identical to their covering > aggregate its hard to appreciate exactly what the engineering intent > may be. I could make a wild guess and call these 45% of more specifics > to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. > > Interestingly, it's the hole punching more specifics that are less > stable, and the senseless routing vandalism more specifics that are more stable than the average. > > thanks, > Geoff From owen at delong.com Tue Apr 29 16:36:50 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Apr 2014 09:36:50 -0700 Subject: What Net Neutrality should and should not cover In-Reply-To: <535EA848.3050201@meetinghouse.net> References: <21342.39572.591252.237834@world.std.com> <535EA848.3050201@meetinghouse.net> Message-ID: <7E0D201A-3CBE-4E5A-B238-17BB8334A1A2@delong.com> On Apr 28, 2014, at 12:13 PM, Miles Fidelman wrote: > Barry Shein wrote: >> I think the problem is simply a lack of competition and the rise of, >> in effect, vertical trusts. That is, content providers also >> controlling last-mile services. >> >> What exists is rife with conflict of interest and unfair market >> power. Particularly in that wire-plants are generally protected >> monopolies or small-N oligopolies. >> >> The wire-plant* operators and content providers need to be separated >> and competition needs to be mandated by allowing easy and fair access >> to wire-plants. >> >> Wire-plant operators should be closely regulated. Content providers >> should not, in general, be regulated. >> >> >> * Which of course may not involve any actual wires but it's a term of >> art, L1/L2 if you prefer. > > I kind of think Layer 3 - metropolitan area IP carriage seems to be where the issues converge. Somehow the notion of multiple IP providers, operating across unbundled fiber, doesn’t seem to work out in practice. It’s working quite well in areas where it’s been tried in earnest. > Yes, there are a few municipal networks that provide Ethernet VPNs as the basic block of unbundled service - with multiple players providing various Internet (IP), video, and voice services on their own VPNs; and there are some networks, particularly in Canada, where the unit of unbundling is a wavelength, on a common fiber/conduit plant; but in most cases, economies of scale seem to dictate a single IP-layer fabric for a geographic area. (Think campus and enterprise networks.) If you build out a fiber plant with home runs to colocation facilities where providers can meet subscriber lines, the economies of scale can generally work and do in some areas. While active ethernet to the subscriber isn’t necessarily viable, GPON with the splitter at the MMR is just as viable as GPON with the splitter in the neighborhood. This was, in fact, discussed at length a while back on this very list. Owen From ml at kenweb.org Tue Apr 29 16:43:17 2014 From: ml at kenweb.org (ML) Date: Tue, 29 Apr 2014 12:43:17 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F6015574F881F3@EXCH> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> <9BD28641-5B59-4C88-BD76-97F4E3BFA570@apnic.net> <4B4120B1642DCF48ACA84E4F82C8E1F6015574F881F3@EXCH> Message-ID: <535FD6A5.7070901@kenweb.org> At one time Covad stated they announce everything as /24 to make hijacking more difficult. Looks like Covad (now MEGAPATH) hasn't changed that policy. On 4/29/2014 12:29 PM, Kate Gerry wrote: > Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. > > -- > Kate Gerry > Network Manager > kate at quadranet.com > > 1-888-5-QUADRA Ext 206 | www.QuadraNet.com > Dedicated Servers, Colocation, Cloud Services and more. > Datacenters in Los Angeles, Dallas and Miami. > > Follow us on: > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore > Sent: Tuesday, April 29, 2014 9:23 AM > To: NANOG list > Subject: Re: We hit half-million: The Cidr Report > >> The remainder of the prefixes (45%) shares the same origin AS and the same path. >> The could be TE prefixes, but as they are identical to their covering >> aggregate its hard to appreciate exactly what the engineering intent >> may be. I could make a wild guess and call these 45% of more specifics >> to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. > This could easily be TE, and a type of TE which would be trivially fixed. > > Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. > > A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE. > > Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?" > > The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".) > > > This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? > > If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. > > Who will be the first to pull back a few prefixes? > > -- > TTFN, > patrick > > On Apr 29, 2014, at 03:31 , Geoff Huston wrote: > >> On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks at vt.edu wrote: >> >>> On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: >>>>> On Apr 28, 2014, at 19:41, Chris Boyd wrote: >>>>> I'm in the middle of a physical move. I promise I'll take the 3 >>>>> deagg'd /24s out as soon as I can. >>>> Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the >>>> table would drop precipitously. We all have to do our part. >>> Do we have a handle on what percent of the de-aggrs are legitimate >>> attempts at TE, and what percent are just whoopsies that should be re-aggregated? >>> >> I made a shot at such a number in a presentation to NANOG in Feb this >> year >> (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) >> >> >> If you assume that Traffic Engineering more specifics share a common >> origin AS with the covering aggregate, then around 26% of more >> specifics are TE advertisements. This number (as a percentage) has >> gwon by 5% over the past three years >> >> >> If you assume that Hole Punching more specifics are more specifics >> that use a different origin AS, then these account for 30% of the more specifics in today's routing table. >> This number has fallen by 5% over the past three years. >> >> The remainder of the prefixes (45%) shares the same origin AS and the same path. >> The could be TE prefixes, but as they are identical to their covering >> aggregate its hard to appreciate exactly what the engineering intent >> may be. I could make a wild guess and call these 45% of more specifics >> to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. >> >> Interestingly, it's the hole punching more specifics that are less >> stable, and the senseless routing vandalism more specifics that are more stable than the average. >> >> thanks, >> Geoff From contact at winterei.se Tue Apr 29 16:46:58 2014 From: contact at winterei.se (Paul S.) Date: Tue, 29 Apr 2014 22:46:58 +0600 Subject: We hit half-million: The Cidr Report In-Reply-To: <4B4120B1642DCF48ACA84E4F82C8E1F6015574F881F3@EXCH> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> <9BD28641-5B59-4C88-BD76-97F4E3BFA570@apnic.net> <4B4120B1642DCF48ACA84E4F82C8E1F6015574F881F3@EXCH> Message-ID: <535FD782.5010805@winterei.se> There are many actually doing this, to be honest. From the top of my head, in the greater Dallas area, 54540 comes to mind. http://bgp.he.net/AS54540#_asinfo For large ASNs like these, aggregation would really help the table size. That said, working on reducing our own as well. On 4/29/2014 10:29 PM, Kate Gerry wrote: > Already working on aggregating as much as I can. I was checking my tables the other day and I think I saw another provider advertising their /18 as /24s, it made me sick. > > -- > Kate Gerry > Network Manager > kate at quadranet.com > > 1-888-5-QUADRA Ext 206 | www.QuadraNet.com > Dedicated Servers, Colocation, Cloud Services and more. > Datacenters in Los Angeles, Dallas and Miami. > > Follow us on: > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick W. Gilmore > Sent: Tuesday, April 29, 2014 9:23 AM > To: NANOG list > Subject: Re: We hit half-million: The Cidr Report > >> The remainder of the prefixes (45%) shares the same origin AS and the same path. >> The could be TE prefixes, but as they are identical to their covering >> aggregate its hard to appreciate exactly what the engineering intent >> may be. I could make a wild guess and call these 45% of more specifics >> to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. > This could easily be TE, and a type of TE which would be trivially fixed. > > Let's take a simple example of a network with a /22 and 4 POPs. They have the same transit provider(s) at all 4 POPs and a small backbone to connect them. Each POP gets a /24. > > A not-ridiculous way to force their transit provider to carry bits instead of clogging their backbone while still ensuring redundancy would be to announce the /22 at all four POPs and the individual /24 at each individual POP. This creates four /24s and a covering /22 with exactly the same path, but still has "use" as TE. > > Of course, it would be trivial for the network to clean up their act by attacking no-export to the /24s. But some people either do not know it exists, know how it works, or know BGP well enough to understand it would not harm them. Or maybe they are just lazy: "What's 3 extra prefixes in half a million?" > > The answer to the last question is, frankly, nothing. But 3 prefixes for 30K ASNs is an ass-ton. (That's a technical term meaning "lots & lots".) > > > This is a good time for a marketing effort. Let's see if we can get the table back under 500K. Everyone check your announcements. Are you announcing more specifics and a covering aggregate with the same path? Can you delete the more specific? Can you add no-export or another community to keep the more specifics from the global table? > > If you are unsure, ask. I think it would be rather awesome if we saw a quick reversal in table growth and went back under 500K, even if it was short lived. ESPECIALLY if we can do it before we hit 512K prefixes. Would prove the community still cares about, well, the community, not just their own network. Because on the Internet, "your network" is part of the "community", and things that harm the latter do harm the former, even if it is difficult for you to see sometimes. > > Who will be the first to pull back a few prefixes? > > -- > TTFN, > patrick > > On Apr 29, 2014, at 03:31 , Geoff Huston wrote: > >> On 29 Apr 2014, at 12:39 pm, Valdis.Kletnieks at vt.edu wrote: >> >>> On Mon, 28 Apr 2014 21:59:43 -0400, "Patrick W. Gilmore" said: >>>>> On Apr 28, 2014, at 19:41, Chris Boyd wrote: >>>>> I'm in the middle of a physical move. I promise I'll take the 3 >>>>> deagg'd /24s out as soon as I can. >>>> Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the >>>> table would drop precipitously. We all have to do our part. >>> Do we have a handle on what percent of the de-aggrs are legitimate >>> attempts at TE, and what percent are just whoopsies that should be re-aggregated? >>> >> I made a shot at such a number in a presentation to NANOG in Feb this >> year >> (http://www.potaroo.net/presentations/2014-02-09-bgp2013.pdf) >> >> >> If you assume that Traffic Engineering more specifics share a common >> origin AS with the covering aggregate, then around 26% of more >> specifics are TE advertisements. This number (as a percentage) has >> gwon by 5% over the past three years >> >> >> If you assume that Hole Punching more specifics are more specifics >> that use a different origin AS, then these account for 30% of the more specifics in today's routing table. >> This number has fallen by 5% over the past three years. >> >> The remainder of the prefixes (45%) shares the same origin AS and the same path. >> The could be TE prefixes, but as they are identical to their covering >> aggregate its hard to appreciate exactly what the engineering intent >> may be. I could make a wild guess and call these 45% of more specifics >> to be an act of senseless routing vandalism. ( :-) ) This number has been steady as a % for the past three years. >> >> Interestingly, it's the hole punching more specifics that are less >> stable, and the senseless routing vandalism more specifics that are more stable than the average. >> >> thanks, >> Geoff From jra at baylink.com Tue Apr 29 17:48:53 2014 From: jra at baylink.com (Jay Ashworth) Date: Tue, 29 Apr 2014 13:48:53 -0400 (EDT) Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <5E7F8485-1516-45CD-A05C-9BC5FB6DBE76@delong.com> Message-ID: <31421771.2411.1398793733859.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > What is absolutely contrary to the public interest is allowing $CABLECO to > leverage their position as a monopoly or oligopoly ISP to create an > operational disadvantage in access for that competing product. I was with you right up til here. > The so-called “internet fast lane” is a euphemism for allowing $CABLECO > to put competing video products into a newly developed slow-lane while > limiting the existing path to their own products and those content > providers that are able to and choose to pay these additional fees. So, how do you explain, and justify -- if you do -- cablecos who use IPTV to deliver their mainline video, and supply VoIP telephone... and use DOCSIS to put that traffic on separate pipes to the end terminal from their IP service, an advantage which providers who might compete with them don't have -- *even*, I think, if they are FCC mandated alternative IP providers who get aggregated access to the cablemodem, as do Earthlink and the local Internet Junction in my market, which can (at least in theory) still be provisioned as your cablemodem supplier for Bright House (Advance/Newhouse) customers. Those are "fast lanes" for TV and Voice traffic, are they not? They are (largely) anticompetitive, and unavailable to other providers. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From kamtha at ak-labs.net Tue Apr 29 18:06:52 2014 From: kamtha at ak-labs.net (Carlos Kamtha) Date: Tue, 29 Apr 2014 14:06:52 -0400 Subject: dedicated server providers in Mexico? Message-ID: <20140429180652.GA93534@ak-labs.net> Hi everyone, I am currently not happy with out MX server provider, and so, inquiring with anyone that can give a recommendation based on experience? I found this list via google. http://www.webhostingsearch.com/dedicated-server/mexico.php I wondering if anyone can speak to any of the providers on this list (outside of 1n1). offlist.. Feedback as always greatly appreciated. Cheers, Carlos. From jason at unlimitednet.us Tue Apr 29 18:13:02 2014 From: jason at unlimitednet.us (Jason Canady) Date: Tue, 29 Apr 2014 14:13:02 -0400 Subject: dedicated server providers in Mexico? In-Reply-To: <20140429180652.GA93534@ak-labs.net> References: <20140429180652.GA93534@ak-labs.net> Message-ID: <535FEBAE.6010305@unlimitednet.us> I have no experience with dedicated hosting providers in Mexico, but that list is incorrect. I know that Steadfast does not have servers located in Mexico. I believe other providers are also incorrectly listed. You should search for providers on Web Hosting Talk, http://www.webhostingtalk.com Regards, Jason On 4/29/14, 2:06 PM, Carlos Kamtha wrote: > Hi everyone, > > I am currently not happy with out MX server provider, and so, inquiring > with anyone that can give a recommendation based on experience? > > I found this list via google. > > http://www.webhostingsearch.com/dedicated-server/mexico.php > > I wondering if anyone can speak to any of the providers on this list > (outside of 1n1). offlist.. > > Feedback as always greatly appreciated. > > Cheers, > > Carlos. From jfmezei_nanog at vaxination.ca Tue Apr 29 22:07:56 2014 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 29 Apr 2014 18:07:56 -0400 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <31421771.2411.1398793733859.JavaMail.root@benjamin.baylink.com> References: <31421771.2411.1398793733859.JavaMail.root@benjamin.baylink.com> Message-ID: <536022BC.6020706@vaxination.ca> On 14-04-29 13:48, Jay Ashworth wrote: > So, how do you explain, and justify -- if you do -- cablecos who use > IPTV to deliver their mainline video, and supply VoIP telephone... In Canada, our "net neutrality" rules are called the ITMP, for Internet Traffic Management Practices which occured as a result of Bell Canada throttling P2P and then wanting to charge UBB *solely to manage traffic* (since the UBB rates had nothing to do with costs, they had to do with moderating usage to reduce congestion). The ITMP rules as well as section 27(2) of the Telecommunications Act prevent undue preference and basically states thart if if apply an ITMP (either throttling or UBB) it must be applied evenly to all content. The apply "evenly" was even argued by the incumbents who stated that everyonr had to pay the same UBB rate for all access in order to ensure that the UBB ITMP plays an equal role in moderating usage. (users with ower UBB rates or with some content exempt would then use mroe of the network capacity and cause disproporaionate congestion which would hurt those paying the higher UBB rates) When an incumbent argues that its *broadcasting* service is on different capacity and does not cause congestion to the telecom side of things, then the "broadcasting" service does not have to play by those rules. In the case of cablecos, their TV service uses different frequencies on the coax, so they do not affect data transfers. For Telcos, in the case of Bell, proper use of semantics and propaganda convinced the CRTC that it FibeTV service was on totally different network capacity right up to the DSLAM, and since there was no congestion on the DSL last copper mile, the fact that the two shared the last mile didn't matter because the congestion happened in the aggregation network where FibeTV was already on a separate network. So both cablecos and telcos get their wireline "broadcasting" execpt from the net neutrality rules in Canada. Currently, there is a complaint about wireless TV where the incumbents do not charge UBB for their own TV service, while charging UBB for competing services such as Netflix, or accessing content from a TV station's web site etc. In the last round, they basically admitted that in the case of wireless, those service co-exist with other internet traffic on the same pipe to the handsets. The TV on mobile phones is the first true test of "network neutrality" under the 2009 ITMP rules. Previous complaints had to do with fautly throttling which singled out certain applications like games. The Mobile TV service is one where the incumbents give their own TV service an undue preference. Bell Canada argues that because their TV service is "broadcasting", it is under a different law (Boradcasting Act) and not bound by ITMP rules. From mpetach at netflight.com Tue Apr 29 23:48:14 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 29 Apr 2014 16:48:14 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: References: <47D17BE3-98EA-4A3E-8655-2562EB256636@ianai.net> Message-ID: It was pointed out privately to me that I may have caused some confusion here with my variable substitution. $BB_provider was intended to be "BroadBand provider", *not* "BackBone provider", as some people have (understandably) misread it. So--to clarify, this was not meant as any type of characterization of backbone providers, but rather of broadband providers. I hope this helps clear up any confusion. Thanks! Matt On Sun, Apr 27, 2014 at 11:44 AM, Matthew Petach wrote: > > > > On Thu, Apr 24, 2014 at 5:15 AM, Patrick W. Gilmore wrote: > >> Anyone afraid what will happen when companies which have monopolies can >> charge content providers or guarantee packet loss? >> >> In a normal "free market", if two companies with a mutual consumer have a >> tiff, the consumer decides which to support. Where I live, I have one >> broadband provider. If they get upset with, say, a streaming provider, I >> cannot choose another BB company because I like the streaming company. I >> MUST pick another streaming company, as that is the only thing I can >> "choose". >> > > > [I speak only for myself here; any use of the word "we" > should be taken to represent only my sense of inclusion > with the rest of humanity, and not with any commercial > entity or organization. Any other characterization of the > following words is patently incorrect, and grounds for > possible actions, up to and including litigation. Please > don't be an ass, and quote me out of context, or as > representing something I'm not. Original post edited > slightly, with specific entity names replaced with > variables; you may do your own substitution back > into the variables as you feel appropriate. --MNP] > > > What if we turn the picture around slightly, and look > at it like the negotiations between broadcast networks > and cable companies? 2010's battle between Fox television > and cablevision comes to mind, where the content holder > blacked out access to their content for specific cable > companies unless they agree to pay the demanded fees. > > It would be interesting to have seen $content_CEO take a > hard line stance; it wouldn't be hard to send a BGP feed > to video streaming servers, and if the requestor's IP was > from a prefix seen behind AS$foo, put up a message > informing the subscriber that their access to $company's > content would cease on such-and-such a date, due > to $BB_provider's unwillingness to agree to increase > interconnect capacity, and that if subscribers wished > to continue to see $company's content, they should consider > switching to a different network provider. Basically, > follow the same model News Corp used against > Cablevision, Viacom used against Time Warner, > or Disney used against Cablevision. > > How long would $BB_provider be able to hold out against > the howls of its users, if there was a scrolling > banner across the top of the screen during their > favorite show, or favorite movie alerting them that > they would soon be unable to see that content > unless they switched to a different service provider? > > It's easy to forget that the sword can be swung both > ways. Right now, $BB_provider is swinging the sharp edge > at $content; but $content is not without its own influence in > the market, and could swing the sword the other way, > cutting back at $BB_provider. Yes, it comes at some great > risk to $content, in terms of potential customer loss; but > no great wins come without great risks (unless you > cheat, and use the government to get you a big win > at no risk--but none of us like that model). > > I think it's high time for content players to flex their > power, and push back on the eyeball networks that > attempt to use their customer base as hostages to > extract additional revenue from the content being > requested by their users. If the content providers > simply make it clearly visible to the end users that > they cannot watch the requested content on that > network, or that they can only watch in reduced > resolution from that network, it will have a two-fold > effect: a) traffic volume from the content provider > to the contentious network will be reduced, limiting > the need for the upgrades in the first place, and > b) customers of the provider will be informed of > their status as hostage cannon fodder on the > battlefield, allowing them to vote with their wallets. > One could potentially even insert suggestions > for alternate connectivity options they might > consider into the content feed, to help the > users vote with their wallets more easily. > Or, provide the phone number of the local > municipal office that granted the franchise > rights to the BB provider, along with instructions > on what to say when calling ("Hi--I'm a registered > voter in your district. If you'd like to get re-elected > next term, you need to repeal the cable franchise > agreement with broadband provider such-and-so, > as their monopolistic practices are hampering > my ability to freely choose what content I can > consume.") > > We're not powerless in this fight. We often take > a victim mindset, and look for some other entity > to rescue us; but that's not the right way to thrive. > Instead of thinking that we're weak, we're victims, > and can't protect ourselves, or that we need some > other big, strong entity to shelter and protect us, > we need to realize that we *are* strong. We *are* > capable of standing up and fighting back. We *do* > have power, and can say no to the bullies. > > They want us to feel we have no say in the matter, > that we cannot survive without protection. > > But they are wrong. > > We are strong. > We are capable. > We *can* fight back. > > For example, in Patrick's case (he being a Bostonian > still, I believe), the municipal cable office responsible > for the cable franchises in the city are handled by: > http://www.cityofboston.gov/contact/?id=35 > > > > >> >> How is this good for the consumer? How is this good for the market? >> >> -- >> TTFN, >> patrick >> >> >> http://m.washingtonpost.com/blogs/the-switch/wp/2014/04/23/the-fcc-is-planning-new-net-neutrality-rules-and-they-could-enshrine-pay-for-play/ >> >> >> Composed on a virtual keyboard, please forgive typos. >> >> >> > I don't think it's good for the consumer or the market; > but I also don't think it's just up to the government to > step in and try to protect the consumer and the market. > There's a lot we can do to shape the outcome, if we > just step up to the plate and make our voices (and our > wallets) heard. > > We are not victims. > > We *are* the market. > > Never forget; we have given them the power they > currently have. > And that means we can take it away again. > > It won't be easy. > > It won't be painless. > > But it *can* be done. > > Matt > From paul.norton at gmail.com Tue Apr 29 21:26:20 2014 From: paul.norton at gmail.com (Paul Norton) Date: Tue, 29 Apr 2014 14:26:20 -0700 Subject: dedicated server providers in Mexico? In-Reply-To: <20140429180652.GA93534@ak-labs.net> References: <20140429180652.GA93534@ak-labs.net> Message-ID: <536018FC.7080401@gmail.com> RedIT -- Paul Norton Carlos Kamtha wrote: > Hi everyone, > > I am currently not happy with out MX server provider, and so, inquiring > with anyone that can give a recommendation based on experience? > > I found this list via google. > > http://www.webhostingsearch.com/dedicated-server/mexico.php > > I wondering if anyone can speak to any of the providers on this list > (outside of 1n1). offlist.. > > Feedback as always greatly appreciated. > > Cheers, > > Carlos. From owen at delong.com Tue Apr 29 18:06:06 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Apr 2014 11:06:06 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> Message-ID: On Apr 28, 2014, at 6:59 PM, Patrick W. Gilmore wrote: > Composed on a virtual keyboard, please forgive typos. > >> On Apr 28, 2014, at 19:41, Chris Boyd wrote: >> >> >>> On Apr 28, 2014, at 2:27 AM, Andy Davidson wrote: >>> >>> .... now aggregate it back down again, please. :-) >> >> I'm in the middle of a physical move. I promise I'll take the 3 deagg'd /24s out as soon as I can. > > Do not laugh. If everyone who had 3 de-agg'ed prefixes fixed it, the table would drop precipitously. We all have to do our part. If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… As a bonus, we could get rid of NAT, too. ;-) /me ducks (but you know I had to say it) Owen From owen at delong.com Tue Apr 29 18:14:59 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Apr 2014 11:14:59 -0700 Subject: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post In-Reply-To: <31421771.2411.1398793733859.JavaMail.root@benjamin.baylink.com> References: <31421771.2411.1398793733859.JavaMail.root@benjamin.baylink.com> Message-ID: On Apr 29, 2014, at 10:48 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> What is absolutely contrary to the public interest is allowing $CABLECO to >> leverage their position as a monopoly or oligopoly ISP to create an >> operational disadvantage in access for that competing product. > > I was with you right up til here. > >> The so-called “internet fast lane” is a euphemism for allowing $CABLECO >> to put competing video products into a newly developed slow-lane while >> limiting the existing path to their own products and those content >> providers that are able to and choose to pay these additional fees. > > So, how do you explain, and justify -- if you do -- cablecos who use > IPTV to deliver their mainline video, and supply VoIP telephone... > > and use DOCSIS to put that traffic on separate pipes to the end terminal > from their IP service, an advantage which providers who might compete > with them don't have -- *even*, I think, if they are FCC mandated > alternative IP providers who get aggregated access to the cablemodem, > as do Earthlink and the local Internet Junction in my market, which > can (at least in theory) still be provisioned as your cablemodem > supplier for Bright House (Advance/Newhouse) customers. I don’t explain it, don’t justify it, don’t support it. > Those are “fast lanes" for TV and Voice traffic, are they not? Carving the pipe up into lanes to begin with is kind of questionable IMHO. I realize it’s tradition, but if you think about it, it was only necessary when things were TDM/FDM. Once everything is IP, dividing the IP up among different TDM/FDM is just a way to take one large fast lane and turn it into slow lanes (some slower than others, perhaps) where some traffic can be given preferential treatment. > They are (largely) anticompetitive, and unavailable to other providers. Agreed… I thought that’s what I said above. Owen From jeff-kell at utc.edu Wed Apr 30 02:54:59 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 29 Apr 2014 22:54:59 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> Message-ID: <53606603.1070004@utc.edu> On 4/29/2014 2:06 PM, Owen DeLong wrote: > If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… > > As a bonus, we could get rid of NAT, too. ;-) > > /me ducks (but you know I had to say it) Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / etc had been eliminated by process of "can't get there from here"... we expose millions more endpoints... /me ducks too (but you know *I* had to say it) From cb.list6 at gmail.com Wed Apr 30 03:37:32 2014 From: cb.list6 at gmail.com (TheIpv6guy .) Date: Tue, 29 Apr 2014 20:37:32 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <53606603.1070004@utc.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> Message-ID: On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell wrote: > On 4/29/2014 2:06 PM, Owen DeLong wrote: >> If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… >> >> As a bonus, we could get rid of NAT, too. ;-) >> >> /me ducks (but you know I had to say it) > > Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / > etc had been eliminated by process of "can't get there from here"... we > expose millions more endpoints... > > /me ducks too (but you know *I* had to say it) > No ducking here. You forgot Nimda. Do you have an example from the last 10 years of this class ? Windows XP SP3 with a default host firewall on really did solve most of this, not NAT. Not stateful firewalls in networks. In fact, jogging my memory, i clearly remember Blaster taking out enterprise networks with network firewalls and stateful inspection... because people manually move their laptops between security zones. Right? They got infected on one LAN and then attached and spread the worm to other LANs. I also remember the folks saying we just spent $100k on a pair of super Netscreen firewalls, why is our network crashing? Right? And then the infection scanning from hacked hosts... of course, overloaded the firewall, and that crashed the entire campus... because the firewall was a single point of failure sitting on the internet boarder... and it has the 0-day flaw of too many sessions = crash. Most firewalls have this 0-day, it's a feature. This really happened to me in 2003, where a network based attack had a broad impact on hosts. But, never again after Win XP SP3. Now, i just have DDoS from purposefully publicly (poorly) run NTP and DNS servers. And, hacks from users clicking on links they know they should not click on. Oh, and anything made with Java or Adobe or IE. Those things are impossible to run securely, so secure systems don't run them. And, every now and then a server gets cracked, right through the stateful firewall... because there was a rule allowing ANY to TCP 80. CB From jeff-kell at utc.edu Wed Apr 30 04:00:19 2014 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 30 Apr 2014 00:00:19 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> Message-ID: <53607553.7020206@utc.edu> On 4/29/2014 11:37 PM, TheIpv6guy . wrote: > On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell wrote: >> On 4/29/2014 2:06 PM, Owen DeLong wrote: >>> If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… >>> As a bonus, we could get rid of NAT, too. ;-) >>> /me ducks (but you know I had to say it) >> Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / >> etc had been eliminated by process of "can't get there from here"... we >> expose millions more endpoints... >> >> /me ducks too (but you know *I* had to say it) >> > No ducking here. You forgot Nimda. Do you have an example from the > last 10 years of this class ? Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP (tdp/3389 -- CVE-2012-0002 ring any bells?). The vulnerabilities never stop. We just stop paying attention because most of us have blocked 135-139 and 445 and 3389 at the border long ago. Now granted that 80/443 (server-side) are more dangerous these days :) But that doesn't eliminate the original risks. These are ports that were originally open by default... and if you "don't" have a perimeter policy, you're "wrong" (policy, compliance, regulation, etc). Not to mention that PCI compliance requires you are RFC1918 (non-routed) at your endpoints, but I digress... Jeff From owen at delong.com Wed Apr 30 05:13:34 2014 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Apr 2014 22:13:34 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <53606603.1070004@utc.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> Message-ID: <577C94B1-DF0F-40B1-A593-EE713AA016B3@delong.com> On Apr 29, 2014, at 7:54 PM, Jeff Kell wrote: > On 4/29/2014 2:06 PM, Owen DeLong wrote: >> If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… >> >> As a bonus, we could get rid of NAT, too. ;-) >> >> /me ducks (but you know I had to say it) > > Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / > etc had been eliminated by process of "can't get there from here"... we > expose millions more endpoints... > > /me ducks too (but you know *I* had to say it) Pretending that endpoints are not exposed to those things with NAT is kind of like putting a screen door in front of a bank vault and saying “now safe from tornadoes”. Owen From jnanog at gmail.com Wed Apr 30 09:53:47 2014 From: jnanog at gmail.com (Rick Astley) Date: Wed, 30 Apr 2014 05:53:47 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <577C94B1-DF0F-40B1-A593-EE713AA016B3@delong.com> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <577C94B1-DF0F-40B1-A593-EE713AA016B3@delong.com> Message-ID: Security is a layered approach though. I can't recall any server or service that runs in listening state (and reachable from public address space) that hasn't had some type of remotely exploitable vulnerability. It's hard to lean on operating systems and software companies to default services to off. When you run "netstat -a" on a lot of operating systems there are too many things in listening state without a convincing enough reason. NAT is stateful only out of necessity but after IPv6 a small layer of security will go away but there is potentially another alternative. Scanning blocks of IPv6 addresses for valid hosts is mostly a waste of time but you could do things like looking at server logs or getting IP addresses of clients you are connected with on P2P networks. A good way to prevent that is to assign multiple IPv6 addresses to operating systems as security "zones" so a source address a browser or P2P client would use is not the same one with potentially remotely exploitable services running in listening state. As a bonus they should probably take it one step further and just place web browsers and email clients in a dedicated VM sandbox that can be blown out and recreated in case of infection or persistent browser toolbars and stuff. So far malware seems to be winning the war so it might be best to just acknowledge that people are likely to be attacked successfully and attempt to quarantine it when it happens. It would probably be less intrusive than trying to force people into restricted user accounts so I never understood why nobody ever really pushed for this. Technical users have been running suspect code and links in VM's for a while now. On Wed, Apr 30, 2014 at 1:13 AM, Owen DeLong wrote: > > On Apr 29, 2014, at 7:54 PM, Jeff Kell wrote: > > > On 4/29/2014 2:06 PM, Owen DeLong wrote: > >> If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 > (or even 3) IPv6 prefixes… > >> > >> As a bonus, we could get rid of NAT, too. ;-) > >> > >> /me ducks (but you know I had to say it) > > > > Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / > > etc had been eliminated by process of "can't get there from here"... we > > expose millions more endpoints... > > > > /me ducks too (but you know *I* had to say it) > > Pretending that endpoints are not exposed to those things with NAT is kind > of like putting a screen door in front of a bank vault and saying “now safe > from tornadoes”. > > Owen > > From jerome at ceriz.fr Wed Apr 30 13:15:50 2014 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Wed, 30 Apr 2014 15:15:50 +0200 Subject: We hit half-million: The Cidr Report In-Reply-To: <3883.1398739149@turing-police.cc.vt.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> Message-ID: <5360F786.3090101@ceriz.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 29/04/2014 04:39, Valdis.Kletnieks at vt.edu a écrit : > Do we have a handle on what percent of the de-aggrs are legitimate > attempts at TE, and what percent are just whoopsies that should be > re-aggregated? Deaggs can "legitimatelly" occur for a different purpose : hijack prevention (Pilosov & Kapela style). It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs. For a less densely connected network (no presence on public IXPs, poor transits...), renumbering critical services (DNS, MX, extranets) to one of their /24s and de-aggregating it could be a smart move. - -- Jérôme Nicolle -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNg94YACgkQbt+nwQamihvv6wCdFS6gqfUJwD0m/OelYdWjCZui S9cAnAkxlWyM4/JJmTPKxPWKYRXbz/c0 =vuYo -----END PGP SIGNATURE----- From ikiris at gmail.com Wed Apr 30 13:45:41 2014 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 30 Apr 2014 08:45:41 -0500 Subject: We hit half-million: The Cidr Report In-Reply-To: <53607553.7020206@utc.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> Message-ID: Just out of curiosity, how does removing port address translation from the equation magically and suddenly make everything exposed, and un-invent the firewall? -Blake On Tue, Apr 29, 2014 at 11:00 PM, Jeff Kell wrote: > On 4/29/2014 11:37 PM, TheIpv6guy . wrote: >> On Tue, Apr 29, 2014 at 7:54 PM, Jeff Kell wrote: >>> On 4/29/2014 2:06 PM, Owen DeLong wrote: >>>> If everyone who had 30+ inaggregable IPv4 prefixes replaced them with 1 (or even 3) IPv6 prefixes… >>>> As a bonus, we could get rid of NAT, too. ;-) >>>> /me ducks (but you know I had to say it) >>> Yeah, just when we thought Slammer / Blaster / Nachi / Welchia / etc / >>> etc had been eliminated by process of "can't get there from here"... we >>> expose millions more endpoints... >>> >>> /me ducks too (but you know *I* had to say it) >>> >> No ducking here. You forgot Nimda. Do you have an example from the >> last 10 years of this class ? > > Oh? Anything hitting portmapper (tcp/135), or CIFS (tcp/445), or RDP > (tdp/3389 -- CVE-2012-0002 ring any bells?). > > The vulnerabilities never stop. We just stop paying attention because > most of us have blocked 135-139 and 445 and 3389 at the border long ago. > > Now granted that 80/443 (server-side) are more dangerous these days :) > But that doesn't eliminate the original risks. > > These are ports that were originally open by default... and if you > "don't" have a perimeter policy, you're "wrong" (policy, compliance, > regulation, etc). > > Not to mention that PCI compliance requires you are RFC1918 (non-routed) > at your endpoints, but I digress... > > Jeff > From alex at corp.nac.net Wed Apr 30 14:18:20 2014 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 30 Apr 2014 14:18:20 +0000 Subject: North NJ LATA 224 Message-ID: Anyone selling IP over ATM / Frame Relay in North NJ Verizon LATA 224 that could carve a PVC real fast? From Joshua_Sholes at cable.comcast.com Wed Apr 30 14:29:36 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Wed, 30 Apr 2014 14:29:36 +0000 Subject: We hit half-million: The Cidr Report In-Reply-To: <53607553.7020206@utc.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> Message-ID: On 4/30/14, 12:00 AM, "Jeff Kell" wrote: >Not to mention that PCI compliance requires you are RFC1918 (non-routed) >at your endpoints, but I digress... This is emphatically not true. All PCI compliance requires is that your private IP addresses are not disclosed to the public, which could be RFC1918, NAT, firewalling, proxies, creative routing, etc. --Josh hates this misconception. From patrick at ianai.net Wed Apr 30 14:54:34 2014 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 30 Apr 2014 10:54:34 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: <5360F786.3090101@ceriz.fr> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> <5360F786.3090101@ceriz.fr> Message-ID: On Apr 30, 2014, at 09:15 , Jérôme Nicolle wrote: > Le 29/04/2014 04:39, Valdis.Kletnieks at vt.edu a écrit : > > Do we have a handle on what percent of the de-aggrs are legitimate > > attempts at TE, and what percent are just whoopsies that should be > > re-aggregated? > > Deaggs can "legitimatelly" occur for a different purpose : hijack > prevention (Pilosov & Kapela style). > > It's fairly easy to punch a hole in a larger prefix, but winning the > reachability race while unable to propagate a more specific prefix > significantly increase hijacking costs. Excellent point, Jérôme. Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain > 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle? Or we could stop thinking that abusing a shared resource for personal gain is a great idea. > For a less densely connected network (no presence on public IXPs, poor > transits...), renumbering critical services (DNS, MX, extranets) to > one of their /24s and de-aggregating it could be a smart move. See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying. The idea "I have a 'reason' for hurting everyone else, so it is OK" has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm. -- TTFN, patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jamie at photon.com Wed Apr 30 15:40:43 2014 From: jamie at photon.com (Jamie Bowden) Date: Wed, 30 Apr 2014 15:40:43 +0000 Subject: We hit half-million: The Cidr Report In-Reply-To: <53607553.7020206@utc.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> Message-ID: <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> > Behalf Of Jeff Kell > Not to mention that PCI compliance requires you are RFC1918 (non-routed) > at your endpoints, but I digress... You're not funny. And if you're not joking, you're wrong. We just went over this on this very list two weeks ago. Jamie From Valdis.Kletnieks at vt.edu Wed Apr 30 16:30:51 2014 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 30 Apr 2014 12:30:51 -0400 Subject: We hit half-million: The Cidr Report In-Reply-To: Your message of "Wed, 30 Apr 2014 15:40:43 -0000." <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> Message-ID: <12495.1398875451@turing-police.cc.vt.edu> On Wed, 30 Apr 2014 15:40:43 -0000, Jamie Bowden said: > You're not funny. And if you're not joking, you're wrong. We just went over > this on this very list two weeks ago. And in that discussion, we ascertained that what the PCI standard actually says, and what you need to do in order to get unclued boneheaded auditors to sign the piece of paper, are two very different things. Yes, the PCI standard gives a list of 4 options and then continues on to say that other creative solutions are acceptable as well. But if you discover mid-engagement that your auditor *thinks* it says "Thou shalt NAT", you have a problem. Anybody got recommendations on how to make sure the company you engage for the audit ends up sending you critters that actually have a clue? (Not necessarily PCI, but in general) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available URL: From joelja at bogus.com Wed Apr 30 17:25:00 2014 From: joelja at bogus.com (joel jaeggli) Date: Wed, 30 Apr 2014 10:25:00 -0700 Subject: We hit half-million: The Cidr Report In-Reply-To: <12495.1398875451@turing-police.cc.vt.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> Message-ID: <536131EC.3000507@bogus.com> On 4/30/14, 9:30 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 30 Apr 2014 15:40:43 -0000, Jamie Bowden said: > >> You're not funny. And if you're not joking, you're wrong. We just went over >> this on this very list two weeks ago. > > And in that discussion, we ascertained that what the PCI standard actually > says, and what you need to do in order to get unclued boneheaded auditors to > sign the piece of paper, are two very different things. > > Yes, the PCI standard gives a list of 4 options and then continues on to > say that other creative solutions are acceptable as well. But if you > discover mid-engagement that your auditor *thinks* it says "Thou shalt NAT", > you have a problem. > > Anybody got recommendations on how to make sure the company you engage > for the audit ends up sending you critters that actually have a clue? (Not > necessarily PCI, but in general) So, I've been (fomerly) involved in the design/build/operation/refresh of pci environments as part of application services for enterprise with ~ order of .8 billion annually in online sales. The process starts at the beginning e.g. before you build it. If you parachute in a consultant or auditor totally cold, you are going to have to educate them to the nuances of your particular operation, it's is very similar with SOX controls. In any event your documentation should be order. and actual operation should be as documented. Ultimately as was my experience with FIPA/HERPA compliance in the educational environment these should not taken as mysterious externalities foisted on operations by hostile regulators, or industrial cartels, but as part of normal business operations, and internalized as such. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 308 bytes Desc: OpenPGP digital signature URL: From Joshua_Sholes at cable.comcast.com Wed Apr 30 18:44:02 2014 From: Joshua_Sholes at cable.comcast.com (Sholes, Joshua) Date: Wed, 30 Apr 2014 18:44:02 +0000 Subject: We hit half-million: The Cidr Report In-Reply-To: <12495.1398875451@turing-police.cc.vt.edu> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <12495.1398875451@turing-police.cc.vt.edu> Message-ID: >Anybody got recommendations on how to make sure the company you engage >for the audit ends up sending you critters that actually have a clue? (Not >necessarily PCI, but in general) In my previous jobs when I was doing FIPS/NIST/whatever compliance, it ended up being the case that having a highlighted copy of the spec document worked wonders most of the time. Barring that, the one place where I had a problem with this also had a COO who was formerly a shark-in-an-$8000-suit type of lawyer, and he was often able to explain to a clue-free auditor's boss exactly what would happen if they failed us despite the fact we met the spec as written (starting with reporting them to the PCI guys in charge of maintaining the list of qualified auditors). It's been my general experience that one must vet auditors in the same way one vets other vendors of intangible products--carefully and thoroughly, lest they screw you. Spend the same amount of energy you'd spend choosing the appropriate corporate lawyers or outsourced HR. -- Josh From jerome at ceriz.fr Wed Apr 30 20:55:05 2014 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Wed, 30 Apr 2014 22:55:05 +0200 Subject: We hit half-million: The Cidr Report In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <3883.1398739149@turing-police.cc.vt.edu> <5360F786.3090101@ceriz.fr> Message-ID: <53616329.1030003@ceriz.fr> Patrick, Le 30/04/2014 16:54, Patrick W. Gilmore a écrit : >> It's fairly easy to punch a hole in a larger prefix, but winning >> the reachability race while unable to propagate a more specific >> prefix significantly increase hijacking costs. > > Excellent point, Jérôme. > > Let's make sure nothing is hijack-able. Quick, let's de-agg > -everything- to /24s. Everyone's routers can sustain > 10 million > prefixes per full table, right? Jérôme, how many prefixes can your > routers handle? > > Or we could stop thinking that abusing a shared resource for personal > gain is a great idea. I totally agree with you. It's a shame to have to consider bad practices from a network perspective as necessities from a security standpoint. That beeing said, let's try to consider adverse interests on that matter. Large routing tables are an issue for smaller networks generating less value than major players usually providing transits to others. The constant growth of the routing table gives a technical and economical advantages to established carriers (roughly the same arguing OTTs _must_ pay premium PNIs because of an arbitrary ratio-driven peering policy). The necessity for higher-end routers to provide transit services could also slow down the steep fall of transit prices. It would establish a sensible barrier to newcomers on local transit services. It's also reducing the value of older equipments and killing the grey-market and brokers. Well, the power-draw of 6500's and other oldies could be enough, but their unability to scale to today's standards helps newer hardware sales. Now there would be a smart way to handle the issue with SDN. A "smart" network controler could manage a larger RIB with ease and provide routing-ASICs with a virtualy agregated FIB much smaller than the previous 256k routes limit, thus creating more interest for older routing-switches. Would a manufacturer develop such a smart conroller ? Nah, let's sell bigger overpriced TCAMs instead. Oh, and of course, the argument about hijack-prevention would disapear if everyone was doing there part and deploy RPKI in a matter of weeks. As did everyone feel the responsability to deploy IPv6, for that matter. > See my previous post. Of course deaggregation can have a use, but for > a network is no peering an one or a few transits, those more > specifices never have to hit the global table. Sending that /24 to > your transit provider(s) with no-export will have the > _exact_same_effect_, and not pollute anyone's routers whom you are > not paying. I'm not sure we're on the same page here. De-agregating with a no-export tag will have no effect at all but on TE between the orinating AS and its transit provider. If the more specific prefix isn't propagated, a hijack may occur locally anywhere else on the Internet. Let's consider someone willing to intercept mails from major hosted services (gmail, outlook...) to a company connected through bad transits. The hijacker would simply announce the more specific prefix on a few IXPs and win the reachability. The backchannel route could then be established over any other T1 (who won't pick up the more-specific anyway). Simply put, you have to be no more than one hop away from most IXPs to get a decent hijack-proof reachability. De-agg with no-export is a nonsense. > The idea "I have a 'reason' for hurting everyone else, so it is OK" > has got to stop. Just because you have a reason does not make it OK. > And even when it is a good idea, most people implement it so poorly > as to cause unneeded harm. Alright, let's implement new policies at a RIR, IXPs and T1s levels to forbid anyone from de-agregation without no-exports. Culprits would fall under a three-strike policy before definitive de-peering and public humiliation. Who's with me ? :) -- Jérôme Nicolle From LarrySheldon at cox.net Wed Apr 30 21:23:17 2014 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 30 Apr 2014 16:23:17 -0500 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) In-Reply-To: References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> Message-ID: <536169C5.6060607@cox.net> On 4/30/2014 11:30 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 30 Apr 2014 15:40:43 -0000, Jamie Bowden said: > >> You're not funny. And if you're not joking, you're wrong. We just went over >> this on this very list two weeks ago. > > And in that discussion, we ascertained that what the PCI standard actually > says, and what you need to do in order to get unclued boneheaded auditors to > sign the piece of paper, are two very different things. > > Yes, the PCI standard gives a list of 4 options and then continues on to > say that other creative solutions are acceptable as well. But if you > discover mid-engagement that your auditor *thinks* it says "Thou shalt NAT", > you have a problem. > > Anybody got recommendations on how to make sure the company you engage > for the audit ends up sending you critters that actually have a clue? (Not > necessarily PCI, but in general) I am no longer active on the battlefield but as of the last time I was, it can't be did. For years I managed various aspect of a UNIVAC 1100 operation and the audits thereof. EVERY TIME, we were dinged badly because we didn't look like an IBM shop (some may be surprised to learn that different hardware and different operating systems require very different operating procedures (and it appeared to us that some of the things they wanted us to do would weaken us badly, others just simply didn't make any sense, and we got dinged for things we DID do, because they were strange. Later years I was in a small 1100-many HP9000 shop--same thing only different. (That was also the environment with a medical school and hospital with Internet-accessible heart monitors on Windows 95.) I think there has been some drift away from IBMishness as The Gold Standard, but it still looks like there is no allowance for the real world in computing and networking. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker) From bill at herrin.us Wed Apr 30 21:31:53 2014 From: bill at herrin.us (William Herrin) Date: Wed, 30 Apr 2014 17:31:53 -0400 Subject: Dealing with auditors (was Re: We hit half-million: The Cidr Report) In-Reply-To: <536169C5.6060607@cox.net> References: <201404252200.s3PM0041030660@wattle.apnic.net> <1722438D-5B44-48C7-9FB7-B710CADA3D40@ianai.net> <53606603.1070004@utc.edu> <53607553.7020206@utc.edu> <465966A5F5B867419F604CD3E604C1E55DD5EE51@PRA-DCA-MAIL.pra.ray.com> <536169C5.6060607@cox.net> Message-ID: On Wed, Apr 30, 2014 at 5:23 PM, Larry Sheldon wrote: > On 4/30/2014 11:30 AM, Valdis.Kletnieks at vt.edu wrote: >> And in that discussion, we ascertained that what the PCI standard actually >> says, and what you need to do in order to get unclued boneheaded auditors >> to sign the piece of paper, are two very different things. > > I am no longer active on the battlefield but as of the last time I was, it > can't be did. > > For years I managed various aspect of a UNIVAC 1100 operation and the audits > thereof. EVERY TIME, we were dinged badly because we didn't look like an > IBM shop (some may be surprised to learn that different hardware and > different operating systems require very different operating procedures (and > it appeared to us that some of the things they wanted us to do would weaken > us badly, others just simply didn't make any sense, and we got dinged for > things we DID do, because they were strange. I won the argument with PCI auditors about leaving telnet alive on my exterior router (which at the time would have had to be replaced to support ssh). It's not a chore for the timid. You'd better be a heck of a guru before you challenge the auditors expectations and you'd better be prepared for your boss' aggravation that the audit isn't done yet. And I think we pretty well established that PCI auditors arrive expecting to see NAT. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From fred at cisco.com Wed Apr 30 21:32:27 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Wed, 30 Apr 2014 21:32:27 +0000 Subject: The Cidr Report In-Reply-To: References: <5.1.1.6.2.20140426210411.0549a1f8@efes.iucc.ac.il> <25FC66F4-6BDF-4585-85A2-CA046ACF5F5B@dds.nl> Message-ID: <95514318-C76B-480D-BD1E-CA956371E19D@cisco.com> On Apr 26, 2014, at 12:19 PM, Deepak Jain wrote: > Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack). A /64 deaggregte only makes it through because folks let it; there’s something to be said for filters. That said, one might generally expect every AS (there are about 60K or them, I gather) to have one prefix, and if it deaggregates, it might be reasonable to expect it to multiply by four. RIR online records suggest that someone that asks for additional addresses beyond their /32 is told to shorten the existing prefix, not allocated a new one - the same prefix becomes a /31 or whatever. The reason we have 500K+ IPv4 prefixes is because we hand them out in dribbles, and there is no correlation between the one you received last week and the one you receive today. Geoff’s slides are interesting in part because of their observations regarding deaggregates. If 1% of of all AS’s advertise over half of the deaggregates, that seems like a problem their neighbors can help with, and if not them, the neighbors' neighbors. It’s hard to imagine that a single Ethernet (a single /64) is so critical that the entire world needs a distinct route to it. In any event, I would not approach this as a statistical issue, and say “well, IPv4 grew in a certain way, and IPv6 will do the same”. It can. But we have had the opportunity to think ahead and plan for the growth, and the RIR communities have been planning. It seems likely that, with a little care, IPv6 should do quite a bit better. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From me at anuragbhatia.com Wed Apr 30 22:20:30 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 1 May 2014 03:50:30 +0530 Subject: Rancid with Maipu devices Message-ID: Hello everyone! I was wondering if anyone is using Rancid with Maipu devices? I am slightly stuck because default clogin gives error on "terminal length 0" and widith command in Maipu cli. Also, I tried adding "no more" which is being executed but still overall script is failing. Did anyone got around this? If so, it would be helpful if you can share your customized script for Maipu. Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2