April 2014 - Test - lists.nanog.org

BGPMON Alert Questions
by Joseph Jenkins 10 Apr '14

10 Apr '14

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

54 92

ARIN 33 Chicago - 14 proposed changes to IP address policy (non-attendee options)
by John Curran 10 Apr '14

10 Apr '14

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/discuss… 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

1 0

CVE-2014-0160 mitigation using iptables
by Fabien Bourdaire 10 Apr '14

10 Apr '14

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

5 4

Akamai DNS for GoDaddy hosted servers?
by Nanog Smitasin 10 Apr '14

10 Apr '14

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 <snip> 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. <snip> # dig ip-redacted.ip.secureserver.net(a)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 <snip> ;; 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. <snip> # dig ip-redacted.ip.secureserver.net @a9-67.akam.net <snip> ;; ->>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

1 0

ICANN issues call for public input on process to develop IANA stewardship transition plan
by John Curran 10 Apr '14

10 Apr '14

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 <info(a)arin.net<mailto:info@arin.net>> 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(a)arin.net<mailto:arin-announce@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-08a… Feedback can be submitted via the publicly archived mailing list: ianatransition(a)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)

1 0

Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed"
by Paul Ferguson 10 Apr '14

10 Apr '14

-----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 <rsk(a)gsp.org> 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-reve… > > 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-----

24 35

Re: Yahoo DMARC breakage
by Larry Sheldon 10 Apr '14

10 Apr '14

On 4/9/2014 5:11 PM, bmanning(a)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@somehost does not qualify :) >> >> Jeff > > and just how is an algorithm supposed to detect that > <jeff-kell(a)utc.edu> 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)

3 2

Re: Yahoo DMARC breakage
by Larry Sheldon 10 Apr '14

10 Apr '14

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(a)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@somehost does not qualify :) >>>> >>>> Jeff >>> >>> and just how is an algorithm supposed to detect that >>> <jeff-kell(a)utc.edu> 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 <LarrySheldon(a)cox.net> >> Organization: Maybe tomorrow >> User-Agent: Mozilla/5.0 (Windows NT 5.1; >> rv:24.0) Gecko/20100101 Thunderbird/24.4.0 >> To: <nanog(a)nanog.org> >> 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)

1 0

real-world data about fragmentation
by Joe Abley 09 Apr '14

09 Apr '14

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

5 4

any network folks from github.com here?
by Dave Curado 08 Apr '14

08 Apr '14

Please contact me off list? Thank you.

1 0