May 2003 - Test - lists.nanog.org

Club-Internet/T-Online France
by Dan Hollis 15 May '03

15 May '03

Anyone have a clueful abuse contact at Club-Internet/T-Online France? The abusedroids there apparently dont believe they are responsible for the 212.194.0.0 - 212.194.191.255 netblock. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

2 1

Is latency equivalent to RTT?
by Michael.Dillon＠radianz.com 14 May '03

14 May '03

Has it become common usage to define latency in an IP network as the round trip time in that network? I've always considered latency to be a one-way measure of delay and RTT to be the sum of the latencies in both directions. When I tried to find something to back up this view, I discovered that a number of companies define latency as equivalent to RTT in their SLAs. Assuming that one has measuring devices in every PoP, do you think it is harder to measure a full matrix of one way latency compared to measuring a full matrix of RTT? Does it even make sense to measure a full matrix of RTT when the measurement of A to B to A should be equivalent to the measurement of B to A to B? --Michael Dillon

6 5

Clocking Sources (was NTp sources that work in a datacenter (was Re: Is latency equivalentto RTT?))
by Spinka, Kristofer 14 May '03

14 May '03

The actual clock source, the time pulses, produced by BITS (Building Integrated Timing Systems) are not usually just a "re-feed" of the GPS source. Instead, contained within the clock system, BITS device, is some sort of highly resolvable, measurable, predictable, stable, oscillator such as Cesium, Rubidium or Quartz, depending on your budget. The GPS signal, being transmitted from orbiting Cesium clocks, is used to "discipline" or prevent your local oscillator drift from degrading your time code. This basically means that if the oscillator installed in the unit is supposed to oscillate exactly 10,255,432 times per second, and an interal or external condition has now caused it to oscillate at 10,255,434 times per second, your pulse generator will account for this and keep your time code stable. These GPS satellites have Cesium oscillators that drift also, and are in turn disciplined themselves against the "USNO Master Clock", which is an average time code calculated from a slew of cesium atomic and hydrogen maser clocks. So, why can't an entire bulding share the same GPS discipline source? It would save some roof space and money. If you are worried about someone kicking the antenna over, just make sure that your oscillator is reasonable enough to maintain your necessary accuracy without external discipline while they glue the antenna back on. For most applications a high quality, stable quartz based oscillator will be more than sufficient and is the least expensive. If you need to get fancy, and depending on your internal and external condition variables, the general rule is: Quartz < Rubidium < Cesium. /kristofer

1 0

Re: Is latency equivalent to RTT?
by Michael.Dillon＠radianz.com 14 May '03

14 May '03

>> Assuming that one has measuring devices in every PoP, do you think it is >> harder to measure a full matrix of one way latency compared to measuring a >> full matrix of RTT? >Your problem with 1-way is finding a way to do it thats reliable, for rtt ping >is about as simple as you can get and works a treat but for 1-way you have to be >a bit more creative.... I assume that it's fairly common for people to have Solaris or Linux boxes in every PoP to do measurements. In that case, the difficulty isn't in measuring one-way latency, it's in synchronizing the time on all the servers. And with fairly cheap GPS and CDMA clocks that is a lot easier/cheaper than it once was. I really think that there are a lot of people out there who do not understand that RTT is not the same thing as two times the one-way latency. In other words if you measure (A-to-B + B-to-A) / 2 then you have failed to learn anything about one-way latency on either path A-to-B or B-to-A. Yet that's precisely what people are doing when they measure RTT and then assume that RTT/2 is equal to the one-way latency A-to-B. --Michael Dillon

10 10

MFN fiber cut (Boston)?
by Scott Francis 14 May '03

14 May '03

I've been hearing things from various different folks around the Net (Hosting.com/ALGX) about a fiber cut in Boston yesterday (which may or may not be related to some kind of issue with an MFN/Above.net gateway - traces die at 208.185.139.1). Unfortunately, that is about as much information as I have, and I thought it odd that I hadn't heard anything here about it already (Sean is usually quicker on the fiber news than any other media outlet I know of :)). Anybody else have details, or am I hallucinating again? -- Scott Francis || darkuncle (at) darkuncle (dot) net illum oportet crescere me autem minui

2 1

Re: NTp sources that work in a datacenter (was Re: Is latency equivalent to RTT?)
by Steven M. Bellovin 14 May '03

14 May '03

In message <Pine.LNX.4.44.0305140802170.7544-100000(a)twin.uoregon.edu>, Joel Jae ggli writes: > > >Also if you just need a high level of syncronization between the time on >all your hosts you can just deploy one standalone ntp server, sync it >against public time sources and get everything synced against that. its >probably a 95% solution to most people's timeing needs. > If I recall correctly, NTP assumes that latency = RTT/2. You might make it work well for his application *if* you set up your tree so that your paths are each one hop, or at least symmetric over your network. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

3 2

Re: Fwd: Club-Internet/T-Online France
by Dan Hollis 14 May '03

14 May '03

On Tue, 13 May 2003, Thomas Kuiper wrote: > Well, what kind of abuse? > The whole 212.194.0.0/16 is customer ADSL access > and abuse(a)club-internet.fr works very well. No, it doesn't. The abuse(a)club-internet.fr denied that 212.194.0.0/16 belongs to them, and they told me to "talk to the real provider, not club-internet.fr". -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

4 5

Detection and preferential dropping of high bandwidth unresponsive flows
by Sean Donelan 14 May '03

14 May '03

