speaking as regular ol' member On Aug 8, 2014, at 5:16 PM, Andy Newton <[email protected]> wrote:
> > On Aug 8, 2014, at 4:23 PM, Sandra Murphy <[email protected]> wrote: > >> >> On Aug 8, 2014, at 3:17 PM, Andy Newton <[email protected]> wrote: >> >>> >>> On Aug 8, 2014, at 2:04 PM, Sandra Murphy <[email protected]> wrote: >>> >> >> You mischaracterize the motivation. I indicated that the desired features >> of the RPKI design matched the features provided by an existing technology. >> That is decidedly not just following tradition. > > I’m fine with not characterizing motives and historical context. Just > following your lead. :) I did not mention motives, I mentioned motivations, as in the requirements that drove the design. I did not suggest 3779 was adopted because it existed but because it had the desirable features. So you may think you are following my lead, but I think you are not on the same path I'm on. > >> For example, the RPKI also uses CMS, because it provides the features the >> RPKI needs. That is not just following tradition. > > CMS is used in many deployed systems. As has been asked but has been left > unanswered, in what other deployed systems is 3779 used? The grounds for > changing the 3779 rules has been described as “wobbly” but how is that > accusation made if we cannot put our fingers on the reasons for the 3779 > rules in the first place? I think I answered that. The RPKI was designed for the prefix allocation system. In the prefix allocation system, one can allocate only from the allocation one holds. 3779 also was designed to follow the prefix allocation system and its rules enforce that allocation behavior. It provided the features a certification of the prefix allocation system needed, so it was adopted. I suppose we could have invented an entirely new crypto based system, but the prefix allocation system's behavior would have been part of what we built anyway. 3779 did not invent the encompassing rules, those rules are derived from the behavior of the existing system. > >>>> This prefix allocation system is encapsulated in the RPSL authorization >>>> model that is used in some RIRs. In those systems, you can only create an >>>> inetnum if you hold the rights to a parent inetnum. >>>> >>>> That's the authorization model people have been using in some regions for >>>> decades. I have always found the fact that the RPKI authorization model >>>> was a good match to the IRR authorization model in long use to be >>>> reassuring. It meant the RPKI followed what people had already long >>>> accepted, and it meant that operators should find the semantics familiar. >>> >>> Well, not all IRRs are tied to RIR registrations. In fact, most are not. >> >> I mentioned those used in some RIRs. I did not address all IRRs. >> >> Yes, most do not. Those that do not are subject to unauthorized >> registrations. As has happened. >> >> I am not sure why you are bringing up systems which provide no security in >> discussing the design of a secure system. As an example of what to avoid? > > Again, I was following your lead by addressing the example you gave. I was talking about IRR/RPSL systems that follow the authorization model. You pointed out examples of those that do not. That's not following my lead. I was attempting to point out that the only other existing system with an authorization model also follows the same encompassing rule. Again, the encompassing rule is derived from the behavior of the prefix allocation system. > >>> >>> Reverse DNS might be a better parallel. However, if a particular delegation >>> is lame, the DNS does not consider all delegations of the network holder to >>> be lame. >>> >> >> I do not follow the parallel at all. > > If you are looking for a system that follows the address allocation > hierarchy, reverse DNS is one such system. However, I get the feeling you and > I are talking past each other. If that was not the characteristic you were > describing or I have done a poor job explaining my point, please let me know. The parallel to DNS delegation that is bad would be one RPKI certificate that is bad. The parallel to "all delegations of the network holder" would be "all RPKI certificates of a resource holder". So the parallel is: if a particular RPKI certificate is bad, the system does not consider all RPKI certificates of the resource holder to be bad. True. So I don't follow why you think this parallel is better. But I'm not sure that it helps the discussion to explore it. If you think it would, maybe we better take it off list? --Sandy, speaking as regular ol' member
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
