I remember, and agree with the decision to not try to distinguish among various
flavors of INVALID.
I think this discussion is different. RFC6811 provides a complete 3 state
taxonomy for the result of origin validation, but is based on some assumptions
(e.g., reasonable access ("loose consistency") to RPKI (or other DB)
information).
"UNDEFINED" is a implementation realization that there are circumstances when
the implicit assumptions of RFC6811 may not hold, and one may like to have
routing policies that take that fact into consideration.
So far we have waived our hands and said smart people won't let those
assumptions fail. Folks who are worried about new systemic dependencies
between routing and global info systems would appreciate the ability to write
purposeful policies that could deal with the scenario "what if we can't perform
the validation function as defined?".
I can think of scenarios in which I might treat UNDEFINED different than
UNKNOWN/NOT-FOUND.
I don't think could/should standardize all circumstances under which the result
UNDEFINED is returned - other than the situations in which the assumptions of
RFC6811 aren't met, or the validation function is unable to execute the defined
validation algorithm.
dougm
--
Doug Montgomery - Manager Internet and Scalable Systems Research / ITL / NIST
________________________________________
From: [email protected] [[email protected]] On Behalf Of aservin
[[email protected]]
Sent: Thursday, March 14, 2013 9:51 AM
To: [email protected]
Subject: Re: [sidr] NotFound vs Uninitialized
After talking to Oliver and the comments of Andy I think that it
might valuable that fourth state.
Trying to respond to Randy I thought that it may be useful to know if
a route is unknown (prefix holder does not care about the prefix, i
might not trust it) or "undefined" (i lost connectivity with the cache)
Perhaps adding a very low preference to unknown (not signed, perhaps
unsecure?) and leave undefined untouched?
Does it make sense?
/as
El 14-03-2013 03:55, Randy Bush escribió:
> what will an operator do differently for these two shades of grey?
>
> what is the trust difference?
>
> was this perhaps discussed extensively before? what did the security
> folk tell us in that discussion?
>
> randy
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
