Re: [homenet] [Cake] [Cerowrt-devel] althea presentation on isp in a box at nanog 76

[Toke Høiland-Jørgensen]

Maciej Sołtysiak  writes:

>> https://www.youtube.com/watch?v=G4EKbgShyLw
>>
>> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new
>> metric that allows for cryptocurrency traffic billing.
> Very refreshing, would love to see that succeed and then get popular in 
> Europe too!
>
> On Getting Started Page [1] they suggest TP Link C7 for CPEs. Is that
> still one of the best suited home routers for getting make-wifi-fast
> and bufferbloat-combat in?

Yeah, if your link speed is within its capabilities. It can shape up to
~250 Mbps I think...

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] -CoDel

[Toke Høiland-Jørgensen]

"David R. Oran"  writes:

> On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote:
>
>> Juliusz Chroboczek  writes:
>>
>>>> PIE [...] lends itself better for implementation in existing 
>>>> hardware,
>>>> or hardware with small modification.
>>>
>>> Could one of you please explain why?
>>
>> With the caveat that I have never worked with any of this hardware, 
>> this
>> is my understanding:
>>
>> Basically, you can re-use the drop mechanism from RED and use the PIE
>> algorithm as a (better) way to control the setpoints. This makes it
>> possible to retrofit it in existing hardware. In fact I believe you 
>> can
>> implement PIE entirely in the (software) control plane on (a lot of)
>> gear that already knows how to do RED.
>>
> Another factor, which as I recall was perhaps the strongest of the
> original motivations for PIE, is that PIE does nearly all its work on
> enqueue, whereas CoDel does most of its work on dequeue. In many
> hardware interfaces, especially at a head end where there are lots of
> queues and a simple hardware FIFO feeding the link, it turns out to be
> difficult/expensive to insert the computations CoDel does on each
> dequeue operation.

Ah, I see. I guess that makes sense. Although I have also seen someone
implement CoDel in a "virtual queueing" setting where all computation is
done on enqueue and the sojourn time is simulated ahead of time. You
can't do this in all scenarios, but probably in more than one might
think... Obviously it would require a bit of work to go from the spec
(or reference implementation) to that, but it's definitely possible.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>> PIE [...] lends itself better for implementation in existing hardware,
>> or hardware with small modification.
>
> Could one of you please explain why?

With the caveat that I have never worked with any of this hardware, this
is my understanding:

Basically, you can re-use the drop mechanism from RED and use the PIE
algorithm as a (better) way to control the setpoints. This makes it
possible to retrofit it in existing hardware. In fact I believe you can
implement PIE entirely in the (software) control plane on (a lot of)
gear that already knows how to do RED.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote:
>
>> You're right that packet accelerators complicate things a bit. I'm not 
>> entirely convinced that the "doesn't lend itself to FQ-CoDel and the 
>> rest of the mechanisms the bufferbloat movement has gravitated towards" 
>> actually *has* to be true, but it's harder to do a proof of concept 
>> since the barrier to entry for hardware development is higher. So I 
>> doubt anything is likely to happen here unless someone with the 
>> resources to do hardware development steps up.
>
> The people with hardware experience want to do PIE, because it lends
> itself better for implementation in existing hardware, or hardware
> with small modification.
>
> Sometimes it's better to accept non-perfect more easily implementable
> solutions that solves most of the problem space, instead of aiming for
> the "perfect one" and getting nothing.

Absolutely, I'm all for that. But even something that is as
retrofitable[0] as PIE is not getting implemented... So then what to do?
This makes it difficult to motivate spending more resources on doing
more work in this area... :/

-Toke

[0] "Retrofitable" is totally a word...

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote:
>
>> Since you seem to be pretty up to date on the ISP-level CPE offerings, 
>> just out of curiosity: Do any of these fancy ARM boxes include actual 
>> fixes for bufferbloat? :)
>
> Short answer, no.
>
> Bufferbloat isn't on the radar of any product managers I have talked
> to. Cable Labs is the only organisation that seems to do anything
> about this that I have seen.

Right, yeah, that's what I thought. :/

> I have made statements previously in that context of most newer higer
> end devices having packet accelerators which doesn't lend itself to
> FQ_CODEL and the rest of the mechanisms the bufferbloat movement has
> gravitated towards, but I still feel what I said wasn't really
> accepted and "taken in".

Well, for my part I have mentally filed this under "vendors don't care",
which has been my impression the whole time (with a few exceptions).
It's terribly frustrating, but it's not like there's anything I can
really do about it, so I've more or less resigned myself to this.

You're right that packet accelerators complicate things a bit. I'm not
entirely convinced that the "doesn't lend itself to FQ-CoDel and the
rest of the mechanisms the bufferbloat movement has gravitated towards"
actually *has* to be true, but it's harder to do a proof of concept
since the barrier to entry for hardware development is higher. So I
doubt anything is likely to happen here unless someone with the
resources to do hardware development steps up.

But anyway, thanks for confirming by suspicions :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> I suppose a point to be investigated is that however roaming happens,
> unless all packets are flooded to all links, the layer 2 switch always
> triggers a routing change, whether at layer 2 or layer 3.
>
> So it might be worth doing an analysis of the pros and cons of L2 versus L3
> roaming. I know Dave Täht has looked into doing it at L3 at the host, but
> that isn’t practical and is in any case out of scope for homenet. What is
> easier if it’s done at L2?  At L3?

Yeah; off the top of my head: getting the address to distribute is
easier at L2 (it's built in to the WiFi handshake), and there's only one
of them; but distributing it (them) once you know it may be easier (or
more efficient) at L3. Assuming you already have a decent layer 3
routing protocol available, of course (which is why it makes sense to
solve it in a homenet context) :)

L3 also has the advantage that it can aggregate lots of host routes into
a covering prefix, so fewer routes when no one is roaming; but when
clients do roam, you mostly have to announce host routes anyway, so in
the worst case we get back to "one route per address"... A longer
analysis would probably be needed to assess performance in the worst
case.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet market gap analysis...

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> I especially agree with the statement on wifi roaming between APs does
> require shared L2, and there has been discussions about this and how
> to solve that, and I think it's a requirement for homenet to become a
> useful solution in that space. This would probably require some kind
> of tunneling or vlan encapsuatlion between homenet devices to be
> controlled somehow. There are routing protocols out there that already
> do this, can perhaps be used as inspiration.

You don't actually need encapsulation or VLANs if all access points
participate in the routing protocol. You can just announce routes for
each of the clients' IP addresses on roaming. You'll need some mechanism
for discovering those IP addresses of course; one option is something
like l3roamd[0] (which more or less just sniffs the addresses used by
the client), but others are certainly possible. I remember discussing
other approaches with Juliusz at some point, but I guess none of us ever
got around to implementing something.

Either way, I guess this is something homenet could conceivably specify
a solution for if there was sufficient interest... :)

-Toke

