- NANOG - lists.nanog.org

Re: Common Carrier Question
by Fergie 13 Apr '06

13 Apr '06

That is _such_ a red herring. Semantics. ;-) Let's just call it Network Inequity. ;-) - ferg -- "Patrick W. Gilmore" <patrick(a)ianai.net> wrote: On Apr 13, 2006, at 5:57 PM, Eric Germann wrote: > I'm working on a graduate policy paper regarding Internet filtering by > blocking ASN's or IP prefixes. It is a variation of Net > Neutrality, just > by a different name. Except Network Neutrality is about QoS, not filtering. [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Open Letter to D-Link about their NTP vandalism
by Miquel van Smoorenburg 13 Apr '06

13 Apr '06

In article <cistron.Pine.GSO.4.61.0604111656450.15259(a)pants.snark.net>, Matt Ghali <matt(a)snark.net> wrote: >> .or do you think that TCP/IP connection >> should be held open until the message can be scanned for spam and >> viruses just so we can give a 550 MESSAGE REJECTED error instead of >> silently dropping it? > >absolutely. is that actually a problem, today, in 2006? RCPT TO: <user1@domain> RCPT TO: <user2@domain> DATA . .. after content scanning, user1 wants the mail, user2 doesn't. Now what ? Mike.

4 3

Re: Open Letter to D-Link about their NTP vandalism
by Gregory Hicks 13 Apr '06

13 Apr '06

From the BBC "Daily news", Technology section: * Net clocks suffering data deluge * Home hardware maker D-Link has been accused of denting the net's ability to tell the time accurately. Full story: http://news.bbc.co.uk/go/em/-/2/hi/technology/4906138.stm

2 1

Re: Open Letter to D-Link about their NTP vandalism
by Robert Bonomi 13 Apr '06

13 Apr '06

