trading bandwidth

Lorell Hathcock lorell at hathcock.org
Tue May 29 22:10:38 UTC 2012


If you ever want a run down on how Enron did it (or didn't do it), there are
several on this list who can tell you all about it.

-----Original Message-----
From: carl gough [mobsource] [mailto:carl at mobsource.com] 
Sent: Tuesday, May 29, 2012 4:50 PM
To: Nabil Sharma; nanog at nanog.org
Subject: trading bandwidth

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 <nabilsharma at hotmail.com>
Date:  Tue, 29 May 2012 14:06:41 +0000
To:  carl gough <carl at mobsource.com>, <nanog at 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: carl at mobsource.com
> To: nanog at 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-request at nanog.org" 
> <nanog-request at nanog.org>
> wrote:
> 
> >Send NANOG mailing list submissions to  nanog at 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-request at nanog.org
> >
> >You can reach the person managing the list at  nanog-owner at 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.
> >      (bmanning at 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 <fernando at gont.com.ar>
> >To: NANOG <nanog at nanog.org>
> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent  
> >presentations, trainings, etc...
> >Message-ID: <4FC423AD.5000703 at 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: fgont at si6networks.com
> >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >
> >
> >--
> >Fernando Gont
> >e-mail: fernando at gont.com.ar || fgont at 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 <marka at isc.org>
> >To: Jay Ashworth <jra at baylink.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
> >
> >
> >In message
> ><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay 
> >Ashworth writ
> >es:
> >> ----- Original Message -----
> >> > From: "Mark Andrews" <marka at 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
> >>jra at 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: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 3
> >Date: Tue, 29 May 2012 12:47:10 +1000
> >From: Mark Andrews <marka at isc.org>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
> >
> >
> >In message
> ><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
> >, Jimmy Hess writes:
> >> On 5/28/12, Mark Andrews <marka at 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: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 28 May 2012 23:58:00 -0500
> >From: Jimmy Hess <mysidia at gmail.com>
> >To: David Conrad <drc at virtualized.org>
> >Cc: NANOG Mailing List <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs  
> >registrar/registry policies
> >Message-ID:
> > <CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
> >Content-Type: text/plain; charset=ISO-8859-1
> >
> >On 5/28/12, David Conrad <drc at 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: bmanning at vacation.karoshi.com
> >To: Mark Andrews <marka at isc.org>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529055919.GA23179 at 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 <randy at psg.com>
> >To: Jimmy Hess <mysidia at gmail.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs  
> >registrar/registry policies
> >Message-ID: <m2txyzikfm.wl%randy at 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 <marka at isc.org>
> >To: bmanning at vacation.karoshi.com
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
> >
> >
> >In message <20120529055919.GA23179 at vacation.karoshi.com.>,
> >bmanning at 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: marka at isc.org
> >
> >
> >
> >------------------------------
> >
> >Message: 8
> >Date: Mon, 28 May 2012 23:42:14 -0700
> >From: George Herbert <george.herbert at gmail.com>
> >To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
> >Cc: NANOG <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> >
> >On May 28, 2012, at 22:59, bmanning at 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 <dot at dotat.at>
> >To: Randy Bush <randy at psg.com>
> >Cc: North American Network Operators' Group <nanog at nanog.org>
> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> >Message-ID:
> > <alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >Randy Bush <randy at 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  <dot at 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
> >*************************************
> 
> 
> 
       






More information about the NANOG mailing list