[0] https://github.com/freifunk-gluon/l3roamd

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Fri, 1 Mar 2019, Michael Richardson wrote:
>
>> For the last 10 to 15 years the ISP-provided home router has come to
>> dominate the market, with the belief by the ISPs that this is a MUST
>> that they control the device. Many (but not all) at the IETF do not
>> share this view, but most non-technical users see the ISP provided
>> router is simply saving the trip to BestBuy, rather than an
>> abdication of control over their home. If this trend continues, then
>> I believe that ISPs (residential IAPs) will come to want to control
>> all IoT devices in the home -- because security -- telling
>> residential customers what they can and not connect.
>
> I have data from some ISPs here pointing to 1% of the customers
> setting the media converter/router into bridge mode and providing
> their own HGW. Most people just keep whatever the ISP provided them
> with. Looking at the SSIDs I see, typically people don't even change
> the SSIDs/passwords from what came out of the box.
>
> A multi-router home isn't on the product managers radar. Their biggest
> issue right now, is customers complaining about bad service and most
> of the time this is related to bad wifi for the last 0-30 meters of
> access to the end-user device.
>
> If HOMENET somehow could help solve that problem (diagnosing bad wifi
> and helping the ISP/customer figure out what's wrong and what needs to
> be done) then HOMENET might get onto the radar and be of interest.
>
> The good thing is that the HGW is going from an unloved cost-cut
> necessity into a more important device that is a lot higher end
> device. It's gone from a 2-4MB flash / 16 MB RAM device, to nowadays
> often having 128-512MB RAM and 32-128MB flash (or even more). It now
> also is more likely to have aN ARM processor which is several times
> faster than the devices of 5-10 years ago. A negative though, is that
> it's also very likely to contain a packet accelerator that is quite
> constrained in what it can and can't do acceleration of. This might
> make some use-cases harder to achieve. Speeds have gone up and
> nowadays having 4x4 wifi chips in there that'll in practice support
> actual transport payload speeds of upwards of 1 gigabit/s on wifi
> isn't uncommon. We're also now seeing devices with even higher port
> speeds than 1GE, but that might take a bit longer to reach wider
> adoption.

Since you seem to be pretty up to date on the ISP-level CPE offerings,
just out of curiosity: Do any of these fancy ARM boxes include actual
fixes for bufferbloat? :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>> Why? What is wrong with the owner of the network selecting which devices
>> / services he/she wants globally reachable
>
> I don't think this is about global reachability (which is hopefully
> managed by PCP), it's about exporting names into the global DNS. We
> ought to distinguish the two -- you can be remotely reachable without
> publishing your name in the DNS.

Fair enough.

>> without each device/service having to implement (and be configured for)
>> an external naming provider?
>
> Roughly 100% of Homenet devices don't need a name in the global DNS --
> neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything
> else that normal people run in their home relies on the DNS for
> locating remote peers.

Well, those all work because they use a "giant MITM in the cloud"
rendezvous point. If publishing things into global DNS worked reliably
and automatically, and we had IPv6 everywhere, such designs would not be
needed...

> In the rare case where a device needs to be in the global DNS (and the
> only case I can see is that of a web server), I'd much rather
> configure that on the device itself than on the buggy web interface of
> my ISP-provided CPE (or, even worse, "in the cloud").

Right, I can certainly see where you're coming from with this :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

> Exporting names from the Homenet into the global namespace, on the
> other hand, should be done by the hosts, with no involvement of any
> third party (neither the ISP nor the Homenet itself). This is where I
> argue for some form of end-to-end, secured, dynamic DNS update.

Why? What is wrong with the owner of the network selecting which devices
/ services he/she wants globally reachable without each device/service
having to implement (and be configured for) an external naming provider?

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>> we are writing a standards document, not a 19th century romance novel
>
> It is a truth generally acknowledged that a single man in possession of
> a good fortune must be in want of a home network.

Ah yes, much better. I for one believe it prudent to adopt this style
for all homenet documents, lest we risk being relegated to the obscurity
of the cold and corporate world of yesteryear ;)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>>> This is not the notion that I tried to express, probably badly.  It's not
>>> necessarily the important feature, it's the one that will make people
>>> implement and deploy the protocol stack in the first place.
>
>> Suggestion for '"killer feature" of Homenet': driver for using Homenet
>
> That's good.
>
>>> If you find a sufficiently stately term that covers all of the above,
>>> I'll take it.  (My thesaurus suggests "chieftain", but I tend to favour
>>> "foreman".)
>
>> Suggestion for "our bosses": decision makers
>
> "easy to explain to the decision makers"?  It's okay, but sounds somewhat
> cold and corporate to my (admittedly foreign) ears.  I'll wait a little
> while in case somebody has a better idea.

"masters"
"liege lords"
"jarls"
"overseers"
"(robot) overlords"
"decision-making units"
"callers of shots"
"head honchos"


(As you can see, I tried and failed to come up with something better;
I'd tend to agree that "decision makers" is a bit cold and corporate,
but then we are writing a standards document, not a 19th century romance
novel...)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet "no host changes" assumption and DNS

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> I think that what you are proposing here is great, except that I don't
> think we actually _need_ to go out of charter on this.   I think that
> what Toke has been advocating can be worked into the framework you are
> describing, so that you and I! get what we want, and Toke gets what he
> wants.

Yeah, I think so too. I.e., we can create a framework that will work for
existing hosts and still provide the information for more capable hosts
to do their thing.

Whether these more capable hosts will actually end up performing better
is another matter; but I guess we'll see about that... ;)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> El 16 ag 2017, a les 9:40, Ted Lemon  va escriure:
>> Ah, if this is your concern, I think that's answered by the whitelisting 
>> stuff I was talking about earlier.   But in this case you really do need to 
>> have separate caches per PvD, and the MPvD-aware clients on the net need to 
>> be able to use them.   We could say that this is optional to support, 
>> though, and so if you want to pay for one router with this feature, that 
>> router's resolver can be advertised in the PvD-aware path.
>
> BTW, I think we have probably carried this discussion as far as is
> useful until a new rev of the draft is done. Daniel is working on a
> new draft, he said, and when he's done his bit I'll do a pass as well
> and try to capture the changes we've discussed here, and then we can
> iterate again. :)

Yup, fine with me :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
>> Ted Lemon <mel...@fugue.com <mailto:mel...@fugue.com>> writes:
>> 
>>> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen <t...@toke.dk> va 
>>> escriure:
>>>>> In both of these cases, you are better off doing what we discussed
>>>>> earlier and setting up your own DNS cache, possibly with a whitelist
>>>>> for domains you want to send to the ISP forwarder.
>>>> 
>>>> Sure, and that's what I usually do. But if we can't specify that
>>>> behaviour for homenet, at least trying all upstream DNS servers gives a
>>>> better chance of finding one that works.
>>> 
>>> I'm really sorry, but I'm actually having trouble contextualizing the
>>> failure mode that you are talking about here.   Didn't I agree with
>>> you in a previous message that we should try all the upstream DNS
>>> servers?
>> 
>> Hmm, right, I guess you did. My point was more that an MPvD-aware client
>> that only uses on PvD may experience worse performance than one that
>> uses the in-home resolver. But I guess the client should be smart
>> enough to deal with that?
>
> I think this is a real edge case. You have two connections, the DNS
> server on one of them is broken, the DNS server on the other is not,
> but the second connection performs so much worse than the first that
> you'd rather use an answer from the DNS server on the second to
> contact a service on the first.

Well, it's quite clear from this discussion that we have different ideas
about how likely this is. I think we'll just have to agree to disagree
on that, for now at least...

> If you were in an engineering staff meeting trying to justify adding
> extra code to do this, what would you have to say to get the group to
> agree to do the work? What would that code look like?

