trading bandwidth
carl gough [mobsource]
carl at mobsource.com
Tue May 29 21:50:07 UTC 2012
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