Re: [homenet] routing protocol comparison document and hncp
> > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to > bootstrap a certificate infrastructure, zero touch. Once every device in a > domain has a domain certificate, two devices can directly authenticate each > other, without PSK. Then you can also authenticate a key negotiation > scheme such as IKE, to negotiate a PSK which you can then use in your > "normal" authentication scheme. Obviously, would be nice if protocol > supported certs directly, but it’s not required. > > IKE provides just symmetric crypto key between two parties. Typical > network has more (and routing protocols use multicast). Multiparty IKE is > more or less dead (or undead?). > > Remember, we need whole network to agree on the keys, or at least > everyone on the link if any multicast is used in a way that requires > authentication or confidentiality. (HNCP is designed to avoid transmitting > anything important over multicast; are routing protocols? For most part, I > think not.) Sorry, I haven't been following all this discussion so I may be missing something, but ... I would say: Pick a master (on a link, or the entire network); master calculates a random key; distributes it to the other nodes using asymmetric crypto; all nodes use that key. For rollover use some key chain mechanism such that for a period of time old and new key are accepted. Plug those keys into the "normal" routing protocol security mechanism. What am I missing? Michael ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 09:37 AM, Michael Behringer (mbehring) wrote: I scanned this over (I think I've scanned Max's base doc too, but it's been a long time), and don't think that the problem at hand has much to do with needing a CA of any sort. Binding "human" names to cryptographic identities is fraught with trouble -- and if they're not intended to be human consumable, they might as well be the fingerprint of a public key. The big question i have is whether the non-interactive nature of certs is being taken advantage of. For example, if I throw my root current CA in the trash what happens? I have a lot of other questions, but I'm not sure whether this is right time to go through them. There are lots of questions which we should discuss. To the above question, easiest case would be that you create a new root CA and re-enrol devices there. Not perfect, but probably acceptable in a homenet, if the enrolment process is easy (which I believe we can make it). Yuck, obviously. It seems to me that there's a larger distributed database problem that this is probably another for-instance of. I really want to be able to throw my current CPE in the trash when it dies and not spend an entire day of harrowing configuration annotated with the dictionary's 4-letter word section. (others being dns naming/config, router/routing configs, dhcp goodies, etc, etc). Should we set up an informal meeting in Dallas to discuss this? Find a slot that works for most, a quiet corner, and discuss? Alas, I will not be in Dallas. Grassy knolls give me the sneezes. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> -Original Message- > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Michael > Thomas > Sent: 03 March 2015 18:20 > To: homenet@ietf.org > Subject: Re: [homenet] routing protocol comparison document and hncp > > On 03/03/2015 08:43 AM, Gert Doering wrote: > > Hi, > > > > On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: > >> Considering that provisioning personal certificates is the almost the > >> polar opposite of zeroconf, the chances of the normal schlub seeing > >> an informative and/or trustworthy name are really, really low. > > You might want to entertain you reading > > > >draft-behringer-homenet-trust-bootstrap > > > > which gives a good idea how this could work (the general ideas, maybe > > not the specific implementation). > > > > Of course the normal end user is not going to ever look at or manually > > generate a certificate. > > > > > > I scanned this over (I think I've scanned Max's base doc too, but it's been a > long time), and don't think that the problem at hand has much to do with > needing a CA of any sort. Binding "human" names to cryptographic > identities is fraught with trouble -- and if they're not intended to be human > consumable, they might as well be the fingerprint of a public key. > > The big question i have is whether the non-interactive nature of certs is > being taken advantage of. For example, if I throw my root current CA in the > trash what happens? > > I have a lot of other questions, but I'm not sure whether this is right time > to > go through them. There are lots of questions which we should discuss. To the above question, easiest case would be that you create a new root CA and re-enrol devices there. Not perfect, but probably acceptable in a homenet, if the enrolment process is easy (which I believe we can make it). Should we set up an informal meeting in Dallas to discuss this? Find a slot that works for most, a quiet corner, and discuss? Michael > Mike > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 08:43 AM, Gert Doering wrote: Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. You might want to entertain you reading draft-behringer-homenet-trust-bootstrap which gives a good idea how this could work (the general ideas, maybe not the specific implementation). Of course the normal end user is not going to ever look at or manually generate a certificate. I scanned this over (I think I've scanned Max's base doc too, but it's been a long time), and don't think that the problem at hand has much to do with needing a CA of any sort. Binding "human" names to cryptographic identities is fraught with trouble -- and if they're not intended to be human consumable, they might as well be the fingerprint of a public key. The big question i have is whether the non-interactive nature of certs is being taken advantage of. For example, if I throw my root current CA in the trash what happens? I have a lot of other questions, but I'm not sure whether this is right time to go through them. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: > Considering that provisioning personal certificates is the almost the > polar opposite of zeroconf, the chances > of the normal schlub seeing an informative and/or trustworthy name are > really, really low. You might want to entertain you reading draft-behringer-homenet-trust-bootstrap which gives a good idea how this could work (the general ideas, maybe not the specific implementation). Of course the normal end user is not going to ever look at or manually generate a certificate. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 05:55 AM, David Oran wrote: On Mar 2, 2015, at 9:05 PM, Michael Thomas wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says "Hi, I'm your friendly homenet router and here's my public key." so you're mollified if somebody's cert says "hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" instead? Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> On Mar 2, 2015, at 9:05 PM, Michael Thomas wrote: > > On 03/02/2015 01:21 PM, Brian E Carpenter wrote: >> On 03/03/2015 09:12, Michael Thomas wrote: >>> >>> I'm doubtful that routing protocols need PSK's. They almost certainly >>> would like to share a symmetric key(s) but >>> is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. >>> s/and certificates// >> Well, I want certificates, because I don't believe someone who >> says "Hi, I'm your friendly homenet router and here's my public >> key." >> > > so you're mollified if somebody's cert says "hi i'm > 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" > instead? > Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. > the possession of a cert does nothing in and of itself to make an enrollment > decision. > I agree that the cert itself does nothing. The name in the cert, as long as it isn’t self signed, provides a trust anchor. > Mike > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> On Mar 2, 2015, at 7:32 PM, Curtis Villamizar wrote: > > In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> > Christian Hopps writes: > >> Hi homenet-wg, >> >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. If true should we be calling this out >> more explicitly in the document? >> >> Thanks, >> Chris. > > > Chris, > > Yes. I agree. > > And OSPF could do the same, without dragging CLNP in with it. Using CLNP framing for IS-IS packets at the L2 layer is not the same as dragging in CLNP. No homenet router is going to do anything with ISO like frames other than drop them or hand them off to IS-IS. > Maybe ISIS-WG should consider an ISIS-over-IP draft? I actually presented that draft back in 1999, it was my first presentation at IETF; it didn’t go anywhere. :) Chris. > > Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:48:24PM -0500, Curtis Villamizar wrote: > The way IETF has normally done things is to allow multiple > developments to exist if they have support and then drop only those > that are not being deployed or prove to be less desirable. "Having multiple examples of running code" is certainly a good thing. "Discussing all potential approaches to death, unless the committee has won, and the result is an unimplementable nightmare of myriads of different options" is what IETF WGs have changed to in more recent years - and if I look at the last few rounds of discussions, I can certainly understand why Dave moved off to get something *done*. A: "here's a draft that got implemented, works, and needs feedback" "but I want ISIS!" "and I want OSPF!" goto A gert, tempted to call it a day and spend my time *deploying* IPv6 somewhere -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 06:50 PM, Brian E Carpenter wrote: so you're mollified if somebody's cert says "hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" instead? the possession of a cert does nothing in and of itself to make an enrollment decision. No, of course not. That is the whole point of using draft-pritikin-anima-bootstrapping-keyinfra or an equivalent. The point being that enrollment decisions have very little to do with the name binding claimed by some third party, especially when the name binding itself in a zero/littleconf most likely has little/no meaning to the enrollor (ie, mybrandnewrouter1...@china.com). It's hardly news that I'm biased against certs, but the biggest reason is that people impute in them superpowers which only get in the way of discussing the actual problems. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 03/03/2015 15:05, Michael Thomas wrote: > On 03/02/2015 01:21 PM, Brian E Carpenter wrote: >> On 03/03/2015 09:12, Michael Thomas wrote: >>> >>> I'm doubtful that routing protocols need PSK's. They almost >>> certainly would like to share a symmetric key(s) but is not the >>> same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. >>> s/and certificates// >> Well, I want certificates, because I don't believe someone who says >> "Hi, I'm your friendly homenet router and here's my public key." >> > > so you're mollified if somebody's cert says "hi i'm > 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" > instead? > the possession of a cert does nothing in and of itself to make an > enrollment decision. No, of course not. That is the whole point of using draft-pritikin-anima-bootstrapping-keyinfra or an equivalent. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says "Hi, I'm your friendly homenet router and here's my public key." so you're mollified if somebody's cert says "hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" instead? the possession of a cert does nothing in and of itself to make an enrollment decision. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi Curtis, The main reason for going forward with IS-IS over OSPFv3 is that there was an open source implementation willing to implement and support all the enhancements necessary for Homenet. Admittedly, the source/destination routing requirement makes the entrance barrier a bit higher for OSPFv3 than other protocols. The reason for this is that it requires the implementation of http://www.ietf.org/id/draft-ietf-ospf-ospfv3-lsa-extend-06.txt in order to support fully extendable LSAs. Hopefully, we can get some implementation momentum for OSPFv3 Extendable LSAs this year. If not soon, I have an idea for a cheaper, yet less elegant approach. Thanks, Acee On 3/2/15, 7:32 PM, "Curtis Villamizar" wrote: >In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> >Christian Hopps writes: > >> Hi homenet-wg, >> >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. If true should we be calling this out >> more explicitly in the document? >> >> Thanks, >> Chris. > > >Chris, > >Yes. I agree. > >And OSPF could do the same, without dragging CLNP in with it. > >Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - >non-routability of CLNP is a security feature - so don't forget to >mention that in the security section. You might need providers to use >filters at borders and GTSM as they do for OSPF. > >Curtis > >___ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message <87twy3wjtr.wl-...@pps.univ-paris-diderot.fr> Juliusz Chroboczek writes: > > I got my hands on ISO 10589 today and tried to very briefly glance through > > it. And personally I had a really hard time getting into it. > > > > Having read the comparison document beforehand I haven't found anything > > about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned > > in the draft (and that ISO standard was ~200 pages already). > > You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. > > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet Hint: RFC 1195 does a better job explaining what ISIS does than ISO 10589. Read RFC 1195 first. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message Christian Hopps writes: > > > On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek > > wrote: > > > >> One thing that has been mentioned to me is that IS-IS could be used > >> (with proper TLV additions) to completely replace HNCP, if IS-IS were > >> used as the homenet protocol. > > > > I see that you've been speaking with Abrahamsson. Please let me give you > > some background. > > It's not just Mikael that has this opinion, he's just the more active > email participant. > > >> If true should we be calling this out more explicitly in the document? > > > > I seem to recall that I already mentioned that I find your tendency to > > bring out controversial arguments just before a deadline somewhat > > offputting. > > There was nothing nefarious here. I just thought of a question and > raised it. I think we should be open to doing that any time free > of attack. > > Thanks, > Chris. I agree with Chris. WGs are allowed to change their decisions particularly in early stages when there is no significant ***deployment***. Even then WGs can take a new direction but need to include backward compatibility or at least have a solid plan for (hopefully painless) transition. For example, MPLS started with RSVP-TE and CRLDP and years later dropped CRLDP due to lack of deployment. CIDR obsoleted EGP, BGP1-3, RIP1, and lots of other protocols, but there was a good reason and a clear transition plan. The way IETF has normally done things is to allow multiple developments to exist if they have support and then drop only those that are not being deployed or prove to be less desirable. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> Christian Hopps writes: > Hi homenet-wg, > > One thing that has been mentioned to me is that IS-IS could be used > (with proper TLV additions) to completely replace HNCP, if IS-IS were > used as the homenet protocol. If true should we be calling this out > more explicitly in the document? > > Thanks, > Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - non-routability of CLNP is a security feature - so don't forget to mention that in the security section. You might need providers to use filters at borders and GTSM as they do for OSPF. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 21.34, Michael Behringer (mbehring) wrote: >>> Then one can always discuss what kind of information could go into each >> protocol after bootstrap. Perhaps what we actually need is a new bootstrap >> security protocol (not only for homenet), and that this is where the >> emphasis should be. >> >> Possibly. However, even if we had one, bootstrap protocol does not lead >> easily to widely shared PSKs, and that’s what routing protocols require. >> >> E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I >> had a >> certificate, I am not sure how it helps with PSK IS-IS scheme. > > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to > bootstrap a certificate infrastructure, zero touch. Once every device in a > domain has a domain certificate, two devices can directly authenticate each > other, without PSK. Then you can also authenticate a key negotiation scheme > such as IKE, to negotiate a PSK which you can then use in your "normal" > authentication scheme. Obviously, would be nice if protocol supported certs > directly, but it’s not required. IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?). Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.) I might be wrong, hopefully some points me at some asymmetric crypto enabled multi-party authentication method for _some_ routing protocol.. Only way I could imagine this working is by firing up metric shitload of on-demand (e.g. GRE) tunnels on top of IPsec (based on some yet undefined on-link peer detection scheme), then running some RP over them in p2p mode. Then we realize that all security needed is really in the peer-detection (which can be conservative, very rate limited and so on) and the IPsec, and we would require no security features from the routing protocol itself. > I still think that the above draft is a very good way to bootstrap a > certificate infrastructure, which can be leveraged in many different ways. It is relatively heavy in terms of number of protocols to the functionality I would want, but I agree that on the paper[1] it does what it advertises it does, but it is not enough to make routing protocols work in and of itself, see above. Cheers, -Markus [1] I have yet to see an implementation; I have heard one exists. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 09:12, Michael Thomas wrote: > On 03/02/2015 11:54 AM, Brian E Carpenter wrote: >> On 03/03/2015 08:38, Michael Thomas wrote: Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. >>> I'm doubtful that routing protocols need PSK's. They almost certainly >>> would like to share a symmetric key(s) but >>> is not the same thing. >> But they need to agree on the shared key(s) securely, and the only way >> I know how to do that zero-touch is by starting with asymmetric keys >> and certificates. >> >> > s/and certificates// Well, I want certificates, because I don't believe someone who says "Hi, I'm your friendly homenet router and here's my public key." Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 11:54 AM, Brian E Carpenter wrote: On 03/03/2015 08:38, Michael Thomas wrote: Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 08:38, Michael Thomas wrote: > On 03/02/2015 11:34 AM, Michael Behringer (mbehring) wrote: >>> -Original Message- >>> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus >>> Stenberg >>> Sent: 02 March 2015 15:11 >>> To: Mikael Abrahamsson >>> Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian >>> Hopps >>> Subject: Re: [homenet] routing protocol comparison document and hncp >>> >>> On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: >>>> On Mon, 2 Mar 2015, Margaret Wasserman wrote: >>>>> I think Markus' comments on security are also very important to >>>>> consider >>> here, as some sort of integrated security mechanism between the routing >>> protocol and HNCP might be strongly desired. >>>> Yes, I agree that HNCP has gained security that currently none of the >>> routing protocols have, and that this is important. >>>> Then one can always discuss what kind of information could go into each >>> protocol after bootstrap. Perhaps what we actually need is a new >>> bootstrap >>> security protocol (not only for homenet), and that this is where the >>> emphasis should be. >>> >>> Possibly. However, even if we had one, bootstrap protocol does not lead >>> easily to widely shared PSKs, and that’s what routing protocols require. >>> >>> E.g. anima bootstrap stuff is focusing only on enrolling >>> certificates. If I had a >>> certificate, I am not sure how it helps with PSK IS-IS scheme. >> Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way >> to bootstrap a certificate infrastructure, zero touch. Once every >> device in a domain has a domain certificate, two devices can directly >> authenticate each other, without PSK. Then you can also authenticate a >> key negotiation scheme such as IKE, to negotiate a PSK which you can >> then use in your "normal" authentication scheme. Obviously, would be >> nice if protocol supported certs directly, but it's not required. >> >> I still think that the above draft is a very good way to bootstrap a >> certificate infrastructure, which can be leveraged in many different >> ways. >> >> > > I'm doubtful that routing protocols need PSK's. They almost certainly > would like to share a symmetric key(s) but > is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 11:34 AM, Michael Behringer (mbehring) wrote: -Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus Stenberg Sent: 02 March 2015 15:11 To: Mikael Abrahamsson Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian Hopps Subject: Re: [homenet] routing protocol comparison document and hncp On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> -Original Message- > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus > Stenberg > Sent: 02 March 2015 15:11 > To: Mikael Abrahamsson > Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian > Hopps > Subject: Re: [homenet] routing protocol comparison document and hncp > > On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: > > On Mon, 2 Mar 2015, Margaret Wasserman wrote: > >> I think Markus' comments on security are also very important to consider > here, as some sort of integrated security mechanism between the routing > protocol and HNCP might be strongly desired. > > > > Yes, I agree that HNCP has gained security that currently none of the > routing protocols have, and that this is important. > > > > Then one can always discuss what kind of information could go into each > protocol after bootstrap. Perhaps what we actually need is a new bootstrap > security protocol (not only for homenet), and that this is where the > emphasis should be. > > Possibly. However, even if we had one, bootstrap protocol does not lead > easily to widely shared PSKs, and that’s what routing protocols require. > > E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I > had a > certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. Michael > Babel + IKE + IPsec, on the other hand, could of course run with the > certificate, but would not be link-state => hard to replicate state. > > Looking at fast adoption, perhaps OSPF would be preferable then, as it > already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, > IKE, IPsec, OSPF’ and world is your oyster. No standardization required > (beyond dst-src draft by Baker, just like IS-IS). > > Cheers, > > -Markus > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Thanks for the quick reply. Looks like I will be having something to read on the plane to Dallas. On 02.03.2015 15:56, Christian Hopps wrote: On Mar 2, 2015, at 9:07 AM, Steven Barth wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The "Decision Process" (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Basically a trimmed down version is "level-1" operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> On Mar 2, 2015, at 9:07 AM, Steven Barth wrote: > > >> One thing that has been mentioned to me is that IS-IS could be used (with >> proper TLV additions) to completely replace HNCP, if IS-IS were used as the >> homenet protocol. If true should we be calling this out more explicitly in >> the document? > I got my hands on ISO 10589 today and tried to very briefly glance through > it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The "Decision Process" (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). > Having read the comparison document beforehand I haven't found anything about > IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the > draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) > So I think I asked Mikael the same thing already but could you (or anyone > else) please provide a dumbed down specification or at least an overview > document that references all relevant ISO-standards, RFCs and drafts (or > chapters thereof) that one needs to read to understand modern IS-IS? > On top of that if you could mention what could / or should be removed for a > trimmed down homenet version that would be a huge plus. Basically a trimmed down version is "level-1" operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. > > > Cheers, > > Steven > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> I got my hands on ISO 10589 today and tried to very briefly glance through > it. And personally I had a really hard time getting into it. > > Having read the comparison document beforehand I haven't found anything > about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned > in the draft (and that ISO standard was ~200 pages already). You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: > On Mon, 2 Mar 2015, Margaret Wasserman wrote: >> I think Markus' comments on security are also very important to consider >> here, as some sort of integrated security mechanism between the routing >> protocol and HNCP might be strongly desired. > > Yes, I agree that HNCP has gained security that currently none of the routing > protocols have, and that this is important. > > Then one can always discuss what kind of information could go into each > protocol after bootstrap. Perhaps what we actually need is a new bootstrap > security protocol (not only for homenet), and that this is where the emphasis > should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Babel + IKE + IPsec, on the other hand, could of course run with the certificate, but would not be link-state => hard to replicate state. Looking at fast adoption, perhaps OSPF would be preferable then, as it already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, IKE, IPsec, OSPF’ and world is your oyster. No standardization required (beyond dst-src draft by Baker, just like IS-IS). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Juliusz, I've actually been wondering about this, too. I am not sure about the history here, because the last version of HNCP I read (in preparation for the last IETF meeting), HNCP contained its own (underspecified) link-state routing protocol… If that protocol were replaced with an already-existing link-state routing protocol, one that had the ability flood additional information about the links, it might be possible to use that already-existing routing protocol as the underlying communication mechanism for HNCP. We would still need to specify what HNCP information is sent, but the routing information and HNCP information could, possibly, be transmitted over the same protocol. I don't know if that would work with a non-link-state routing protocol, as part of what HNCP was using its internal routing protocol to distribute was information about all of the links. I don't know what facilities IS-IS or Babel have for sending additional information about each link, and I don't know if we actually want to require that very node that needs HNCP information run IS-IS or Babel, but I think this is worth considering. I will think about this, read some stuff, and try to come up with my own opinion about it ASAP. I would suggest that other people do that, too. I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Margaret On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek wrote: >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. > > I see that you've been speaking with Abrahamsson. Please let me give you > some background. > > Two years ago, there was a very animated discussion about whether the > configuration protocol and the routing protocol should be separate or not. > After a lot of energy was spent on the issue, Markus designed HNCP, which > went through a few iterations. The chairs judged that WG consensus was > achieved, and the configuration protocol is now separate from the routing > protocol. > > Since achieving consensus on this was a lot of work, some of us are > somewhat annoyed at Mikael bringing this argument back from the dead at > every opportunity. > >> If true should we be calling this out more explicitly in the document? > > I seem to recall that I already mentioned that I find your tendency to > bring out controversial arguments just before a deadline somewhat offputting. > > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek > wrote: > >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. > > I see that you've been speaking with Abrahamsson. Please let me give you > some background. It’s not just Mikael that has this opinion, he’s just the more active email participant. >> If true should we be calling this out more explicitly in the document? > > I seem to recall that I already mentioned that I find your tendency to > bring out controversial arguments just before a deadline somewhat offputting. There was nothing nefarious here. I just thought of a question and raised it. I think we should be open to doing that any time free of attack. Thanks, Chris. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 15.00, Juliusz Chroboczek wrote: >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. > I see that you've been speaking with Abrahamsson. Please let me give you > some background. > > Two years ago, there was a very animated discussion about whether the > configuration protocol and the routing protocol should be separate or not. > After a lot of energy was spent on the issue, Markus designed HNCP, which > went through a few iterations. The chairs judged that WG consensus was > achieved, and the configuration protocol is now separate from the routing > protocol. > > Since achieving consensus on this was a lot of work, some of us are > somewhat annoyed at Mikael bringing this argument back from the dead at > every opportunity. Funny part is, the argument has changed substantially since. Originally I considered HNCP security to be strictly optional, but as there was push-back to have built-in security, I added it in. And now it is essentially more littleconf’able than any routing protocol security scheme I have ever met before. The current draft specifies only PSK based security; do you really want to bootstrap your home security either with well-known ‘IamGoodguy’ password, or perhaps by logging in to every router to do magic things? No, me neither. I am looking forward to hearing some of some relatively dynamic security protocol (think IKE, or TLS handshake) that runs on top of CLNP though that we can hook in to IS-IS. The current draft’s ’security’ requirements for (stand-alone) use of either routing protocol’s own security framework are inadequate to what the group has been discussing here (among other places) over the last year. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:33:47AM -0500, Christian Hopps wrote: > One thing that has been mentioned to me is that IS-IS could be used (with > proper TLV additions) to completely replace HNCP, if IS-IS were used as the > homenet protocol. If true should we be calling this out more explicitly in > the document? I'm sure we could, but "what is it that the WG wants?" - achieve something that vendors could deploy, in finite time - do another few rounds on protocols, variations, personal peeves, and end up with something like IPSEC? I'm firmly in the "do something that is good enough, and get it deployed" camp, which means "no, we don't do everything-on-top-of-ISIS". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> One thing that has been mentioned to me is that IS-IS could be used > (with proper TLV additions) to completely replace HNCP, if IS-IS were > used as the homenet protocol. I see that you've been speaking with Abrahamsson. Please let me give you some background. Two years ago, there was a very animated discussion about whether the configuration protocol and the routing protocol should be separate or not. After a lot of energy was spent on the issue, Markus designed HNCP, which went through a few iterations. The chairs judged that WG consensus was achieved, and the configuration protocol is now separate from the routing protocol. Since achieving consensus on this was a lot of work, some of us are somewhat annoyed at Mikael bringing this argument back from the dead at every opportunity. > If true should we be calling this out more explicitly in the document? I seem to recall that I already mentioned that I find your tendency to bring out controversial arguments just before a deadline somewhat offputting. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] routing protocol comparison document and hncp
Hi homenet-wg, One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? Thanks, Chris. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