Ah, but I'm not arguing for adding code, I'm arguing that we should
remove some :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ralf Weber <d...@fl1ger.de> writes:

> Moin!
>
> On 15 Aug 2017, at 21:38, Toke Høiland-Jørgensen wrote:
>> Ted Lemon <mel...@fugue.com> writes:
>>> I think we are wandering off into nonsense territory here.   Have you
>>> observed this sort of problem in the field?   If so, can you describe
>>> what happened?   If not, why would we optimize for it?
>>
>> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
>> more fortunate with your ISPs than me. And that's before even going into
>> the DNS censorship issue; in my part of the world ISP DNS servers are
>> broken *by design*.
> And we wonder why there is no ISP/operator participation in the IETF...
> Your email address indicates you live in Denmark. I personally know people
> at ISPs in Denmark who run DNS resolvers for their customers and I in a
> previous job ran DNS servers for customers in Denmark, although the actual
> servers where located in Sweden and Germany. I can assure you that neither
> I nor my colleagues design DNS servers to be broken. If you have an issue
> with your ISP open a ticket with them and if they can't fix it switch ISPs.
> But don't blame all the ISPs to deliver broken service, without
> evidence.

Ah, I wasn't trying to imply that ISPs deliberately design sub-par
services just to annoy their customers; sorry if it came across that
way. My "broken by design" comment was referring specifically to
DNS-based censorship [1].

-Toke

[1] https://en.wikipedia.org/wiki/Censorship_in_denmark#Internet_censorship

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
>>> In both of these cases, you are better off doing what we discussed
>>> earlier and setting up your own DNS cache, possibly with a whitelist
>>> for domains you want to send to the ISP forwarder.
>> 
>> Sure, and that's what I usually do. But if we can't specify that
>> behaviour for homenet, at least trying all upstream DNS servers gives a
>> better chance of finding one that works.
>
> I'm really sorry, but I'm actually having trouble contextualizing the
> failure mode that you are talking about here.   Didn't I agree with
> you in a previous message that we should try all the upstream DNS
> servers?

Hmm, right, I guess you did. My point was more that an MPvD-aware client
that only uses on PvD may experience worse performance than one that
uses the in-home resolver. But I guess the client should be smart
enough to deal with that?

>> You may be right that hacking up a working prototype isn't that hard.
>> But the failure modes change from "the internet is down" or may "I
>> cannot access site A", to "site A is working every third attempt, except
>> it is entirely broken on device X" maybe even with an added "ah, but
>> it works on device X if I go into the kitchen".
>
> Didn't we agree that we aren't round-robining?

Yeah, but I was referring to the failure mode for MPvD vs non-MPvD
clients. I.e. if one of the resolvers fails for whatever reason, only
MPvD-aware clients that happen to select that PvD will notice; whereas
if there's only one resolver it will be very obvious when it's not
working...

>> Hmm, while writing this is occurred to me that it might make sense to
>> just export the ISP DNS server(s) directly in the MPvD-only RAs?
>
> This would certainly work, but now you can't have your nice local
> resolver that does what you want.   However, I think you are right
> that this is the right default behavior for MPvD-aware devices.

I would keep the in-home resolver for clients that do not support MPvD;
and probably also announce it as a separate PvD for MPvD-aware clients?

Also, I think I would prefer running a single resolver in the home,
rather than running one on every router.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> El 15 ag 2017, a les 15:38, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
>>> I think we are wandering off into nonsense territory here.   Have you
>>> observed this sort of problem in the field?   If so, can you describe
>>> what happened?   If not, why would we optimize for it?
>> 
>> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
>> more fortunate with your ISPs than me. And that's before even going into
>> the DNS censorship issue; in my part of the world ISP DNS servers are
>> broken *by design*.
>
> In both of these cases, you are better off doing what we discussed
> earlier and setting up your own DNS cache, possibly with a whitelist
> for domains you want to send to the ISP forwarder.

Sure, and that's what I usually do. But if we can't specify that
behaviour for homenet, at least trying all upstream DNS servers gives a
better chance of finding one that works.

>>>> Right, so if this is the case, how about we specify that routers MAY (or
>>>> maybe even SHOULD) support MPvD-specific resolver addresses, and
>>>> advertise the fact over HNCP. And that if a router receives such an
>>>> announcement from another router it MUST announce the MPvD-specific
>>>> resolver addresses over DHCP/RA. This way we ensure that *if* a router
>>>> on the network implements MPvD it is going to work for the whole
>>>> network; but routers can still opt to not implement the functionality
>>>> itself if the implementer doesn't want to pay the implementation cost.
>>> 
>>> Can you describe for us what this implementation cost is that you want
>>> to avoid?
>> 
>> Can you describe for us how multiplying the number of resolvers by N (or
>> MxN if we follow your suggestion of running a full set of resolvers on
>> every router) is *not* going to incur a significant implementation and
>> debugability cost?
>
> It's just a bunch of ports/address pairs, with one thing listening on
> all of them, and using the port/address pair as a behavioral selector.
> I'm not going to say that it's zero effort, but it's not hard.
> Honestly, every home router right now has some kind of DNS proxy or
> DNS resolver in it; this is not a big change. Compared to, say,
> implementing HNCP or DNSSD, it's utterly trivial.

You may be right that hacking up a working prototype isn't that hard.
But the failure modes change from "the internet is down" or may "I
cannot access site A", to "site A is working every third attempt, except
it is entirely broken on device X" maybe even with an added "ah, but
it works on device X if I go into the kitchen".

Hmm, while writing this is occurred to me that it might make sense to
just export the ISP DNS server(s) directly in the MPvD-only RAs?

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

>> Depending on the type of performance problem. If the performance problem
>> is general, yes. If it is specific to DNS, there's no reason to not use
>> the connection for other things; and the "send queries to all upstreams"
>> solution will automatically converge to use the best-performing upstream.
>
> I think we are wandering off into nonsense territory here.   Have you
> observed this sort of problem in the field?   If so, can you describe
> what happened?   If not, why would we optimize for it?

If you consider flaky ISP DNS servers to be "nonsense" you are clearly
more fortunate with your ISPs than me. And that's before even going into
the DNS censorship issue; in my part of the world ISP DNS servers are
broken *by design*.

>> Right, so if this is the case, how about we specify that routers MAY (or
>> maybe even SHOULD) support MPvD-specific resolver addresses, and
>> advertise the fact over HNCP. And that if a router receives such an
>> announcement from another router it MUST announce the MPvD-specific
>> resolver addresses over DHCP/RA. This way we ensure that *if* a router
>> on the network implements MPvD it is going to work for the whole
>> network; but routers can still opt to not implement the functionality
>> itself if the implementer doesn't want to pay the implementation cost.
>
> Can you describe for us what this implementation cost is that you want
> to avoid?

