Sorry, my bad. I somehow thought you were talking about two different PATH elements in the same update. That assumption made your questions sound bizarre. I am sure my misunderstanding made my answers sound equally bizarre.
So, yes if they are different updates for the same prefix received from different peers ... Then of course this will happen all the time. As for if you somehow prefer the signed path over the unsigned path, in the end that is a local decision. I think there is/will be strong wording that one SHOULD choose the signed and valid path because at the moment there is no explicit way of distinguishing that a path should have been signed, and as a result, there is a simple downgrade attack to strip the PATHSIG, if one is not strictly preferring signed over unsigned paths. One could think of fixing this, by having AS's push and object in the RPKI that says "I am signing my paths", then it would be possible to detect the simple downgrade attack. I guess one might think of AS_CERTS as such a signal, but that is a bit problematic WRT timing issues. The right way to do it would be some other explicit object. Anyway, to answer your question below, one SHOULD choose the second path, but I doubt the specs will ever say you MUST choose the second path. dougm -- Doug Montgomery Mgr. Internet & Scalable Systems Research / ITL / NIST On 3/21/12 7:11 PM, "Robert Raszuk" <[email protected]> wrote: > >Maybe there is misunderstanding ... > >Chris example was stating: > > 1) first path gets evaluated, is it 'good' (next-hop reachable, not >discarded by prefix-list/etc) > > 2) second path gets evaluated, is it 'good' (same as above + >origin-validate + path-validation) > >One path comes without signature the other one with signature .. AS >PATHs they traverse is disjoined at some point. > >Are you saying this can not happen ? > >Many thx, >R. > > >> On 3/21/12 6:05 PM, "Robert Raszuk"<[email protected]> wrote: >> >>> >>>>>> What happens in your example if singed comes with PATH_SIG listing >>>>> 4 ASes >>>>>> (pCount=1 of each) and real AS_PATH is length of 3 ? >>>> >>>> so, pcount I'm not a fan of.... but, you're suggesting a path that's >>>> invalid? or impossible? >>> >>> Worse .. in my example both paths are valid, crystal clear and pass all >>> validations one can apply. >> >> If you are talking about BGPSEC as currently proposed, this can't >>happen. >> The definition of validity of a PATH_SIG is that valid signatures >>exactly >> correspond to AS_PATH data. >> >> See: >> >>http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5.1 >> >> Once again, given the encoding of AS_PATH directly in PATH_SIG >>attribute, >> the exact scenario is moot (a BGPSEC update will never contain both >> AS_PATH and PATH_SIG attributes), but the spirit is the same, the >> validation algorithm will return "Invalid" >> >> Dougm >> >> >> > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
