RE: trading bandwidth

["Lorell Hathcock" <lorell () hathcock org>]

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 () mobsource com] 
Sent: Tuesday, May 29, 2012 4:50 PM
To: Nabil Sharma; nanog () 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 () hotmail com>
Date:  Tue, 29 May 2012 14:06:41 +0000
To:  carl gough <carl () 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: carl () 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-request () nanog org" 
> <nanog-request () 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-request () nanog org
> >
> > You can reach the person managing the list at  nanog-owner () 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 () 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 () 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.5000703 () 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 () si6networks com
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> >
> >
> > --
> > Fernando Gont
> > e-mail: fernando () gont com ar || fgont () 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 () isc org>
> > To: Jay Ashworth <jra () baylink com>
> > Cc: NANOG <nanog () nanog org>
> > Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> > Message-ID: <20120529023823.C2B5220FE5A8 () drugs dv isc org>
> >
> >
> > In message
> > <23491623.6382.1338256344974.JavaMail.root () benjamin baylink com>, Jay 
> > Ashworth writ
> > es:
> > > ----- Original Message -----
> > > > From: "Mark Andrews" <marka () 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 () 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 () isc org
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 29 May 2012 12:47:10 +1000
> > From: Mark Andrews <marka () isc org>
> > To: Jimmy Hess <mysidia () gmail com>
> > Cc: NANOG <nanog () nanog org>
> > Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> > Message-ID: <20120529024710.8971D20FE6A0 () drugs dv isc org>
> >
> >
> > In message
> > <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg () mail gmail com>
> > , Jimmy Hess writes:
> > > On 5/28/12, Mark Andrews <marka () 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 () isc org
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Mon, 28 May 2012 23:58:00 -0500
> > From: Jimmy Hess <mysidia () gmail com>
> > To: David Conrad <drc () 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=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ () mail gmail com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On 5/28/12, David Conrad <drc () 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 () vacation karoshi com
> > To: Mark Andrews <marka () isc org>
> > Cc: NANOG <nanog () nanog org>
> > Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> > Message-ID: <20120529055919.GA23179 () 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 () psg com>
> > To: Jimmy Hess <mysidia () 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%randy () 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 () isc org>
> > To: bmanning () vacation karoshi com
> > Cc: NANOG <nanog () nanog org>
> > Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> > Message-ID: <20120529063731.686622106AEB () drugs dv isc org>
> >
> >
> > In message <20120529055919.GA23179 () vacation karoshi com.>,
> > bmanning () 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 () isc org
> >
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Mon, 28 May 2012 23:42:14 -0700
> > From: George Herbert <george.herbert () gmail com>
> > To: "bmanning () vacation karoshi com" <bmanning () vacation karoshi com>
> > Cc: NANOG <nanog () nanog org>
> > Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
> > Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 () gmail com>
> > Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> >
> > On May 28, 2012, at 22:59, bmanning () 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 () dotat at>
> > To: Randy Bush <randy () 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.5807 () hermes-2 csi cam ac uk>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> > Randy Bush <randy () 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 () 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
> > *************************************