Can you describe for us how multiplying the number of resolvers by N (or
MxN if we follow your suggestion of running a full set of resolvers on
every router) is *not* going to incur a significant implementation and
debugability cost?

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
>>> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <t...@toke.dk 
>>> <mailto:t...@toke.dk>> va escriure:
>>>> In any case, the failure mode of getting a it wrong is a sub-optimal
>>>> path being chosen; but if ISP A's DNS server takes five seconds to
>>>> respond, we'd get a better result from just using the timely answer from
>>>> ISP B's and going over the suboptimal path to get to the content (in
>>>> many cases, at least).
>>> 
>>> Not if the suboptimal path has substantially worse performance for the
>>> duration of the session.
>> 
>> Sure, it depends on the particular application (hence the "in many
>> cases" in my original statement)... My point is just that it's not an
>> obvious across the board win.
>
> Indeed.  However, it is never a lose.

Erm, except when the suboptimal path does *not* have substantially worse
performance for the duration of the session? CDNs are used for other
things than Netflix...

>>> Many hosts we care about already support MPvD because the companies
>>> that sell the software that runs on those hosts think it solves a
>>> useful problem.   Adding support for MPvD on the homenet is a
>>> relatively small change now that their stacks already support it.
>> 
>> Right, so we're adding it as an extra service for hosts that support it?
>> That is fine with me, but then it shouldn't be a requirement. I.e., we
>> can go "supporting MPvD is a good idea, and here is how you do it
>> correctly", rather than the current "must support" language.
>
> If we don't require it, we can assume that it will not be supported.
> It is likely that most hosts will support it,

What are you basing this assessment on?

> so if we don't support it, we are missing an opportunity to make
> things work well on the homenet, not just failing to add a "nice to
> have" feature.

Well, I guess I'm not convinced that MPvD support is really required to
'make things work well'. But, well, if we can limit the complexity cost
I guess that becomes less of a problem.

>>> As for a "degraded experience," do you mean that if we select one
>>> upstream provider for a particular client, that's going to result in a
>>> degraded experience for the user?   Why would that be the case?
>> 
>> I mean that if we query all upstreams we get the best aggregate
>> performance from all available DNS servers. Whereas if we limit queries
>> to a particular ISP, we only get as good performance as that particular
>> ISP can provide. If that was going to be the best on anyway, fine. If
>> not, we are worse off by limiting queries to that ISP.
>
> If one ISP is performing substantially worse than the other, the right
> thing to do is use only the one that's performing well. Neither "doing
> nothing" nor "doing MPvDs" accomplishes this end. However, "doing
> MPvDs" arguably comes closer.

Depending on the type of performance problem. If the performance problem
is general, yes. If it is specific to DNS, there's no reason to not use
the connection for other things; and the "send queries to all upstreams"
solution will automatically converge to use the best-performing upstream.

> The downside is that if the lousy ISP wins, hosts are stuck with it.
> This is a serious problem. It may indeed be the case that a better
> choice for non-MPvD hosts is to give them a name server that fans out
> to both ISPs.

On this we are agreed, I think :)

>> How do non-MPvD-aware hosts react to an announcement of an MPvD-specific
>> DNS server? Does it ignore the server entirely, or does it ignore the
>> PvD information and use the server anyway?
>
> It has to be announced in such a way that non-MPvD hosts don't see it.

Right, so if this is the case, how about we specify that routers MAY (or
maybe even SHOULD) support MPvD-specific resolver addresses, and
advertise the fact over HNCP. And that if a router receives such an
announcement from another router it MUST announce the MPvD-specific
resolver addresses over DHCP/RA. This way we ensure that *if* a router
on the network implements MPvD it is going to work for the whole
network; but routers can still opt to not implement the functionality
itself if the implementer doesn't want to pay the implementation cost.


-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
>> In any case, the failure mode of getting a it wrong is a sub-optimal
>> path being chosen; but if ISP A's DNS server takes five seconds to
>> respond, we'd get a better result from just using the timely answer from
>> ISP B's and going over the suboptimal path to get to the content (in
>> many cases, at least).
>
> Not if the suboptimal path has substantially worse performance for the
> duration of the session.

Sure, it depends on the particular application (hence the "in many
cases" in my original statement)... My point is just that it's not an
obvious across the board win.

>> But only the client can make that coupling (from DNS reply to connection
>> attempt). So if we're just filtering the result set based on the address
>> the client uses (which is how I interpret what you put in the draft),
>> we're degrading the experience for any client that doesn't know how to
>> repeat the query from another source address. So we'd effectively be
>> requiring hosts to support MPvD; and we're not supposed to require host
>> changes, are we?
>
> Many hosts we care about already support MPvD because the companies
> that sell the software that runs on those hosts think it solves a
> useful problem.   Adding support for MPvD on the homenet is a
> relatively small change now that their stacks already support it.

Right, so we're adding it as an extra service for hosts that support it?
That is fine with me, but then it shouldn't be a requirement. I.e., we
can go "supporting MPvD is a good idea, and here is how you do it
correctly", rather than the current "must support" language.

> As for a "degraded experience," do you mean that if we select one
> upstream provider for a particular client, that's going to result in a
> degraded experience for the user?   Why would that be the case?

I mean that if we query all upstreams we get the best aggregate
performance from all available DNS servers. Whereas if we limit queries
to a particular ISP, we only get as good performance as that particular
ISP can provide. If that was going to be the best on anyway, fine. If
not, we are worse off by limiting queries to that ISP.

>> I can see how these scenarios make sense for a device that know the
>> types of connection (like a cell phone with cellular and WiFi links).
>> Less so in the home, where all the client sees are different prefixes;
>> in this case, either the network has to enforce policy (like the
>> failover scenario), or we'll have to communicate more information to the
>> hosts, which goes back to my point above about host changes...
>
> Yes, in order to make this work we have to communicate additional
> information to the host, and the host has to use it. That's why I
> described a fallback solution for hosts that don't support this. It's
> not clear that the solution I described is the right one, of course;
> the point of saying something there was to have a place where we can
> write whatever the advice is that we decide to give when we figure
> this out; what I described would work, but it's possible that an
> entirely RA-based solution would work just as well, in which case
> personally I'd prefer it.

How do non-MPvD-aware hosts react to an announcement of an MPvD-specific
DNS server? Does it ignore the server entirely, or does it ignore the
PvD information and use the server anyway?

>> Right, well, I'm not sure I have the energy to go argue with dnsop on
>> this one... :) But I can probably live with a mechanism where we just
>> specify that the user needs to have an option to override the default
>> behaviour (i.e., add their own DNS servers which take precedence over
>> whatever we end up specifying).
>
> That's fine with me!

Cool :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

>> Perhaps it would help if you could explain (a) the details of "the CDN
>> problem" (what mechanism is used to determine answers for a given
>> prefix, and what is the failure mode if the wrong address is used?), and
>> (b) how the client is supposed to actually work with this mechanism
>> (seems to me an unmodified client will probably make a mess of things?).
>
> The idea with CDNs is that you put the content close to the edge and
> give different answers using DNS or HTTP depending on where the client
> is. By doing this, you can balance the load across the right number of
> servers in the right data centers, and avoid transporting the same
> traffic over the backbone many times.

Yeah, I am aware of the basic concept of a CDN. What I am (was?)
confused about is what it has to do with different DNS answers. I have
only ever used Cloudflare, and they use anycast to do their magic (which
also seems to me like the obvious way to do it; why are people messing
with DNS for this?). Anyhow, consider me educated... :)

In any case, the failure mode of getting a it wrong is a sub-optimal
path being chosen; but if ISP A's DNS server takes five seconds to
respond, we'd get a better result from just using the timely answer from
ISP B's and going over the suboptimal path to get to the content (in
many cases, at least).

