RE: Stumper
Linksys has frequent releases and I had the opportunity to stumble several times into firmware versions where some special applications (e.g. X-Window session over IPSec) wouldn't work. Turned out, they were playing with the MTU. Two releases further on, it would work, then again not etc. I would rather try to solve the problem on the server side (make sure your server sends out unfragmented smaller packets). /Martin This is a private statement and does not necessarily reflect the opinion of my employer... -Original Message- From: jeffrey.arnold [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 2:36 PM To: Mark J. Scheller Cc: [EMAIL PROTECTED] Subject: 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
Earthquake Mag: 7.6 - 2003/01/21 20:07 - Epicenter: Costa Colima Mexico
Found at... http://www.ssn.unam.mx/ ...which is now somewhat overrun! Nothing yet at... http://neic.usgs.gov/neis/current/m_america.html Martin
Re: FW: Re: Is there a line of defense against Distributed Reflective attacks?
Vadim - the newest form of SPAM uses the Messenger facility to place a pop-up in the middle of your screen without any email, pop, smtp or other service being involved. I apologize for the tone of the first posting, but I still stand by it. When ISP's are held accountable for what people do with the BW they sell them, then these issues will all be moot. Until then, the lie is that there is no way to stop these behaviors and its the one the ISP's proffer exclusively. Todd - Original Message - From: "Vadim Antonov" <[EMAIL PROTECTED]> To: "todd glassey" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, January 21, 2003 5:51 PM Subject: Re: FW: Re: Is there a line of defense against Distributed Reflective attacks? > > On Tue, 21 Jan 2003, todd glassey wrote: > > > 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, > > We were talking about P2P, not spam. P2P participants _want_ to talk to > each other, unlike spammer and his victims. ISPs already agressively > fight spammers by termninating their service completely - no port blocking > or lawsuits are needed. > > Blocking ports is not going to prevent communication between parties which > wish to communicate. And carriage of bits is about an order of magintude > bigger economically than the whole entertaintment industry. RIAA already > was stupid enough to make enemies of telcos (with that Verizon lawsut). > > The tech industry was bending themselves over to court Hollywood because > the common wisdom was that the content is going to be what people will pay > for. Wrong. Content-based dotcoms died, and people still pay for > Internet connectivity, in ever-increasing numbers. And spend more and > more time in front of computers instead of TVs. Simply because live > people on the other end of the wire are infinitely more interesting than > the prechewed corporate crud called "content". > > So I think we'll see some fireworks on the legal front, but the outcome is > already clear - unfiltered connectivity is what consumers wish to pay for, > not the sanitized disneys. > > --vadim >
Re: FW: Re: Is there a line of defense against Distributed Reflectiveattacks?
On Tue, 21 Jan 2003, todd glassey wrote: > 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, We were talking about P2P, not spam. P2P participants _want_ to talk to each other, unlike spammer and his victims. ISPs already agressively fight spammers by termninating their service completely - no port blocking or lawsuits are needed. Blocking ports is not going to prevent communication between parties which wish to communicate. And carriage of bits is about an order of magintude bigger economically than the whole entertaintment industry. RIAA already was stupid enough to make enemies of telcos (with that Verizon lawsut). The tech industry was bending themselves over to court Hollywood because the common wisdom was that the content is going to be what people will pay for. Wrong. Content-based dotcoms died, and people still pay for Internet connectivity, in ever-increasing numbers. And spend more and more time in front of computers instead of TVs. Simply because live people on the other end of the wire are infinitely more interesting than the prechewed corporate crud called "content". So I think we'll see some fireworks on the legal front, but the outcome is already clear - unfiltered connectivity is what consumers wish to pay for, not the sanitized disneys. --vadim
Re: Stumper
On Tue, Jan 21, 2003 at 08:06:07PM -0500, hc wrote: > > 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. Well, you're forgetting that odd things tend to happen if MTU on one side of the connection doesn't agree with the other side of the link. (MTU is not a function of the transmitter or the receiver but, rather, a function of the link you're operating on.) We all know what kind of screwy things can happen when they disagree. (Try holding a BGP link up over a connection where they differ... t'ain't easy.) One other possibility here: I once had to deal with a problem where a particular link would receive and send data, apparently, just fine. There were errors counting up one one end, yes, but slowly enough that it didn't seem to indicate a real source of a problem. Well, DNS queries would go out just fine but the responses never made it back over this link. As I said, once connected via IP instead of domain name, everything seemed to progress just fine. After much head scratching and a complete visual inspection of every device in the circuit, turns out that two pieces of gear in the middle were misoptioned. Very weird but it did happen. Not that I suspect that to be the problem here (I'm firmly in the MTU court on this one until evidence shows otherwise) but it is a possibility.. -Wayne
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])
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 the PC's -Original Message- From: Mark J. Scheller [mailto:[EMAIL PROTECTED]] Sent: 2003-01-21, Tuesday 5:45 PM To: [EMAIL PROTECTED] Subject: 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: > 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. If you're using path MTU discovery (in other words, sending out packets with the DF bit set), it works like this: The host on each end of the connection has an MTU configured in its TCP stack, so on initial connection (generally with very small syn/ack packets), the packet size gets negotiated and set to the lower of those two numbers. If all the router interfaces in between have an MTU equal or greater than the MTU that gets negotiated between the hosts, packets will continue to flow at that size without incident. In general, when you're dealing with two ethernet connected hosts with MTUs of 1500 bytes, and a bunch of routers in between with MTUs of greater than 1500, this is what happens. However, if there's a network link in the path with an MTU smaller than the MTUs of the two end devices, the large packets sent by the end devices won't be able to pass through that link. Instead, the router with the small MTU link sends an ICMP response back to the sending host, requesting smaller packets. The sending host retries with progressively smaller packets until arriving at a size that works. Therefore, I think the scenario that people are describing here is this: The user's computer is talking to the Linksys across a regular ethernet with an MTU of 1500. The host on your network probably also has an MTU of 1500. The Linksys is talking to the DSL provider via PPPoE, and thus has an MTU of 1492. The connection starts out with an initial MTU of 1500 in each direction, but 1500 byte packets can't pass through the 1492 byte MTU of the connection between the Linksys and the DSL provider. Therefore, the devices on the two ends of that link would be sending back ICMP messages requesting smaller packets. If all ICMP were being blocked somewhere, those ICMP messages wouldn't arrive, and the host that wasn't receiving them would keep obliviously sending out 1500 byte packets until the connection timed out. But, if you were plugging the client computers directly into the DSL line and running PPPoE on them, you'd have the 1492 byte MTU negotiated from the start and everything would work. In this scenario, decreasing the Linksys's MTU wouldn't help you, because the problem would already be that the MTU on the Linksys was smaller than the MTU on the end points. Decreasing the MTU on the end points would help. What would help even more would be fixing the ICMP filtering. Now that I've said all that, this scenario doesn't really fit what you're seeing. You said your packet sniffer showed no packets coming across, but TCP connections don't generally start out with 1500 byte packets. In general, when you see an path MTU discovery issue, you see the connection being successfully opened, small packets (containing such small bits of data as "GET /") flowing freely, and then the connection freezing when a big burst of data gets sent for the first time. Since that's not what you're seeing here, I'm more inclined to agree with those who have suggested upgrading the Linksys's firmware. I don't have any experience with that -- The Linksys NAT box on my home network works fine and I haven't had any reason to mess with it -- but it does seem like a far more plausible explanation for what you're seeing. -Steve Steve Gibbard [EMAIL PROTECTED] +1 510 528-1263 http://www.gibbard.org/~scg
Re: Stumper
This would depend upon the direction of the packets that are dropped and where the broken device is. If the 1500 byte packets are coming in from the Internet and the Linksys needs to forward onto a smaller MTU media but finds the DF bit set it will return an icmp fragment.. if this icmp is then dropped back at the client then you'll see what you describe. If the Linksys or device infront of it will allow remove the DF bit from inbound packets. Steve On Tue, 21 Jan 2003, 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]) > > >
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: 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
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
Definitely sounds like an MTU problem. I have seen IPSEC break across Verizon DSL with a Linksys router until the MTU on the ?PCs?" where dropped to just under 1500 bytes to allow for the IPSEC header. DJ > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Mark J. Scheller > Sent: Tuesday, January 21, 2003 5:26 PM > 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
Most DSL providers want an MTU of 1492..also there are some issues with older firmwares and some DSL providers. You may want to also check for an updated firmware on the Linksys site. Ray Burkholder wrote: 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]) -- 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: 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
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
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
MTU
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: 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. > > > > > > >
Re: [spamtools] Tracking a DDOS
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] wrote: : So did you aquire those "assets" from clearblue or where the appliedtheory's : assets kindof devided between fastnet and clearblue? And if undertand it : correctly apliedtheory name & domain are still with clearblue/navisite? : If so is it the same for CRL? : I'm primarily just curious in terms of finding out what happened to : earliest companies that made internet - CRL being one of the first : commercial isp... FastNet purchased the access business from AppliedTheory, and Clearblue got the hosting. In terms of abuse, [EMAIL PROTECTED] can be used for fastnet and appliedtheory space also. I just supped with Mr. Abuse @netaxs last Saturday night, and he can resolve or forward internally anything for appliedtheory/fastnet/netaxs/etc customers. Thanks, Avi
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.
The Awards: Best network service provider security architecture
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: 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: 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: .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: .gov whois server down
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: TTM use in North America
Josh, others, > I am interested in hearing how/if TTM (Test Traffic Measurements) is > currently being used in North American networks. At the moment, there are 8 sites participating in the measurements and a 9th ordered its test-box this morning. The 8 boxes are located in Palo Alto, Denver (2), Chicago, Fermilab (near Chicago), Austin, Washington DC and Ann Arbor. The 9th box will be installed in the Bay area as well. Besides that, 3 big ISP's have shown interest in deploying boxes for 2 different projects, this would involve something between 5 and 15 boxes all over the US. > Practical experiences, gotcha's, The biggest problem so-far was the installation of the GPS antenna. In order for GPS to work, it requires a view of the sky, preferably from the outside of the building. That is not always possible in the US, with its buildings where windows cannot open and PoP's are frequently located in the basements of buildings. This problem has now been solved. We now support CDMA based clocks units that use the carrier signal from CDMA based cell-phones. These units work inside buildings, everywhere where a cell-phone works. Geographic coverage of the USA is about 99%. Installation costs of these units are 0. > value proposition, support, etc.. would be of interest. We recently did a user survey of TTM and our customers rated both value for money and support as excellent. Henk Uijterwaal Project manager for TTM -- Henk Uijterwaal Email: [EMAIL PROTECTED] RIPE Network Coordination CentreWWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB AmsterdamFax: +31.20.5354445 The NetherlandsThe Netherlands Mobile: +31.6.55861746 -- That problem that we weren't having yesterday, is it better? (Big ISP NOC)
.gov whois server down
It looks like it's broken.. I called their helpdesk and they're looking into it. Len
