Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
> Juliusz, please go read RFC2026. You are completely out of order. > Proposed standards do not need *ANY* interoperable implementations. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Removing the IESG from CC. > I propose you start mentioning what you believe are unspecified gaps > that could lead to interoperability issues. With all due respect, Daniel, I'm a little surprised by this development. In this WG, we did spend a lot of effort ensuring that all of our specifications have at least two independent implementations. This allowed us to claim with assurance that our protocols are not only implementable, but actually described clearly enough to allow independent reimplementation. (Which didn't prevent a small minority of IESG members from blocking progress for months, but that's a different story, and one that's well documented in RFC 3774.) >From your mail, it would appear that the burden of proof has changed sides: it is apparently no longer the people who propose a protocol who need to prove that it is implementable, but the people who have tried but failed to understand how to implement a draft who need to prove that the draft is incoplete. When did that happen? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)
>> this document tries to describe would see adoption, it's become very >> clear that dynamic DNS services as described in Section 4 have won out >> here. These services are far from perfect, but at least some of the >> limitations in Section 4 have been addressed, and others are arguably a >> feature and not a limitation. > so, perhaps you could explain to me how to use some service to host my IPv6 > reverse DNS then. RFC 4620? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] A few comments about draft-lemon-stub-networks-02
I haven't been following Ted's work on stub networks, and I've only just taken some time to read through the latest draft. Sorry if I repeat things that have already been said, I haven't caught up yet with my Homenet mail. A few quick comments while I think it over. 1. There's a lack of definitions The draft speaks about "stub networks", but I couldn't find where the term is defined. Is a stub network a single layer-2 link, or can it be a layer 3 mesh ? Is a stub network connected through a single router, or can it be connected through multiple ones? If there are multiple stub routers, do they need to be connected to the same infrastructure link, or can they be connected to distinct links? To different providers (think BCP 38)? I think the draft could be usefully improved if the terms were more clearly defined. 2. There's a lack of a problem statement I couldn't work out what problem the draft is aiming to solve. In Section 3.2, it appears to be about client tethering, but in Section 3.5, it would appear to be about some sort of DMZ, that makes services available to the rest of the homenet. I think the draft would be improved if it were circuscribed by a clear problem statement. 3. NAT64 is controversial The draft recommends NAT64 as the IPv4 connectivity technique. I'm certainly not alone in this group in disliking NAT64, which combines all the problems of NAT with all the problems of split-horizon DNS. (See also RFCs 7368 and 9080, both products of this WG, which clearly discourage the use of NAT.) I think that the draft would be less contentious if the part about NAT64 were removed. Hope this helps, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Looking for a Homenet co-chair
> FWIW, I think there's further work after stub networks for HomeNet to do. We > now have Babel and Source-Specific routing, but I suspect that setting it up > will involve some innovation, and that ought to be documented. That would be RFC 9080. It's fully implemented in both hnetd and shncpd. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming drafts
>> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/ > I didn't find any clear definition of how DDNS works in that email. [...] > What's the Performance Specification that describes this process? Yes, > I know where the vendor specific documentation is. As far as I'm aware, all the REST-like DDNS protocols are vendor-specific. However, they are widely deployed. To give a data point, the ISP-provided CPE I'm using right now implements no less than three distinct vendor protocols for name registration (disabled by default, thankfully). Michael, it would probably take you 20 minutes to write up an I-D describing a reasonable REST-based DDNS protocol, another 5 minutes to write a client implementation in Javascript, and one hour to write a robust server that is well integrated with Bind. > Second, how are the credentials for that communication established? > [...] What name does your NAS pick? [...] Once the 14 year old in the > house does this, how does the parent find out about the name that was > used? [...] > If the device renumbers, or experiences a flash renumbering, how does it > know to re-register? All of these are interesting issues. However, I don't see how they depend on whether the update is carried over HTTPS or AXFR. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] naming drafts
Hi Michael, >> Stephen and Juliusz expressed that they're still not convinced that >> DDNS isn't a good enough solution for the use case. > Well, I'd be happy to discuss with this them again, but they'd have to > actually tell us what "DDNS" really is for them. https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/ > In particular, I'd like to know if it's okay with them if an arbitrary device > in their home automatically signs up with a DDNS provider, disclosing their > IPv6 address to the world. No; unless the user has explicitly requested that a device be accessible from the Global Internet, it has no business publishing its IP address. I've tried to be very clear on that specific point in the mail linked above. Hope that clarifies things, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt
> #5 The arguments why this is better than DDNS don't convince > me, except for the last one (new RR types). Given that DDNS is > deployed, what's the chances that this would also get traction? I think that's an important point. I actually asked the very same question back in 2014: https://mailarchive.ietf.org/arch/msg/homenet/CBoLV2St-kSW0vQNE4GtKqRQthA/ https://mailarchive.ietf.org/arch/msg/homenet/m3tmE8m1pt11YIB5yAtWUMFlv3c/ The authors integrated the discussion as Section 1.2 of the draft, which is what you are referring to. I'm not sure if I'm convinced by their arguments, I suspect that there's some unstated requirement that I don't undestand. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] biggest L2 domain
> I thought that we wrote somewhere in RFC7368 that the Homenet router should > collect as many ports as possible together into a single L2 zone. Section 3.3.2? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> AFAICS there's certainly enough room for me to experiment with patches to > i) reduce MTU to avoid problems arising from L2 MTU mismatches and > ii) to reduce the amount of fragments (at the expense of more UDP packets) > without any tweaking of the standards. In case you're interested, here's the code that decides whether to aggregate or to ship out in shncpd: https://github.com/jech/shncpd/blob/master/send.c#L99 In short -- we try to limit our payload to 1412 bytes whenever possible, within the constraints of not being able to fragment large TLVs. (This should depend on the outgoing interface's MTU, as in Babel, but I decided I'm lazy and just hardwired the constant.) > My reason for investigating ii) is to potentially reduce the impact of > the loss of an individual frame on a lossy link (we would lose 1 node > status TLV from 1 device rather than multiple TLV's related to multiple > devices). Recall, however, that 802.11 has absolutely horrific per-frame overhead. Recall further that HNCP does flooding, so that if there are parallel lossy and lossless links, packet loss on the lossy link doesn't matter as long as the data gets correctly flooded over the lossless link. In short, there is a non-trivial tradeoff here. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
>>> 1) DNCP allows an option of whether a network state TLV contains optional >>> nested payload (HNCP) TLV's or not. >> I'm pretty sure that's not the case. RFC 7787 Section 7.2.2. > A OK so you're saying this is already covered in (Section 4.4 of) 7787 [...] > state hash. The Node State TLVs SHOULD NOT contain the optional > node data part to avoid redundant transmission of node data, > unless explicitly specified in the DNCP profile. > So what I was suggesting was merely additional clarification of that. Careful here. There is no optional part in the *network*-state TLV - this TLV's payload is just the network state hash. The optional payload is for the *node*-state TLVs. >> The replying node MUST reply to all node state queries. However, it is up >> to the replying node whether these replies are sent in a single packet or >> split into multiple packets. > So requesting multiple node status TLV's in one packet could lead to an > oversized UDP reply packet. Yes, this was discussed back in July 2015. Here's what I said back then: It should also say that a node MUST NOT send a datagram with a larger payload, and that it MUST silently drop any larger datagrams (optionally log to system management, etc.). If this is not done, persistent state desynchronisation may occur. This is what Markus replied: I am not sure I want to cripple use in non-crippled networks, just provide guaranteed base value which works everywhere and *RED ALERT* light should light up on crippledbox if it encounters this Since nobody supported my position at the time, I had to agree to the following: - Section 3 of RFC 778 says that "Each node MUST be able to receive (and potentially reassemble) UDP datagrams with a payload of at least 4000 bytes." - there is no limit on the size of the packets that a node may send. > So if I understand you correctly, you're saying this is the problem of the > sender of the response to ensure UDP fragmentation doesn't break, I'm not sure what you mean. We certainly assume that the network obeys RFCs 2460 and 4443. > and that multiple long UDP replies can be generated from a single query > packet (potential amplification). Let's please discuss security at some other time, I'd like the current discussion to come to a conclusion first. > If there's multiple UDP replies required for a single query, would you expect > sending of these individual packets to also be rate limited by trickle? Let's please discuss congestion control at some other time, I'd like the current discussion to come to a conclusion first. > What behavior would we expect from the requester during this time? The requester parses each top-level TLV in turn, and acts upon it. > Wait for all outstanding replies to arrive? No. The requester parses each top-level TLV and acts upon it as soon as it arrives. > Re-transmit a node TLV request for missing / dropped replies? How would the receiving node detect missing replies? If some node-state TLVs are missing, then the receiving node's state might not get updated correctly, which will cause the network hash to mismatch, which will be detected when it receives a new network-state TLV (trickle-driven, worst-case 17s). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> 1) DNCP allows an option of whether a network state TLV contains optional > nested payload (HNCP) TLV's or not. I'm pretty sure that's not the case. RFC 7787 Section 7.2.2. The Network-State TLV only contains the network state hash, short Node-State TLVs are separate top-level TLVs. An implementation may choose to send them in the same packet, but they're independent TLVs and can be sent in different packets. > 2) The node requesting a node status TLV doesn't know in advance how big a > reply packet will be generated. > DNCP states that nodes MUST reply to all node status TLV queries. The replying node MUST reply to all node state queries. However, it is up to the replying node whether these replies are sent in a single packet or split into multiple packets. In other words, the only constraint is that every single node state TLV must be sent in its entirety within a single packet. As described in a previous mail, this does bound the amount of data that a single node can publish, but no bounds on the total size of the network. > So requesting multiple node status TLV's in one packet could lead to an > oversized UDP reply packet. The replying node's behaviour has nothing to do with whether the requests are aggregated in a single packet or not. The replying node processes each request independently, whether it finds them in a single packet or in multiple packets. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> The reason for the 64k limit is clear (due to the design choice of relying on > UDP fragmentation). > What's still unclear to me is why the packet contains all the nodes' TLV's. Because HNCP allows aggregating multiple TLVs in a single packet, to the implementation's discretion. Section 4.2 of RFC 7787. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
>> HNCP is a standards track protocol, and there's nobody left who's >> willing and competent to work on a new revision. > Yes, of course. We can never change a standards track protocol. That > would be wrong. :) My wording was perhaps badly chosen. Sorry for that. I meant to say that I don't currently see anyone who would be both willing and able to (1) change the HNCP spec to add application-layer fragmentation, (2) update the hnetd implementation to obey the new protocol, and (3) go through the somewhat time- and energy-consuming process required to publish a new Standards Track protocol. (To be clear -- as far as I'm concerned, I declare myself incompetent on all three points above. The most I could conceivably do would be to review a new spec and update shncpd so it interoperates with a new revision of hnetd.) > What I’m trying to understand is how bad a problem this is. My understanding is that while HNCP should have no trouble scaling to large networks, it is not designed to carry large amounts of per-node data. This could cause trouble in the following cases: - if a single node has hundreds of HNCP neighbours (e.g. because it is connected to a large switch or serves as a tunnel server); - if a single node announces large numbers (dozens) of external connections; or - if a protocol extension dumps large binary blobs into HNCP. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> I notice in the current Openwrt code that the max UDP packet size is set at > 9000 octets with the comment: > /* Very arbitrary. On some implementations, I have seen some issues > * with 10+kb frames so we use this for now. It MUST be significantly > * more than 4k, due to how code is written at the moment. */ > #define HNCP_MAXIMUM_UNICAST_SIZE 9000 > With current code (without expanding the TLV data set), and my sample > test routers, that sets a current maximum network size of approx. 12 > nodes. I don't think that the limit applies to the total network size, it applies to the maximum size of a single NODE-STATE TLV. If memory serves, HNCP is able to send each NODE-STATE in a separate datagram, so the network can grow without bound; it's the amount of data published by a single node that is limited to slightly less than 9kB. However, I agree that this could prove problematic if you build a very dense network (a single node with a lot of neighbours) or if you have large numbers of external connections terminating at a single node. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> This still doesn’t address the problem that the HNCP packet needs to be > fragmented. Fragmented Multicast doesn’t scale well. HNCP doesn't fragment multicast, it only uses fragmentation for (link-local) unicast. This is way less severe than what you incorrectly claim. At any rate, the right time to discuss that was 2015, not now. HNCP is a standards track protocol, and there's nobody left who's willing and competent to work on a new revision. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> If you have a discontinuous L2 MTU, you do not need fragmented packets > to see packets disappear. Ah, I see. > No fragmentation of any sort involved, just incorrectly set up L2 segments. Right. It's an incorrect network setup. To fix that, it should be enough to point the tunnel directly at a Homenet router rather than relying on bridging. (A good idea in any case, since Babel is able to make better routing decisions if the tunnel is directly visible to it.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> The problem is, how’d the packet get so big that it was fragmented? HNCP relies on network-layer fragmentation: it uses UDP and has no application-layer mechanism for fragmenting large TLVs. See Section 4.2 and Appendix B.2 of RFC 7787. (I seem to recall that an earlier version of DNCP included provisions for application-layer fragmentation of TLVs, but that was removed at some point. I don't remember why.) Let's please come back to my question. RFC 4443 paragraph 3.2 says A Packet Too Big MUST be sent by a router in response to a packet that it cannot forward because the packet is larger than the MTU of the outgoing link. If your tunnelling software violates this, how is it not buggy? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNCP/HNCP Revisited
> The L2TPv3 tunnel has a lower MTU than the local LAN, and does not report ICMP > PTB, so HNCP packets in one direction get through, but replies get dropped. Is that not a bug? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] IPv6 & firewall config in a home net
> Question: do PCP messages always go to the default route? Yes, at least according to 6887. > I re-read 6887 and that was unclear. Section 8.1: the default router list (for IPv4 and IPv6) is used as the list of PCP server(s). [...] For the purposes of this document, only a single PCP server address is supported. Should future specifications define configuration methods that provide a longer list of PCP server addresses, those specifications will define how clients select one or more addresses from that list. > RFC7488 did not clarify for me. Yeah, I'm not quite sure what it's about. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [babel] Éric Vyncke's Discuss on draft-ietf-babel-applicability-07: (with DISCUSS and COMMENT)
> Hmm, so do you think it's possible that HOMENET could land in the "uses > secure link layers" bucket? No opinion on the above. I'll only state that HNCP supports running over DTLS (this is implemented in hnetd, the reference implementation of HNCP). Section 8.3 of RFC 7787 describes a distributed algorithm for semi-autonomously choosing a set of trusted DTLS keys. > (It sounds like it's also possibl e it would use babel-hmac or babel-dtls.) If Homenet ends up running HNCP in a secure mode, then it could be used as a trust anchor for Babel. We could do either of the following: - use HNCP to elect a single Babel-HMAC key for the network; - generate random Babel-DTLS keypairs and flood the public part over HNCP; - reuse HNCP keypairs in Babel-DTLS. Of course, if HNCP runs insecure, then it would be somewhat doubtful to use it for key distribution. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Babel-users] althea presentation on isp in a box at nanog 76
> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new > metric that allows for cryptocurrency traffic billing. Justin, could you please document the private TLVs that you're using and register them with IANA? (I'm currently under pressure to make the TLV allocation more onerous, and yours is a good example of why requiring an RFC for every Babel extension is a bad idea.) You're running Wireguard over Babel or the other way around? Any issues with that? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> No, we are assuming that there are one or more homenet routers that either > come with a delegated domain from the manufacturer (probably a very ugly > one), or which that CPE's ISP will delegate via DHCPv6. (or both) I see. (I still disagree with the technical choices, especially that of binding the domain with either the manufacturer or the ISP, but now I see a little better where you're coming from.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
>> Your turn now. Could you please describe the UI that you envision? > The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames) > is presented to the house owner, they click on the ones that the want to > be publically visible. Are you assuming here there's a central Homenet controller that presents a web interface where the "house owner" can choose which names get published? Daniel's original draft used the term "CPE" for the hidden primary. At the time, I pointed out two things: - there's no single CPE in Homenet, there's zero, one or more edge routers which might or might not be ISP-controlled devices; - no Homenet service should be bound to an ISP-controlled device. I believe that these requirements still reflect WG consensus. Assuming that I'm right, I can only see two ways to provide global naming without giving up on the properties above: - we avoid relying on a central controller (hidden primary with web interface); - we define a way to elect the central controller (hidden primary) in a way that doesn't bind the election to an ISP-controlled device. (Am I missing a third option?) The protocol that I have outlined is certainly not perfect, but it has the virtue of avoiding the need for a central controller in the Homenet by outsourcing naming using an end-to-end protocol between the host being named and an external DNS primary. I'm probably missing something, Michael, so please explain if you agree with the analysis above, whether you're assuming a central controller, and, if so, where is the central controller located in a network that has multiple edge routers. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> It would seem your objection can be summarized as "we don't need this". > Correct me if I'm wrong. No, my objection is that I cannot see how that can work in a decentralised manner -- with no central Homenet controller. > To me is like saying we don't need a new routing protocol like BABEL, because > we have loads of routing protocols already. > [for the record I strongly supported incorporating BABEL into Homenet, > because to me it was the best choice] When we argued between Babel and IS-IS, we were deciding between two decentralised protocols. In some sense, we were having an argument among friends -- had someone suggested we use a central SDN controller instead of a distributed routing protocol, we'd probably have ganged on the culprit. If that's okay, I'll give a more detailed description of my objection as a followup to MCR's comment, since the two of you are saying very roughly the same thing. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> Actually, it's fatal, because you can't get a certificate for "boombox.local" > so you can't secure it that way. So you always have to use the FQDN. That sucks, of course, but the problem is completely unrelated to being published in the global DNS -- the very same problem applies to names that only appear in local MDNS. >> I think that's our main disagreement. >> For some reason, you guys seem to be assuming that the average user will >> want to publish hundreds of names in the global DNS. > Hundreds? How about two. > My son wants to publish his desktop's name so that his friend can reach his > system directly for minecraft. I want the same. Your son clicks "publish name" in the Minecraft server's UI, at which point he faces the following dialog box: Domain: dyndns.minecraft.example.com Hostname: minecraft-7ac8 Password: The young man considers that default values are for noobz, and edits as follows: Domain: richardson-family.vanity-dyndns.example.com Hostname: better-server-than-dads Password: After the name is published (which takes half a second), the Minecraft UI displays a "share" icon, so that your son can publish the server's name over UUCP, or whatever it is that them youngsters use nowadays for chatting. Your turn now. Could you please describe the UI that you envision? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] securing zone transfer
> The front end naming architecture uses a primary and a secondary dns server to > synchronize a zone. People will recall that the need for a hidden primary hasn't been established yet. Please see my unanswered e-mail of 21 November 2018. https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
>> If there is a more complex HNCP network, then we could probably simulate >> the L2 scenario with VXLAN, configured by HNCP. > If memory serves, VXLAN requires support for multicast, which HNCP+Babel > doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid > the use of multicast, I'm not a fan. Another issue is that since VXLAN emulates a layer 2 network, it doesn't have any means to regulate MTU; hence, it requires either network-layer fragmentation or the use of jumbograms. Not a fan, sorry. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> If there is a more complex HNCP network, then we could probably simulate > the L2 scenario with VXLAN, configured by HNCP. If memory serves, VXLAN requires support for multicast, which HNCP+Babel doesn't provide. There's a set of IBM (?) extensions to VXLAN that avoid the use of multicast, I'm not a fan. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] wifi broadcast domain - Mikael Abrahamsson's comments
> prplMesh solves the wifi broadcast domain issue. >https://prplfoundation.org/working-groups/prplmesh/ >From their website: « prplMesh is an open-source, carrier-grade and certifiable implementation of the WiFi Alliance’s Multi-AP specification. » That's a purely layer 2 solution that relies on a central controller. It depends on IEEE 1905: https://en.wikipedia.org/wiki/IEEE_1905 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> PIE [...] lends itself better for implementation in existing hardware, > or hardware with small modification. Could one of you please explain why? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
>> I think that this work should be stalled until we have an implementation >> to play with and make some in vivo experiments. > I'm not sure if by "stalled" you mean sticking with the plan above, or > something else I'm concerned about two things: - if you're not implementing yourself, everything seems easy, and you end up with an overly complex design; - once you've spent a lot of time on a paper protocol, you're unwilling to change things even when the implementation work indicates they're broken, so you end up with a design that is not only overly complex, but doesn't work very well. I think this protocol has reached the point where any further paper work will be counter-productive until somebody tries their hand at implementing it. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
Hi Stephen, Sorry if I'm repeating myself -- I've already expressed the opinions below, both at the mike and on the list. > (a) work on simple naming I think that this work should be stalled until we have an implementation to play with and make some in vivo experiments. (Experience shows that the best way to break a protocol is to give an implementation to Dave.) > (b) the drafts on handling names with help from your ISP. I fear that these drafts are a bad case of complexity for the sake of complexity (or perhaps a case of involving the ISP for the sake of involving the ISP). I still haven't seen a compelling argument that they do solve a problem that a trivial end-to-end protocol wouldn't solve. Back in July 2018, I wrote the following: This is a question that I've been asking since July 2014, and I still haven't received an answer I could understand. Please see the thread starting on 18 July 2018: https://www.mail-archive.com/homenet@ietf.org/msg07012.html > (We also have a chartered work item [4] on security that has seen no > progress but you can comment on that as item (c) if you like;-) Some pointers for the rare people who don't spend most of their leisure time reading Internet-Drafts: - HNCP is based on DNCP, which includes a security mechanism designed to provide authenticity, integrity and confidentiality of the HNCP data: RFC 7525 Section 8 I believe that this is implemented in hnetd. (Yeah, Markus and Stephen did some remarkable work.) - Babel has two security mechanisms: https://tools.ietf.org/html/draft-ietf-babel-hmac https://tools.ietf.org/html/draft-ietf-babel-dtls There appear to be no standards-track key distribution and rotation protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems to be the norm), so a natural question is whether HNCP could serve this purpose, or whether it would be better to use a dedicated key distribution and rotation mechanism. - RFC 3971 Section 6 says the following: To protect Router Discovery, SEND requires that routers be authorized to act as routers. This authorization is provisioned in both routers and hosts. Since hosts don't participate in HNCP, it is not clear if HNCP can be used as a SEND trust anchor. I believe there's the same issue with securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> Both HNCP and Babel carry their control traffic over link-local IPv6, but > they support both IPv4 and IPv6 with almost equal functionality. > (The only significant difference is the treatment of border routers, which > are assumed to be doing NAT in IPv4 and stateless routing in IPv6.) > Does that equality mean that I can route from a device in one home to a device > in another over v4. You'll need something like ICE (RFC 8445), or at least STUN (of which ICE is a superset). PCP (or NAT-PMP) should in principle work too, but I haven't actually tried getting it to work over multiple hops. You'll need ICE STUN or PCP even for IPv6, since people appear to be intent on putting stateful IPv6 firewalls on their edge routers. > Won’t they both have rfc 1918 addresses (possibly the same ones). ICE is fine with that. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> I do remember that talk. CS grad students are not our target market. First year undergrad, Ted. Eighteen year-old lass with no previous networking experience. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
>> It should be an easy fix, feel free to go ahead. > The point of soliciting participation at hackathon is for us to gain > collective experience on the easy or difficulty of deploying homenet in > practice. Oh, that's different, and not at all the motivation you give in your previous mail. Experience shows that the best way to make something happen is to organise it oneself, and therefore you should feel free to organise a Homenet tutorial yourself, just like you should feel free to fix yourself the issues you're having with hnetd. I'm not sure that you'll find much of an audience, though -- as you rightly point out, there doesn't appear to be much excitement left around Homenet, and the main contributors appear to have moved on with their lives. It's been six years, after all. (For my part, my IETF funding runs out in September.) On that subject, you might remember the talk I gave about HNCP deployment back in 2016. The conclusions were that a first year student who had never done any networking before was able to deploy an HNCP+Babel mesh network in two weeks, and most of that time was spent learning to reflash off-the-shelf routers from scratch. https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
>> Both HNCP and Babel carry their control traffic over link-local IPv6, but >> they support both IPv4 and IPv6 with almost equal functionality. >> >> (The only significant difference is the treatment of border routers, which >> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.) > Oh, I thought the charter was for v6 only. Did that change, or am > I misremembering? Yeah, I never understood that. The charter is pretty much v6-only, but I don't recall anyone ever suggesting that we should omit IPv4 support (but then, I only got involved around the summer of 2014). RFC 7788 says: While RFC 7368 sets no requirements for IPv4 support, HNCP aims to support the dual-stack mode of operation, and therefore the functionality is designed with that in mind. while the Babel profile for Homenet says: REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol The implementation status is pretty solid: - both implementations of HNCP (hnetd and shncpd) have good support for IPv4 and DHCPv4; - of the six implementations of Babel known to me, four support IPv4 (babeld, BIRD, FRR and David's Top Secret Implementation). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> Both HNCP and Babel carry their control traffic over link-local IPv6, but > they support both IPv4 and IPv6 with almost equal functionality. > in fact while what you are saying is technically true, in practice IPv4 > _is_ treated like a second-class citizen in the sense that if your > ISP-provided public IP address ever goes away, all of your RFC1918 > addresses on the homenet also go away. That's an property of the hnetd implementation, not a feature of the protocol (and it doesn't apply to shncpd). See RFC 7788 Section 6.5. > This is one of the reasons that I would like us to get together and hack on > this at the hackathon: It should be an easy fix, feel free to go ahead. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
> What I meant is that homenet router protocols are v6 only. No, they're not. Both HNCP and Babel carry their control traffic over link-local IPv6, but they support both IPv4 and IPv6 with almost equal functionality. (The only significant difference is the treatment of border routers, which are assumed to be doing NAT in IPv4 and stateless routing in IPv6.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation
Thanks for your reply, Daniel. > If I understand correctly the question is why do we have a Homenet Naming > Authority responsible to outsource the Homenet Zone to the Public > Authoritative > Servers ( Front End architecture) instead of having each device updating their > data directly to the Public Authoritative Servers (End to end architecture) ? Yes, that's a good summary. > * The End to end architecture does not seem to be scalable in term of > management I don't think that this argument is relevant to Homenet. I'd expect most devices in a home network to have no externally visible name. The number of externally named devices is 0 for the typical user, and just 3 for a rather extreme geek (NAS, boom box, and game server). I'm sure we can agree that the end-to-end architecture scales well beyond 3 devices. > The architecture where all devices directly update their data to the Public > Authoritative Servers requires these devices being configured appropriately > with authentication credentials, This is also the case with the proxying architecture: devices are by default not announced to the global DNS, and per-device configuration is needed for devices that want to be named globally. > With the architecture proposed, all this information is centralized to the HNA > and easier to secure. The devices that need to have globally visible names are the secure ones (the NAS, the music collection, the game server). The insecure devices are exactly the ones that should not have a global name. Or are you assuming that I'll want to publish each lightbulb in the global DNS? > * End-to-end Architecture does not provide internal and external views. I don't see how. The end-to-end protocol only publishes names of devices that have been explicitly configured to do so, just like the proxying algorithm. > In addition its design imply that everything is published to the > Internet, and the naming within the homenet hardly work without > connectivity. I don't see how. Homenet-local naming is not impacted by how we publish externelly-visible names. > * End-to-end architecture is hard to get adopted. > DNS update seems the only standard way to update DNS data. There's no reason why DNS updates couldn't happen end-to-end. I am not discussing the exact encoding here, what I'm discussing is the need for a proxy. > Currently most homenet architectures have a CPE that assigns ip addresses to > devices. This statement is in clear contradiction with the Homenet architecture. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation
Dear Daniel, > I am planning to update the front end naming delegation draft [1] in the next > weeks. Before revisiting the draft, I am collecting comments that need to be > addressed. After your talk at IETF-102, I asked what is the purpose of this rather complex protocol, and why it is preferable to a trivial end-to-end protocol. As instructed during the meeting, I carried my question to the list, in a message dated 18 July 2018. A number of people participated in the ensuing discussion, however, none provided a definitive answer to my question. I may have missed something, but as far as I know you did not participate in this discussion. Daniel, please explain why proxying through a hidden master is needed, and what problem this protocol solves that could not be solved with a trivial end-to-end protocol. Thanks for your understanding, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] writeup of my 2018 homenet experience on openwrt
> Markus, I tried to be really clear about what I was communicating on the > slide about implementations, but probably failed. Indeed. A number of your comments about Markus' code were entirely unnecessary. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] writeup of my 2018 homenet experience on openwrt
> Anyway, getting back to topic of Ted's passionate speech about bad HNCP > implementations, I'd love to see him (or someone else) provide better one :-) Ted is busy working on his implementation of Simple Naming. Please leave him in peace, it's important that he convince us that Simple Naming is as simple as he claims. (Not that we don't trust him, but obviously nobody in this WG would ever seriously listen to a person without an implementation.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] writeup of my 2018 homenet experience on openwrt
>> From a user perspective, there are a few problems: > When an interface goes down and then up again, it's renumbered. This > includes reboots. That shouldn't happen as long as there remains at least one Homenet router to maintain the prefix (see Section 4.1 point 3 of RFC 7695). I believe that hnetd (but not shncpd) additionally supports some mechanism to handle the case where there are no routers left to maintain the prefix, but I'm less sure. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] (no subject)
> Juliusz is saying that he wants a nearly stateless homenet; No, I'm not. > for him, putting the public/primary functional block in the cloud makes > sense No, it doesn't. Ted, please don't put words into my mouth. It's unpleasant, and it's disrespectful. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] (no subject)
> if the homenet loses its memory, it can simply refresh it from the cloud. What? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] (no subject)
>> 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. > If publishing things into global DNS worked reliably and automatically, > and we had IPv6 everywhere, such designs would not be needed... That's arguable, but we can probably agree that Daniel's draft does not provide a useful service for these applications. For example, if I'm using Skype, I want to be globally findable even if I'm at an IETF meeting in Bangkok -- whereas Daniel's draft only allows me to publish my address if I'm in my Homenet. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> 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. > 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. 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"). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> Apparently my comment was clear as mud. I meant this: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-25 Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages. Revision 25, and still a draft. I wish you a lot of fun implementing that. > Having a public/private zone pair where the public zone is an image of > the private zone that is constructed following rules, the default rule > being "don't copy," seems very straightforward to me. It's not clear to > me in what sense it's brittle. It's brittle because you have state in the network. (You know, end-to-end argument and so on.) More concretely: - what happens when the current hidden master loses an election? Is the state magically transferred? - what happens when the current hidden master crashes/is unplugged/is retired? let alone the issue of electing the hidden master in the first place, which I believe Daniel hasn't addressed at all. > To me, the difference between what you are proposing, Juliusz, and what > Daniel is proposing, is where the control point is. For you, the control > point is the device. That's right. > For Daniel, the control point is the resolver. Which resolver? (I could be wrong, but I don't think that the Homenet architecture has a central resolver.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> By using DynDns are you proposing to remove the requirement of having > a naming resolution mechanism internally in the homenet ? No. Naming *internal* to the Homenet needs another mechanism, perhaps what Ted is designing (and implementing), perhaps something else. 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. > But considering that we need an internal dns to serve internal requests > (regardless of an ISP connection) and that we also need an outsourced > one for external resolution, isn't it simpler to make them synchronize > in a primary / secondary fashion ? Wouldn't it be an extra work to > manage (update/add/delete) multiple records through dyndns ? I claim it isn't. Synchronising with the external DNS provider is no more work than synchronising with the hidden master, and it avoids the hairy issue of electing the hidden master. > From my understanding dyndns would solve just a small part of the whole > problem being tackled here which is: providing internal/external name > resolution and manage the synchronization of an entire zone, rather than > updating a single record continuously. It solves the issue of exporting names into the public namespace. This has nothing to do with name resolution internal to the Homenet. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> One way to automate this would be using mud. A bright light shines from the heavens, bathing you in its warm glow. An enormous, white temple stands to the north, taking most of your view. In order to enter the Temple of Homenet Naming, you must travel up the large staircase that stands in front of you. Exits: North, West, East, South. (Perhaps you had something else in mind when you said MUD?) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> On the other hand same thing using nsupdate (using TSIG and dynamic > dns) is one command line + input file for nsupdate: Cool. Whichever end-to-end (host to DNS provider with no intermediate proxying) encrypted and authentified protocol you pick, I'm with you. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
>> And it's literally four lines of shell: > vs > while true; do > (omitted for brevity) You're doing end-to-end dynamic update over DNS, which is fine with me. The exact transport we end up using doesn't matter that much. You're not doing the proxying through a hidden master mandated by Daniel's draft, which is what I find complex and fragile. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> I am not speaking about discovery within the Homenet. I am speaking about > exporting names into the global DNS, which is what Daniel's draft is > about. > Yes, but the problem is that you are treating this as if these are two > separate problems, but they are not. These are two completely different problems, with different default behaviours and different failure modes. The default behaviour for the local zone is that devices should be discoverable. The default behaviour for the public DNS is that a device should not be published unless it takes explicit action. It makes a lot of sense to have two different protocols, rather than essentially leaking a local zone into the ISP's DNS servers. > I'm not following your reasoning here -- why does the zone being tied to > the ISP imply that we must use a more complex protocol? > Doing this transaction over HTTP means another service that the ISP has > to operate, Not the ISP, a third-party DNS provider. That's the whole point. > and another service that the HNR has to connect to. Not the HNR, the end host. That's the whole point. And it's literally four lines of shell: while true; do wget --post-data 'name=gameserver.myhome.net=topsecret' \ https://dyndns.example.com sleep $((24 * 3600)) done > Quite the opposite. In the trivial update protocol, the update is > end-to-end, encrypted, and only the host and the DNS provider see the > data. > You've published a record in a public zone. It doesn't matter that the > protocol you used to publish it is privacy-protecting, because the > publication of the name immediately negated that. With delegation through an ISP-controlled hidden master, the ISP gets a database of all the names published by all of its users. With an encrypted connection to a DNS provider, the ISP needs to troll all of the DNS providers in order to build such a database. > I actually share your concern that what he's got written down right now > is more complicated than it needs to be, and this is partly because it > was originally motivated by his work at an ISP. Uh-huh. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] In-network connectivity and HNCP: IPv6 ULA
> I think the local ULA should be used for all intra-ULA connections. We had a > debate about this about four years ago, and apparently the text in the HNCP > spec reflects the outcome of that discussion, but I think we understand the > problem better now and we should fix this. Agreed. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] In-network connectivity and HNCP: IPv6 ULA
I've re-read Section 6.5 of 7788, and it looks like I was wrong. Sorry, I should not be writing technical mails in the middle of the night. As far as I can tell from the wording of 6.5: - creating ULA is SHOULD if there's no global IPv6, MUST NOT otherwise; - creating private IPv4 is MAY if there's no global IPv4, MUST NOT otherwise. If my reading is correct, that sucks. I don't see how the MAY can be implemented, since there's no obvious way to distinguish global from local IPv4, and if you don't implement the MAY, then you'll lose local IPv4 whenever your IPv4 provider has a glitch, as you described. > if you have a connection over IPv4 and suddenly your IPv4 network is > deconfigured, your connection will hang. The point Brian and I are trying to make is that you should have no intra-Homenet IPv4 traffic -- your applications should prefer IPv6 to IPv4, and and there should always be IPv6 in your Homenet. Unfortunately, our point is made moot by the first MUST NOT above, since the ULA becomes deprecated whenever there's global IPv6. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> In order for services to be discoverable on the homenet, they have to > publish their contact info on the homenet. The protocol that everyone > uses for this is DNSSD. This is how you find your printer when you want > to print to it. Nobody uses the ad-hoc DynDNS protocol for this. I am not speaking about discovery within the Homenet. I am speaking about exporting names into the global DNS, which is what Daniel's draft is about. > It's certainly true that we could use an HTTPS-based protocol for setting up > delegations for the forward mapping zone. This makes a great deal of sense, Good. > The reverse mapping zone has to be delegated by the ISP, so we might as > well do it in a prefix delegation transaction. I'm not following your reasoning here -- why does the zone being tied to the ISP imply that we must use a more complex protocol? > So if you are advocating this second thing, that makes sense, and we should > definitely talk about whether it makes sense to do it this way. Let's. > Also, think of the privacy implications if all of the services on the > homenet had to be discovered from a shared zone like dyndns.org. Quite the opposite. In the trivial update protocol, the update is end-to-end, encrypted, and only the host and the DNS provider see the data. Every Homenet, every host, heck, even every application can use a different DNS provider, and each DNS provider only sees the data that was explicitly sent to it. In Daniel's protocol, the data goes from host to hidden primary to DNS provider. The hidden primary is probably controlled by the ISP, which is convenient if you happen to be a privacy-violating ISP. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] In-network connectivity and HNCP: IPv6 ULA
>> But if we want homenet to be widely adopted, I do not think this is the >> correct default behavior: it violates the principle of least surprise. > There's no surprise, it just works. RFC 6724, Section 6, Rule 8. Er, no. ULAs have global scope. My bad. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] In-network connectivity and HNCP: IPv6 ULA
> In order for IPv6 to be useful, you need naming to work. No argument here. > But if we want homenet to be widely adopted, I do not think this is the > correct default behavior: it violates the principle of least surprise. There's no surprise, it just works. RFC 6724, Section 6, Rule 8. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
> All of this can be done in the DNS without resorting to any other protocol. Excellent. So what technical reasons are there to prefer the complexity of draft...front-end-naming-delegation over a trivial update protocol, whether encapsulated in HTTPS or DNS? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] In-network connectivity and HNCP: IPv6 ULA
During his talk, Ted claimed that he lost all connectivity when his uplink went down. This should not happen -- HNCP normally maintains an IPv6 ULA that remains stable no matter what happens to DHCPv6 prefix delegations or DHCPv4 leases. This is described in Section 6.5 of RFC 7788, and it is the default behaviour of hnetd. Either Ted had tweaked the configuration of hnetd (which one should not do -- hnetd does the right thing out of the box), or he was using software that doesn't speak IPv6 or ignores ULAs. At any rate, HNCP does not have the issue that Ted described. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS
Dear all, Since the 1990s, people have been putting their dynamically allocated IPv4 addresses into global DNS by using a family of gratuitiously incompatible trivial protocols. The technique doesn't have an official name (let alone a specification), and is usually referred to as DDNS, DynDNS or Dynamic DNS. The basic idea is as follows: - the client is configured with its DynDNS provider; - whenever its public IP changes, the client makes an HTTP request to register the name directly with the provider. Usually, but not always, there's some form of garbage collection -- if the client fails to refresh its name within some timeframe, the entry is deleted. Security can be achieved either by using HTTPS with a plaintext password, or by using clear HTTP and a cryptographic challenge mechanism. This kind of protocol has a number of desirable features: - the client side can be implemented in roughly 4 lines of Python; - it's end-to-end, so no privacy issues (if using HTTPS); - it's end-to-end, so it doesn't depend on any local infrastructure; - it's end-to-end, so it can be used in a foreign network (e.g. you can use it to advertise the address of the game server you run on your laptop during IETF meetings). DynDNS has been widely deployed for 20 years or so, and would appear to solve the problem of name outsourcing quite nicely. What technical problem is draft-ietf-homenet-front-end-naming-delegation solving that is not adequately solved by a DynDNS-style solution? This is a question that I've been asking since July 2014: https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA and I still haven't received an answer I could understand. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] About Babel security
For people who have missed the Babel meeting, both David and I have done our best to write self-contained slides. They're here: https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-hmac-in-babel-00 https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-dtls-in-babel-00 The protocols have two independent implementations each. HMAC has already demonstrated interoperability, DTLS hasn't. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Benjamin Kaduk's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
>REQ5: a Homenet implementation of Babel MUST use metrics that are of >a similar magnitude to the values suggested in Appendix A of >RFC 6126bis. > "MUST" and "similar magnitude" are not a great pairing. Fixed. This is now "must", the exact values are still SHOULD. > I agree with the secdir reviewer that the link classification is > important, and would suggest a that SHOULD become MUST for "if it is > unable to determine whether a link is wired or wireless, it MUST > make the worst-case hypothesis". I most humbly disagree. Babel is sufficiently robust to survive misassignment, the consequence will be sub-optimal routing, and only if mis-assignment happens on both ends of a wireless link, and only in non-trivial topologies. I think the consequences are sufficiently benign for us to afford leaving some latitude to implementers. > Section 4 > I always worry a little bit about the ability to classify links as > "trusted", but there are probably cases where it's valid to do so. I agree that HNCP edge detection is not satisfactory, but that's the best we've got right now, and it's time we moved forward. Hopefully the security work will progress so that we can make crypto the default at some point, thus making this issue moot, but I request that this document should not be held up waiting for the security work to complete. > I do wonder whether it's worth enumerating the "upper-layer security > protocol"s that HNCP and Babel support, as there are tradeoffs among > the PSK/PKI/TOFU options that the implementor may need to consider. Since this document is intended for standards track, I worry that an enumeration will be taken as exhaustive, and limit the choices of the WG. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Ben Campbell's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
> §2.1, REQ5: I agree with Benjamin Kaduk that " MUST use metrics that are of >a similar magnitude" is a bit vague to be used with a MUST. This is now "must". Exact values are still SHOULD. > §1.1: Please consider using the 8174 boilerplate. There is at least one > instance of a lower case keyword. Done, sorry. > §2.2 and others: I find the term "non-requirements" confusing here. Please > consider "Optional Requirements". This is now "Optional features". Thanks for the suggestion. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Alvaro Retana's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
> I do have some non-blocking comments: Thank you very much, Alvaro. > (1) I think that this document walks a fine line when Normatively > referring to Appendix A in rfc6126bis given that it is an informative > appendix. Fixed to use non-normative language, as you suggested. > (2) This reminds me; please use rfc8174 template (for Normative language). Done, sorry. > (3) The Non-requirements sections (2.2/3.2) are confusing to me. Maybe it's > the "negative logic"... I've renamed "non-requirements" to "optional features" -- NR1 is now OPT1. > NR2, for example, is worded as a requirement that was considered, and > the rationale explains why not: an "implementation of Babel MAY include > support for other extensions" s/MAY/may/ > (3.3.1) NR3 -- The text says that the requirement not considered > (non-requirement) is such that "an HNCP node that receives a DHCPv6 > prefix delegation MAY announce a non-specific IPv6 default route", but > the rationale says that "announcing an additional non-specific route is > allowed". I'm confused. Is announcing the additional route ok, or not? > Is it ok to assume that optionally advertising the additional route is > ok? If it's allowed, then why is this a non-requirement? This is hopefully clear now -- announcing the non-specific route is an optional feature. > (3.3.2) For NR4, is the non-requirement, i.e. one that was not > considered, that the source-specific route SHOULD NOT be announced? > This piece is also confusing to me because the rationale says (at least > the way I read it) that it may be ok to advertise. It seems to me that > the text is saying that in fact the route SHOULD NOT (or even MUST NOT > be announced)...which brings me to the question: what is the requirement > that was not considered? What am I missing? I've re-read the section, and I think I'm going to leave the current wording. The intent is: - we don't recommend you do it, since it makes your network more complex with no benefits we can see; - however, it won't break your network, so if you've got a good reason we didn't foresee, it's not forbidden. It is my understanding that this fits pretty well the meaning of SHOULD NOT. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet agenda update
> - draft-ietf-homenet-babel-profile-06 waiting on Juliusz for updated draft My current draft of -07 is here: https://raw.githubusercontent.com/jech/babel-drafts/master/draft-ietf-homenet-babel-profile/draft-ietf-homenet-babel-profile.xml It addresses all of Tim Chown's Opsdir review, almost all of Stewart Bryant's Genart review, and almost all of the IESG's comments. I've allowed myself to disregard one of Stewart Bryan's comments, and only partially followed Alvaro's suggestion to remove normative language from the optional section. Stewart, Alvaro, please let me know if you feel strongly about that. Plan is to listen for any comments during the Montréal session (which I'll be attending remotely), and publish -07 as soon as the server reopens. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] A summary of Babel cryptographic extensions
Hi, and sorry for the massive cross-posting. I suggest followups should go to babel@ietf. The mails that I'm receiving indicate that we (Babel@IETF) have confused some people with our crypto plans. Thanks to all for your questions, and let me please try to clarify things publicly. Considering security, I am concerned by the tension between simple, auditable protocols and excessive complexity due to additional features. Of course, we could just design a simple protocol and say that extra features are out of scope, but many of the feature requests are actually legitimate (confidentiality, asymmetric keying, pairwise keying, ASN.1, etc..). So we're currently pushing for having two protocols for Babel: - HMAC for Babel [1,2,3], which is simple, understandable, implementable, and has almost no dependencies, but requires minimal changes to Babel, but has minimal features (static symmetric keying only, no pairwise keying); - Babel over DTLS [4], which pushes the crypto down to DTLS, and therefore has all the creepy features of your DTLS implementation -- at the cost of depending on a DTLS library, which some feel is overkill. [1] https://tools.ietf.org/html/rfc7298 [2] https://tools.ietf.org/html/draft-ovsienko-babel-rfc7298bis [3] https://tools.ietf.org/html/draft-do-babel-hmac [4] https://tools.ietf.org/html/draft-decimo-babel-dtls (References draft-ovsienko and draft-do are two competing protocols, both based on RFC 7298; I'm supporting draft-do or something based on it.) Both protocols have implementations [5,6], and independent reimplementations are in progress or at least being considered. Details are likely to change, but the implementations are mature enough for experimentation. [5] https://github.com/MisterDA/babeld branch unicast-dtls [6] https://github.com/wkolod/babeld branch hmac-challenge What I'd like to see eventually is: - both protocols published as RFCs; - one of the protocols being the recommended protocol (I'm kibbitzing for HMAC); - all publicly available implementations of Babel supporting the recommended protocol, at least as a compile-time option. Concerning Homenet -- Homenet will need at some point to decide what HNCP security looks like, and decide how it interacts with Babel security. My personal opinion at this early stage is that HNCP should perform key negociation and distribute symmetric keys to Babel-HMAC, but I know that at least one prominent visionary in the Homenet community feels rather strongly about asymmetric or pairwise keying. Given that HMAC security is probably going to depend on DTLS anyhow, it's not unreasonable to require Babel-DTLS in Homenet. We'll try to arrange for presentations on the subject at IETF Montréal, but all the parties involved are rather busy, so it's not a given. I hope this clarifies things, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-simple-naming-02.txt
> My biggest problem is that I don't have a very clear idea of how this all fits > together. Same here. As I mentioned at the microphone in London, there's a lot of moving pieces here, and everybody would feel much more comfortable if 1. we could have a look at Ted's implementation; and 2. somebody could produce an independent reimplementation. That's what we did for HNCP back then (Markus, Steven and Pierre published their implementation, and then I did an independent reimplementation), and I believe it helped to put everyone at ease. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)
>> The draft lives here: >> >> https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls > As far as the commit history goes, the file was first added to the > repository above on 25 June 2018 (four days ago), then it was updated > three times on 27 June 2018 and two times on 29 June 2018 (today, last > time about three hours ago). This is partly my fault. Antonin is a full-time student, and I have been recommending that he follow his classes and pass his exams in priority to doing IETF work. I stand by this advice, and remain convinced that this was the right thing to do. > I have studied the document and I find it difficult to discuss right > now, to be honest. Please let us know what it is that you didn't understand. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)
Dear Denis,
Thank you very much for your kind mail.
Unfortunately, I think there might be some confusion:
- DTLS is Stenberg-style security;
- HMAC is Ovsienko-style security,
- it has four variants (7298, 7298bis, DKC, Stenberg)
- two of which have fatal flaws (7298 and 7298bis).
I am really sorry for causing confusion by using both DTLS and
Stenberg-style for what is the same thing, and for furthering this
confusion for using "Stenberg variant" for one variant of the HMAC
protocol.
> Another fact is, in early 2016 you were promoting the pre-IETF Babel
> work before and at the Babel BoF and claimed that besides the HMAC (then
> RFC 7298) approach to Babel security there was another viable
> alternative, namely, "Stenberg-style security". You were promoting the
> idea that the Babel WG should evaluate both mechanisms and choose the
> best.
> * Q1: Do you acknowledge these two facts and do you agree they are
> directly related? (yes/no, please explain if "no")
Yes, besides HMAC I have been advocating DTLS, also known as
Stenberg-style security. Markus Stenberg is a competent security
expert, and I always try to listen to his advice.
> The specification of "Stenberg-style security" for Babel was never
> published. It is June 2018 and I have never seen it, although I asked
> to.
It was presented at IETF 101 in March 2018 (at which you were present).
The draft lives here:
https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls
I am not an author. Please ask the authors, not me, about why it hasn't
been published yet.
> * Q2: In 2016 did you know "Stenberg-style security" for Babel did not
> exist as a workable WG item in the first place? (yes/no)
DTLS, also known as Stenberg-style security, has been implemented by
Antonin Décimo and independently reimplemented by David Schinazi during
the spring of 2018. It took somewhat longer than expected, for various
reasons that are none of your business (such as Antonin wanting to pass
his exams).
> * Q3: Why were you promoting a WG option that either you didn't verify
> exists in the first place (if "no" above) or you definitely knew does
> not exist (if "yes" above)? Please explain.
I knew it didn't exist at the time. I was confident we could make it
happen. Antonin and David have made it happen, which shows that I was
right.
> At some point between 2016 and 2017 you stopped mentioning
> "Stenberg-style security" and began to promote DTLS for Babel
> security. The first "running code" prototypes (not implementations)
The two are the same thing. Sorry again for the confusion.
> * Q4: In 2016-2018 did you know a specification for the "DTLS" Babel
> security did not exist as a workable WG item? (yes/no)
Stenberg-style security and DTLS are the same thing, so my answer to Q2
applies.
> * Q5: same as Q3
Stenberg-style security and DTLS are the same thing, so my answer to Q3
applies.
> * Q6: Do you agree your long-time presenting effort had created and
> maintained an impression that the "alternative" security option was
> viable and workable by the Babel WG, regardless of its actual status
> at the time? (yes/no, please explain if "no")
Yes, I did believe that DTLS was viable, and did my best to communicate
this fact to the list. As explained in my answer to Q2 above, I maintain
that I was right.
> * Q7: If "yes" to Q6, was this impression what you intentionally were
> trying to achieve? (yes/no, please explain if "no")
Yes.
> * Q8: If "yes" to Q6, do you agree this impression has been influencing
> decision making in both Babel and Homenet WGs? (yes/no, please explain
> if "no")
I do not know. Please ask the WG participants.
> * Q9: Do you agree the end effect was that the work on HMAC Babel
> security was held back in the Babel WG? (yes/no, please explain if
> "no")
No. I have been actively promoting the HMAC work ("Ovsienko-style"), just
as I have been promoting the DTLS work ("Stenberg-style").
The HMAC work has been held up because 7298bis had fatal flaws.
> * Q10: After the WG decision about HMAC (which was in line with your
> latest position at the time) are you still maintaining that choosing
> between HMAC and DTLS would benefit the Babel WG? (yes/no, please
> explain if "yes")
I would like see both HMAC and DTLS published as Standards Track
documents. It will be a lot of work, but I am confident that we will
manage it.
I would prefer that we didn't choose between the two -- I want to have
both. As stated publicly at the microphone at IETF 101 in London, should
we be forced to choose, I would support HMAC. Of course, I may change my
opinion in the future, it depends on how HMAC and DTLS will develop.
> * Q11: If "no", could you explain why did not you denounce the idea on
> the mailing list with appropriate comments?
I do not understand the question. It is not my role to "denounce"
anything or anyone, I merely express my opinions, just like any
Re: [homenet] Introduction to draft-ietf-homenet-simple-naming
> Well, let me invent something. I throw together my network and it > names the printers as printer1 and printer2. Being a stickler, > I decide to rename them as Printer 1 and Printer 2. I mess around > and find a config file somewhere and manually edit it. Let me rephrase it: « For her birthday, I bought my girlfriend the nice printer she's been wanting. The network named it "Printer7839cf31". Since I love my girlfriend, I renamed it to "Mathilda's printer". Now she can no longer print. » > It would be good if you could come up with a real example. This isn't > going to happen in practice, (Giggle.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Martin Vigoureux's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
> Perhaps he refers to the RFC8174 update to the boilerplate: Ah, thanks. Will do. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Martin Vigoureux's No Objection on draft-ietf-homenet-babel-profile-06: (with COMMENT)
> you should refer to 8174. Perhaps you could kindly justify your advice? Non-capitalised "must" is used just once in this document, and I don't see any opportunity for ambiguity. -- Juliusz ___ 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
After much thought, I have settled on the following: Rationale: support for wireless transit links is a distinguishing feature of Homenet, and one that is requested by our users. In the absence of dynamically computed metrics, the routing protocol attempts to minimise the number of links crossed by a route, and therefore prefers long, lossy links to shorter, lossless ones. In wireless networks, "hop-count routing is worst-path routing". I find the previous version clearer and more informative, but I've read ISO/IEC 10589, and therefore understand that the author of a Standard should aim to sound professional rather than indulging in such amateurish endeavours as being clear or informative. -- Juliusz ___ 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
> 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. ___ 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
>> 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. (Since we all seem to be in a chatty mood -- on Tuesday last, I was teaching virtual memory allocation techniques, and needed a translation for "eager allocation" as opposed to "lazy". One student proposed "allocation zélée". I'm loving it.) -- Juliusz ___ 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
> I too think the rationale is important but the phrasing may be confusing. > Being > a native speaker of U.S. English (and almost fluent in Southern Californiaese > ;-) I found the colloquialisms confusing. Being myself a native speaker of an Eastern-European dialect with way too many postalveolar fricatives, I will be grateful for additional guidance. > Perhaps I could suggest something in the vein of "very important" or > "much desired feature" 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. Long-term, the important feature of Homenet is having a clean architecture for multi-link IPv6 networks. From the point of view of the end-user, however, multiple layers of NAT work just as well, so it's not a "killer" feature. Short-term, the two visible features are support for multiple uplinks and support for wireless transit. No other protocol stack can do either of these without manual intervention, so these are Homenet's "killer" features. I agree that the term might not be familiar to everyone, and I would be sincerely grateful for help with expressing this notion concisely and without undue colloquialisms. > I found the term "bosses" leaving much to interpretation This happens to be deliberate. I am trying to avoid implying too much about the organisational structure to which the reader belongs -- the "boss" here could be the CIO, but it could be the leader of an Academic project, it could be the supervisor of the intern who's implementing Homenet, or it could be the Benevolent Dictator for Life of a Free Software project. 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".) > or perhaps even "Corporate" used instead. Now you're trying to pick a fight ;-) -- Juliusz ___ 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
> I am the assigned Gen-ART reviewer for this draft. Thanks for your comments, Stewart. > if implementations use conflicting route selection policies, > persistent oscillations might occur. SB> Is this consistent with the statement earlier in the para that SB> " Distinct SB> implementations of RFC 6126bis Babel will interoperate, in the SB> sense that they will maintain a set of loop-free forwarding paths"? Yes, it is consistent. Please see Section 3.6 of rfc6126bis. In short, Babel guarantees that the forwarding graph remains loop-free at all times (which is somewhat weaker than what you'd expect -- in particular, it does not entail that a packet will never pass the same router more than once). It does not make any guarantees about the stability of the forwarding graph if the route selection policy is completely crazy. As far as I am aware, the problem of defining the class of non-crazy route selection policies is an open research problem. The best we can do, to the best of my knowledge, is give examples of policies that do not cause oscillations. This is not unlike BGP, which does an excellent job avoiding loops, but does not prevent persisten oscillations in the presence of crazy policies. Interestingly enough, a numbre of papers indicate that this is not a problem in the Internet, and that router operators are pretty good at defining reasonable BGP policies. I believe the same is true of Babel. > Since IPv6 has some > features that make implementations somewhat simpler and more > reliable (notably link-local addresses), we require carrying > control data over IPv6. SB> Earlier you said that IPv4 also had Link Local addresses, so how SB> can link local addresses be the deciding selection criteria? Is there SB> something technically better about IPv6 LL? No, I didn't -- I'm trying to be consistent, and use LL to mean fe80::/64. I believe the issue is in Section 1, where I say traffic is carried over either link-local IPv6 or IPv4 where what I mean is either link-local IPv6 carries traffic, or IPv4 carries traffic. I'm not a native speaker, and I'll be grateful if you can suggest a better formulation. > Minor issues: > Rationale: support for wireless transit links is a "killer > feature" of Homenet, something that is requested by our users and > easy to explain to our bosses. In the absence of dynamically SB> Not sure explicability to your boss counts for much as a basis for SB> a feature an international standard. I think this paragraph is helpful for implementors -- it helps people explain to their bosses why we're bothering with link-quality estimation when we've done routing protocols with no link-quality estimation for the last fifty years or so. (The Fuzzball LSI-11 router had link-quality estimation, but that was in the 1980s.) Still, if you find the tone too informal, I'm open to reformulating. > Abstract >This document defines the subset of the Babel routing protocol and >its extensions that a Homenet router must implement, as well as the >interactions between HNCP and Babel. SB> HNCP needs to be expanded Both need a reference, but the reference SB> needs to be expanded i.e. RFC7788 not [RFC7788] Is this consistent with the last sentence of RFC 7322 Section 4.3? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security work items - what do we want to do?
> the AmazonEcho/GoogleHome/Mycroft/etc. devices seem like ideal platforms > to be the root of a secure network. Huh? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security work items - what do we want to do?
> I do agree we'd need to know e.g. whether Babel implementations would > plan to support what flavours of DTLS (e.g. pre-shared keys vs. bare > public keys vs. certs if they do plan to use DTLS), I'm not worried about Babel. I am worried about HNCP, since I fear there's nobody who's both able and willing to work on HNCP extensions for security. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-babel-profile-04.txt
> Filename: draft-ietf-homenet-babel-profile-04.txt Barbara has pointed out that I had some minor changes in my git repository that I hadn't submitted yet. Barbara also requested that I upgrade this draft to Standards Track before I quit. I couldn't possibly bring myself to refuse a request from Barbara. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] I quit as editor of draft-ietf-homenet-babel-profile
Dear Barbara, dear Stephen, After re-reading the comments I have received on the mailing list, and re-reading my slides from 2017-03-27, I have decided that this has taken way too long. I hereby quit as editor of draft-ietf-homenet-babel-profile. Should you be able to find a new editor, I expect to remain a co-author. Regards, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet-babel-profile: determining link type
>> Should we really only suggest that the router dynamically probe the >> quality of wireless links? Or would it make sense to suggest dynamic >> probing of all links, because assuming the entire path between 2 >> routers uses a single physical layer technology may not be a good >> assumption? > I agree that is should probe all interfaces! Then you need to define suitable algorithms for non-WiFi interfaces. I'm open to collaboration, of course, since dynamically computed metrics is something that's close to my heart. (Somebody promised to send me some G.hn hardware at some point, but they must have forgotten.) > Some wires might be better than others; assume use of random joiners between > cat3,cat5,cat6 and chicken wire in the home. Babeld's wireless link quality estimation triggers around 5% packet loss; on WiFi, it only works because we're careful to send frames that are not protected by ARQ -- after ARQ, the loss rate is way below that, even on dodgy links. You're not going to get loss rates that over chicken wire (unless you've got really bad quality chicken wire). > (a booth at N+I back in ~2000 or something had a very nice GbE over > barbed wire demo) Somewhat charged politically ;-) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet-babel-profile: determining link type
>REQ6: a Homenet implementation of Babel SHOULD distinguish between >wired and wireless links ; if it is unable to determine whether a link >is wired or wireless, it SHOULD make the worst-case hypothesis that >the link is wireless. It SHOULD dynamically probe the quality of >wireless links and derive a suitable metric from its quality >estimation. The algorithm described in Appendix A of RFC 6126 MAY be >used. > Some older powerline technologies perform worse than Wi-Fi. But since > powerline is "wired", this requirement suggests it would be preferred. Do you have a suggestion for better wording? I guess we could say "lossless wired links" and "potentially lossy links". I'll think about it. > Also, it's not uncommon to use Wi-Fi to Ethernet or powerline bridges in > home networks. A router attached to Ethernet that is subsequently > bridged to Wi-Fi would look to the router like a wired link. Yes, that's a problem for Babel in general, not just for Homenet. It is impossible to reliably determine the layer-2 topology. There are two factors that mitigate the issue: 1. usually, there is a wireless bridge on just one side of a link; if the link is being treated as wireless on the other side, we still end up with a reasonable metric; 2. powerline links are not usually laid up in places where they are redundant; if there's a powerline, it's the only path, and so the metric doesn't matter in the first place. > Should we really only suggest that the router dynamically probe the > quality of wireless links? We only have implementation experience with three categories of links -- lossless, wireless, and tunnels. If we are to suggest a strategy for powerline, we need to do more research. We also need evidence that it makes a difference. > Or would it make sense to suggest dynamic probing of all links, because > assuming the entire path between 2 routers uses a single physical layer > technology may not be a good assumption? Link-quality estimation slows down convergence, so I think we should only suggest it where it makes a difference. For it to make a difference, you need to satisfy two conditions: (1) variable quality links that can be measured and (2) sufficiently diverse paths so that the metric can make you choose different paths. It's easy to get the two to happen with wireless links, much more difficult with powerline. If you have evidence otherwise, I'm interested. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet-babel-profile: status experimental?
> Currently the draft has intended status of "Experimental". That's what Mark told me to do. > Given the intended status of 6126bis is Standards Track (and HNCP (RFC > 7788) is also Standards Track), would it make sense to make > homenet-babel-profile Standards Track as well? Yes, I think so. > This question does depend on which Babel spec homenet-babel-profile will > reference (6126 or 6126bis). [I sent a separate email with comments > related to references.] If homenet-babel-profile is going to use 6126 as > its spec reference, then Experimental probably would make more sense. It's going to use 6126bis. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet-babel-profile: references
>> draft-chouasne-babel-tos-specific-00 may also cause issues, even though >> it is just informational. You may want to consider removing the >> reference so it doesn't create issues. > Ok. Does the same apply to [BABEL-Z]? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet-babel-profile: references
Thanks, Barbara. > The first 4 references to the "Babel routing protocol" spec are to > [RFC6126bis]. All subsequent mentions are to RFC 6126. Changed to 6126bis throughout. Since Homenet depends on source-specific, and source-specific depends on mandatory bits, Homenet cannot be implemented with just 6126. > If 6126bis, then I suggest changing the reference name from [RFC6126bis] > to something like [BABEL-PROTOCOL]. [...] > If you choose to go with a friendly name for the 6126(bis) reference, > consider also friendly-naming RFC 7788 to something like [HNCP] and RFC > 7298 to [BABEL-HMAC]. I've previously been chastised for the opposite (using friendly names instead of the RFC numbers), so I'm leaving it as it is right now. If you're sure of yourself, I'll be glad to change to friendly names. > draft-chouasne-babel-tos-specific-00 may also cause issues, even though > it is just informational. You may want to consider removing the > reference so it doesn't create issues. Ok. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] comments on babel-profile-03
> I re-read babel-profile-03 and have a few comments (below) > offered as a WG participant (i.e. chair hat off) as part of > WGLC. Thanks, this is appreciated. > - Req5: Is "MUST be... of a similar magnitude..." clear enough? Yes. Minor tweaks to metrics don't cause suboptimal routing -- if one router vendor chooses 64 as the cose of a wired link, and another uses 96, then one hop is still preferred to two hops, which is what matters at the end. On the other hand, if one router vendor picks a cost of 1 and another one chooses 256, then bad routing will occur. Here, the costs are not of similar magnitude. The reason we don't want to be too precise here is that we want to encourage vendors to experiment with smarter out-of-the-box metrics. For example, a vendor that cares about powerline ethernet should be allowed to do something smart to prefer Ethernet to powerline. > - 2.2: I'm not sure this entire section is useful. If there is > something specific we'd like to avoid (at a MUST NOT or NOT > RECOMMENDED level), it'd be better to say exactly what. "Non-recommendations" are just MAYs. Perhaps the term is badly chosen, if you have a better suggestion, I'm listening. What this section says is basically "if you want to be smart, that's cool, but if you're in a rush, don't bother, it's not expected to be particularly useful in a home network". Let me know if you have suggestions to make it clearer. > - NR2: I don't see the point of that. If See above. The point here is the rationale -- we're explaining why the smarter metric computation algorithms are not going to matter in a home network. > - section 3: "...using the existing redistribution mechanisms" > could maybe do with a reference for seme well known OS. I think redistribution is a standard term -- it's used by Quagga and by Cisco, at least. > - NR3: I don't see what is not required here, that seems like a > straightforward 2119 MAY statement Yes. See above. > - section 4: "only susceptible" seems like overstatment. If > babel picks up routes from the OS and then annouces those, [...] > - section 4: "secured at a lower layer" includes links with no > security (in reality), is that right? [...] > - section 4: "trusted X" is not a good term unless you say > who/what is trusting whom/what for what. So, s/trusted > links/links/ would be better. [...] > - section 4: The security properties here seem to be directly > and wholly dependent on nodes being able to safely identify > interfaces into the categories in 5.1 of 7788. I need to do > some more reading to convince myself that that's a good thing > to assume. [...] > If there are weaknesses in that assumption, then it'd be better to call > those out here, [...] > - section 4: I dislike the plan of assuming lower layer security [...] You're right on all counts, as usual. However, this document is called "Homenet Babel Profile", it's not called "Security Considerations for the Homenet Protocol Suite". I think the right thing to do would be to replace all of Section 4 with a single sentence that says "This document describes the profile of Babel that is implement in Homenet implementations and the interaction between HNCP and Babel. It does not in any way change the security properties of those two protocols." and let somebody competent write another document, called "Security Considerations for the Homenet Protocol Suite". Is that a plan? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] About draft-homenet-babel-profile
Cross-posting between Babel and Homenet. At this morning's Babel meeting, Barbara asked whether the work going on in Babel on security means that homenet-babel-profile should be delayed. I said no. Please, no. I beg you, Barbara, no. I started working on this document in early autumn of 2016. I've done a lot of work on it, listened to a fair amount of feedback, and it's reached a state where it's concise, accurate and understandable. After over a year, my enthusiasm for this document is starting to wane. I now still have enough energy to go through IESG review, I cannot promise that it'll still be the case if it is delayed by a few months, or, Eris forbid, years. Let's please advance this document, and use the energy we'll save this way to improve the security of both Babel and Homenet. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] support for HNCP in IPv6 CE routers
>> I think you're underestimating normal people, James. > Bear with me please. With you -- always. > It's worth noting that in the vast majority of cases like you describe, > the CE router provided by the ISP is only serviceable by the provider, or > if it *is* serviceable by the subscriber, the serviceability is > ridiculously tortuous and very limited. Uh-huh. But there's just one single uplink behind which there's a local network with multiple hosts -- unlike the one uplink-one host topology you were describing in your earlier mail. >> At least over here, there definitely is a market for non-trivial home >> networks > Indeed, and I think there is definitely a case for IETF establishing > standards for how to use Internet protocols in them, as HOMENET is > doing. What I don't think is helpful is gating our development of those > standards on the predicate that ISPs should have anything to do with > it. Agreed, as long as we don't assume normal people want one uplink per host. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] support for HNCP in IPv6 CE routers
> The protocols we are developing here in HOMENET are for the tiny minority > of people who prefer to build their own home networks instead of just > plumbing their ISP directly up to every device in their home. I think you're underestimating normal people, James. I do not remember the last time I've been in a flat that didn't have: - an ISP-provided CPE; - a network-connected media playback device (either a Windows machine or a gaming console connected to a large); - a WiFi network with a password that's shared with the guests. When people learn I'm a network person, they ask me suprisingly technical questions. Youtube stutters when I'm in the kitchen, how do I improve the WiFi coverage without any new wires. My wife uses a Mac, can I stream her music to my android phone, I found an app for that but it didn't work well. What's the title of the movie you told me about, no, don't bother, I'll find it on BitTorrent. At least over here, there definitely is a market for non-trivial home networks: - flats in the 19th century areas of Paris, where WiFi has trouble crossing the thick walls and so you cannot easily put new cabling; - shared flats (students and young professionals), where each tenant wants good Internet access in their room, there's a shared media playback device and a shared NAS full of music; - student halls (a whole story in themselves); - people who need to provide WiFi access to others (small cafes, doctor waiting rooms, airBNB). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] support for HNCP in IPv6 CE routers
> I find the model of "there is a CPE, and behind that CPE, I connect > another router to get homenet functionality" a bit unsatisfactory. I think there are two possible deployment models. 1. The « My Friendly ISP » model Every ISP-provided CPE participates in HNCP. Each ISP has access to all the information flooded into the Homenet, including information about External Links announced by other ISPs. 2. The « My Home, my Castle » model HNCP ends at the Edge Home Router (EHR). The CPE is outside the Homenet, and the link between the CPE and the EHR is treated as External (untrusted) by HNCP. Information between the CPE and the Homenet is communicated over non-Homenet protocols such as DHCPv6-PD. The CPE has no topology information about the Homenet, and doesn't even know that the Homenet is connected to multiple CPEs. Note that the « My Home, my Castle » model is more general, since it can implement the « My Friendly ISP » model by co-locating the EHR and the CPE. I don't think the opposite is true -- once you've leaked HNCP data to the ISP, there's no way to unleak it. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-lemon-homenet-babel-security-latest-00.txt
> That makes perfect sense to me. I don't think the DTLS implementation would be > that hard—is there any chance that anyone would be interested in working on > this during the hackathon in Singapore? A student of mine (Antonin, whom you might remember from Berlin) has been working on that. Unfortunately, it turned out a little bit more difficult than expected, and so he ran out of summer. He'll come back to it, I believe, but certainly not before the January exam session is over. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: I-D Action: draft-lemon-homenet-babel-security-latest-00.txt
[Added babel@ietf to CC.] Thanks, Ted. > https://datatracker.ietf.org/doc/draft-lemon-homenet-babel-security-latest/ I'm not a security specialist, so just a few comments: 1. You're using a TLV, which means that the TLV parser runs before auth. Is this good practice? What about using the packet trailer ? 2. A number of security mechanisms are being considered for Babel. There's Denis' RFC 7557, which you're aware of. The other technique that we're working on is the use of DTLS. See point 3. 3. The main improvement of RFC6126bis over 6126 is the ability to run Babel over unicast with no multicast except for discovery (and no multicast at all if discovery is done out of band). This makes it possible to use DTLS and/or dynamically keyed IPsec to secure Babel. At least some of the participants of the Babel WG are in favour of such an approach. 4. It is my understanding that there is consensus in the Babel WG that we don't adopt before there is an implementation. That's not to diminish your input, just the statement of an (IMHO happy) state of affairs. Dinnertime for me. Be hearing from you later. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-ietf-homenet-babel-profile: please review Security Considerations
> Please, please, please take the time to read the Security Considerations > and tell me if there's anything I need to change. > https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-02#section-4 This is now https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-03#section-4 I believe this answers at least some of the concerns that Leif Johansson expressed in his early review of 10 August 2017. I believe this is the best that we can do without further protocol work, but I would love to be proved wrong. Barbara, Stephen -- should I write up an answer to Leif's security review? Thanks, -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] draft-ietf-homenet-babel-profile: please review Security Considerations
Dear all, This is just to remind you that I'm going to request Last Call for draft-ietf-homenet-babel-profile. I'll be submitting a very slightly amended (editorial changes only) version in the next days. Please, please, please take the time to read the Security Considerations and tell me if there's anything I need to change. https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-02#section-4 -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Technical Errata Reported] RFC7788 (5113)
Confirmed, this is consistent with both known implementations of HNCP, as well as with the tcpdump parser. This was also confirmed by Markus Stenberg in a mail dated 9 June 2016 to myself and the former Homenet chairs. Message-Id: <0aacde36-6a89-471e-8eea-b6a90197b...@iki.fi> -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
>> If the fast connection's DNS server replies after a delay or not at all, >> and the slow connection's DNS server replies in a timely manner, using >> a smart resolver across all the available DNS servers will improve latenc > Yes, but if your fast connection is lossy, it's not fast. Lossy looks like > congestion, so TCP slows down. I never said the fast connection was lossy. The scenario I'm envisioning is one in which the DNS server behind the fast link is laggy. Ted, DNS latency is a significant part of what the web people call "time to first byte". DNS resolvers make serious efforts to minimise that latency by keeping RTT and loss statistics and picking the best resolver. I don't know if you agree, but I suspect that any protocol that causes web latency to increase is not going to get deployed easily. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA
> I don't think anything we are talking about here would actually help > with that. If the fast connection's DNS server replies after a delay or not at all, and the slow connection's DNS server replies in a timely manner, using a smart resolver across all the available DNS servers will improve latency. Both dnsmasq and (I believe) bind will do the smart thing. (Which does not consist in sending the request to all servers, contrary to what you appear to believe.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