>> As for an "ideal" resolver behaviour, to me that would be full recursive
>> resolution from the root inside the home, replicating all queries across
>> all upstreams and picking the best reply (best being something like
>> "first reply that passes DNSSEC validation"). With an "advanced
>> configuration" option somewhere that allows the user to override
>> arbitrary names/zones as they see fit.
>
> This is mostly what the MPvD solution does (minus the override option,
> which I think is out of scope). Queries are sent to all upstreams, and
> the good answer that arrives first is used. What MPvD does _in
> addition_ is to make sure that if ISP A's answer is chosen, then ISP
> A's connection is used to connect to the destination.

But only the client can make that coupling (from DNS reply to connection
attempt). So if we're just filtering the result set based on the address
the client uses (which is how I interpret what you put in the draft),
we're degrading the experience for any client that doesn't know how to
repeat the query from another source address. So we'd effectively be
requiring hosts to support MPvD; and we're not supposed to require host
changes, are we?

> For example, if you really, really want to use connection A, then you
> only try connection B if you don't have a successful connection
> established after 30 seconds, but if you don't care, then you try both
> nearly simultaneously and take the first one to succeed to the point
> where you have completed the https handshake (for example) and
> validated the cert using PKI validation.
>
> You may also want to configure things so that you have a primary and a
> backup connection, and your backup connection is never used for
> certain things, or only used for certain things. E.g., if your backup
> is a cell phone backup that costs more per megabyte, or has a lower
> data cap. Or in some cases just the opposite. This is useful for
> situations where you want to be able to have dual-homing for the sake
> of IoT six-sigma reliability, but don't want to use the backup link
> for anything else, because it's expensive.

I can see how these scenarios make sense for a device that know the
types of connection (like a cell phone with cellular and WiFi links).
Less so in the home, where all the client sees are different prefixes;
in this case, either the network has to enforce policy (like the
failover scenario), or we'll have to communicate more information to the
hosts, which goes back to my point above about host changes...

> Now, as for the "mostly" above, the problem with what you've said is
> that it doesn't scale: if every home does full recursion, that's a
> much larger load on authoritative name servers than currently exists.
> There's a reason why that's not how things are done now. If we were to
> specify this behaviour, there would be substantial pushback from
> dnsop, and I would be participating in that pushback. I don't think
> this would get IETF consensus. This is not to say that you are wrong,
> but the point is that this is the wrong working group in which to have
> that argument.

Right, well, I'm not sure I have the energy to go argue with dnsop on
this one... :) But I can probably live with a mechanism where we just
specify that the user needs to have an option to override the default
behaviour (i.e., add their own DNS servers which take precedence over
whatever we end up specifying).

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

> The point is that what I have specified in the architecture document is
> what is minimally required to allow a homenet to function given ordinary
> ISPs and ordinary users.   I think trying to do some of the things on the
> above laundry list would be very interesting work; trying to get it to
> where end-users can use it without being experts and without being made
> vulnerable to scams would be very cool, but is out of scope for this
> document.
>
> Does that make sense?

Sure. I'm just not sure I agree that MPvD shouldn't also be on the "nice
to have" list, rather than the "absolutely required" list.

Perhaps it would help if you could explain (a) the details of "the CDN
problem" (what mechanism is used to determine answers for a given
prefix, and what is the failure mode if the wrong address is used?), and
(b) how the client is supposed to actually work with this mechanism
(seems to me an unmodified client will probably make a mess of things?).

As for an "ideal" resolver behaviour, to me that would be full recursive
resolution from the root inside the home, replicating all queries across
all upstreams and picking the best reply (best being something like
"first reply that passes DNSSEC validation"). With an "advanced
configuration" option somewhere that allows the user to override
arbitrary names/zones as they see fit.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> What I find completely perplexing about this conversation is that you,
> Markus and Toke, all of whom I know to be smart people, think this is
> hard.   What is hard about it?   I think the reason you think it's
> hard is simply that you don't know how to do it.

Ah no, this was not was I was trying to express. As you say, technically
implementing what's currently in your draft is doable, but adds a small
to moderate amount of complexity. This can be acceptable, *if* it
provides a corresponding benefit. However, I do not believe that it
does, for two main reasons:

1. In every encounter I've had with an ISP-provided DNS server, that
   server is either (a) flaky, (b) censored or (c) both. So limiting
   ourselves to getting replies from just one upstream for a given query
   is going to give worse performance than using all available servers
   (or just doing our own full recursing from the root).

2. Even if DNS queries are paired with source prefixes, the client still
   has to pick which source prefix to send the DNS query from; how is it
   going to do that? (This may just be me that is ignorant of the
   details of the MPvD architecture; if so, please do enlighten me).

Together, these points mean that as far as I'm concerned, what you're
proposing is adding complexity to achieve a behaviour that is going to
result in *worse* performance than doing the simple thing. Which is not
a good proposition, as I'm sure you'll agree.

Now, as I said a few mails back, I am perfectly happy to be convinced
that there *is* a benefit worth paying the complexity cost for; but,
well, someone is going to have to do the convincing... :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> Why do you want it to be optional?  What problem are you trying to solve?
> Do you not know how to do it?  Do you think it's resource intensive? Do you
> think it reduces reliability more than not doing it?

Because I'm not convinced the added implementation complexity is worth
it; so yeah, the last one I guess...

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> How does the client know in which PvD a response is intended to exist.

Well, in some cases normal source address selection rules are going to
do the trick (i.e., the client picks the source address closest to the
destination). In others it won't, and the client will get degraded
behaviour.

> Also, what problem are you trying to solve here? What you described
> sounds like it's just an attempt at implementing mpvd on a homenet
> without requiring that all routers behave the same.

Well, as I said I would be perfectly happy to just ignore the MPvD issue
entirely. What I'm trying to do is at least make it optional for a
homenet router to implement it... :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
>> all queries to router A, using a source address in the same prefix
>> as the original request was received from.
>
>> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
>> router A's address (which would need to be routable inside the
>> homenet, obviously) as the DNS server in RAs.
>
> This has the significant advantage of not requiring a DNS proxy on each
> Homenet router.  It has the disadvantage of not requiring a DNS proxy on
> each Homenet router.
>
> I like it.
>
> (Aside: what's the fallback mode if there's no A in the network?  One
> could either advertise all of the ISPs' DNS servers in RAs, or advertise
> oneself notwithstanding no support for MPvD.  I guess both should be
> allowed.)

Yeah, or fallback to 2 (send queries to all upstreams and reply with the
union to the client). If you don't want to bother being MPvD-aware, you
just set N (the number of upstreams to wait for) to 1, and it turns into
a sort of happy eyeballs for DNS...

> (Second aside: what happens when there are multiple As in the network?
> One could either elect the "master" DNS server, so that all links use the
> same DNS proxy, or let each router pick one at random, so you get load
> balancing.  I guess only one should be allowed.)

I'd say don't bother with an election. All routers with the capability
are eligible as upstreams. Picking one at random is probably fine, but
not sure if we need to specify that? "Pick the first one you see" would
probably also work, as long as you update your choice if that router
goes away...

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>> Now, assuming that I am wrong and this is actually a serious issue that
>> we need to solve (of which I am not opposed to being convinced), I think
>> it would be feasible to come up with a solution where we could at least
>> allow less capable routers that do not implement the full MPvD support.
>> I can think of at least two ways off the top of my head:
>> 
>> 1. Allow the router in question to offload queries to a more capable
>>   router elsewhere in the homenet.
>> 
>> 2. Allow the router in question to just query all upstreams and combine
>>   the results (and so offload the problem to the client).
>
> Great.   Can you explain, step by step, how to do either of these
> things?