> Date: Tue, 11 Apr 2006 14:29:02 -0400 (EDT) > From: "Michael Froomkin - U.Miami School of Law" <froomkin(a)law.miami.edu> > Cc: nanog(a)nanog.org` > Subject: Re: Open Letter to D-Link about their NTP vandalism > > On Tue, 11 Apr 2006, Alexei Roudnev wrote: > > > > > It's legal to have broken NTP server in ANY country, and it's legal in most > > (by number) countries to send counter-attack (except USA as usual, where > > lawyers want to get their money and so do not allow people to self-defence). > > > > > <law professor> I'd really suggest that readers confirm this claim (that > intentional sending of false data with a malicious purpose is perfectly > acceptable) with a local lawyer before trying it at home or at work.</law > professor> I'll suggest that there are several presumptions in that 'claim' that are not fully supported by the facts of the matter, as previously described. 1) _Who_says_ it is 'false data'? *Who*knows* what that machines is 'supposed' to provide TO WHOM? (The _published_ functionality is to provide time service to queries from a specific address-range. This does *not* place any limits on the 'expected behavior' when queried from _outside_ of that specific address- range.) 2) *Who*says* there is 'malicious intent' involved? I'm going to be travelling 'off network'(with the 'network' being defined as the one where I have published that I'm providing time-server services to), and I happen to have a recurring need for 32-bit units of a specifically transformed out- put of a local hardware-based "/dev/random". So, I put up a server to deliver that data when requested. For reasons of 'convenience' in my programming, I choose to format the queries/responses like a particular 'well known' protocol, and run it on the port associated with that well-known protocol. Do I have any responsibility to 'announce' that I'm doing something like that, for 'private' use? *Am*I*responsible* if 'somebody else', _without_checking_with_me, and =without=asking=my=permission=, queries that machine, and "assumes" that the data that they get back is, in fact, from that 'well known' protocol? In point of fact, if the server in question were located in the United States, there is a colorable argument that can be advanced that the queries originating from outside the address-space for which the owner declared he intended to provide a specified service, constitute a violation of 18 USC 1030 (a) (2) (C). (<http://www.law.cornell.edu/uscode/18/1030.html>, for those who need it :) Note that that section applies _regardless_ of the 'truthfulness'/'accuracy' of the data returned. I submit that; 1) If the query originator is 'entitled' to make assumptions about what the 2) It would seem that the server operator is *equally* 'entitled' to make assumptions about what the query means, and 3) to respond in a manner consistent with _his_ understanding of what the query originater 'wanted'. If the query originator fails to 'get what he wanted', due to his failure to communicate _in_advance_ with the server operator, *WHO* is to blame? Now, if the sever operator publishes that he will provide a certain type of date, in reqponse to a certain type of query, and someone sends that type of query, you do (potentially) have the elements the elements of a contract, and the server operator might be commiting a civil tort *if* the server returns 'something unexpected'. > I also bet that the claim of widespread acceptability would fail badly if > we weigh countries by population. Or even connectivity. > > Not to mention the fact that your packets might stray across borders > sometimes. > There's a _whole_nuther_ can of of worms, as regards "who is responsible" when a device is totally passive until 'directed' to act by an outside party. Is the one that is 'responsible' the one who configured the 'possible' actions of the device, or the one who issued the command to perform one of those actions? Does it matter if, through not bothering to investigate adequately, the command issued does _not_ do what the issuer intended?

11 13

anyone with network/bgp clue @ cogent onlist?
by Drew Weaver 13 Apr '06

13 Apr '06

Please hit me offlist. I've already attempted all regular means of communication. Thanks, Andrew

1 0

Re: How to handle AAAA query for v4 only host
by Owen DeLong 12 Apr '06

12 Apr '06

--On April 13, 2006 8:13:27 AM +0930 Mark Smith <nanog(a)fa1c52f96c54f7450e1ffb215f29991e.nosense.org> wrote: > On Wed, 12 Apr 2006 17:27:54 -0400 > Owen DeLong <owen(a)delong.com> wrote: > >> Apologies if anyone thinks this does not require coordination or is >> somehow not operational. >> >> However, I have a situation where some nameservers for which I am >> responsible >> are receiving AAAA queries for hosts for which we are authoritative. We >> return the SOA only as it seems we are supposed to, but, we are seeing a >> significant delay before we get an A query back from the resolver, which, >> we believe represents a significant delay for the end user in getting to >> the web page in question. >> > > I'd have thought you were supposed to return a record not found error, > which would then cause the remote resolver to immediately revert to > performing an A query. > Strangely enough, RFCs 1866, 3596, and 4074 seem to specifically say this is a bad thing. >> Is there a better way to answer an AAAA query for a v4 only host? Is it >> permitted and/or desirable to return a 6to4 or IPv4-Mapped address? >> Is there some other preferable thing to return? >> > > As long as you don't not respond, like doublelclick don't or didn't > used to. Very frustrating waiting for AAAA queries to timeout before a > page will fully load. Nope... As near as I can tell, responding with SOA only data is the right thing to do. FWIW, that's what f.root-servers.net seems to do as well. Owen

1 0

Re: How to handle AAAA query for v4 only host
by Mark Andrews 12 Apr '06

12 Apr '06

>Apologies if anyone thinks this does not require coordination or is somehow >not operational. > >However, I have a situation where some nameservers for which I am=20 >responsible >are receiving AAAA queries for hosts for which we are authoritative. We >return the SOA only as it seems we are supposed to, but, we are seeing a >significant delay before we get an A query back from the resolver, which, >we believe represents a significant delay for the end user in getting to >the web page in question. Both NAME ERROR and NOERROR NODATA responses can include the SOA record in the authority section (RFC 1034, RFC 2308). You don't give enough information to determine which of the abore responses you are talking about. >Is there a better way to answer an AAAA query for a v4 only host? Is it >permitted and/or desirable to return a 6to4 or IPv4-Mapped address? >Is there some other preferable thing to return? > >Thanks, > >Owen NOERROR NODATA is the correct response. As for why there is a delay between the AAAA and A queries there are lots of possible reason. Non RFC1535 aware resolvers. Not looking for AAAA/A in parallel when walking the search list. Firewalls block EDNS queries so you only see plain DNS queries. Sending NAME ERROR not NOERROR NODATA. Mark

1 0

How to handle AAAA query for v4 only host
by Owen DeLong 12 Apr '06

12 Apr '06

Apologies if anyone thinks this does not require coordination or is somehow not operational. However, I have a situation where some nameservers for which I am responsible are receiving AAAA queries for hosts for which we are authoritative. We return the SOA only as it seems we are supposed to, but, we are seeing a significant delay before we get an A query back from the resolver, which, we believe represents a significant delay for the end user in getting to the web page in question. Is there a better way to answer an AAAA query for a v4 only host? Is it permitted and/or desirable to return a 6to4 or IPv4-Mapped address? Is there some other preferable thing to return? Thanks, Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.

1 0

[non-operational] possible IXP operators BOF in San Jose in June
by Joe Abley 12 Apr '06

12 Apr '06

Hi all, Any IXP operators on this list interested in participating in a BOF at NANOG 37 in San Jose? This would be a get-together for exchange point operators to discuss back-end automation and measurement, switches, etc, not a place for ISPs to discuss peering. If anybody is interested, drop me a note directly, off-list. Thanks! Joe

1 0

Re: Open Letter to D-Link about their NTP vandalism
by Brian Dickson 12 Apr '06

12 Apr '06

Two concrete technical suggestions to mitigate the volunteered NTP server's usage issues at the DIX: (1) Have someone else anycast the DIX block, and NAT the incoming NTP requests to another NTP stratum-1 server (eg pool address(es)). Or a much better idea: (2) Renumber into a new /24, which is announced only at the DIX with no-export, so that only DIX members are able to reach the server - as was the intended usage of this NTP server in the first place. (The announcment can be made by anyone at the DIX, it is not strictly necessary that the NTP server be the announcer of the /24. And in fact, it need not be a /24, as the server should be the only occupant of the block - but it should not be covered by any globally visible aggregate, at least not one contiguous to the connectivity at the DIX.) As to the liability issue, it is easy enough to envision that someone, somewhere, is relying on time results from NTP for a life-or-death application, like a medical device, and is innocently an impacted third party in this. Sending bad NTP values could in theory be responsible for killing someone's scratch monkey... -- Brian Dickson Email: briand(a)chateau-briand.net http://www.chateau-briand.net Tel : +1 647 234 7282

3 2