.gov whois server down
It looks like it's broken.. I called their helpdesk and they're looking into it. Len
Re: .gov whois server down
I asked them about that they claimed it was not.. we'll see :) On Tue, Jan 21, 2003 at 08:17:48AM -0800, Brian wrote: I wouldn't be surprised if it were taken down deliberately for information modification's sake. Bri - Original Message - From: Len Rose [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 21, 2003 7:35 AM Subject: .gov whois server down It looks like it's broken.. I called their helpdesk and they're looking into it. Len
Re: Peering BOF VI at NANOG
And for those attending the Gigabit Peering Forum in Los Angeles following NANOG, please drop me a line [EMAIL PROTECTED] if you can make the dinner out in Malibu at http://www.gladstones.com on the 12th. Cheers, -ren At 08:16 AM 1/10/2003 -0800, William B. Norton wrote: Hi all - If you are not a Peering Coordinator attending NANOG 27 then you needn't read any further. The 6th Peering BOF at NANOG will be held Monday night and focuses on helping Peering Coordinators make contact with other Peering Coordinators using Peering Personals. We solicit Peering Coordinators (via this e-mail), asking them to characterize their networks and peering policies in general ways (content heavy or access (eyeball) -heavy, Multiple Points Required or Will Peer anywhere, Peering with Content OK, etc.). From the answers we will select a set of ISP Peering Coordinators to present a 2-3 minute description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. If you are a Peering Coordinator and wish to participate in this BOF, please fill out the following form and e-mail it to [EMAIL PROTECTED] with Subject: Peering BOF VI . Name: Title: Company: AS#: Check each that applies: ___ We are an ISP (sell access to the Internet) -- OR -- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy -- OR -- ___ We are Access-Heavy ___ Peering with Content Players or Content Heavy ISPs is OK by us ___ We generally require peering in multiple locations ___ We will peer with anyone in any single location ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering Current Peering Locations: ___ Planned (3-6 mos) Peering Locations: ___ See you in Phoenix! Bill PS - This form is also on the NANOG web page at: http://www.nanog.org/mtg-0302/norton.html --- William B. Norton [EMAIL PROTECTED] 650.315.8635 Co-Founder and Chief Technical Liaison Equinix, Inc.
RE: uunet
Only if they include it in the growth, performance, or other metrics. I would _hope_ that it would have the worst tickets/revenue ratio in their database, but you never know... DJ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rubens Kuhl Jr. Sent: Tuesday, January 21, 2003 12:26 AM To: [EMAIL PROTECTED] Subject: Re: uunet Someone might read this as inflation of customer base numbers... has this company been involved in scandals recently ? :-) Rubens - Original Message - From: Vadim Antonov [EMAIL PROTECTED] To: Scott Granados [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 10:36 PM Subject: Re: uunet | | | I have a suggestion for UUNET's backbone engineering folks: | | Please, create a fake customer ID and publish it, so outside folks could | file trouble reports regarding routing issues within UUNET. | | --vadim | | | On Sat, 18 Jan 2003, Scott Granados wrote: | | | What's interesting is that I just tried to call the noc and was told | We have to have you e-mail the group | | my response, I can't I have no route working to uunet | | Well you have to | | my response, ok I'll use someone elses mail box where do I mail? | | We can't tell you your not a customer | | My response its a routing issue do you have somewhere I can e-mail you. | | Your not my customer I really don't care *click* | | Nice. professional too. | | Anyone have a number to the noc that someone with clue might answer? | | - Original Message - | From: David Diaz [EMAIL PROTECTED] | To: Scott Granados [EMAIL PROTECTED]; [EMAIL PROTECTED] | Sent: Saturday, January 18, 2003 4:35 PM | Subject: Re: uunet | | | Im not seeing anything coming from qwest. | | | | At 16:55 -0800 1/18/03, Scott Granados wrote: | Is something up on uunet tonight? | | It looks to me that dns is broken forward and reverse but more likely it | looks like a bad bogan fiilter popped up suddenly. I have issue as soon | as | I leave mfn's network and hit uunet. | | -- | | David Diaz | [EMAIL PROTECTED] [Email] | [EMAIL PROTECTED] [Pager] | www.smoton.net [Peering Site under development] | Smotons (Smart Photons) trump dumb photons | | | | |
Re: The Awards: Best network service provider security architecture
I absolutely agree with Item 3. Sure, IP itself doesn't protect against those things, but if a BN doesn't provide service without delay, misdelivery, or nondelivery of otherwise adequately protected information (valid packets), then the BN isn't very useful. If I met all the other criteria here, but blackholed half the traffic, my BN wouldn't be very good. Owen --On Tuesday, January 21, 2003 15:07 -0500 Sean Donelan [EMAIL PROTECTED] wrote: I've been looking at a lot of different technical security architectures for network providers. Obviously many providers keep their security secret, so they may or may not have a decent security architecture. Nevertheless there is still a lot of good information available from government agency networks, academics and vendors. The best network service provider security architecture document First Place: Information Assurance Technical Framework Second Place: The ESNET unclassified Security Plan Third Place: University of Washington Network Security Credo From the IATF document http://www.iatf.net/ 5.1 Availability of Backbone Network I would disagree about item #3, IP is a datagram service, and does not protect against delay or packet drops (see item #1). Otherwise this is a decent list of functional security requirements for most Internet backbone providers. Its short, but covers the big items. 1. BNs must provide an agreed level of responsiveness, continuity of service and resistance to accidental or intentional corruption of the communications service. (The agreement is between the owners of the network and the users of the network.) 2. BNs are not required to provide security services of user data (such as confidentiality and integrity)that is the user's responsibility. 3. BNs must protect against the delay, misdelivery, or nondelivery of otherwise adequately protected information. 4. BNs, as a part of the end-to-end information transfer system, must provide the service transparently to the user. 5. As part of the transparency requirement, the BN must operate seamlessly with other backbones and local networks.
Re: The Awards: Best network service provider security architecture
If you have done a good job negotiating Item 1, item 3 is redundant. On the other hand if you have choosen a crappy backbone in Item 1, using VPN/SSL/whatever to secure your packets won't help delay or nondelivery of packets. On Tue, 21 Jan 2003, Owen DeLong wrote: I absolutely agree with Item 3. Sure, IP itself doesn't protect against those things, but if a BN doesn't provide service without delay, misdelivery, or nondelivery of otherwise adequately protected information (valid packets), then the BN isn't very useful. If I met all the other criteria here, but blackholed half the traffic, my BN wouldn't be very good. Owen --On Tuesday, January 21, 2003 15:07 -0500 Sean Donelan [EMAIL PROTECTED] wrote: I've been looking at a lot of different technical security architectures for network providers. Obviously many providers keep their security secret, so they may or may not have a decent security architecture. Nevertheless there is still a lot of good information available from government agency networks, academics and vendors. The best network service provider security architecture document First Place: Information Assurance Technical Framework Second Place: The ESNET unclassified Security Plan Third Place: University of Washington Network Security Credo From the IATF document http://www.iatf.net/ 5.1 Availability of Backbone Network I would disagree about item #3, IP is a datagram service, and does not protect against delay or packet drops (see item #1). Otherwise this is a decent list of functional security requirements for most Internet backbone providers. Its short, but covers the big items. 1. BNs must provide an agreed level of responsiveness, continuity of service and resistance to accidental or intentional corruption of the communications service. (The agreement is between the owners of the network and the users of the network.) 2. BNs are not required to provide security services of user data (such as confidentiality and integrity)that is the user's responsibility. 3. BNs must protect against the delay, misdelivery, or nondelivery of otherwise adequately protected information. 4. BNs, as a part of the end-to-end information transfer system, must provide the service transparently to the user. 5. As part of the transparency requirement, the BN must operate seamlessly with other backbones and local networks.
Stumper
I have run into a problem that has me completely stumped, so I'm tossing it out to NANOG for some help. Before I lay out the specifics, I'm not trying to point fingers at any particular ISP or vendor here, but this problem only exhibits itself in very specific configurations. Unfortunately, the configuration is common enough as to get unwanted attention from the higher-ups. Here's the particulars: Users that have Verizon DSL and a Linksys cable/DSL router have difficulties accessing sites on my network -- whether they are trying with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings seem to be fine. Low latency, no loss. This is true even for access to a server brought up in the DMZ, to keep the firewalls out of the equation. Doing some packet sniffing on the ethernet side of my router, I could see specific http requests never showed up (and the user saw the broken image icon). This was for an mrtg graph page with +/- 30 images. I saw the request for almost all the image files, save for one and the user reported the broken image icon for the one. So this looks and smells like a packet loss issue. but who/where/how? Taking the Linksys out of the pictures (connecting their PC directly to the Verizon DSL modem) makes the problem go away. These same users report no trouble whatsoever accessing many other common sites across the internet. Here's another interesting data point: when one user runs Morpheus (on any machine in his home network) he then has absolutely no problems accessing servers/services on my network. Other users with Linksys routers and, say cable modem, do not have this problem! So I'm looking for some pointers. What could I have done to my edge router (a Cisco 3640 if that helps any) that would make it drop packets from Verizon DSL customers with Linksys routers so long as they aren't running Morpheus? Mark J. Scheller ([EMAIL PROTECTED])
Re: Stumper
MTU
Re: Stumper
Are there sub-1500 byte MTUs anywhere and is one of the devices (Linksys?) dropping the relevant icmp fragments? Morpheus might be working by not having DF bit set.. just a possibility test by removing any filtering of icmp Steve On Tue, 21 Jan 2003, Mark J. Scheller wrote: I have run into a problem that has me completely stumped, so I'm tossing it out to NANOG for some help. Before I lay out the specifics, I'm not trying to point fingers at any particular ISP or vendor here, but this problem only exhibits itself in very specific configurations. Unfortunately, the configuration is common enough as to get unwanted attention from the higher-ups. Here's the particulars: Users that have Verizon DSL and a Linksys cable/DSL router have difficulties accessing sites on my network -- whether they are trying with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings seem to be fine. Low latency, no loss. This is true even for access to a server brought up in the DMZ, to keep the firewalls out of the equation. Doing some packet sniffing on the ethernet side of my router, I could see specific http requests never showed up (and the user saw the broken image icon). This was for an mrtg graph page with +/- 30 images. I saw the request for almost all the image files, save for one and the user reported the broken image icon for the one. So this looks and smells like a packet loss issue. but who/where/how? Taking the Linksys out of the pictures (connecting their PC directly to the Verizon DSL modem) makes the problem go away. These same users report no trouble whatsoever accessing many other common sites across the internet. Here's another interesting data point: when one user runs Morpheus (on any machine in his home network) he then has absolutely no problems accessing servers/services on my network. Other users with Linksys routers and, say cable modem, do not have this problem! So I'm looking for some pointers. What could I have done to my edge router (a Cisco 3640 if that helps any) that would make it drop packets from Verizon DSL customers with Linksys routers so long as they aren't running Morpheus? Mark J. Scheller ([EMAIL PROTECTED])
RE: Stumper
This might be an MTU setting issue. If pppoe, then on my Cisco stuff, an MTU of 1492 (I think that is the right value) seemed to clear things up. Ray Burkholder -Original Message- From: Mark J. Scheller [mailto:[EMAIL PROTECTED]] Sent: January 21, 2003 18:26 To: [EMAIL PROTECTED] Subject: Stumper I have run into a problem that has me completely stumped, so I'm tossing it out to NANOG for some help. Before I lay out the specifics, I'm not trying to point fingers at any particular ISP or vendor here, but this problem only exhibits itself in very specific configurations. Unfortunately, the configuration is common enough as to get unwanted attention from the higher-ups. Here's the particulars: Users that have Verizon DSL and a Linksys cable/DSL router have difficulties accessing sites on my network -- whether they are trying with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings seem to be fine. Low latency, no loss. This is true even for access to a server brought up in the DMZ, to keep the firewalls out of the equation. Doing some packet sniffing on the ethernet side of my router, I could see specific http requests never showed up (and the user saw the broken image icon). This was for an mrtg graph page with +/- 30 images. I saw the request for almost all the image files, save for one and the user reported the broken image icon for the one. So this looks and smells like a packet loss issue. but who/where/how? Taking the Linksys out of the pictures (connecting their PC directly to the Verizon DSL modem) makes the problem go away. These same users report no trouble whatsoever accessing many other common sites across the internet. Here's another interesting data point: when one user runs Morpheus (on any machine in his home network) he then has absolutely no problems accessing servers/services on my network. Other users with Linksys routers and, say cable modem, do not have this problem! So I'm looking for some pointers. What could I have done to my edge router (a Cisco 3640 if that helps any) that would make it drop packets from Verizon DSL customers with Linksys routers so long as they aren't running Morpheus? Mark J. Scheller ([EMAIL PROTECTED])
Re: Stumper
Could this be a packet size issue ? You might try ping -s and see if, say, 1500 byte and 4500 byte packets get through.m On Tuesday, January 21, 2003, at 05:25 PM, Mark J. Scheller wrote: I have run into a problem that has me completely stumped, so I'm tossing it out to NANOG for some help. Before I lay out the specifics, I'm not trying to point fingers at any particular ISP or vendor here, but this problem only exhibits itself in very specific configurations. Unfortunately, the configuration is common enough as to get unwanted attention from the higher-ups. Here's the particulars: Users that have Verizon DSL and a Linksys cable/DSL router have difficulties accessing sites on my network -- whether they are trying with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings seem to be fine. Low latency, no loss. This is true even for access to a server brought up in the DMZ, to keep the firewalls out of the equation. Doing some packet sniffing on the ethernet side of my router, I could see specific http requests never showed up (and the user saw the broken image icon). This was for an mrtg graph page with +/- 30 images. I saw the request for almost all the image files, save for one and the user reported the broken image icon for the one. So this looks and smells like a packet loss issue. but who/where/how? Taking the Linksys out of the pictures (connecting their PC directly to the Verizon DSL modem) makes the problem go away. These same users report no trouble whatsoever accessing many other common sites across the internet. Here's another interesting data point: when one user runs Morpheus (on any machine in his home network) he then has absolutely no problems accessing servers/services on my network. Other users with Linksys routers and, say cable modem, do not have this problem! So I'm looking for some pointers. What could I have done to my edge router (a Cisco 3640 if that helps any) that would make it drop packets from Verizon DSL customers with Linksys routers so long as they aren't running Morpheus? Mark J. Scheller ([EMAIL PROTECTED]) Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
Re: Stumper
The Linksys does have an MTU setting, and I've had my users try some lower settings to see if it made any differences. One user set the MTU on the Linksys as low as 1200 with no noticeable improvement. Anything else I should look at? mS ([EMAIL PROTECTED])
Re: Stumper
On Tue, 21 Jan 2003, Mark J. Scheller wrote: :: Here's the particulars: :: :: Users that have Verizon DSL and a Linksys cable/DSL router have :: difficulties accessing sites on my network -- whether they are trying :: with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings :: seem to be fine. Low latency, no loss. This is true even for access :: to a server brought up in the DMZ, to keep the firewalls out of the :: equation. :: Have the user update their linksys firmware. I see this problem all the time. Linksys soho gateways are notorious for their early firmware not sending fragments with proper headers. Any acl that does not allow *all frags* by default will deny their packets. There may be other issues as well, but the firmware update tends to fix all of the problems. -jba __ [[EMAIL PROTECTED]] :: analogue.networks.nyc :: http://analogue.net
Re: Stumper
If the MTU is not helping then go get the latest firmware. Also you cannot use port forwarding in most linksys routers with DHCP enabled. For those routers you have to set everyone statically and turn of DHCP for port forwarding to work. Mark J. Scheller wrote: The Linksys does have an MTU setting, and I've had my users try some lower settings to see if it made any differences. One user set the MTU on the Linksys as low as 1200 with no noticeable improvement. Anything else I should look at? mS ([EMAIL PROTECTED]) -- May God Bless you and everything you touch. My foundation verse: Isaiah 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
Vadim - the instant someone sues a Provider for sexual harassment from their spam epidemic you will start to see things change. The reason that No-Sane provider will block these ports or services is because they have been listening to their Network Admins too long, and in fact the problem is that they are not sane providers. What they are, and this is pretty much true across the board, is people that just don't care what they do to earn a buck otherwise we would not have these problems, and this is especially true of those Network Operators that push all those billions of bytes of illicit SPAM and throw their hands up and say What do you expect us to do - well the answer is simple. I expect you folks to operate within the law and to cooperate in stopping people who use your services in violation of the laws. And if the providers out there don't like that - then they should find other businesses. Todd Glassey - Original Message - From: Vadim Antonov [EMAIL PROTECTED] To: Avleen Vig [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 7:59 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks? On Mon, 20 Jan 2003, Avleen Vig wrote: On Mon, 20 Jan 2003, Christopher L. Morrow wrote: I was refering specifically to end user workstations. For example home machines on dial up or broadband connections. A lot of broadband providers already prohibit running servers and block certain inbound ports (eg 21 and 80). *shrug* just seems like it would make more sense to block all incoming 'syn' packets. Indeed it does break that. P2P clients: Mostly transfer illegal content. As much as a lot of people love using these, I'm sure most realise they're on borrowed time in their current state. Well, blocking TCP SYNs is not a way to block establishment of sessions between _cooperating_ hosts. Simply make a small hack in TCP stack to leave SYN flag clear, and use some other bit instead. To really block something you need an application proxy... and then there are always ways to subvert those. Elimination of covert channels is one of the hardest problems. In any case, no sane provider will restrict traffic only to applications which can be served by its proxies. Going further, the growing awareness of the importance of security will cause more and more legitimate apps to create totally indiscriminate encrypted traffic... and it is a good idea to routinely encrypt all traffic, to avoid revealing importance of particular communications. Leaving identity of applications (different port #s) in the clear is also a bad idea, security-wise. --vadim
Re: Stumper
MTU on user-end shouldn't really be an issue here.. B/c if so, then (I am only assuming this) how could they access other sites like yahoo.com, etc? I am sure your web site is no different than other common ones. Linksys routers have various issues. The best bet is to go after the firmware and make sure its up-to-date. -- but yet they have no problems accessing other sites?? hmm. This is probably not the cause of the issue but just in case --- You may wanna check to make sure that your server does not have ECN enabled. I've experienced some firewalls/internet sharing devices misbehaving whenever trying to connect to an ECN-enabled server. Again, this is probably not it, but just one of the things to try out, if you run out of other clues... -hc Mark J. Scheller wrote: I have run into a problem that has me completely stumped, so I'm tossing it out to NANOG for some help. Before I lay out the specifics, I'm not trying to point fingers at any particular ISP or vendor here, but this problem only exhibits itself in very specific configurations. Unfortunately, the configuration is common enough as to get unwanted attention from the higher-ups. Here's the particulars: Users that have Verizon DSL and a Linksys cable/DSL router have difficulties accessing sites on my network -- whether they are trying with http, https, smtp, pop3, ssh, ftp, etc., etc. Oh, but pings seem to be fine. Low latency, no loss. This is true even for access to a server brought up in the DMZ, to keep the firewalls out of the equation. Doing some packet sniffing on the ethernet side of my router, I could see specific http requests never showed up (and the user saw the broken image icon). This was for an mrtg graph page with +/- 30 images. I saw the request for almost all the image files, save for one and the user reported the broken image icon for the one. So this looks and smells like a packet loss issue. but who/where/how? Taking the Linksys out of the pictures (connecting their PC directly to the Verizon DSL modem) makes the problem go away. These same users report no trouble whatsoever accessing many other common sites across the internet. Here's another interesting data point: when one user runs Morpheus (on any machine in his home network) he then has absolutely no problems accessing servers/services on my network. Other users with Linksys routers and, say cable modem, do not have this problem! So I'm looking for some pointers. What could I have done to my edge router (a Cisco 3640 if that helps any) that would make it drop packets from Verizon DSL customers with Linksys routers so long as they aren't running Morpheus? Mark J. Scheller ([EMAIL PROTECTED])