Given that router A supports MPvD and router B doesn't:

1a. Router A exports over HNCP that it supports MPvD. Router B forwards
all queries to router A, using a source address in the same prefix
as the original request was received from.

1b. Router A exports over HNCP that it supports MPvD. Router B uses
router A's address (which would need to be routable inside the
homenet, obviously) as the DNS server in RAs.

2. Router B simultaneously forwards the query to all upstream DNS
   servers known to the homenet, waits for replies from N of them,
   creates the union set of all those replies and sends that back to the
   client.

If N=1 in 2, that corresponds to just ignoring MPvD. Router B could also
fall back to 2 if no router A is available on the network.

Now, please feel free to explain why you think these would break
things... ;)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>> with the possible exception of the
>> requirement for supporting multiple provisioning domains
>
> How would you solve the problem of dual-homing without the multiple
> provisioning domain support described in the document?

We're talking about the "oh no, my netflix streams is coming from the
wrong ISP" kind of problem here, right? I.e., same DNS request gives
different answer depending on which ISP I send it to?

For one thing, I'm not convinced this is that big of a problem. I happen
to live in a country that likes to apply censorship by messing with DNS;
so I generally don't use my ISP's name servers, and have never had any
issues arising from this. So in this case a solution could just be to
ignore the issue... :)

Now, assuming that I am wrong and this is actually a serious issue that
we need to solve (of which I am not opposed to being convinced), I think
it would be feasible to come up with a solution where we could at least
allow less capable routers that do not implement the full MPvD support.
I can think of at least two ways off the top of my head:

1. Allow the router in question to offload queries to a more capable
   router elsewhere in the homenet.

2. Allow the router in question to just query all upstreams and combine
   the results (and so offload the problem to the client).


-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Toke Høiland-Jørgensen]

Andrew Sullivan  writes:

> On Thu, Aug 10, 2017 at 08:33:11PM +, STARK, BARBARA H wrote:
>> Does anyone else have an opinion? Does anyone who has expressed an opinion 
>> want to express a new and different opinion?
>> Barbara
>
> I haven't weighed in because I can't make up my mind.
>
> On the one hand, I think this is a reasonable and limited set of
> things to do to get started with, and so I'd normally say we should
> adopt it and go ahead.
>
> On the other hand, as I suggested in Prague, it's quite a limited set
> of aspirations, and quite a bit short of what we had originally
> suggested we were trying to do. It even seems shy of various claims in
> the architecture document, which I see as a sort of requirements
> document.

I am in a bit of the same boat. I think most of the things in the
document are reasonable things to do (with the possible exception of the
requirement for supporting multiple provisioning domains), but I would
also like to solve some of the other problems that are deemed out of
scope in the current version of the document. At a minimum, I would like
to solve the "services should be visible from the outside" problem.

I guess I'm fine with adopting the document, as long as it's still
possible to make these kinds of adjustments in scope further along the
way... :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

[Toke Høiland-Jørgensen]

>> you couldn't use the fact that you can publish in a name in it
>> to do the ACME authentication.
>
> there SHOULD NOT be the ACME authentication or any neccessarity of any
> other authentication, as these domain names need not be unique ...
>
> in case you use 'teddynet.home.arpa.' and I use this domain name, too;
> we wouldn't have the same x509 SSL certificate, because each of us uses
> its own private key ...
>
> why not just define the org. that hosts the ARPA TLD (IANA?), as the CA
> for these domains and the root certificate as built in token to the common
> browsers and/or operating systems?
> there it should only be neccessary to upload the certificate request,
> gicwn the '.home.arpa.' domain name, and an email address where the
> certificate is sent to;
> the certificate will be a wild card certificate for this .home.arpa.
> domain ..
>
> I would want this to be added as additional section to this Draft/RFC;

If you're going through all this trouble of having a central API that
will hand out certificates, wouldn't it be possible to make that same
authority hand out pseudo-random unique subdomains (of some suitable
domain; not necessarily .home.arpa)? Then you are only an NS record from
solving the globally visible naming problem... :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <t...@toke.dk> writes:

> Ted Lemon <mel...@fugue.com> writes:
>
>> I think it would be worth presenting your work, yes. In addition to this, 
>> I've
>> been working with Stuart Cheshire on an enhancement to the hybrid proxy that 
>> I
>> expect to present in Prague. It would be interesting to tie your work in with
>> that. I'm going to write up some initial documents that talk about this in 
>> the
>> next couple of days. The work we are doing will happen in dnssd, not homenet,
>> but it's directly related to the work I've been doing on the homenet naming
>> architecture, and will be reflected in the next version of that document.
>>
>> I don't know if your work is more something that should be presented in 
>> homenet,
>> or should be presented in dnssd, or some combination. We should talk about 
>> this
>> once the documents are out.
>
> ACK. Let me know when that is :)

Ping?

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> I think it would be worth presenting your work, yes. In addition to this, I've
> been working with Stuart Cheshire on an enhancement to the hybrid proxy that I
> expect to present in Prague. It would be interesting to tie your work in with
> that. I'm going to write up some initial documents that talk about this in the
> next couple of days. The work we are doing will happen in dnssd, not homenet,
> but it's directly related to the work I've been doing on the homenet naming
> architecture, and will be reflected in the next version of that document.
>
> I don't know if your work is more something that should be presented in 
> homenet,
> or should be presented in dnssd, or some combination. We should talk about 
> this
> once the documents are out.

ACK. Let me know when that is :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <t...@toke.dk> writes:

> Ted Lemon <mel...@fugue.com> writes:
>
>> On Apr 17, 2017, at 3:16 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>>
>>  Hmm, turns out RFC6763 already defines a way to do this (in section 11).
>>  r._dns-sd._udp.. where  is either the in-addr.arpa zone
>>  derived from the network address of a host address, or "local.". I guess
>>  I'll teach the nsregc client to resolve that...
>>
>> Cool!   Sorry I didn't mention it earlier—haven't had a chance to try
>> the code yet. 
>
> No worries. I added auto-discovery to the client, and improved
> configuration for both client and server (and the client will now run
> without any configuration with sensible defaults). The server also
> supports synthesising reverse PTR records now.
>
> Only thing missing now for my own use case is the ability to add local
> records to Unbound (for having a separate internal view while keeping
> private addresses out of the global DNS).

I've added the missing Unbound support, and also wrote a blog post about
nsregd, and how to use ohybridproxy to enable DNS-SD on a routed network
using OpenWrt:

https://blog.tohojo.dk/2017/06/naming-and-service-discovery-on-a-routed-ipv6-network.html

I'm happy to present some of this in Prague if you think that would be
useful :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Ted Lemon <mel...@fugue.com> writes:

> On Apr 17, 2017, at 3:16 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote:
>
>  Hmm, turns out RFC6763 already defines a way to do this (in section 11).
>  r._dns-sd._udp.. where  is either the in-addr.arpa zone
>  derived from the network address of a host address, or "local.". I guess
>  I'll teach the nsregc client to resolve that...
>
> Cool!   Sorry I didn't mention it earlier—haven't had a chance to try
> the code yet. 

