hat tip to .gov hostmasters
http://it.slashdot.org/article.pl?sid=08/09/22/1253201&from=rss nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)). /sf PGP.sig Description: This is a digitally signed message part
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote: > nice to see a wholesale DNSSEC rollout underway (I must confess to being a > little surprised at the source, too!). Granted, it's a much more manageable > problem set than, say, .com - but if one US-controlled TLD can do it, hope > is buoyed for a .com rollout sooner rather than later (although probably not > much sooner :)). I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful? > /sf -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: hat tip to .gov hostmasters
* Jason Frisvold: > On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote: >> nice to see a wholesale DNSSEC rollout underway (I must confess to being a >> little surprised at the source, too!). Granted, it's a much more manageable >> problem set than, say, .com - but if one US-controlled TLD can do it, hope >> is buoyed for a .com rollout sooner rather than later (although probably not >> much sooner :)). > > I'm not much up on DNSSEC, but don't you need to be using a resolver > that recognizes DNSSEC in order for this to be useful? Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: hat tip to .gov hostmasters
On Mon, 22 Sep 2008 10:52:42 -0400 "Jason Frisvold" <[EMAIL PROTECTED]> wrote: > I'm not much up on DNSSEC, but don't you need to be using a resolver > that recognizes DNSSEC in order for this to be useful? You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does Simon
Re: hat tip to .gov hostmasters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote: On Mon, 22 Sep 2008 10:52:42 -0400 "Jason Frisvold" <[EMAIL PROTECTED]> wrote: I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful? You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. Chris Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~A stupidity tax Hubris Communications Inc www.hubris.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkjXs30ACgkQElUlCLUT2d0SfwCbB8FQ4izN061GoQQMl3fkq+NT ga0AoJnwGG8PfBs5PaziRB6m0NQBuZwc =68dm -END PGP SIGNATURE-
Re: hat tip to .gov hostmasters
Florian Weimer wrote: > * Jason Frisvold: > >> On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote: >>> nice to see a wholesale DNSSEC rollout underway (I must confess to being a >>> little surprised at the source, too!). Granted, it's a much more manageable >>> problem set than, say, .com - but if one US-controlled TLD can do it, hope >>> is buoyed for a .com rollout sooner rather than later (although probably not >>> much sooner :)). >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > Correct, you need a validating, security-aware stub resolver, or the > ISP needs to validate the records for you. > In public space like .com, don't you need some kind of central trustworthy CA?
Re: hat tip to .gov hostmasters
* Colin Alston: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > In public space like .com, don't you need some kind of central > trustworthy CA? No, why would you? You need to trust the zone operator, and you need some trustworthy channel to exchange trust anchors at one point in time (a significant improvement compared to classic DNS, where you need a trustworthy channel all the time). -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: hat tip to .gov hostmasters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 22 Sep 2008 10:02:21 -0500 Chris Owen <[EMAIL PROTECTED]> wrote: > Chicken, meet egg. > > I think the point of the original post is that one end or the other > has to start things. At least we have one US zone doing something on > the server end of things. I totally agree on that, but wanted to point out that there still is some work be done. The folks at NLnet do have a nice DNSSEC implementation, though, as well as the BIND library. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjXtWUACgkQccZs6oMJsYR5XQCbB6e92xTcaR2ijn0DcAALdswA 358AmQH36qg/fBRGxJIFS4Alm4sAKF9w =7JfR -END PGP SIGNATURE-
RE: hat tip to .gov hostmasters
> Correct, you need a validating, security-aware stub resolver, or the > ISP needs to validate the records for you. That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC. If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now. Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security". It is likely that IPv48 will be deployed long before DNSSEC is implemented.
Re: hat tip to .gov hostmasters
* Simon Vallet: >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > You do -- and last time I checked few native resolvers actually did : > glibc doesn't, and I'd be surprised if the Windows resolver does Windows doesn't. To my knowledge, there aren't any deployed valdiating, security-aware stub resolvers. Your best bet is to run BIND or Unbound locally with appropriate trust anchors, and use that as the system's resolver. With modern LRU-based caches which are efficient even at smallish sizes, this isn't much of a problem. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
RE: hat tip to .gov hostmasters
DNSSEC is not a PKI. There are no CAs and no X.509 certificates. It's a chain of trust that can be validated using public/private key pairs. OK, that's oversimplification but you get the idea. While we wait for applications to become DNSSEC-aware, if your local DNS server can be trusted (a big "if" of course) then it can proxy the DNSSEC awareness for you. Since nearly everybody trusts a local DNS server to resolve queries, then making that server DNSSEC aware is an enormous step forward, even if the actual applications and operating systems on end-user computers are not fully DNSSEC-aware and won't be for many years to come. Marc -Original Message- From: Florian Weimer [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 11:10 AM To: Colin Alston Cc: nanog@nanog.org Subject: Re: hat tip to .gov hostmasters * Colin Alston: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > In public space like .com, don't you need some kind of central > trustworthy CA? No, why would you? You need to trust the zone operator, and you need some trustworthy channel to exchange trust anchors at one point in time (a significant improvement compared to classic DNS, where you need a trustworthy channel all the time). -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <[EMAIL PROTECTED]> wrote: > Chicken, meet egg. > > I think the point of the original post is that one end or the other has to > start things. At least we have one US zone doing something on the server > end of things. Oh, agreed, absolutely. And it's great to see. However, neither the slashdot blurb, nor the NetworkWorld article mention that without a valid resolver, there is no guarantee of security. Sure, they mention that vendors are rolling it out and that ISPs should be following suit, but no mention is made of the end-user's resolver at all... > Chris -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: hat tip to .gov hostmasters
* Keith Medcalf: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > > That would defeat the entire purpose of using DNSSEC. In order for >DNSSEC to actually provide any improvement in security whatsoever, >the ROOT ZONE (.) needs to be signed, and every delegation up the >chain needs to be signed. And EVERY resolver (whether recursive or >local on host) needs to understand and enforce DNSSEC. Either the resolver needs to enforce, or the host. It's not necessary to do both. It's also not strictly necessary that the root is signed, provided that there is some way to manage the trust anchors (either through software updates, like it is done for the browser CA list, or through regular DNS management at the ISP resolver). > If even one delegation is unsigned or even one resolver does not > enforce DNSSEC, then, from an actual security perspective, you will > be far worse off than you are now. Why? > Until such time as EVERY SINGLE DOMAIN including the root is signed > and every single DNS Server and resolver (including the local host > resolvers) understand and enforce DNSSEC you should realize that > DNSSEC does nothing for you whatsoever except give the uneducated a > false sense of "security". DNSSEC is totally invisible to the end user. There won't be any browser icon that says "it's okay to enter your PII here because the zone is DNSSEC-signed". It's purely an infrastructure measure, like physically securing your routers. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 10:52:42AM -0400, Jason Frisvold wrote: > On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis <[EMAIL PROTECTED]> wrote: > > nice to see a wholesale DNSSEC rollout underway (I must confess to being a > > little surprised at the source, too!). Granted, it's a much more manageable > > problem set than, say, .com - but if one US-controlled TLD can do it, hope > > is buoyed for a .com rollout sooner rather than later (although probably not > > much sooner :)). > > I'm not much up on DNSSEC, but don't you need to be using a resolver > that recognizes DNSSEC in order for this to be useful? > > > /sf > > > -- > Jason 'XenoPhage' Frisvold > [EMAIL PROTECTED] > http://blog.godshell.com yes and no. to fully trust the data from the servers you need three things: ) signed data (this is what .gov is doing) ) a validator in the end system (this is mostly missing/not configured today) ) accurate trust anchors from a couple of places in the DNS namespace ## however, if all you start with is signed data - it becomes possible to verify the source of the data - independently of inline DNS validation. e.g. you can - with a high degree of certainty, be assured that the root zone you load is really the ORSN root and not that flaky root from DoC/ICANN/VSGN... :) so "naked" signed data, in the absence of TA's or validators is still useful. ## you'll need a couple of these - and how you get them and keep them up to date is still a mostly unsolved operational problem. --bill
Re: hat tip to .gov hostmasters
* marcus sachs: > While we wait for applications to become DNSSEC-aware, Uhm, applications shouldn't be DNSSEC-aware. Down that road lies madness. What should an end user do when the browser tells him, "Warning: Could not validate DNSSEC signature on www.example.com, signature has expired. Continue to connect?" -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 11:11:40AM -0400, Keith Medcalf wrote: > > > Correct, you need a validating, security-aware stub resolver, or the > > ISP needs to validate the records for you. > > That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to > actually provide any improvement in security whatsoever, the ROOT ZONE (.) > needs to be signed, and every delegation up the chain needs to be signed. > And EVERY resolver (whether recursive or local on host) needs to understand > and enforce DNSSEC. er, no. the root zone does not need to be signed and not every delegation. and only the resolvers in the path from auth servers to validators need to ensure that the DNSSEC data is retained. if the only TA I have is for .SE (configured in my validator) and my resolver passes the DNSSEC data unchanged it received from the .SE servers, then I can securely trust the (short) validation chain when I look up axfr.se. even though -nothing else- is signed. > > If even one delegation is unsigned or even one resolver does not enforce > DNSSEC, then, from an actual security perspective, you will be far worse off > than you are now. depends on your POV of course... > Until such time as EVERY SINGLE DOMAIN including the root is signed and every > single DNS Server and resolver (including the local host resolvers) > understand and enforce DNSSEC you should realize that DNSSEC does nothing for > you whatsoever except give the uneducated a false sense of "security". I think you have unrealistic expectations. Time will tell. > > It is likely that IPv48 will be deployed long before DNSSEC is implemented. --bill
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 05:24:00PM +0200, Florian Weimer wrote: > * marcus sachs: > > > While we wait for applications to become DNSSEC-aware, > > Uhm, applications shouldn't be DNSSEC-aware. Down that road lies > madness. What should an end user do when the browser tells him, > "Warning: Could not validate DNSSEC signature on www.example.com, > signature has expired. Continue to connect?" > > -- > Florian Weimer<[EMAIL PROTECTED]> actually, I am really hoping that at least one API is standardized so that applications can use DNSSEC data. We never finished the discussion on fail/open fail/closed wrt DNSSEC. --bill
Re: hat tip to .gov hostmasters
Jason Frisvold wrote: On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <[EMAIL PROTECTED]> wrote: Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. Oh, agreed, absolutely. And it's great to see. However, neither the slashdot blurb, nor the NetworkWorld article mention that without a valid resolver, there is no guarantee of security. Sure, they mention that vendors are rolling it out and that ISPs should be following suit, but no mention is made of the end-user's resolver at all... I dunno, a few very strategically placed validating resolvers could subject a huge amount of DNS traffic to a much higher bar were the senders so inclined to sign their zones. But I tend to view these kinds of things much more from an "epidemiology" point of view: you don't have to have 100% eradication to control an epidemic. Same thing pretty much goes with internet based attacks, IMO: when the barrier is set sufficiently high in one area, attackers don't spend their entire time trying to break that barrier, they find the next lowest barrier and move on. Mike
RE: hat tip to .gov hostmasters
> nice to see a wholesale DNSSEC rollout underway (I must confess to > being a little surprised at the source, too!). Granted, it's a much > more manageable problem set than, say, .com - but if one US-controlled > TLD can do it, hope is buoyed for a .com rollout sooner rather than > later (although probably not much sooner :)). It ain't done yet. I don't speak for the hostmasters of .gov or any subdomain thereof. But I'll believe it when I see it. Remember, they've also "mandated" IPv6 support on all backbones. -- Jim Goltz <[EMAIL PROTECTED]> CIT/DCSS/HSB/ASIG 12/2216
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 8:16 AM, Jason Frisvold <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen <[EMAIL PROTECTED]> wrote: >> Chicken, meet egg. >> >> I think the point of the original post is that one end or the other has to >> start things. At least we have one US zone doing something on the server >> end of things. > > Oh, agreed, absolutely. And it's great to see. However, neither the > slashdot blurb, nor the NetworkWorld article mention that without a > valid resolver, there is no guarantee of security. Sure, they mention > that vendors are rolling it out and that ISPs should be following > suit, but no mention is made of the end-user's resolver at all... the NetworkWorld article (in the printer-friendly version, at least) has a little table that shows the DNSSEC status of the major vendors. And support in the resolver library is not strictly necessary, as long as you trust _your_ (or your ISP's) nameservers. (not to say that it isn't a good idea, just that it's not requirement for initial rollout.) -- [EMAIL PROTECTED],darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
RE: hat tip to .gov hostmasters
> > That would defeat the entire purpose of using DNSSEC. In order for > >DNSSEC to actually provide any improvement in security whatsoever, > >the ROOT ZONE (.) needs to be signed, and every delegation up the > >chain needs to be signed. And EVERY resolver (whether recursive or > >local on host) needs to understand and enforce DNSSEC. > Either the resolver needs to enforce, or the host. It's not necessary > to do both. It's also not strictly necessary that the root is signed, > provided that there is some way to manage the trust anchors (either > through software updates, like it is done for the browser CA list, or > through regular DNS management at the ISP resolver). > > If even one delegation is unsigned or even one resolver does not > > enforce DNSSEC, then, from an actual security perspective, you will > > be far worse off than you are now. > Why? If the local resolver does not perform DNSSEC validation, then I cannot validate that the response is correct. I certainly do not trust anyone else to verify that the information is correct and then, without any possible verification, simply believe that the third party did the validation. In fact, I have no way of knowing that the response even came from the "ISP" at all unless the client resolver supports DNSSEC. Just because YOU check the digital signature on an email and forward that email to me (either with or without the signature data), if I do not have the capability to verify the signature myself, I sure as hell am not going to trust your mere say-so that the signature is valid! If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now. The real problem is that the clueless (with a hidden self-aggrandizing and a primary motive of "lining my pockets with other peoples money" will convince the ignorant that it is more secure. Sort of like banning toothpaste from carry-on baggage "impoves" the security of air travel, when in fact it does nothing more than help the idiots in charge of promulgating such polies to rip off (rob) other people of their money by deliberate fraud and misrepresentation. > > Until such time as EVERY SINGLE DOMAIN including the root is signed > > and every single DNS Server and resolver (including the local host > > resolvers) understand and enforce DNSSEC you should realize that > > DNSSEC does nothing for you whatsoever except give the uneducated a > > false sense of "security". > DNSSEC is totally invisible to the end user. There won't be any > browser icon that says "it's okay to enter your PII here because the > zone is DNSSEC-signed". It's purely an infrastructure measure, like > physically securing your routers. The end-stage is secure only if at that stage you also set all DNS infrastructure to refuse to talk to any DNS client/server/resolver that DOES NOT validate and enforce DNSSEC. Up until that point in time, there is NO CHANGE in the security posture from what we have today with no DNSSEC whatsoever. To hold forth otherwise is to participate in deliberate fraud and misrepresentation of material facts.
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 8:49 AM, Keith Medcalf <[EMAIL PROTECTED]> wrote: >> > If even one delegation is unsigned or even one resolver does not >> > enforce DNSSEC, then, from an actual security perspective, you will >> > be far worse off than you are now. > >> Why? > > If the local resolver does not perform DNSSEC validation, then I cannot > validate that the response is correct. > I certainly do not trust anyone else to verify that the information is > correct and then, without any possible verification, > simply believe that the third party did the validation. In fact, I have no > way of knowing that the response even came > from the "ISP" at all unless the client resolver supports DNSSEC. > > Just because YOU check the digital signature on an email and forward that > email to me (either with or without the > signature data), if I do not have the capability to verify the signature > myself, I sure as hell am not going to trust your > mere say-so that the signature is valid! > > If I cannot authenticate the data myself, then it is simply untrusted and > untrustworthy -- exactly the same as it is now. so I guess PGP web of trust is right out, then? (in the real world, we rarely get boolean values on security questions) -- [EMAIL PROTECTED],darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
Re: Atrivo/Intercage: NO Upstream depeer
Emil, If you've actually shut off the RBN, you should have no problem finding some new transit to turn up, right? We're in a buyer's market, and there are dozens of vendors on-net at 200 Paul who'd love a piece of your business. Drive Slow, Paul Wall On Sun, Sep 21, 2008 at 3:20 PM, Emil Kacperski <[EMAIL PROTECTED]> wrote: > Hello, > > It's true that David from PIE disconnected our link approx 9pm or so > yesterday. Things were going perfect, no complaints for a few weeks now. > The only thing I believe is that NTT gave lots of pressure to PIE. For some > unknown reason when I tried to reach out to the security guy at NTT he > basically said our contract is with PIE. > > So in a time like this you really get to know who your friends are and who > should be avoided. > > Onward and upward! What doesn't kill you only makes you stronger ;-). Just > feel bad for the customers for which I am truly sorry for right now ;-(. > > Thanks! > > Contact: Emil Kacperski > > Company: Intercage Inc. - Atrivo > > Dedicated Servers > > San Francisco Datacenter > > E-Mail: [EMAIL PROTECTED] > > Phone: 925-550-3947 > > ICQ: 23531098 > > > >
RE: hat tip to .gov hostmasters
> > Just because YOU check the digital signature on an email > and forward that email to me (either with or without the > > signature data), if I do not have the capability to verify > the signature myself, I sure as hell am not going to trust your > > mere say-so that the signature is valid! > > If I cannot authenticate the data myself, then it is simply > untrusted and untrustworthy -- exactly the same as it is now. > so I guess PGP web of trust is right out, then? You are confusing "validating signature" with "validating the holder of the keying material and the authorization of the holder to deploy it to create a non-repudiable signature", which are two entirely different and completely unreleated things. (This is quite common by the way, so maybe you can be excused your confusion). If there is a piece of data X signed with a cryptographically generated signature, and *I* verify that indeed the signature is valid, then the signature is valid -- that is, I can say with 100% absolute certainty that specific bit of keying material was used to generate a signature on something and that I have another bit of keying material which validates that signature. I am assured with very high certainty that THE DATA WAS SIGNED BY THE POSSESSOR OF THE SECRET KEYING MATERIAL. Nothing more can be determined from the signature. You now want to confuse the issue by associating the "keying material" with a "person" or "entity". That problem is entirely outside the purview of the exercize and completely irrelevant. (I certainly do not "trust" that any certificate issued by a so-called Certificate Authority (other than myself) was issued to the entity it is purported to be issued to, nor that the key is properly kept secret, nor anything else. The mathematical validity of the signature is beyond question. Associating that signature to anything other than a mere statement that "this data was signed by the possessor of the secret key corresponding to the public key that I have" is a personal judgement call.
Re: hat tip to .gov hostmasters
At 15:30 + 9/22/08, [EMAIL PROTECTED] wrote: data. We never finished the discussion on fail/open fail/closed wrt DNSSEC. And I'd bet a dollar we never will finish that discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
Re: hat tip to .gov hostmasters
> > The end-stage is secure only if at that stage you also set all DNS > infrastructure to refuse to talk to any DNS client/server/resolver that DOES > NOT validate and enforce DNSSEC. Up until that point in time, there is NO > CHANGE in the security posture from what we have today with no DNSSEC > whatsoever. > > To hold forth otherwise is to participate in deliberate fraud and > misrepresentation of material facts. > > so you are a "fail/closed" proponent. a fail/open approach would have failure of DNSSEC-based validation behave just like the DNS of today. The use of Trust Anchors and signed "islands" allow one to find "golden threads" of validated chains in the dns fabric ... e.g. incremental rollout vs flag day. --bill
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 12:06:57PM -0400, Edward Lewis wrote: > At 15:30 + 9/22/08, [EMAIL PROTECTED] wrote: > > > data. We never finished the discussion on fail/open > > fail/closed wrt DNSSEC. > > And I'd bet a dollar we never will finish that discussion. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis+1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. taken. (never is a -very- long time) --bill
Re: hat tip to .gov hostmasters
On Mon, Sep 22, 2008 at 12:14:53PM -0400, Keith Medcalf wrote: > > > > If I cannot authenticate the data myself, then it is simply > > untrusted and untrustworthy -- exactly the same as it is now. > > > so I guess PGP web of trust is right out, then? > [elided] > > If there is a piece of data X signed with a cryptographically generated > signature, and *I* verify that indeed the signature is valid, then the > signature is valid -- that is, I can say with 100% absolute certainty that > specific bit of keying material was used to generate a signature on something > and that I have another bit of keying material which validates that > signature. I am assured with very high certainty that THE DATA WAS SIGNED BY > THE POSSESSOR OF THE SECRET KEYING MATERIAL. > > Nothing more can be determined from the signature. > let me understand this ... your use of the pronoun "I" in these contexts is in reference to your corporal being i.e. meatspace and not a software application running on some computer. --bill
Re: hat tip to .gov hostmasters
> Date: Mon, 22 Sep 2008 11:42:33 -0400 > From: "Goltz, Jim (NIH/CIT) [E]" <[EMAIL PROTECTED]> > > > nice to see a wholesale DNSSEC rollout underway (I must confess to > > being a little surprised at the source, too!). Granted, it's a much > > more manageable problem set than, say, .com - but if one US-controlled > > TLD can do it, hope is buoyed for a .com rollout sooner rather than > > later (although probably not much sooner :)). > > It ain't done yet. > > I don't speak for the hostmasters of .gov or any subdomain thereof. > But I'll believe it when I see it. I am pretty sure that you will see it. Unlike things like the IPv6 requirement, there are no waivers available for this. '.gov' must be signed early next year and all zones delegated from the '.gov' GTLD must be signed in early 2010. I doubt that many will sign until '.gov' is signed, so you won't see much change for a few months. Now, if the DOC people responsible for root would just catch a clue, we could get that signed and have DNSSEC actually usable (except for Mr. Metcalf) in a significant part of the US network before I retire. > Remember, they've also "mandated" IPv6 support on all backbones. Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp2Nyla9XDdl.pgp Description: PGP signature
Re: hat tip to .gov hostmasters
On Sep 22, 2008, at 7:56 AM, Florian Weimer wrote: I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful? Yes, and you also need the trust anchors for the zones you want to validate configured. Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you. Slight clarification: you need a validating, security-aware resolver, whether that resolver is local (e.g., running on the same machine issuing the DNS queries) or remote (e.g., your ISP's resolver). Note that, for good or ill, you are trusting the operator of the resolver and the communication channel between the resolver and the application making the DNS requests. A validating, security-aware _stub_ resolver, typically linked into the program issuing the DNS requests and thus would be the ultimate in 'local', would have the ability to validate the response and supply feedback to the application with minimum vulnerability to MITM attacks. The downside is the added complexity of the code to the validation and to handle validation failures. Regards, -drc
Re: hat tip to .gov hostmasters
On Sep 22, 2008, at 8:11 AM, Keith Medcalf wrote: Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you. That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. The root does not need to be signed to provide security improvement. If you have configured the (say) .SE trust anchor in your validating resolver, you greatly reduce the chances that any lookup for a name in .SE can be spoofed. The downside of not having the root signed is that you need to maintain multiple trust anchors. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC. I personally believe it is more-or-less safe to trust communications local to the machine. As such, running a validating resolver on your local host would suffice. Having a stub resolver also validate in this scenario would be overkill. If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now. In what way? I'm running a validating resolver on my laptop (using the signed root zone and trust anchor available from ns.iana.org so I only have to deal with one trust anchor). If someone tries to spoof a name in the root, .SE, .BG, .PR, .BR, .CZ, their efforts will fail. How is this worse off than before I configured my resolver? Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security". If this were true, DNSSEC would be a complete waste of time. Fortunately, it isn't true. Regards, -drc
Re: hat tip to .gov hostmasters
Kevin Oberman wrote: Date: Mon, 22 Sep 2008 11:42:33 -0400 From: "Goltz, Jim (NIH/CIT) [E]" <[EMAIL PROTECTED]> Remember, they've also "mandated" IPv6 support on all backbones. Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. They mandated that all products, not just hardware, support IPv6. However, all that the requirement turned out to be, in practice, is that all products be "software upgradeable" to IPv6. My employer is still selling stuff by the truckload to the USG because the hardware itself is "IPv6 capable" (just like it's OSI or DECnet "capable"), but we haven't written a single line of IPv6 code yet because customers aren't actually demanding it and we have other, more profitable, things to spend developers' limited time on. For vendors whose hardware needs to change for IPv4, like core routers, this is a big deal; for the rest of us, it was a non-event once we read the fine print. S
RE: hat tip to .gov hostmasters
> Subject: RE: hat tip to .gov hostmasters > Date: Mon, 22 Sep 2008 11:49:50 -0400 > From: "Keith Medcalf" <[EMAIL PROTECTED]> > > If I cannot authenticate the data myself, then it is simply untrusted and u= > ntrustworthy -- exactly the same as it is now. "Speak for yourself, John" applies. In the real world, there are cases where data that one is unable to authenticate by ones self *is* treated as fully trusted. Because someone with the authority to declare it to be that, by fiat, has done so. There may be a common "chain of command", and someone higher in the chain has declared that various inferiors "shall"(i.e. 'must') trust the work of other inferiors within the organization, for example. Or, it may be a contractually-delegated trust. Or, any of a number of other possibilities. Admittedly, in any of those scenarios, the 'strength' of trust is somewhat weaker than if it was self-verified, but it _is_ "far above" your claim of 'untrusted and untrustworthy'. > The end-stage is secure only if at that stage you also set all DNS infrastr= > ucture to refuse to talk to any DNS client/server/resolver that DOES NOT va= > lidate and enforce DNSSEC. Up until that point in time, there is NO CHANGE= > in the security posture from what we have today with no DNSSEC whatsoever. FALSE TO FACT. One does not have a _guarantee_ of 'accurate' data without end-to-end enforcement, this is true. Even _with_ end-to-end DNSSEC enforcement, one does not have such a guarantee. All it accomplishes is to make the insertion of bogus data harder. Not 'impossible', just 'harder'. If a local non-DNSSEC resolver consults _only_ a DNSSEC-aware server on an immediately adjacent network, it takes only a moderate 'extension of trust' to (a) the local network operator, (b) the adjacent network operator, and (c) the DNSSEC-aware server operator, to have a "reasonable degree" of trust in the accuracy of the data the local reslover has. This 'trust' involves the physical integrity of the networks -- that a host on -those- networks will not be allowed to spoof a source address of the DNSSEC-aware server; and the use of ingress-filtering on _source_ addresses -- to prevent any 'external' network/machine from spoofing it either. Beyond that, it is just a matter of 'trusting' a proper implementation on the server itself. _IF_ the anti-spoofing provisions are in place, and 'downstream' (non-aware) DNS resolvers (which consult -only- the 'aware' server) are under the same administrative control as the DNSSEC-aware one, *THEN* there is zero effective difference in the trust level for an answer obtained from the 'non-aware' system as one obtained from the 'aware' one. > To hold forth otherwise is to participate in deliberate fraud and misrepres= > entation of material facts. This really sounds like someone who has a financial interest in promulgating FUD.
RE: hat tip to .gov hostmasters
To digress on IPv6 momentarily.
The airline magazine engineering memorandum* from OMB left two terms
undefined in the mandate; "backbone network" and "IPv6 compatible." The
Intra-agency IPv6 Federal Working Group wisely defined "backbone
network" as (paraphrasing) the wire exiting the first publicly-reachable
network perimeter router and entering the router next in the line of
traffic and all devices attached to that wire between those two points
as follows:
{Internet}->|router|<-connecting wire---IPV6-[firewall, IDS,
etc.]-IPV6--connecting wire->|next router in line|->NO IPV6-...
NIST is still working on "compatible."
*Airline Magazine Engineering Memorandum: a mandate issued by an
executive who can. The memorandum has four characteristics; 1) It
mandates a technology not well understood by either the issuer or the
recipient of the memo, 2) it sets a date certain by which the technology
must be implemented, 3) it provides no funding, and 4, it contains one
or more undefined terms whose exact meanings are absolutely crucial to
actual implementation of the mandate. Source of the inspiration that
originally convinced the issuing executive that they actually understood
the scope and technology of the mandate is inherent in the title of this
paragraph.
JimL
James R Lindley
Senior Computer Engineer
Advanced Technical Analysis Team
IT Security Architecture and Engineering
Internal Revenue Service
An unquenchable thirst for Pierian waters.
-Original Message-
From: Kevin Oberman [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 12:54
To: Goltz, Jim (NIH/CIT) [E]
Cc: nanog@nanog.org
Subject: Re: hat tip to .gov hostmasters
> Date: Mon, 22 Sep 2008 11:42:33 -0400
> From: "Goltz, Jim (NIH/CIT) [E]" <[EMAIL PROTECTED]>
>
> > nice to see a wholesale DNSSEC rollout underway (I must confess to
> > being a little surprised at the source, too!). Granted, it's a much
> > more manageable problem set than, say, .com - but if one
> > US-controlled TLD can do it, hope is buoyed for a .com rollout
> > sooner rather than later (although probably not much sooner :)).
>
> It ain't done yet.
>
> I don't speak for the hostmasters of .gov or any subdomain thereof.
> But I'll believe it when I see it.
I am pretty sure that you will see it. Unlike things like the IPv6
requirement, there are no waivers available for this. '.gov' must be
signed early next year and all zones delegated from the '.gov' GTLD must
be signed in early 2010. I doubt that many will sign until '.gov' is
signed, so you won't see much change for a few months.
Now, if the DOC people responsible for root would just catch a clue, we
could get that signed and have DNSSEC actually usable (except for Mr.
Metcalf) in a significant part of the US network before I retire.
> Remember, they've also "mandated" IPv6 support on all backbones.
Yes, and the goal, relatively insignificant that it was, was met. It was
not a requirement that anyone actually use IPv6, only that the agency
backbone networks be able to carry IPv6. In fact, the wording was such
that doing proper routing was not even really needed.
Our backbone has offered IPv6 as a production service since 2002, so it
was a non-effort for us. Most other agency backbones were pretty trivial
to make "IPv6 capable".
The problem is that only the backbone currently needs IPv6. No facility
network or end host needs it, No network service needs it. No IPv6
packets, even routing updates, need to be delivered in any useful way.
It was a pretty trivial goal and was met with very little effort.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
favourite XFP supplier?
Hi all, Anybody have a preferred supplier for 10GE XFPs, multimode and singlemode? These are to be installed in Force10 and Juniper hardware in Toronto, so a Canadian supplier would be fabulous although I won't hold my breath. Joe
RE: Atrivo/Intercage
Just to add my $0.02 to this discussion and a disclaimer - I've known Emil for years, I've seen his shop and even the controversy. 200 Paul is a small community, and most of the folks in there know eachother, I've been in there since 2001 or so. Intercage is not a big shop, there are very few people involved in running it and I have a very hard time believing the accusations made by some of the folks around. I also don't believe Intercage was complicit in any net-crime; Thats not to say it didn't exist, but more along the lines of they got lost in the noise of running a business. I'd guess that given the server volume they've got, abuse emails are less than one percent of all the email they get in a week. From what I've seen, the bulk of their customer base is webhosters, Unix Shell providers and some video/audio streamers. Were I to venture a guess on the number of folks reselling those webservers, its probably on the order of thousands... Any time I've had an issue with one of Atrivo's customers, it only took one email to get it dealt with, or I got Emil on IM or on the phone and it was taken care of. My experience with being on the other end of abuse@, I'd say a good 60-75% of the complaints I saw coming in were bogus. Either people complaining about their ZoneAlarm's going off, people complaining about bounced emails with spam and a bunch of automated stuff that was always wrong. The legit complaints were not always easy to deal with either since a good 20-30% of them were unclear on what was actually wrong until you spent some time digging. Basically is what it boils down to for me - its easy to blame an NSP/ISP/Hoster for what their clients do, it takes real dedication to find out whats *actually* going on. -- Tom Sparks (415) 367-7328x1001
Re: Atrivo/Intercage
On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: Intercage is not a big shop, there are very few people involved in running it I have no dog in this fight, but I would comment on the "small shop" issue as it relates to handling abuse complaints. I own a small colo/hosting shop too. We don't have many employees. If we had to deal with so many abuse complaints that things were "getting lost in the noise", I'd have to seriously examine my AUP and associated enforcement policies, add staff to handle abuse issues, or both. Being small isn't an excuse. In fact, a small shop that runs a clean network should be far better at handling abuse issues than the larger players could ever hope to be.
Re: Atrivo/Intercage
On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: Basically is what it boils down to for me - its easy to blame an NSP/ISP/Hoster for what their clients do, it takes real dedication to find out whats *actually* going on. Tom, Atrivo is not just a spammer, and Intercage has _not_ "taken care of" problems - unless you count moving IP addresses around as "taking care of" things. I'm sure the people downloading child pr0n or hosting virus / C&C servers were very inconvenienced from having to change a hostname. Pardon me if I am incredulous. And not because we were not dedicated in trying to find out what was *actually* going on. Try reading up on your friend before accusing the community of not doing due diligence. And don't give me any BS about not reading his abuse@ mail. Eventually ignorance (willful ignorance?) in the service of evil becomes indistinguishable from malice. Basically, THAT is what it boils down to for me, and apparently everyone else as well. -- TTFN, patrick
Re: Atrivo/Intercage
On Mon, Sep 22, 2008 at 04:48:16PM -0400, Drew Linsalata wrote: > I have no dog in this fight, but I would comment on the "small shop" > issue as it relates to handling abuse complaints. > > I own a small colo/hosting shop too. We don't have many employees. > If we had to deal with so many abuse complaints that things were > "getting lost in the noise" Perhaps I should clarify - Abuse complaints being a small percentage of normal requests for service (IE: I need a new hdd, an OS reinstalled) I would agree that anyone beseiged in abuse requests should take a machete to the offending customer's cables :) -- Tom Sparks (415) 367-7328x1001
Re: Atrivo/Intercage
So... apparently AS27595 is back on the air, with aspath's like: 6461 23342 27595 6539 23342 27595 8075 23342 27595 23342 == UnitedLayer, Tom isn't that you or is that another Tom I'm remembering? -Chris
Re: Atrivo/Intercage
On Mon, Sep 22, 2008 at 5:17 PM, Christopher Morrow <[EMAIL PROTECTED]> wrote: > So... apparently AS27595 is back on the air, with aspath's like: > > 6461 23342 27595 > 6539 23342 27595 > 8075 23342 27595 > > 23342 == UnitedLayer, Tom isn't that you or is that another Tom I'm > remembering? ah! someone reminded me that Tom left UL :( but at least I was remembering the right tom :)
Re: Atrivo/Intercage
On Mon, Sep 22, 2008 at 05:17:42PM -0400, Christopher Morrow wrote: > So... apparently AS27595 is back on the air, with aspath's like: > 6461 23342 27595 > 6539 23342 27595 > 8075 23342 27595 > > 23342 == UnitedLayer, Tom isn't that you or is that another > Tom I'm remembering? Yep, same Tom, I was one of the founders of UnitedLayer. I haven't been there since 2006, so its not my doing. I also noticed AS paths like this: * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i I'm not sure whats going on there, but I'm thinking someone needs some help :) -- Tom Sparks (415) 367-7328x1001
XO Outage
We are seeing some issues w/ XO/Savvis peering.. Trace from XO to Savvis IP space (64.75.10.151) Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. scrubbed 0.0% 60.6 0.5 0.4 0.6 0.1 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 61.3 1.3 1.2 1.4 0.1 3. ??? Trace from Savvis to XO IP space (65.44.114.97) 1. scrubbed 0.0%380.4 0.4 0.3 0.5 0.1 2. 64.41.199.129 0.0%371.0 24.0 0.6 330.2 80.4 3. hr1-ge-7-47.santaclarasc5.savvis.net 0.0%370.7 1.4 0.6 27.3 4.4 4. er1-te-1-0-0.sanjose3equinix.savvis.net 0.0%370.7 5.2 0.6 140.3 23.2 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net 2.7%372.9 4.0 2.6 16.6 2.5 6. cr2-pos-0-0-3-3.dallas.savvis.net 0.0%37 42.6 43.1 42.3 51.4 1.4 7. dpr1-ge-4-0-0.dallasequinix.savvis.net 0.0%37 43.1 44.8 42.9 76.9 6.7 8. er1-te-2-1.dallasequinix.savvis.net 0.0%37 43.3 49.2 42.8 233.6 31.6 9. 208.175.175.90 0.0%37 43.0 42.8 42.6 43.6 0.2 10. 65.106.1.102 75.0%37 43.5 46.5 43.4 62.9 6.3 11. 65.106.1.101 0.0%37 43.4 47.8 43.2 112.3 12.5 12. 65.106.0.41 0.0%37 57.5 65.1 57.1 177.3 21.0 13. 65.106.1.73 0.0%37 57.4 66.5 57.1 162.1 24.2 14. ??? Trying to call into XO and they aren't even taking calls, they mention something about network issues in Spokane. Any ideas as to what is going on/ETA to fix? --Justin
Re: favourite XFP supplier?
On 2008-09-22-15:01:35, Joe Abley <[EMAIL PROTECTED]> wrote: > Anybody have a preferred supplier for 10GE XFPs, multimode and > singlemode? Fluxlight (www.fluxlightinc.com) is good source for 10GBASE-SR and LR XFPs. They tend to keep an inventory, often able to ship on the day of order; their web store works; they run a reputable shop, and are fully understanding of "I'll need a tracking number ASAP, otherwise the facility you're sending them to might reject the shipment" -- all in all, a real win. If you have a Dell Premier account, you might want to check there, as they usually have XFPs listed at steep discount... If you're looking for exotics, such as ZR-D (DWDM), going with a Finisar reseller is a safe bet. I've had particularly good dealings with Cube Optics AG. (Fair warning: these are tougher to source on short notice.) HTH, -a
Re: XO Outage
yeah, we noticed it as well. looks like they're back now. i noticed their routes drop off at about 14:16 PT and come back just after 14:30 PT. +m Justin Sharp wrote: > We are seeing some issues w/ XO/Savvis peering.. > > Trace from XO to Savvis IP space (64.75.10.151) > > Keys: Help Display mode Restart statistics Order of fields quit > > > Packets Pings > Host > > Loss% Snt Last Avg Best Wrst StDev > 1. scrubbed > > 0.0% 60.6 0.5 0.4 0.6 0.1 > 2. > ip65-44-114-97.z114-44-65.customer.algx.net > > 0.0% 61.3 1.3 1.2 1.4 0.1 > 3. ??? > > > Trace from Savvis to XO IP space (65.44.114.97) > > 1. scrubbed > > > 0.0%380.4 0.4 0.3 0.5 0.1 > 2. > 64.41.199.129 > > 0.0%371.0 24.0 0.6 330.2 80.4 > 3. > hr1-ge-7-47.santaclarasc5.savvis.net > > 0.0%370.7 1.4 0.6 27.3 4.4 > 4. > er1-te-1-0-0.sanjose3equinix.savvis.net > > 0.0%370.7 5.2 0.6 140.3 23.2 > 5. > cr1-tenge-0-7-5-0.sanfrancisco.savvis.net > > 2.7%372.9 4.0 2.6 16.6 2.5 > 6. > cr2-pos-0-0-3-3.dallas.savvis.net > > 0.0%37 42.6 43.1 42.3 51.4 1.4 > 7. > dpr1-ge-4-0-0.dallasequinix.savvis.net > > 0.0%37 43.1 44.8 42.9 76.9 6.7 > 8. > er1-te-2-1.dallasequinix.savvis.net > > 0.0%37 43.3 49.2 42.8 233.6 31.6 > 9. > 208.175.175.90 > > 0.0%37 43.0 42.8 42.6 43.6 0.2 > 10. > 65.106.1.102 > > 75.0%37 43.5 46.5 43.4 62.9 6.3 > 11. > 65.106.1.101 > > 0.0%37 43.4 47.8 43.2 112.3 12.5 > 12. > 65.106.0.41 > > 0.0%37 57.5 65.1 57.1 177.3 21.0 > 13. > 65.106.1.73 > > 0.0%37 57.4 66.5 57.1 162.1 24.2 > 14. ??? > > Trying to call into XO and they aren't even taking calls, they mention > something about network issues in Spokane. Any ideas as to what is > going on/ETA to fix? > > --Justin > >
Re: XO Outage
Also seeing some issues with XO out here: Tracing route to yahoo.com [68.180.206.184] over a maximum of 30 hops: 1 2 ms 1 ms 1 ms 10.100.20.1 2 2 ms 1 ms 2 ms sjcisr01-int.wyse.com [10.100.1.15] 3 3 ms 2 ms 2 ms 132.237.245.1 4 3 ms 3 ms 2 ms 207.88.3.37.ptr.us.xo.net [207.88.3.37] 5 7 ms 3 ms 3 ms p3-0-0.mar2.fremont-ca.us.xo.net [207.88.80.181] 616 ms 5 ms 3 ms p4-0-0.rar2.sanjose-ca.us.xo.net [65.106.5.137] 712 ms14 ms11 ms p6-0-0.rar1.la-ca.us.xo.net [65.106.0.17] 817 ms11 ms11 ms p0-0-0d0.rar2.la-ca.us.xo.net [65.106.1.50] 944 ms50 ms52 ms p6-0-0.rar1.dallas-tx.us.xo.net [65.106.0.13] 10 *** Request timed out. 1144 ms44 ms44 ms 207.88.12.150.ptr.us.xo.net [207.88.12.150] 1253 ms85 ms52 ms 206.111.5.42.ptr.us.xo.net [206.111.5.42] ^C On Mon, Sep 22, 2008 at 2:35 PM, Justin Sharp <[EMAIL PROTECTED]> wrote: > We are seeing some issues w/ XO/Savvis peering.. > > Trace from XO to Savvis IP space (64.75.10.151) > > Keys: Help Display mode Restart statistics Order of fields quit > >Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. scrubbed > 0.0% 60.6 0.5 0.4 0.6 0.1 > 2. ip65-44-114-97.z114-44-65.customer.algx.net > 0.0% 61.3 1.3 1.2 1.4 0.1 > 3. ??? > > > Trace from Savvis to XO IP space (65.44.114.97) > > 1. scrubbed > 0.0%380.4 0.4 0.3 0.5 0.1 > 2. 64.41.199.129 > 0.0%371.0 24.0 0.6 330.2 80.4 > 3. hr1-ge-7-47.santaclarasc5.savvis.net >0.0%370.7 1.4 0.6 27.3 4.4 > 4. er1-te-1-0-0.sanjose3equinix.savvis.net > 0.0%370.7 5.2 0.6 140.3 23.2 > 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net > 2.7%372.9 4.0 2.6 16.6 2.5 > 6. cr2-pos-0-0-3-3.dallas.savvis.net > 0.0%37 42.6 43.1 42.3 51.4 1.4 > 7. dpr1-ge-4-0-0.dallasequinix.savvis.net >0.0%37 43.1 44.8 42.9 76.9 6.7 > 8. er1-te-2-1.dallasequinix.savvis.net > 0.0%37 43.3 49.2 42.8 233.6 31.6 > 9. 208.175.175.90 >0.0%37 43.0 42.8 42.6 43.6 0.2 > 10. 65.106.1.102 > 75.0%37 43.5 46.5 43.4 62.9 6.3 > 11. 65.106.1.101 >0.0%37 43.4 47.8 43.2 112.3 12.5 > 12. 65.106.0.41 > 0.0%37 57.5 65.1 57.1 177.3 21.0 > 13. 65.106.1.73 > 0.0%37 57.4 66.5 57.1 162.1 24.2 > 14. ??? > > Trying to call into XO and they aren't even taking calls, they mention > something about network issues in Spokane. Any ideas as to what is going > on/ETA to fix? > > --Justin > > >
Re: Atrivo/Intercage
On Mon, Sep 22, 2008 at 5:25 PM, Tom Sparks (Applied Operations) <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 05:17:42PM -0400, Christopher Morrow wrote: >> So... apparently AS27595 is back on the air, with aspath's like: >> 6461 23342 27595 >> 6539 23342 27595 >> 8075 23342 27595 >> >> 23342 == UnitedLayer, Tom isn't that you or is that another >> Tom I'm remembering? > > Yep, same Tom, I was one of the founders of UnitedLayer. > I haven't been there since 2006, so its not my doing. > yup, didn't particularly mean it was 'your doing' (even if you were there) but that perhaps (if you were still there) you might be able to influence the ops folks some... if you thought it worthy. > I also noticed AS paths like this: > * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i > > I'm not sure whats going on there, but I'm thinking someone needs some help :) > yea I suspect that's a history route (or PIE re-opened the links between PIE/Atrivo). Or... Abovenet & PIE & NTT aren't filtering their customers in a way that keeps PIE form providing transit to NTT for Abovenet :( (NTT says loud and long they filter based on IRR data, PIE might not have updated their IRR info?) wierd though.
Re: XO Outage
Seems like Savvis/XO routes have been restored, albeit through an unusual Dallas route (usually takes an XO Los Angeles route).. 1. scrubbed 0.0% 2040.4 0.7 0.3 7.0 0.9 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 2041.8 1.8 1.1 8.4 1.2 3. ip65-46-48-29.z48-46-65.customer.algx.net 0.0% 2043.3 6.3 2.8 96.4 9.0 4. p6-0-0-0.mar1.saltlake-ut.us.xo.net 0.5% 2048.1 14.4 3.1 161.0 26.3 5. p4-1-0-0.rar1.denver-co.us.xo.net 0.0% 204 15.5 25.6 15.3 191.4 26.7 6. p0-0-0d0.rar2.denver-co.us.xo.net 0.0% 204 16.2 22.4 16.1 129.2 14.4 7. p1-0-0.rar2.dallas-tx.us.xo.net 0.0% 204 45.3 38.3 29.9 201.3 21.3 8. te-3-4-0.rar3.dallas-tx.us.xo.net 66.0% 204 30.3 34.2 29.6 116.2 11.6 9. 207.88.12.146.ptr.us.xo.net 0.0% 204 33.1 32.7 29.4 106.7 8.5 10. 208.175.175.89 0.0% 204 29.8 35.7 29.5 195.4 20.0 11. dpr1-ge-2-0-0.dallasequinix.savvis.net 0.0% 204 34.3 33.8 29.6 115.2 10.5 12. cr2-tengige0-7-5-0.dallas.savvis.net 1.5% 204 30.2 33.3 29.7 68.6 5.4 13. cr2-loopback.sfo.savvis.net 0.0% 203 75.1 209.8 74.0 3270. 493.7 14. er1-te-2-0-1.sanjose3equinix.savvis.net 0.0% 203 71.8 75.6 71.7 219.5 11.7 15. hr1-te-2-0-0.santaclarasc5.savvis.net 0.0% 203 72.1 75.5 72.0 194.0 9.4 16. 216.34.2.226 0.0% 203 72.3 105.4 72.1 723.7 102.5 17. 64.41.199.140 28.6% 203 77.5 74.9 72.0 183.1 9.7 18. scrubbed 0.0% 203 73.8 76.0 72.4 207.9 11.3 Hop 8 looks busy.. --Justin Mike Lyon wrote: Also seeing some issues with XO out here: Tracing route to yahoo.com [68.180.206.184] over a maximum of 30 hops: 1 2 ms 1 ms 1 ms 10.100.20.1 2 2 ms 1 ms 2 ms sjcisr01-int.wyse.com [10.100.1.15] 3 3 ms 2 ms 2 ms 132.237.245.1 4 3 ms 3 ms 2 ms 207.88.3.37.ptr.us.xo.net [207.88.3.37] 5 7 ms 3 ms 3 ms p3-0-0.mar2.fremont-ca.us.xo.net [207.88.80.181] 616 ms 5 ms 3 ms p4-0-0.rar2.sanjose-ca.us.xo.net [65.106.5.137] 712 ms14 ms11 ms p6-0-0.rar1.la-ca.us.xo.net [65.106.0.17] 817 ms11 ms11 ms p0-0-0d0.rar2.la-ca.us.xo.net [65.106.1.50] 944 ms50 ms52 ms p6-0-0.rar1.dallas-tx.us.xo.net [65.106.0.13] 10 *** Request timed out. 1144 ms44 ms44 ms 207.88.12.150.ptr.us.xo.net [207.88.12.150] 1253 ms85 ms52 ms 206.111.5.42.ptr.us.xo.net [206.111.5.42] ^C On Mon, Sep 22, 2008 at 2:35 PM, Justin Sharp <[EMAIL PROTECTED]> wrote: We are seeing some issues w/ XO/Savvis peering.. Trace from XO to Savvis IP space (64.75.10.151) Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. scrubbed 0.0% 60.6 0.5 0.4 0.6 0.1 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 61.3 1.3 1.2 1.4 0.1 3. ??? Trace from Savvis to XO IP space (65.44.114.97) 1. scrubbed 0.0%380.4 0.4 0.3 0.5 0.1 2. 64.41.199.129 0.0%371.0 24.0 0.6 330.2 80.4 3. hr1-ge-7-47.santaclarasc5.savvis.net 0.0%370.7 1.4 0.6 27.3 4.4 4. er1-te-1-0-0.sanjose3equinix.savvis.net 0.0%370.7 5.2 0.6 140.3 23.2 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net 2.7%372.9 4.0 2.6 16.6 2.5 6. cr2-pos-0-0-3-3.dallas.savvis.net 0.0%37 42.6 43.1 42.3 51.4 1.4 7. dpr1-ge-4-0-0.dallasequinix.savvis.net
Re: XO Outage
I am seeing it on my end also: traceroute: Warning: www.cnn.com has multiple addresses; using 157.166.224.25 traceroute to www.cnn.com (157.166.224.25), 64 hops max, 40 byte packets 1 hq-rtr1.genius.local (64.244.66.1) 0.891 ms 0.429 ms 0.449 ms 2 ip65-46-253-157.z253-46-65.customer.algx.net (65.46.253.157) 1.856 ms 2.860 ms 1.881 ms 3 p3-0-0.mar2.fremont-ca.us.xo.net (207.88.80.181) 16.922 ms 2.041 ms 2.013 ms 4 p4-3-0.rar2.sanjose-ca.us.xo.net (65.106.5.161) 2.637 ms 2.192 ms 2.823 ms 5 p6-0-0.rar1.la-ca.us.xo.net (65.106.0.17) 10.308 ms 10.258 ms 10.386 ms 6 207.88.13.22.ptr.us.xo.net (207.88.13.22) 10.931 ms 10.535 ms 10.037 ms 7 *^C Justin Sharp wrote: We are seeing some issues w/ XO/Savvis peering.. Trace from XO to Savvis IP space (64.75.10.151) Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. scrubbed 0.0% 60.6 0.5 0.4 0.6 0.1 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 61.3 1.3 1.2 1.4 0.1 3. ??? Trace from Savvis to XO IP space (65.44.114.97) 1. scrubbed 0.0%380.4 0.4 0.3 0.5 0.1 2. 64.41.199.129 0.0%371.0 24.0 0.6 330.2 80.4 3. hr1-ge-7-47.santaclarasc5.savvis.net 0.0%370.7 1.4 0.6 27.3 4.4 4. er1-te-1-0-0.sanjose3equinix.savvis.net 0.0%370.7 5.2 0.6 140.3 23.2 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net 2.7%372.9 4.0 2.6 16.6 2.5 6. cr2-pos-0-0-3-3.dallas.savvis.net 0.0%37 42.6 43.1 42.3 51.4 1.4 7. dpr1-ge-4-0-0.dallasequinix.savvis.net 0.0%37 43.1 44.8 42.9 76.9 6.7 8. er1-te-2-1.dallasequinix.savvis.net 0.0%37 43.3 49.2 42.8 233.6 31.6 9. 208.175.175.90 0.0%37 43.0 42.8 42.6 43.6 0.2 10. 65.106.1.102 75.0%37 43.5 46.5 43.4 62.9 6.3 11. 65.106.1.101 0.0%37 43.4 47.8 43.2 112.3 12.5 12. 65.106.0.41 0.0%37 57.5 65.1 57.1 177.3 21.0 13. 65.106.1.73 0.0%37 57.4 66.5 57.1 162.1 24.2 14. ??? Trying to call into XO and they aren't even taking calls, they mention something about network issues in Spokane. Any ideas as to what is going on/ETA to fix? --Justin
Re: Atrivo/Intercage
On Mon, Sep 22, 2008 at 5:48 PM, Christopher Morrow <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 5:25 PM, Tom Sparks (Applied Operations) > <[EMAIL PROTECTED]> wrote: >> I also noticed AS paths like this: >> * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i >> >> I'm not sure whats going on there, but I'm thinking someone needs some help >> :) >> > > yea I suspect that's a history route (or PIE re-opened the links > between PIE/Atrivo). Or... Abovenet & PIE & NTT aren't filtering their > customers in a way that keeps PIE form providing transit to NTT for > Abovenet :( (NTT says loud and long they filter based on IRR data, PIE > might not have updated their IRR info?) > > wierd though. > actually, I think PIE sees this route from 6461 and passes it along probably because they didn't update the filters on their sessions when they dropped the links to 27595 :( Also they didn't update the IRR data to remove this set of prefixes. bummers.
Re: Atrivo/Intercage
On Mon, Sep 22, 2008 at 05:50:58PM -0400, Christopher Morrow wrote: > actually, I think PIE sees this route from 6461 and passes it along > probably because they didn't update the filters on their sessions when > they dropped the links to 27595 :( Has anyone actually confirmed that the link is dropped with PIE? > Also they didn't update the IRR data to remove this set of prefixes. Looks like they've got all kindsa stuff in there... -- Tom Sparks (415) 367-7328x1001
Re: InterCage, Inc. (NOT Atrivo)
Patrick W. Gilmore wrote: There is no law or even custom stopping me from asking you to prove you are worthy to connect to my network. There may not be a law preventing you from asking him for proof of legitimate customers, but there is a law preventing him from answering you. Google for CPNI and "red flag". Justin
YAY! Re: Atrivo/Intercage: NO Upstream depeer
On Sun, Sep 21, 2008 at 12:46:54PM -0700, Emil Kacperski wrote: > Hey James, > > That's the worst part in all this, so many been with me for years!? I just put my fate into companies I shouldn't have. Emil: Yes, they have been with you for years -- it's quite unfortunate, such great customers. Take those customers who steal identity from the public -- did you get a cut, or just the hosting fees? Next, move to those who host trojans, rogue antivirus, bill people for fake software (and keep billing them), etc. Oh, and the ad-ware, despite being a lower security risk, it was some of the most hated stuff out there. I'd say you have put your fate into companies you shouldn't have -- not just your fate but your business. This is the logical result (actually, this is just the start). I'm surprised it took so long. You can't wash away years of malicious activity by simply claiming innocence and disconnecting some of your worst offenders. Male parta male dilabuntur. For the NANOG folks who apparently don't understand what is going on and are so easily socially engineered by these claims of innocence -- do a little research: http://www.google.com/search?hl=en&q=intercage+malware http://www.google.com/search?hl=en&q=atrivo+malware Here's some research for you: Complaints on Intercage/Atrivo from 2003: Re: The in-your-face hijacking example http://www.irbs.net/internet/nanog/0305/0038.html >From 2006: More super rogue anti-spyware http://updates.zdnet.com/tags/intercage.com.html Be on the lookout for another new supposed anti-spyware program that might be hijacking desktops any day now. This one is called PestTrap and it.s a clone of SpySheriff. SpySheriff was one of the top 10 rogue anti-spyware apps of 2005, coming in at number 2. PestTrap site is hosted at IP address 69.50.167.173 which belongs to an ISP in California, InterCage, Inc., formerly know n as Atrivo. Note the nameservers are mail.atrrivo.com and pavel.atrivo.com . OrgName:InterCage, Inc. OrgID: INTER-359 Address:1955 Monument Blvd. Address:#236 City: Concord StateProv: CA PostalCode: 94520 Country:US Not surprisingly, SpySheriff.com (link to whois) is hosted at InterCage, and we have SpyTrooper.com on the same IP address, 69.50.170.82. The other domain on the IP is Spy-Sheriff.com. This IP is also currently blacklisted. InterCage, Inc. INTERCAGE-NETWORK-GROUP (NET-69-50-160-0-1) 69.50.160.0 - 69.50.191.255 William Lu STANDARDSHELLS (NET-69-50-170-0-1) 69.50.170.0 - 69.50.170.255 The Intercage.com (link to site) home page is white and blank except for "." in the upper left corner. Now, that seems odd to me. An ISP with a blank homepage? Google searches for Intercage.com and Intercage, Inc. bring up all kinds of interesting links. A Google search for Atrivo produces even more fascinating information like this and this. More on this one later.
Re: hat tip to .gov hostmasters
In article <[EMAIL PROTECTED]> you write: >* marcus sachs: > >> While we wait for applications to become DNSSEC-aware, > >Uhm, applications shouldn't be DNSSEC-aware. Down that road lies >madness. What should an end user do when the browser tells him, >"Warning: Could not validate DNSSEC signature on www.example.com, >signature has expired. Continue to connect?" The application just rejects the answer. Trys again a couple of times then reports failure. This is no different to the application talking to the validating resolver a couple of time and then reporting failure. The advantage of having the application do it is that you don't need to secure the connection between the validating resolver and the application. Mark
Re: InterCage, Inc. (NOT Atrivo)
That does not stop me from asking. Also, I've never seen a viable, legit biz that didn't have at least a couple customers who were willing to let their name be used. -- TTFN, patrick iPhone 3-J (That's 3-Jezuz for the uninitiated.) On Sep 22, 2008, at 18:00, Justin Shore <[EMAIL PROTECTED]> wrote: Patrick W. Gilmore wrote: There is no law or even custom stopping me from asking you to prove you are worthy to connect to my network. There may not be a law preventing you from asking him for proof of legitimate customers, but there is a law preventing him from answering you. Google for CPNI and "red flag". Justin
prefix hijack by ASN 8997
I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and
another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in
using ASN 3267 (Russian Federal University Network) to advertise our space to
ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western
and Saint-Petersburg Area of Russia).
Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in
prefix 72.234.0.0/15 and select the dates:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
If so, am I understanding it correctly if I say ASN 3267 saw a shorter path
from ASN 8997, so refused the proper announcement from ASN 36149 (me) it
normally hears from ASN 174 (Cogent).
If the above two are correct, would it be correct to say only the downstream
customers of ASN 3267 were affected?
scott
Re: InterCage, Inc. (NOT Atrivo)
On Mon, 22 Sep 2008 17:00:35 CDT, Justin Shore said: > There may not be a law preventing you from asking him for proof of > legitimate customers, but there is a law preventing him from answering > you. Google for CPNI and "red flag". Hmm... I'm not sure how "Yes, XYZ is a customer of mine" qualifies as a "red flag" question for identity theft. I'm also not sure how "XYZ is a customer" qualifies as CPNI, which (according to the first few pages of Google hits) comprises things like calling/billing records. http://www.privacyalerts.org/phone-records.html says: For clarity, a "record" in this section is the same thing as a "call log" or a "text log." A "phone record" typically includes: date, time, sender geographic location, recipient phone number, recipient geographic location, and duration of call. A "text record" includes: date, time, and recipient phone number. Nope. Doesn't seem like "xyz is a customer" qualifies there... http://www.ipbusinessmag.com/articles.php?issue_id=63&article_id=387 says: Space does not permit an extended review of the FTC rules here, but they apply to "creditors" who maintain ongoing accounts with customers for repeated transactions. Cell phone accounts are offered by the rules as one example of a "covered" account which is subject to the rules. If a business maintains such "covered accounts" it must comply with the new rules to prevent identity theft of its account holders. Hmm... "xyz is a customer" doesn't seem to run afoul of that either. Feel free to enlighten me about what I missed here? pgpNGkggWH3um.pgp Description: PGP signature
Re: prefix hijack by ASN 8997
I received a phas notification about this today as well...
I couldn't find any relevant data confirming the announcement of one
of my /19 blocks, until a few minutes ago when i checked the route
views bgplay (ripe bgplay turns up nothing) and can now see 8997
announcing and quickly withdrawing my prefix
On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks <[EMAIL PROTECTED]> wrote:
>
>
>
> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and
> another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in
> using ASN 3267 (Russian Federal University Network) to advertise our space to
> ASN 3277 (Regional University and Scientific Network (RUSNet) of
> North-Western and Saint-Petersburg Area of Russia).
>
> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in
> prefix 72.234.0.0/15 and select the dates:
>
> 22/9/2008 9:00:00 and 22/9/2008 15:00:00
>
> If so, am I understanding it correctly if I say ASN 3267 saw a shorter path
> from ASN 8997, so refused the proper announcement from ASN 36149 (me) it
> normally hears from ASN 174 (Cogent).
>
> If the above two are correct, would it be correct to say only the downstream
> customers of ASN 3267 were affected?
>
> scott
>
>
Re: prefix hijack by ASN 8997
--Scott Weeks <[EMAIL PROTECTED]> wrote: --- > I am hoping to confirm a short-duration prefix hijack - --- [EMAIL PROTECTED] wrote: --- From: "Christian Koch" <[EMAIL PROTECTED]> I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix - At what time did you see it? scott
Re: prefix hijack by ASN 8997
about 09:30 UTC per rviews On Mon, Sep 22, 2008 at 9:31 PM, Scott Weeks <[EMAIL PROTECTED]> wrote: > > --Scott Weeks <[EMAIL PROTECTED]> wrote: --- > >> I am hoping to confirm a short-duration prefix hijack > > - > > --- [EMAIL PROTECTED] wrote: --- > From: "Christian Koch" <[EMAIL PROTECTED]> > > I couldn't find any relevant data confirming the announcement of one > of my /19 blocks, until a few minutes ago when i checked the route > views bgplay (ripe bgplay turns up nothing) and can now see 8997 > announcing and quickly withdrawing my prefix > - > > > At what time did you see it? > > scott > >
Re: prefix hijack by ASN 8997
On Mon, Sep 22, 2008 at 21:06, Scott Weeks <[EMAIL PROTECTED]> wrote:
>
> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and
> another of our
> prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267
> (Russian Federal University Network) to advertise our space to ASN 3277
> (Regional
> University and Scientific Network (RUSNet) of North-Western and
> Saint-Petersburg
> Area of Russia).
Yep, saw this for 69.61.0.0/17 GlobalCompass (my upstream) this AM:
SEQUENCE_NUMBER: 1222091638
TYPE: last-hop
BGP-UPDATE-TIME: 1222075864
PHAS-DETECT-TIME: 1222091637
PHAS-NOTIFY-TIME: 1222091637
PREFIX: 69.61.0.0/17
SET: 3561,3267,3356,3491
GAINED: 3267 <- Russian Federal University Network
LOST:
SEQUENCE_NUMBER: 1222091638
TYPE: origin
BGP-UPDATE-TIME: 1222075864
PHAS-DETECT-TIME: 1222091637
PHAS-NOTIFY-TIME: 1222091637
PREFIX: 69.61.0.0/17
SET: 8997,22653
GAINED: 8997 <- OJSC North-West Telecom, St.-Petersburg, Russia
LOST:
SEQUENCE_NUMBER: 1222096125
TYPE: origin
BGP-UPDATE-TIME: 1222076569
PHAS-DETECT-TIME: 1222092415
PHAS-NOTIFY-TIME: 1222096124
PREFIX: 69.61.0.0/17
SET: 22653 <- GlobalCrossing
GAINED:
LOST: 8997
-Jim P.
Re: duplicate packet
She'd have to actually specify -b to ping a broadcast address, and if she did, she would only get replies back from the hosts on that subnet, not duplicate replies from the same IP. On Wed, Sep 10, 2008 at 5:11 AM, Sebastian Abt <[EMAIL PROTECTED]> wrote: > * chloe K wrote: >> When I ping the ip, I get the duplicate >> >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > > What's your netmask? Is 192.168.0.95 your net's broadcast address? > > sebastian > > -- > SABT-RIPE PGPKEY-D008DA9C > >
Re: duplicate packet
At least I think that's how it works. :) On Mon, Sep 22, 2008 at 7:54 PM, John Jensen <[EMAIL PROTECTED]> wrote: > She'd have to actually specify -b to ping a broadcast address, and if > she did, she would only get replies back from the hosts on that > subnet, not duplicate replies from the same IP. > > On Wed, Sep 10, 2008 at 5:11 AM, Sebastian Abt <[EMAIL PROTECTED]> wrote: >> * chloe K wrote: >>> When I ping the ip, I get the duplicate >>> >>> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >>> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) >> >> What's your netmask? Is 192.168.0.95 your net's broadcast address? >> >> sebastian >> >> -- >> SABT-RIPE PGPKEY-D008DA9C >> >> >
Re: duplicate packet
On Mon, 22 Sep 2008 19:54:17 PDT, John Jensen said: > She'd have to actually specify -b to ping a broadcast address, Only true if you're pinging the broadcast address of a network that you have an interface on, or the system has other knowledge of the netmask/etc. If you're pinging a remote address, your system (in general) has no way of knowing if that .0.95 is a broadcast address for a /27, or a normal address in the middle of a /26 (or one of the other possibilities). (I've lost the original posting, and can't recall if the OP said if she was pinging from on-subnet or off-subnet). pgpRzofmeIj6L.pgp Description: PGP signature
Re: prefix hijack by ASN 8997
Looking up some of my prefixes in PHAS and BGPPlay, I too see my
prefixes being advertised by 8997 for a short time. It looks like it
happened around 1222091563 according to PHAS.
Was this a mistake or something else?
Justin
Christian Koch wrote:
I received a phas notification about this today as well...
I couldn't find any relevant data confirming the announcement of one
of my /19 blocks, until a few minutes ago when i checked the route
views bgplay (ripe bgplay turns up nothing) and can now see 8997
announcing and quickly withdrawing my prefix
On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks <[EMAIL PROTECTED]> wrote:
I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of
our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN
3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional
University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of
Russia).
Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in
prefix 72.234.0.0/15 and select the dates:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
If so, am I understanding it correctly if I say ASN 3267 saw a shorter path
from ASN 8997, so refused the proper announcement from ASN 36149 (me) it
normally hears from ASN 174 (Cogent).
If the above two are correct, would it be correct to say only the downstream
customers of ASN 3267 were affected?
scott
Re: prefix hijack by ASN 8997
On Mon, 22 Sep 2008, Scott Weeks wrote:
I too spotted this via PHAS for a large number of prefixes, but have not
received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack:
http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected
with so many RRC boxes that RIPE RIS would have caught it. I had thought
it was a false positive from PHAS but now that you and others have seen it
- I guess it is for real.
-Hank
I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of
our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN
3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional
University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of
Russia).
Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in
prefix 72.234.0.0/15 and select the dates:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
If so, am I understanding it correctly if I say ASN 3267 saw a shorter path
from ASN 8997, so refused the proper announcement from ASN 36149 (me) it
normally hears from ASN 174 (Cogent).
If the above two are correct, would it be correct to say only the downstream
customers of ASN 3267 were affected?
scott
Re: prefix hijack by ASN 8997
On Mon, 22 Sep 2008, Christian Koch wrote:
Strange that RIPE RIS search doesn't show it:
http://www.ris.ripe.net/perl-risapp/risearch.html
but yet you say BGPlay does show it.
-Hank
I received a phas notification about this today as well...
I couldn't find any relevant data confirming the announcement of one
of my /19 blocks, until a few minutes ago when i checked the route
views bgplay (ripe bgplay turns up nothing) and can now see 8997
announcing and quickly withdrawing my prefix
On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks <[EMAIL PROTECTED]> wrote:
I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of
our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN
3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional
University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of
Russia).
Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in
prefix 72.234.0.0/15 and select the dates:
22/9/2008 9:00:00 and 22/9/2008 15:00:00
If so, am I understanding it correctly if I say ASN 3267 saw a shorter path
from ASN 8997, so refused the proper announcement from ASN 36149 (me) it
normally hears from ASN 174 (Cogent).
If the above two are correct, would it be correct to say only the downstream
customers of ASN 3267 were affected?
scott
Re: prefix hijack by ASN 8997
At first glance this morning not seeing any data between the gain and
lost alerts from phas and inability to find a route in any of the many
collectors and route servers out there I had thought it was a possibly
a fat finger mistake by 8997 or a false positive.
After locating the data in bgplay/rviews, and noticing how many more
people this occured to I'm leaning towards 2 possible scenarios:
1 - bgp misconfigurations leading to leaks
(Depends on the overall scale of how many other prefixes were
possibly announced)
2 - 8997 began announcing prefixes as an experiment to "test the
waters" for potential real hijacks in future...
'geography' hints towards #2
Or both theories could be way off :)
I'd be interested to know if Renesys collected any data that might
give some better insight to this...
Christian
On 9/23/08, Justin Shore <[EMAIL PROTECTED]> wrote:
> Looking up some of my prefixes in PHAS and BGPPlay, I too see my
> prefixes being advertised by 8997 for a short time. It looks like it
> happened around 1222091563 according to PHAS.
>
> Was this a mistake or something else?
>
> Justin
>
>
> Christian Koch wrote:
>> I received a phas notification about this today as well...
>>
>> I couldn't find any relevant data confirming the announcement of one
>> of my /19 blocks, until a few minutes ago when i checked the route
>> views bgplay (ripe bgplay turns up nothing) and can now see 8997
>> announcing and quickly withdrawing my prefix
>>
>>
>>
>>
>> On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks <[EMAIL PROTECTED]>
>> wrote:
>>>
>>>
>>> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15
>>> (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in
>>> Russia) in using ASN 3267 (Russian Federal University Network) to
>>> advertise our space to ASN 3277 (Regional University and Scientific
>>> Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia).
>>>
>>> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put
>>> in prefix 72.234.0.0/15 and select the dates:
>>>
>>> 22/9/2008 9:00:00 and 22/9/2008 15:00:00
>>>
>>> If so, am I understanding it correctly if I say ASN 3267 saw a shorter
>>> path from ASN 8997, so refused the proper announcement from ASN 36149
>>> (me) it normally hears from ASN 174 (Cogent).
>>>
>>> If the above two are correct, would it be correct to say only the
>>> downstream customers of ASN 3267 were affected?
>>>
>>> scott
>>>
>>>
>>
>
--
Sent from my mobile device
Re: prefix hijack by ASN 8997
Bgplay on routeviews, not the ripe one :)
Christian
On 9/23/08, Hank Nussbacher <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Sep 2008, Christian Koch wrote:
>
> Strange that RIPE RIS search doesn't show it:
> http://www.ris.ripe.net/perl-risapp/risearch.html
> but yet you say BGPlay does show it.
>
> -Hank
>
>> I received a phas notification about this today as well...
>>
>> I couldn't find any relevant data confirming the announcement of one
>> of my /19 blocks, until a few minutes ago when i checked the route
>> views bgplay (ripe bgplay turns up nothing) and can now see 8997
>> announcing and quickly withdrawing my prefix
>>
>>
>>
>>
>> On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks <[EMAIL PROTECTED]>
>> wrote:
>>>
>>>
>>>
>>> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15
>>> (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in
>>> Russia) in using ASN 3267 (Russian Federal University Network) to
>>> advertise our space to ASN 3277 (Regional University and Scientific
>>> Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia).
>>>
>>> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put
>>> in prefix 72.234.0.0/15 and select the dates:
>>>
>>> 22/9/2008 9:00:00 and 22/9/2008 15:00:00
>>>
>>> If so, am I understanding it correctly if I say ASN 3267 saw a shorter
>>> path from ASN 8997, so refused the proper announcement from ASN 36149
>>> (me) it normally hears from ASN 174 (Cogent).
>>>
>>> If the above two are correct, would it be correct to say only the
>>> downstream customers of ASN 3267 were affected?
>>>
>>> scott
>>>
>>>
>>
>
--
Sent from my mobile device
Re: prefix hijack by ASN 8997
Hi, .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank Nussbacher wrote: > I too spotted this via PHAS for a large number of prefixes, but have not > received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: > http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected > with so many RRC boxes that RIPE RIS would have caught it. I had thought > it was a false positive from PHAS but now that you and others have seen > it - I guess it is for real. Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) * 250495 seen by routeviews (ASpath: 2895 3267 8997). (results of quick query: where AS-path contained '3267 8997' update type = advertisement). I'm using another prefix monitoring tool and within a few minutes it notified me of this hijack for some of our prefixes: <> Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) detected 1 updates for your prefix 128.189.0.0/16 AS271: Update details: 2008-09-22 09:33 (UTC) 128.189.0.0/16 Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), Transit AS: AS3267 (RUNNET RUNNet) ASpath: 2895 3267 8997 Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) detected 1 updates for your prefix 142.231.0.0/16 AS271: Update details: 2008-09-22 09:34 (UTC) 142.231.0.0/16 Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), Transit AS: AS3267 (RUNNET RUNNet) ASpath: 2895 3267 8997 Cheers, Andree
Re: prefix hijack by ASN 8997
Ahah, so my first theory was on the right track :) Thanks for sharing the info... Christian On Tue, Sep 23, 2008 at 2:33 AM, Andree Toonk <[EMAIL PROTECTED]> wrote: > Hi, > > .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank > Nussbacher wrote: > >> I too spotted this via PHAS for a large number of prefixes, but have not >> received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: >> http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected >> with so many RRC boxes that RIPE RIS would have caught it. I had thought >> it was a false positive from PHAS but now that you and others have seen >> it - I guess it is for real. > > Not a false positive, It actually was detected by the RIS box in Moscow > (rrc13). Strange that it's not visible in RIS search website, but it's > definitely in the raw data files. > Looking at that raw data from both routeviews and Ripe, it looks like they > (AS8997) 'leaked' a full table, i.e. : > * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 > 3267 8997) > * 250495 seen by routeviews (ASpath: 2895 3267 8997). > (results of quick query: where AS-path contained '3267 8997' update type = > advertisement). > > I'm using another prefix monitoring tool and within a few minutes it notified > me of this hijack for some of our prefixes: > <> > > Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or > Origin AS changed) > detected 1 updates for your prefix 128.189.0.0/16 AS271: > Update details: 2008-09-22 09:33 (UTC) > 128.189.0.0/16 > Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), > Transit AS: AS3267 (RUNNET RUNNet) > ASpath: 2895 3267 8997 > > Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or > Origin AS changed) > detected 1 updates for your prefix 142.231.0.0/16 AS271: > Update details: 2008-09-22 09:34 (UTC) > 142.231.0.0/16 > Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), > Transit AS: AS3267 (RUNNET RUNNet) > ASpath: 2895 3267 8997 > > > > Cheers, > Andree > >
Re: prefix hijack by ASN 8997
On Tue, 23 Sep 2008, Andree Toonk wrote: Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) * 250495 seen by routeviews (ASpath: 2895 3267 8997). (results of quick query: where AS-path contained '3267 8997' update type = advertisement). ASpath: 2895 3267 8997 Is that the only ASpath that leaked it? There are others - did they filter properly and only that path failed to filter? Regards, Hank