The IEEE international conference on communications this week has several technical papers of interest to network security, although the most relevant weren't labeled network security. Detection and Preferential Dropping of High Bandwidth Unresponsive Flows by Chatranon, Labrador and Banerjee. Controlling Malicious Sources at Internet gateways by Chhabra, Joh, Saran and Shorey. But there are still issues about loading the bottleneck with even more processing during periods of extreme stress, handling distributed management domains, and handling distributed attacks. Scale affects everything on the Internet, including the response.

1 0

RE: Using Policy Routing to stop DoS attacks
by Christopher L. Morrow 14 May '03

14 May '03

On Wed, 14 May 2003, Lars Higham wrote: > Well, this is also from the docs: > > Unicast reverse path-forwarding (uRPF) check is a tool to reduce > forwarding of IP packets that may be spoofing an address. A uRPF check > performs a route table lookup on an IP packet's source address, and > checks the incoming interface. The router determines whether the packet > is arriving from a path that the sender would use to reach the > destination. If the packet is from a valid path, the router forwards the > packet to the destination address. If it is not from a valid path, the > router discards the packet. uRPF is supported for both Internet Protocol > Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) protocol > families. > > Do you have more specific questions about the implementation? The original question was along the lines of: "On a cisco the blackholed SOURCE address will get dumped in uRPF, is that possible on the Juniper also?" > > Regards, > Lars > > -----Original Message----- > From: Christopher L. Morrow [mailto:chris@UU.NET] > Sent: Wednesday, May 14, 2003 9:37 AM > To: Lars Higham > Cc: 'Stefan Mink'; 'Haesu'; jtk(a)aharp.is-net.depaul.edu; nanog(a)merit.edu > Subject: RE: Using Policy Routing to stop DoS attacks > > > > > On Wed, 14 May 2003, Lars Higham wrote: > > > Sorry, > > > > I misunderstood the earlier question - > > > > >From the docs: > > To enable unicast RPF check, include the unicast-reverse-path > > statement at the [edit routing-options forwarding-table] hierarchy > > level: [edit] routing-options { > > forwarding-table{ > > unicast-reverse-path (active-paths | feasible-paths); > > } > > } > > > > yes, the config bits are on the website.... BUT, not the details of the > implementation :) So, does uRPF on a juniper work the same as the > cisco?? > :) > > > Regards, > > Lars Higham > > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf > > Of Christopher L. Morrow > > Sent: Tuesday, May 13, 2003 2:00 AM > > To: Stefan Mink > > Cc: Haesu; jtk(a)aharp.is-net.depaul.edu; nanog(a)merit.edu > > Subject: Re: Using Policy Routing to stop DoS attacks > > > > > > > > > > On Mon, 12 May 2003, Stefan Mink wrote: > > > > > On Tue, Mar 25, 2003 at 04:58:59PM +0000, Christopher L. Morrow > > > wrote: > > > > you could hold blackhole routes for these destinations in your > > > > route > > table > > > > (local or bgp) So long as the destination for the source is bad > > (null for > > > > instance) the traffic would get dropped. I believe the proper > > > > terms > > from > > > > cisco for this are: "So long as the adjacency is invalid" ... > > > > > > is there a way to make this source-blackhole-routing work on J's too > > > > (does this work with discard-routes too)? > > > > > > > I believe someone from Juniper should likely answer this question :) > > As I understand the setup from a Cisco perspective (and someone from > > Cisco can > > correct me if I get it wrong). uRPF works in such a way that if the > > source > > address's destination has an invalid FIB entry (or no entry, or Null0) > > the > > packets are dropped. > > > > Perhaps Juniper implemented it this way? I have not checked anymore > > closely than this. Sorry. :( > > >

1 0

RE: Using Policy Routing to stop DoS attacks
by Christopher L. Morrow 14 May '03

14 May '03

On Wed, 14 May 2003, Lars Higham wrote: > Sorry, > > I misunderstood the earlier question - > > >From the docs: > To enable unicast RPF check, include the unicast-reverse-path statement > at the [edit routing-options forwarding-table] hierarchy level: > [edit] routing-options { > forwarding-table{ > unicast-reverse-path (active-paths | feasible-paths); > } > } > yes, the config bits are on the website.... BUT, not the details of the implementation :) So, does uRPF on a juniper work the same as the cisco?? :) > Regards, > Lars Higham > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Christopher L. Morrow > Sent: Tuesday, May 13, 2003 2:00 AM > To: Stefan Mink > Cc: Haesu; jtk(a)aharp.is-net.depaul.edu; nanog(a)merit.edu > Subject: Re: Using Policy Routing to stop DoS attacks > > > > > On Mon, 12 May 2003, Stefan Mink wrote: > > > On Tue, Mar 25, 2003 at 04:58:59PM +0000, Christopher L. Morrow wrote: > > > you could hold blackhole routes for these destinations in your route > table > > > (local or bgp) So long as the destination for the source is bad > (null for > > > instance) the traffic would get dropped. I believe the proper terms > from > > > cisco for this are: "So long as the adjacency is invalid" ... > > > > is there a way to make this source-blackhole-routing work > > on J's too (does this work with discard-routes too)? > > > > I believe someone from Juniper should likely answer this question :) As > I > understand the setup from a Cisco perspective (and someone from Cisco > can > correct me if I get it wrong). uRPF works in such a way that if the > source > address's destination has an invalid FIB entry (or no entry, or Null0) > the > packets are dropped. > > Perhaps Juniper implemented it this way? I have not checked anymore > closely than this. Sorry. :( >

1 0