No worries. I added auto-discovery to the client, and improved
configuration for both client and server (and the client will now run
without any configuration with sensible defaults). The server also
supports synthesising reverse PTR records now.

Only thing missing now for my own use case is the ability to add local
records to Unbound (for having a separate internal view while keeping
private addresses out of the global DNS).

> Thanks for GPLing it, BTW.

You're welcome! The GPL is my default license :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <t...@toke.dk> writes:

>> Or put it in DNS under dot-home? Since the client already knows how to
>> speak DNS, this avoids yet another coupling between protocols.
>
> Ah yes, that makes sense; since we have a domain that always refers to
> the homenet, just define a name under that that will return PTRs to the
> zones available for registration.

Hmm, turns out RFC6763 already defines a way to do this (in section 11).
r._dns-sd._udp.. where  is either the in-addr.arpa zone
derived from the network address of a host address, or "local.". I guess
I'll teach the nsregc client to resolve that...

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Andrew Sullivan  writes:

> I really like this idea.

Thanks!

> Obviously, it's the sort of thing whose scope had better be pretty
> limited (e.g. you better know what network those TOFU requests are
> coming from), but apart from that it seems quite useful.

Yeah. The daemon will only allow new registrations from configured
white-listed subnets (and only speaks TCP to avoid spoofing problems).
Subsequent authenticated updates can optionally be allowed for any IP.

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

> Simple and elegant, solves a real problem without too much ideology.

Thank you! That is high praise, coming from you :)

>> If the name in a claim is not already taken by another nclient, the
>> client's claim will be successful and the daemon will cache the public
>> key and use it to verify subsequent update requests.
>
> Does this imply there's a single daemon in the Homenet?  How does the
> network elect it in case there are multiple claimants?  How does the
> client learn the address of the daemon?

In the current implementation, a single daemon per registration zone.
The client will query for a SRV at _nsreg._tcp. to find the
daemon, which can be anywhere, in principle (the daemon will only speak
TCP and limits initial registration to a list of configured subnets; I'm
currently running mine on a separate server rather than on my router).
For the multi-homed homenet case, I suppose each uplink could have a
separate zone?

I punted somewhat on how to discover the zone; the client will currently
take it as a command line parameter. But figure that can be distributed
via DHCP/RA?

In principle, there's nothing preventing the daemon state from being
replicated across the homenet routers, I suppose...

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> Thanks for doing this! Did you come up with this on your own, or were
> inspired by
> https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01
> section 3.4.2 and
> https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 section 4.2?

Well, I would by no means claim to have come up with the idea in a
vacuum. As I said, I have been following the naming discussions on this
list. I think I read the -00 of the naming architecture, but I have not
read the latest version, nor have I read the stateful-dnssd draft
before.

Looking at it now, what I have implemented looks like a hybrid of the
two halves of section 3.4.2. I.e., clients generate a KEY and use it to
sign updates, and they use that to remove records as well (i.e., there
is no support for unauthenticated updates in nsregd). But the records
are not permanent; the daemon will expire records that the client does
not maintain (since if a client drops off the network it has no way of
retiring its record).

> I ask both because I'm curious of you're proposing that the previous
> naming architecture document is more in line with what you think
> should be on a homenet, and also because I'm curious whether you are
> interested in working on the documents.

Hmm, well, I have first and foremost been trying to scratch my own itch
here. I was looking for something to replace dnsmasq's slaac address guessing
(https://tools.ietf.org/id/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00.html),
and since no good solutions were forthcoming, I decided to roll my own.

That being said, I do believe this mechanism could be useful as part of
the homenet architecture, which is why I posted it here. And I wouldn't
mind spending some time fleshing out the mechanism and putting it into a
draft, if that is what you mean by "working on the documents"?

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] A TOFU approach to naming things in the homenet (with code!)

[Toke Høiland-Jørgensen]

Hey everyone

While following the naming discussions, I have been thinking about how
to do one of the things that the current naming architecture draft
excludes: Allowing devices on the homenet to register in (public) DNS so
that one may find them. And since I also wanted to learn the Go
programming language, I decided to prototype something. Enter the
'nsregd' daemon.

This daemon will allow a client to claim a name on a Trust On First Use
(TOFU) basis using the RFC2136 dynamic DNS update protocol. A client
claims a name by sending a DNS update request with a SIG(0) (RFC2931)
signature and including the public key corresponding to the signature.
If the name in a claim is not already taken by another client, the
client's claim will be successful and the daemon will cache the public
key and use it to verify subsequent update requests.

Once a name has been claimed by a client, that client can add and remove
A and  records by means of regular DNS update requests signed with
the key used to claim the name. The daemon will forward these updates to
one or more configured upstream authoritative nameservers.

I'm posting this here in the hope that others will find it useful,
either as input to the discussion, or as a tool to play around with.

The code is available on Github:

https://github.com/tohojo/nsregd

The README file has a few more details on how it's supposed to work.
Comments very welcome, patches even more so :)


Cheers,

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Fwd: [babel] A quick summary of babel@ietf

[Toke Høiland-Jørgensen]

This might be of interest to people here. In particular, checking out
Dave's "homenet on hackerboards" talk could be worthwhile.

-Toke

--- Begin Message ---
Dear all,

IETF is over, we've had the first meeting of the Babel WG.  It went
pleasantly smoothly.  You'll find the full recording of the meeting[1],
the minutes, as well as all the meeting materials, including slides[2].

[1] 
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_BABEL=chapter_1
[2] https://datatracker.ietf.org/meeting/96/materials.html#babel

In short:

  - the chairs said some things;
  - I gave a talk about my plans for evolving the protocol, the audience
seemed to agree;
  - Barbara Stark gave a talk about her proposed management information
model, in which she notably recommended to debloat the model; there
was a short misunderstanding between her and Margaret Cullen, which
was quickly cleared up;
  - Dave gave a talk about routing with hackerboards, a talk that was not
specific to Babel but was well-received and appeared to me to be
eye-opening to at least some audience members.

My feeling right now -- unless we f*ck up really badly, this is going to
be a productive and fun working group.

-- Juliusz

___
babel mailing list
ba...@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--- End Message ---
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Routing Design Team outcome and next steps

[Toke Høiland-Jørgensen]

Lorenzo Colitti  writes:

> Hear, hear!
>
> We have spent far too much time arguing about this, and I am happy we have a
> conclusion. A big thank you to the chairs for calling making this call. I
> strongly agree that given the dynamics of the home networking market, there
> needs to be one, and only one, routing protocol. I don't see anything else
> working in the real world.
>
> Personally, I happen to think that babel is the best choice, not so much 
> because
> of the protocol itself but because of the current availability of solid,
> freely-licensed, small-footprint implementations. But IS-IS would have been 
> fine
> as well; so would OSPF, if there had been an implementation, and even HNCP
> fallback would have fine. At the end of the day it doesn't really matter which
> one we choose, as long as we choose one.
>
> Let's hope that this will stop the arguments and we can all get on with
> implementation and deployment.

+1

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Experiences implementing Babel in the Bird routing daemon

[Toke Høiland-Jørgensen]

Hi everyone

Over the last couple of weeks, I've amused myself with doing a
clean-slate implementation of the Babel protocol in the Bird routing
daemon, and thought I'd report my experiences here.

