Re: {SPAM?} Re: IPv6 Deployment for the LAN
The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Adrian Chadd adr...@creative.net.au wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? I'm not exactly a specialist for wireless, but as far as I remember my lectures the 802.11 has additional MAC fields for the wireless source/destination. Stations always send to the AP, the AP retransmits it to the station. IIRC WPA/WPA2 even has some protection against stations forging the AP MAC with the shared group key, but I don't remember any details. Bernhard
need your suggestion about switch
Hi I am requested to get not brand list switch how can I test it? any software or methods eg: reliable speed or any need Thank you so much
Re: Human Factors and Accident reduction/mitigation
On Nov 6, 2009, at 12:04 PM, JC Dill wrote: Owen DeLong wrote: We could learn a lot about this from Aviation. Nowhere in human history has more research, care, training, and discipline been applied to accident prevention, mitigation, and analysis as in aviation. A few examples: NTSB investigations of EVERY US aircraft accident and published findings. Ask any commercial pilot (and especially a commercial commuter flight pilot) what they think of NTSB investigations when the pilot had a bad schedule that doesn't allow enough time for adequate sleep. They will point out that lack of sleep can't be determined in an autopsy. As a point of information, I _AM_ a commercial pilot. The NTSB routinely puts an accident down to pilot error even when pilots who regularly fly those routes and shifts are convinced that exhaustion (lack of sleep, long working days) was clearly involved. And for even worse news - the smaller the plane the more complicated it is to fly and the LESS rest the pilots receive in their overnight stays because commuter airlines are covered under part 135 while major airlines are covered under part 121. My ex flew turbo-prop planes for American Eagle (American Airlines commuter flights). It was common to have the pilot get off duty near 10 pm and be requited to report back at 6 am. That's just 8 hours for rest. The rest period starts with a wait for a shuttle to the hotel, then the drive to the hotel (often 15 minutes or more from the airport) then check-in - it can add up to 30-45 minutes before the pilot is actually inside a hotel room. These overnight stays are in smaller towns like Santa Rosa, Fresno, Bakersfield, etc. Usually the pilots are put up at hotels that don't have a restaurant open this late, and no neighboring restaurants (even fast food) so the pilot doesn't get dinner. (There is no time for dinner in the flight schedule - they get at most 20 minutes of free time between arrival and take- off - enough time to get a bio-break and hit a vending machine but not enough time to actually get a meal.) Take a shower, get to bed at about 11:30. Set the alarm for 4:45 am and catch the shuttle back to the airport at 5:15 to get there before the 6:00 reporting time. In that 8 hour rest period you get less than 6 hours of sleep - if you can fall asleep easily in a strange hotel. Flying in such a state of exhaustion is, whether you like it or not, a form of pilot error. A pilot who chooses to fly on such a schedule is making an error in judgment. Sure, there are all kinds of pressures and employment issues that need to be resolved to reduce and eliminate that pressure, and, I support the idea of updating the crew duty time regulations with that in mind. That does not change the fact that FAR 91.3 still applies: Sec. 91.3 Responsibility and authority of the pilot in command. (a) The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft. (b) In an in-flight emergency requiring immediate action, the pilot in command may deviate from any rule of this part to the extent required to meet that emergency. (c) Each pilot in command who deviates from a rule under paragraph (b) of this section shall, upon the request of the Administrator, send a written report of that deviation to the Administrator. A failure to declare him/herself to be incapable of safely completing the flight is a failure to meet the requirements of 91.3(a). Commuter route pilots have been fighting to get regulations changed to require longer overnight periods, and especially to get the required rest period changed to behind the door so that the airlines can't include the commute time to/from the airport in the rest period. This would force the airlines to select hotels closer to the airport or else allow longer overnight layovers - either way the pilots would get adequate rest. See: http://asrs.arc.nasa.gov/publications/directline/dl5_one.htm And that would be a good change. In part, that change is supported by the number of times that the NTSB has made statments such as: We find the probable cause of the accident was pilot error. We believe that fatigue was likely a factor in the accident. The NTSB does a great job with mechanical issues and with training issues, but they totally miss the boat when it comes to regulating adequate rest periods in the airline schedules. No, you miss the boat on the relationship between the stakeholders. The NTSB has repeatedly commented on the need for better regulations and better studies of crew duty time requirements and fatigue as a factor in accidents and incidents. However, the NTSB CANNOT change regulations. They investigate accidents and make recommendations to the regulatory agencies. The FAA needs to be the one to change the regulations. The FAA has not
Re: need your suggestion about switch
On 07/11/2009 18:21, Deric Kwok wrote: Hi I am requested to get not brand list switch how can I test it? any software or methods eg: reliable speed or any need Thank you so much Hi, Can you please make sentences that make sense ? Are you seeking for advice or help ? I think yes. So the least you can do is ease the pain of people reading your emails. Thanks
Re: {SPAM?} Re: IPv6 Deployment for the LAN
And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
Re: need your suggestion about switch
What I am gathering is that you are looking to by a off brand switch? If this is the case, then I would argue reliability and speed aren't important to you, but rather price, so go for what you can afford I guess. If you lack the knowledge to purchase a switch or test it properly, I would hire a professional services company that can do this for you and stand by their product/decisions. Of course, that would be expensive, and sort of goes against buying a cheap switch in the first place. Most vendors that you should be shopping in the first place, publish data on their switches that is a decent guide to performance at a distance. Just make sure your comparing apples to apples (packet sizes, features, etc). There are also some independent tests you can find such as miercom. Brian On Nov 7, 2009, at 12:21 PM, Deric Kwok wrote: Hi I am requested to get not brand list switch how can I test it? any software or methods eg: reliable speed or any need Thank you so much
Re: Human Factors and Accident reduction/mitigation
Owen DeLong wrote: On Nov 6, 2009, at 12:04 PM, JC Dill wrote: Owen DeLong wrote: We could learn a lot about this from Aviation. Nowhere in human history has more research, care, training, and discipline been applied to accident prevention, mitigation, and analysis as in aviation. A few examples: NTSB investigations of EVERY US aircraft accident and published findings. Ask any commercial pilot (and especially a commercial commuter flight pilot) what they think of NTSB investigations when the pilot had a bad schedule that doesn't allow enough time for adequate sleep. They will point out that lack of sleep can't be determined in an autopsy. As a point of information, I _AM_ a commercial pilot. There are commercial pilots who fly for a living, and there are those who have the certification but who don't fly for a living. Do you regularly fly for a commercial airline where your schedule is determined by the airline's needs, part 135 or part 121 rules, union rules, etc. with no ability to modify your work schedule to allow for adequate rest? The NTSB routinely puts an accident down to pilot error even when pilots who regularly fly those routes and shifts are convinced that exhaustion (lack of sleep, long working days) was clearly involved. And for even worse news - the smaller the plane the more complicated it is to fly and the LESS rest the pilots receive in their overnight stays because commuter airlines are covered under part 135 while major airlines are covered under part 121. My ex flew turbo-prop planes for American Eagle (American Airlines commuter flights). It was common to have the pilot get off duty near 10 pm and be requited to report back at 6 am. That's just 8 hours for rest. The rest period starts with a wait for a shuttle to the hotel, then the drive to the hotel (often 15 minutes or more from the airport) then check-in - it can add up to 30-45 minutes before the pilot is actually inside a hotel room. These overnight stays are in smaller towns like Santa Rosa, Fresno, Bakersfield, etc. Usually the pilots are put up at hotels that don't have a restaurant open this late, and no neighboring restaurants (even fast food) so the pilot doesn't get dinner. (There is no time for dinner in the flight schedule - they get at most 20 minutes of free time between arrival and take-off - enough time to get a bio-break and hit a vending machine but not enough time to actually get a meal.) Take a shower, get to bed at about 11:30. Set the alarm for 4:45 am and catch the shuttle back to the airport at 5:15 to get there before the 6:00 reporting time. In that 8 hour rest period you get less than 6 hours of sleep - if you can fall asleep easily in a strange hotel. Flying in such a state of exhaustion is, whether you like it or not, a form of pilot error. There is no other effective option. Almost all the commuter airline schedules have these short overnights, and it's impossible for most pilots to avoid being scheduled to fly them. If you bid for these schedules you are expected to fly them. You can't just decide at 11:30 pm that you need more than 5 hour's rest and that you won't be getting up at 4:30 am to get to the airport by your 6:00 am report time, or decide when your alarm wakes you at 4:30 that you are too tired and are going to get another 2 hours sleep, or decide at 7 pm that you are too exhausted from flying this schedule for 2 days and are not going to fly your last leg. If you do this *even once* you will get in very hot water with the company and if you do it repeatedly you will ultimately lose your job. They aren't going to change the schedule because it's legal under part 135. A pilot who chooses to fly on such a schedule is making an error in judgment. Sure, there are all kinds of pressures and employment issues that need to be resolved to reduce and eliminate that pressure, Right now there is no way to avoid putting your job in jeopardy by refusing to fly these unsafe schedules. and, I support the idea of updating the crew duty time regulations with that in mind. That does not change the fact that FAR 91.3 still applies: The airlines don't care. They draw up these unsafe schedules and expect pilots to magically be capable of flying them safely. If there's an accident it goes down as pilot error, but if you try to claim exhaustion and refuse to fly citing 91.3 on a repeated basis you WILL be fired. Catch 22. Sounds a lot like working in IT with clueless management, doesn't it? To bring this back to NANOG territory, how many times have you or one of your network admins made a mistake when working with inadequate sleep - due to extra early start hours (needless 8 am meetings), or working long/late hours, or being called to work in the middle of the night? Sure, this happens, but, it's not the only thing that happens. Finally, having lived with a commercial aviation pilot for 5
RE: Pros and Cons of Cloud Computing in dealing with DDoS
-Original Message- From: Florian Weimer [mailto:fwei...@bfk.de] Sent: Friday, November 06, 2009 4:52 AM To: Stefan Fouant Cc: 'Jeffrey Lyon'; 'NANOG list' Subject: Re: Pros and Cons of Cloud Computing in dealing with DDoS Some companies have already suffered from this because they completely outsourced their authoritative DNS service to dedicated DNS service providers. Only very few customers of those providers were attacked, but the impact was felt across larger parts of their customer base. Been there, done that. I used to work for Ultra. 'Nuff said ;) Stefan Fouant GPG Key ID: 0xB5E3803D
RE: Pros and Cons of Cloud Computing in dealing with DDoS
-Original Message- From: Florian Weimer [mailto:fwei...@bfk.de] Sent: Friday, November 06, 2009 4:55 AM Not all attacks involve saturated pipes. There used to be anti-DDoS vendors whose boxes didn't even have WAN links. Part of the problem is that operating systems come with TCP stacks and web servers which are not very robust, so it's pretty easy to create something which behaves spectacularly better under certain attacks. I am in complete agreement with you here. And I don't think the things I've said are generally inconsistent with the views held by others. The original point I was trying to make before the discussion got so eloquently hijacked towards a discussion on flooding and its impact on availability is that with regards to cloud computing, if the discussion hasn't shifted from that of DDoS to EDoS, it should. Just take one look at Amazon's usage-based pricing model, and one can envision that a surplus of resources could actually be just as bad as a lack thereof. How long do you think it will take for the bad guys to realize that they don't need to cause an outage to cause havoc to the victim. A slow trickle of seemingly legitimate requests from just a few thousand hosts performed over several days or weeks might give some organizations pause and that $50k extortion might start looking pretty enticing. I second Roland's comments with regard to the CIA triad, and his opinion that availability of resources is the first among equals is spot on. But I'm willing to bet that if the attackers exploit the so-called elasticity of the cloud and the subsequent associated financial costs, integrity is going to take on a whole new level of importance. BTW, heuristic/behavioral based analysis has benefit here, it just needs to start happening on more granular level... Getting back to the original discussion, I'd still like to hear what some of you think are the Pros vs. the Cons of Cloud Computing in dealing with this situation. We've heard a few and now I'd like to hear what others have to say. BTW, I realize this is a sensitive subject and I can understand why some of you might not want to respond on-list (security through obscurity eh' ;). To those of you who have taken the time to respond to me off-list, I appreciate your feedback and promise to keep your identities confidential. Regards, Stefan Fouant GPG Key ID: 0xB5E3803D
RE: need your suggestion about switch
-Original Message- From: Brian Feeny [mailto:bfe...@mac.com] Sent: Saturday, November 07, 2009 1:37 PM (packet sizes, features, etc). There are also some independent tests you can find such as miercom. Come on... I don't know if I'd use Miercom and independent in the same sentence? More like guns for hire. I've rarely seen a test report they came out with that wasn't commissioned by a particular vendor with the testing done in such a way as to slant the results in their favor. Stefan Fouant GPG Key ID: 0xB5E3803D
Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver. Owen DeLong wrote: And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
RE: {SPAM?} Re: IPv6 Deployment for the LAN
Device driver? Nah.
Just use a tool (like Scapy) to just arbitrarily, easily custom-craft any
packet he|she wants ... Yes, it is that easy.
Thanks!
/TJ
-Original Message-
From: Richard Bennett [mailto:rich...@bennett.com]
Sent: Saturday, November 07, 2009 15:37
To: Owen DeLong
Cc: Bernhard Schmidt; nanog@nanog.org
Subject: Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver.
Owen DeLong wrote:
And of course, a rogue RA station would _NEVER_ mess with that bit
in what it transmits...
Uh, yeah.
Owen
On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:
The Wi-Fi MAC protocol has a pair of header bits that mean from AP
and to AP. In ad-hoc mode, a designated station acts as an AP, so
that's nothing special. There are a couple of non-AP modes for direct
link exchanges and peer-to-peer exchances that probably don't set
from
AP but I'm not sure about that.
Adrian Chadd wrote:
On Sat, Nov 07, 2009, Bernhard Schmidt wrote:
As already said, wireless in infrastructure mode (with access points)
always sends traffic between clients through the access point, so a
decent AP can filter this.
How does the client determine that the traffic came from the AP versus
another client?
Adrian
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
Re: Interesting Point of view - Russian police and RIPE accused of aiding RBN
Hello, Jeffery and other NANOC members. Sorry for making another thread - I'm not too experienced in mailgroups. The problem is in structure of new generation advert or banner networks - they allow to return other subject traffic to the partner's URL. And this could also be used to redirect the traffic to different exploits (a simple way to compromise a banner network or hosting provider). This is extremely hard to monitor or to take preventive measures in case of a large banner or advert network. Unfortunately Google doesn't provide a detailed report on their check results: this could allow the resource's owner easily block their partners in that case. Anyway I'll contact the owner of this resource (91.202.63.96) now in order to perform a check of their partners. I suppose, just having a few domains would be enough. The other resource is situated on the public ip of our reseller - I'll ask him to check this domain, too. Thank you for that information, I'll report on that issue later. Kanak Akrino Support Team 2009/11/7 Jeffrey Lyon jeffrey.l...@blacklotus.net Kanak, Can you please detail your plans to correct the malware issues on your network? (reference: http://google.com/safebrowsing/diagnostic?site=AS:44571 ). Best regards, Jeff [offlist communication snipped for privacy] Kanak Akrino Abuse Team -- Jeffrey Lyon, Leadership Team jeffrey.l...@blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to protect your booty.
Re: Speed Testing and Throughput testing
Date: Mon, 2 Nov 2009 18:22:19 -0500 From: Jon Meek mee...@gmail.com I use iperf with packet capture on both sides, then analyze the packet capture for per-second throughput and re-transmits. I usually do 10 TCP streams for 30 seconds. Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is needed to deal with the bandwidth delay product. It is also possible that Ethernet drivers will have an effect. Local testing of the pair of test machines should be done if you can't get to about 980 Mbps on a Gig link (keeping in mind the comment about TCP tuning as latency increases). Jon On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach mark.urb...@pnpt.com wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? I'll also suggest http://fasterdata.es.net as a resource for network tuning. Tuning TCP is hard. UDP is simple, but some things can even impact UDP. Many less than obvious things can have a huge impact on high-speed data transfer. The choice of congestion algorithms can be very significant. As anyone who has used bittorrent should have noticed, having multiple TCP streams works better than a single stream. An oddity we have noted is that some routers will process switch layer 2 traffic if a layer 3 interface exists on the port even if it is unconfigured and unused. Man, that kills performance, even in low latency situations! FWIW, we use mostly iperf, but may be biased as the iperf maintainer works here. We did start using iperf before we hired him, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Pros and Cons of Cloud Computing in dealing with DDoS
On Nov 8, 2009, at 2:33 AM, Stefan Fouant wrote: if the discussion hasn't shifted from that of DDoS to EDoS, it should. All DDoS is 'EDoS' - it's a distinction without a difference, IMHO. DDoS costs opex, can cost direct revenue, can induce capex spends - it's all about economics at bottom, always has been, or nobody would care in the first place. And look at click-fraud attacks in which the miscreants either a) are committing fraud by causing botnets to make fake clicks so that they can be paid for same or b) wish to exhaust a rival's advertising budget when he's paying per-impression. Plain old packet-flooding DDoSes can cost victims/unwitting sources big money in transit costs, can cost SPs in transit and/or violating peering agreements, etc. There's no need or justification for a separate term; Chris Hoff bounced 'EDoS' around earlier this year, and the same arguments apply. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
