IIRC, the concept was first introduced by MCI and Enron to great fanfare and subsequent graphic demonstrations of the destructive power of unregulated markets controlled by people of limited moral fortitude.
Owen On May 29, 2012, at 2:50 PM, carl gough [mobsource] wrote: > Thanks Nabil, Bandwidth Trading is not a new concept, but to make it > work effectively it will have to address a couple of prerequisites to be > successful. A network of buyers and sellers has to be created, contracted > and connected for instant pricing, inventory management and delivery of a > defined and standardised service. Not a la enron of course, they traded > derivatives. > > [carl gough] founder and CEO +61 425 266 764 > mobsource .com defined by benefits not by technology > Skype mobsource Follow @mobsource Facebook mobsource > > > > From: Nabil Sharma <nabilsha...@hotmail.com> > Date: Tue, 29 May 2012 14:06:41 +0000 > To: carl gough <c...@mobsource.com>, <nanog@nanog.org> > Subject: RE: NANOG Digest, Vol 52, Issue 67 > > Mr Karl: > > We use number of these service to improve delivery of our content to end > users. > > Which service or services do you seek info for? > > Sincerely, > Nabil > >> Date: Tue, 29 May 2012 22:21:39 +1000 >> Subject: Re: NANOG Digest, Vol 52, Issue 67 >> From: c...@mobsource.com >> To: nanog@nanog.org >> >> Does anyone have any intel on bandwidth trading in the usa? >> >> [carl gough] founder and CEO +61 425 266 764 >> >> mobsource .com defined by benefits not by technology >> Skype mobsource Follow @mobsource Facebook mobsource >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 29/05/12 7:52 PM, "nanog-requ...@nanog.org" <nanog-requ...@nanog.org> >> wrote: >> >>> Send NANOG mailing list submissions to >>> nanog@nanog.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://mailman.nanog.org/mailman/listinfo/nanog >>> or, via email, send a message with subject or body 'help' to >>> nanog-requ...@nanog.org >>> >>> You can reach the person managing the list at >>> nanog-ow...@nanog.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of NANOG digest..." >>> >>> >>> Today's Topics: >>> >>> 1. IPv6 security: New IETF I-Ds, slideware and videos of recent >>> presentations, trainings, etc... (Fernando Gont) >>> 2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) >>> 3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) >>> 4. Re: DNS anycasting - multiple DNS servers on same subnet Vs >>> registrar/registry policies (Jimmy Hess) >>> 5. Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> (bmann...@vacation.karoshi.com) >>> 6. Re: DNS anycasting - multiple DNS servers on same subnet Vs >>> registrar/registry policies (Randy Bush) >>> 7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) >>> 8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert) >>> 9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Mon, 28 May 2012 22:17:33 -0300 >>> From: Fernando Gont <ferna...@gont.com.ar> >>> To: NANOG <nanog@nanog.org> >>> Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent >>> presentations, trainings, etc... >>> Message-ID: <4fc423ad.5000...@gont.com.ar> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Folks, >>> >>> * We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting >>> Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like >>> protection against rogue DHCPv6 servers. The I-D is available at: >>> <http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt> >>> Other IPv6 security I-Ds (such as, >>> draft-ietf-v6ops-ra-guard-implementation) have been revised. Please >>> check them out at: >>> <http://www.si6networks.com/publications/ietf.html> >>> >>> * The slideware (and some videos!) of some of our recent presentations >>> about IPv6 security are now available online. You can find them at: >>> <http://www.si6networks.com/presentations/index.html> >>> >>> * We have also scheduled IPv6 hacking trainings in Paris (France) and >>> Ghent (Belgium). You can find more details at: >>> <http://www.si6networks.com/index.html#conferences> >>> >>> Our Twitter: @SI6Networks >>> ipv6hackers mailing-list: >>> <http://lists.si6networks.com/listinfo/ipv6hackers/> >>> >>> Thanks! >>> >>> Best regards, >>> -- >>> Fernando Gont >>> SI6 Networks >>> e-mail: fg...@si6networks.com >>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>> >>> >>> >>> >>> >>> >>> -- >>> Fernando Gont >>> e-mail: ferna...@gont.com.ar || fg...@si6networks.com >>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Tue, 29 May 2012 12:38:23 +1000 >>> From: Mark Andrews <ma...@isc.org> >>> To: Jay Ashworth <j...@baylink.com> >>> Cc: NANOG <nanog@nanog.org> >>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> Message-ID: <20120529023823.c2b5220fe...@drugs.dv.isc.org> >>> >>> >>> In message >>> <23491623.6382.1338256344974.javamail.r...@benjamin.baylink.com>, Jay >>> Ashworth writ >>> es: >>>> ----- Original Message ----- >>>>> From: "Mark Andrews" <ma...@isc.org> >>>> >>>> [ vix: ] >>>>>>> meanwhile isc continues to push for ubiquitous dnssec, through to >>>>>>> the stub, >>>>>>> to take this issue off the table for all people and all time. >>>>>>> (that's "the >>>>>>> real fix" for nxdomain remapping.) >>>>>> >>>>>> You really believe that the outcome of that will be "we can't make >>>>>> some >>>>>> extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the >>>>>> hell >>>>>> with DNSSEC, then"? >>>>> >>>>> People will route around ISP that do stupid things. They do so >>>>> today. When your browers supports DANE there will be more incentive >>>>> to ensure that DNSSEC does not break and more incentive to route >>>>> around ISP's that do break DNSSEC. >>>> >>>> My personal reaction to that, Mark, is to say that you *badly* >>>> overestimate >>>> the average Internet end-user (who make up, roughly, 80% of the >>>> endpoints, >>>> in my jackleg estimation). >>> >>> Google's recursive nameservers see plenty of traffic. >>> >>>>> Even a ISP that is redirecting on NXDOMAIN wants to be sure that >>>>> it is a real NXDOMAIN not one that is spoofed do the path to the >>>>> ISP's resolver will be DNSSEC clean and they will be validating. >>>> >>>> I'm not sure I understood that... >>> >>> Authoritative server >>> ^ >>> secure >>> (DO=1 queries) >>> v >>> ISP's validating recursive server >>> ^ >>> insecure, redirect possible >>> (DO=0 queries) >>> v >>> Stub clients. >>> >>> Putting it another way, the ISP doesn't want to be fooled even if >>> it is fooling its customers. The ISP can't allow it's recursive >>> servers to get the wrong answers for irs.gov, picking a signed >>> domain, as they would look silly for not validating when there is >>> a simple way for them to be sure that they are not being spoofed. >>> >>>>> Until stub resolvers set DO=1 pretty much ubiquitously this won't >>>>> be a problem for ISP's that want to do nxdomain redirection. There >>>>> still plenty of crappy DNS proxies in CPE routers to be replaced >>>>> before you can just set DO=1 as a default without worrying about >>>>> breaking DNS lookups. Even setting EDNS as a default is a issue. >>>> >>>> ...but that's probably because I don't understand DNSSEC well enough. >>> >>> The ISP <-> stub client path often has a additional piece in the >>> path that is often a heap of steaming !@$! that doesn't do basic >>> DNS let alone EDNS and DNSSEC. For example the Netgear router at >>> home doesn't support DNS over TCP which is basic DNS (I'm using it >>> as a access point not a router because of this). It's this sort >>> of breakage that is stopping OS vendors changing defaults. This >>> can often be bypassed by forcing the resolver to use the ISP's >>> nameservers directly but you need to know to do that. >>> >>> ISP's validating recursive server >>> ^ >>> v >>> CPE Router (broken DNS proxy code) >>> ^ >>> v >>> Stub clients. >>> >>> You can also replace CPE Router with a broken firewall that is a >>> steaming heap of !@#% when it comes to DNS packet inspection. These >>> are harder to bypass and require someone to fix the configuration >>> to replace/upgrade the box. >>> >>>>> That said we are starting down the long path to making it EDNS a >>>>> default. DiG in BIND 9 defaults to using EDNS and "dig +trace" >>>>> turns set DO=1 as well. You don't get things fixed if the breakage >>>>> is not visible. >>>> >>>> We may be talking about different breakage here... >>>> >>>> Cheers, >>>> -- jra >>>> -- >>>> Jay R. Ashworth Baylink >>>> j...@baylink.com >>>> Designer The Things I Think >>>> RFC 2100 >>>> Ashworth & Associates http://baylink.pitas.com 2000 Land >>>> Rover DII >>>> St Petersburg FL USA http://photo.imageinc.us +1 727 >>>> 647 1274 >>>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Tue, 29 May 2012 12:47:10 +1000 >>> From: Mark Andrews <ma...@isc.org> >>> To: Jimmy Hess <mysi...@gmail.com> >>> Cc: NANOG <nanog@nanog.org> >>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> Message-ID: <20120529024710.8971d20fe...@drugs.dv.isc.org> >>> >>> >>> In message >>> <CAAAwwbWRGcGcxhJ7G4XcFTr=6q--eowkbgnoqhwba1o0bb+...@mail.gmail.com> >>> , Jimmy Hess writes: >>>> On 5/28/12, Mark Andrews <ma...@isc.org> wrote: >>>>> Until stub resolvers set DO=1 pretty much ubiquitously this won't >>>>> be a problem for ISP's that want to do nxdomain redirection. There >>>> >>>> Yeah............. >>>> Right now current _server_ implementations don't even have it right, >>>> for properly implementing DNSSEC validation down to that level, let >>>> alone the stubs below the server. >>>> >>>> Many SME LANs utilize Windows-based endpoints, and commonly have >>>> Windows-based DNS servers on the LAN, used by endpoints, where the >>>> Windows DNS servers are set to forward queries to ISP recursive >>>> servers. Current Windows' DNS server in 2008 "supports" DNSSEC. >>>> When Windows DNS server is configured to forward DNS queries to a >>>> list of reasonable recursive DNS servers, the server sets CD (Check >>>> disabled) bit set, and the DO bit set for all queries it sends; >>>> there is no option to "support dnssec queries from smart stubs but >>>> don't send queries from dumb stubs with CD". >>> >>> Well I'm trying to get this fixed at the protocol level for other >>> reasons as explained in >>> http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html >>> >>> draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last >>> call and if you think always setting CD=1 when forwarding is bad for >>> whatever reason I could do with some support. >>> >>>> Also, there are by default no trust anchors, and _Every_ response is >>>> treated as valid. (In other words, CD bit and DO bits are set in >>>> forwarded queries, but no validation occurs). >>>> It's kind of like having a SSL implementation that treats ALL SSL >>>> certificates as valid, until and unless you take manual steps to >>>> configure a CA list. >>>> >>>> If you don't like this default and want to configure Windows DNS with >>>> the root trust anchor.... Sorry, Algorithm #5 RSA/SHA-1 is the only >>>> supported key type, and the current root signing key is not of a >>>> compatible format. >>>> >>>> Your "smart" stub can send a query to this broken DNSSEC >>>> implementation with the DO bit set, for sure. >>>> >>>> >>>> >>>> >>>>> still plenty of crappy DNS proxies in CPE routers to be replaced >>>>> before you can just set DO=1 as a default without worrying about >>>>> breaking DNS lookups. Even setting EDNS as a default is a issue. >>>> [snip] >>>> >>>> I'm all for smart stubs as long as (1) They can get the data to them >>>> (2) They can get the proper logging/reporting to them, E.g. No >>>> "silent" upstream validate/discard; No upstream silent "ignore >>>> the stub's requested CD bit and validate/discard anyways" >>>> and >>>> >>>> (3) The validation path is intact for _dumb_ non-validating stubs too. >>>> >>>> -- >>>> -JH >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Mon, 28 May 2012 23:58:00 -0500 >>> From: Jimmy Hess <mysi...@gmail.com> >>> To: David Conrad <d...@virtualized.org> >>> Cc: NANOG Mailing List <nanog@nanog.org> >>> Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs >>> registrar/registry policies >>> Message-ID: >>> <CAAAwwbX8h=3mbuwvo3bpvijqndmmcrrzmnxi5xf5vicc2qd...@mail.gmail.com> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> On 5/28/12, David Conrad <d...@virtualized.org> wrote: >>>> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote: >>>>> I know few registry/registrars >>>>> which do not accept both (or all) name servers of domain name on same >>>>> subnet. They demand at least 1 DNS server should be on different >>>>> subnet for >>>>> failover reasons (old thoughts). >>>> IMHO appropriately so. The fact that anycast allows for multiple >>>> (potentially) geographically distributed machines to respond to DNS >>>> queries >>>> does not remove the value of having multiple prefixes for DNS servers. >>> [snip] >>> It dramatically reduces the value, and meets the basic RFC requirement >>> for geographically distributed DNS servers, although there are still >>> routing issues that will impact all DNS servers to share a prefix >>> It is more important that a domain registrar not refuse to register a >>> domain, or erroneously declare a valid listing invalid. >>> >>> The purpose of using a registrar is to establish DNS delegation, not >>> to validate your site's redundancy meets the absolute best possible >>> practices for fault tolerance. >>> >>> Ideally certainly should have DNS servers under multiple prefixes -- >>> and it seems a little bit silly to go through all the trouble of >>> implementing a complicated anycast geo. dist scheme, while ignoring >>> a simpler failure mode. It's your choice. >>> >>> It's not appropriately so for a registrar to say anything your choice; >>> thats your network >>> not theirs. By the same token the registrar can't tell you not to >>> alias all 3 IP addresses on >>> different subnets to the same physical server. >>> >>> Again, it's ill-advised, but a "mistake" that has nothing to do with >>> the registrar's network or the registration service. >>> >>> -- >>> -JH >>> >>> >>> >>> ------------------------------ >>> >>> Message: 5 >>> Date: Tue, 29 May 2012 05:59:19 +0000 >>> From: bmann...@vacation.karoshi.com >>> To: Mark Andrews <ma...@isc.org> >>> Cc: NANOG <nanog@nanog.org> >>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> Message-ID: <20120529055919.ga23...@vacation.karoshi.com.> >>> Content-Type: text/plain; charset=us-ascii >>> >>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >>>> >>>> Putting it another way, the ISP doesn't want to be fooled even if >>>> it is fooling its customers. >>> >>> don't lie to us, but we lie to our customers. >>> >>> and you don't see a problem with this? >>> >>> /bill >>> >>> >>> >>> ------------------------------ >>> >>> Message: 6 >>> Date: Tue, 29 May 2012 15:13:33 +0900 >>> From: Randy Bush <ra...@psg.com> >>> To: Jimmy Hess <mysi...@gmail.com> >>> Cc: North American Network Operators' Group <nanog@nanog.org> >>> Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs >>> registrar/registry policies >>> Message-ID: <m2txyzikfm.wl%ra...@psg.com> >>> Content-Type: text/plain; charset=US-ASCII >>> >>>> It is more important that a domain registrar not refuse to register a >>>> domain, or erroneously declare a valid listing invalid. >>>> >>>> The purpose of using a registrar is to establish DNS delegation, not >>>> to validate your site's redundancy meets the absolute best possible >>>> practices for fault tolerance. >>> >>> just for my curiosity, where do you draw the line for technical >>> compliance? do the servers need to serve the zone? does the served >>> zone need to have the same NS RRset as the request and hence parent? >>> do the servers need to be able to answer compliant dns queries? over >>> tcp too? >>> >>> your first paragraph quoted above would seem to say that none of this is >>> needed. the registrar's job is to stick the delegation in the parent >>> zone and actually functioning name service be damned. >>> >>> randy, a naggumite >>> >>> >>> >>> ------------------------------ >>> >>> Message: 7 >>> Date: Tue, 29 May 2012 16:37:29 +1000 >>> From: Mark Andrews <ma...@isc.org> >>> To: bmann...@vacation.karoshi.com >>> Cc: NANOG <nanog@nanog.org> >>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> Message-ID: <20120529063731.686622106...@drugs.dv.isc.org> >>> >>> >>> In message <20120529055919.ga23...@vacation.karoshi.com.>, >>> bmann...@vacation.ka >>> roshi.com writes: >>>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >>>>> >>>>> Putting it another way, the ISP doesn't want to be fooled even if >>>>> it is fooling its customers. >>>> >>>> don't lie to us, but we lie to our customers. >>>> >>>> and you don't see a problem with this? >>> >>> I didn't say I like it. It may even be illegal in some juristictions >>> for a ISP to do it without properly informing the customer and >>> allowing them to opt in/out. Doing it to yourself however can't >>> be illegal. In the end it is a tool and the method of deployment >>> is often as important as whether you deploy it or not. >>> >>> It's a little like direct marketing via email. If you have consent >>> of the party being emailed it isn't spam. If you don't have consent >>> it is spam at least here in Australia. Other juristictions have >>> looser guidelines. >>> >>> Mark >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> >>> >>> ------------------------------ >>> >>> Message: 8 >>> Date: Mon, 28 May 2012 23:42:14 -0700 >>> From: George Herbert <george.herb...@gmail.com> >>> To: "bmann...@vacation.karoshi.com" <bmann...@vacation.karoshi.com> >>> Cc: NANOG <nanog@nanog.org> >>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> Message-ID: <2a84793d-5d89-4f4e-adc0-6cb578ad1...@gmail.com> >>> Content-Type: text/plain; charset=us-ascii >>> >>> >>> >>> >>> >>> On May 28, 2012, at 22:59, bmann...@vacation.karoshi.com wrote: >>> >>>> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >>>>> >>>>> Putting it another way, the ISP doesn't want to be fooled even if >>>>> it is fooling its customers. >>>> >>>> don't lie to us, but we lie to our customers. >>>> >>>> and you don't see a problem with this? >>>> >>>> /bill >>> >>> We tried saying no, we tried walking customers away, we tried not adding >>> the feature, we tried shame, someone reputedly had dolls with pins in >>> them. >>> >>> We lost. >>> >>> There is an endgame around that; when it's ready.... >>> >>> >>> George William Herbert >>> Sent from my iPhone >>> >>> >>> ------------------------------ >>> >>> Message: 9 >>> Date: Tue, 29 May 2012 10:51:54 +0100 >>> From: Tony Finch <d...@dotat.at> >>> To: Randy Bush <ra...@psg.com> >>> Cc: North American Network Operators' Group <nanog@nanog.org> >>> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >>> Message-ID: >>> <alpine.lsu.2.00.1205291050540.5...@hermes-2.csi.cam.ac.uk> >>> Content-Type: TEXT/PLAIN; charset=US-ASCII >>> >>> Randy Bush <ra...@psg.com> wrote: >>>> >>>>> When your browers supports DANE >>>> >>>> and a billion home nats support dnssec :( >>> >>> I expect there will be a depressingly large amount of DNS-over-TLS in the >>> future in order to bypass broken ALGs. >>> >>> Tony. >>> -- >>> f.anthony.n.finch <d...@dotat.at> http://dotat.at/ >>> Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate, >>> occasionally very poor. >>> >>> >>> >>> End of NANOG Digest, Vol 52, Issue 67 >>> ************************************* >> >> >> > >