I saw Juliusz' talk at the Babel side meeting in Prague (and again at
Battlemesh), which is what convinced me that this was actually a viable
project. Otherwise, I based my implementation on the RFC and did basic
interoperability testing with the official babeld implementation.

Overall, I found the RFC clear and easy to follow. Section 2 gives a
nice background on how the protocol works, and sections 3 and 4 gives
the details of how the implementation should work; in sufficient detail
that the implementation can done by referring only to those two
sections. The details that are left up to the implementation have nicely
suggested solutions in the appendices (which I used for my
implementation).

The main thing that I found confusing in the text was the mention of
'id' in section 3.5; took me a while to realise that this was supposed
to be the router id. In the rest of the document, this is quite
explicit, but in sections 3.5.1 and 3.5.4 they are referred to simply as
'id'. This is technically defined in the text, but one has to go looking
for it, so when flipping back and forth between the code and the
document I found it somewhat confusing.

The second thing I would have liked to have available is some more
guidance on how to ensure an implementation is actually compliant to the
RFC. I.e. a test suite, or at least some description of what kind of
edge cases to test (tricky topologies, that sort of thing). My testing
so far has been fairly ad hoc, and I'm pretty sure there's still bugs in
there.


The main part of the implementation took about a week, with another week
to fix bugs and convince myself that it actually works as intended; this
includes time to familiarise myself with the Bird daemon API and
internal logic (but on the other hand, I didn't have to write any code
to talk to the kernel). I by no means consider it a production-quality
implementation at this point, but it does exchange routes with the
babeld daemon and hasn't crashed my laptop yet :)

I've posted the implementation as a patch on the Bird list here:
http://trubka.network.cz/pipermail/bird-users/2015-August/009855.html --
that email also describes the current limitations of the implementation.

There's also a github repository with the complete commit history for
those who want to amuse themselves with perusing my struggles:
https://github.com/tohojo/bird

I hope this can serve as a useful data point in the assessment of the
implementability of Babel. I started this mainly as a project to satisfy
my own curiosity (the best way to understand a protocol is to implement
it, and all that), but do plan to put in some effort to get it to a
more robust state, depending on the feedback I get from the Bird
developers :)

Cheers,
-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [babel] Experiences implementing Babel in the Bird routing daemon

[Toke Høiland-Jørgensen]

Juliusz Chroboczek j...@pps.univ-paris-diderot.fr writes:

 Over the last couple of weeks, I've amused myself with doing a
 clean-slate implementation of the Babel protocol in the Bird routing
 daemon

 Excellent news, Toke. I've had a first read over your code, and it
 looks almost correct (I have some minor nits). I'll read it again, and
 do a detailed review with stupid questions about the bits I don't
 understand.

Thanks. I'll look forward to your comments :)

 For the record, while Toke and I are friends, this is a completely
 independent implementation of the IPv6 subset of RFC 6126 together
 with Appendices A and B (I once looked over Toke's shoulder when he
 was hacking at it, and he quickly shooed me away).

Yes, can confirm. Juliusz has likewise been most insistent on not giving
any hints. Most annoying, making me read like that...

 I may be biased, but in my experience the only tricky bit in the
 protocol is reacting to starvation. Everytime I touch this code, I put
 a router in the middle of the network then increase the cost to all
 neighbours, and check that seqno requests behave according to spec. If
 they don't, you'll notice right away -- either there'll be a request
 storm, or your routes will remain unreachable for a long time.

Well, basically taking the above paragraph and putting it in an appendix
as things to test for would be useful. I.e. some list of make sure
these scenarios work and you should be set.

For the packet format, I targeted having wireshark agree with me on the
contents of the packets. That was fairly straight forward.

 If anybody knows how to write a test suite for a routing protocol, I'm
 interested. I imagine a set of scripts that set up some virtual
 machines and perform some tests, but I have trouble imagining how it
 could perform a test such as the one described above.

The CORE emulator might be useful in this regard:
http://www.nrl.navy.mil/itd/ncs/products/core

 Impressive. I'll dust some old laptops, and we'll do some more serious
 testing when you come to Paris.

It'll be instructive, annoying and fun, I expect :)

-Toke

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Please review the No IPv4 draft

[Toke Høiland-Jørgensen]

Simon Perreault simon.perrea...@viagenie.ca writes:

 Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
 can already do this today without this extension.

Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline (if the
option is not in the regular announcements).

Would it not be reasonable to add in a requirement that if a client has
already received a DHCPv4 lease (or more generally, has been configured
for IPv4 in some way), it will ignore requests to turn off the stack?

-Toke


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Please review the No IPv4 draft

[Toke Høiland-Jørgensen]

Simon Perreault simon.perrea...@viagenie.ca writes:

 Sure it can. Just send them to a non-existing default gateway. Unless
 I misunderstood your point.

My point was that if you do this, the next time the real gateway sends
out an advertisement, connections are going to be restored. Whereas if
the gateway doesn't speak this option, all the hosts are just going to
shut down IPv4 and not come back up until someone realises this is what
happened.

 Would it not be reasonable to add in a requirement that if a client has
 already received a DHCPv4 lease (or more generally, has been configured
 for IPv4 in some way), it will ignore requests to turn off the stack?

 I'd be fine with that. Thanks for the idea!

Cool! :)

-Toke


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Please review the No IPv4 draft

[Toke Høiland-Jørgensen]

Ted Lemon mel...@fugue.com writes:

 No, because this just leaves the client open to a different DoS
 attack. If you have rogue configuration protocols running on your
 network, you need to fix it. This just moves the problem around—it
 doesn't solve it.

Well, assuming this stays as an RA option and not a DHCPv4 one, I don't
think it will be unreasonable for someone running an IPv4-only network
to assume that they don't have to worry about IPv6 configuration
protocols disabling their IPv4. Having the exception that if IPv4
already works, don't disable it will make this assumption more likely to
be true.

As an example, consider a university campus network (or a conference
network) running IPv4 only, and someone broadcasting an RA packet onto
the open wireless. Suddenly everything goes offline and will stay that
way (until the RA expires) since no legitimate RAs come along to tell
hosts to turn IPv4 back on.

 One thing that I think would make this less likely to happen would be
 to state that no-ipv4 must be present on all valid configuration
 states received on a particular interface in order for no-ipv4 to be
 valid for that interface. IOW, if you are getting rogue RAs that say
 no IPv4 and also a non-rogue RA that doesn't say no IPv4, the host
 assumes that IPv4 is permitted. This prevents a rogue RA from killing
 IPv4 connectivity even for the lifetime of that RA.

I would definitely think it would be a good idea to have option not
present have the same semantics as option set to allow ipv4.
Otherwise, those actually running dual-stack networks would have to
upgrade just to keep this from potentially causing problems.

-Toke


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Please review the No IPv4 draft

[Toke Høiland-Jørgensen]

Simon Perreault simon.perrea...@viagenie.ca writes:

 In a nutshell, it defines DHCPv6 and RA options indicating to the host
 that IPv4 is not available. Since home networks are among those likely
 to see its use, reviews coming from HOMENET would be of tremendous
 help.

If I understand the draft correctly, a rogue user could completely
disable connectivity for all hosts on the local link, simply by sending
out a single RA message. Is that correct? (I am here thinking of the
case of an IPv4 only network where the real router is not including this
field in its DHCP/RA messages, but the clients understand it).

-Toke


signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet