[{"author": "Jeffrey Haas", "text": "
The celestial light behind you, @Chris Morrow , fools no one.
", "time": "2022-11-10T13:11:43Z"}, {"author": "Chris Morrow", "text": ":) the morning is the most annoying (this time of year) at my desk/home-office.
", "time": "2022-11-10T13:22:11Z"}, {"author": "Doug Montgomery", "text": "Dang, I thought meetecho was flagging the enlightened participants.
", "time": "2022-11-10T13:22:26Z"}, {"author": "Lorenzo Miniero", "text": "Is that a feature request? :joy:
", "time": "2022-11-10T13:22:50Z"}, {"author": "Nathalie Trenaman", "text": ":D
", "time": "2022-11-10T13:23:54Z"}, {"author": "Jeffrey Haas", "text": "I'd prefer meetecho dev time go into a feature that forces the person to find where their mic is actually coming from so we stop people from participating when their actual mic is buried in their couch or similar.
", "time": "2022-11-10T13:24:17Z"}, {"author": "Chris Morrow", "text": "it continues to amaze me that after ~3yrs still 'your mic is garbage' is a thing :(
", "time": "2022-11-10T13:28:13Z"}, {"author": "Chris Morrow", "text": "Would any of these 'do X every Y time' really just be some 'follow the standard advice in RFC<ops rfc>\" ?
", "time": "2022-11-10T13:34:50Z"}, {"author": "Doug Montgomery", "text": "RPKI object staleness is an issue only visible in the validator - typically not the router. BAR-SAV needs to follow the behavior of the basic RPKI validation algorithm.
", "time": "2022-11-10T13:36:23Z"}, {"author": "Chris Morrow", "text": "that is what I said (or what I meant though it may have been a confusing way to say it!)
", "time": "2022-11-10T13:37:11Z"}, {"author": "Rob Austein", "text": "Heh, no, this is changing Job's revision to how RPKI was intended to work. Manifests used to be allowed to use longer term EE certs that could be put in the CRL.
", "time": "2022-11-10T13:37:37Z"}, {"author": "Andrew Newton", "text": "CRL size is certainly an issue for one RIR.
", "time": "2022-11-10T13:38:19Z"}, {"author": "Rob Austein", "text": "Yep
", "time": "2022-11-10T13:38:27Z"}, {"author": "Rob Austein", "text": "\"Allowed\" vs \"required\"
", "time": "2022-11-10T13:38:46Z"}, {"author": "Ties de Kock", "text": "Andrew Newton said:
\n\n\nCRL size is certainly an issue for one RIR.
\n
But implementing 9286 should fix that, for all but 1-2 CRLs per CA.
", "time": "2022-11-10T13:41:29Z"}, {"author": "Job Snijders", "text": "My point was that many certificate serials don't appear on CRLs; because simply delisting them from the Manifest is sufficient.
", "time": "2022-11-10T13:41:34Z"}, {"author": "Ties de Kock", "text": "\n\nRPKI object staleness is an issue only visible in the validator - typically not the router. BAR-SAV needs to follow the behavior of the basic RPKI validation algorithm.
\n
Does BAR-SAV need to use the current RPKI data? Or some union of a sliding window over time of what was valid at points in time?
", "time": "2022-11-10T13:42:44Z"}, {"author": "Job Snijders", "text": "I'd also consider putting BAR-SAV information in a new RTR PDU type, to avoid stomping on existing ROA/ROV implementations; BAR-SAV having its own RTR PDU allows for example delaying withdraws
", "time": "2022-11-10T13:46:45Z"}, {"author": "Doug Montgomery", "text": "As currently proposed the algorithm can be implemented on a router using only Adj-RIB-in data that has been flagged with the results of RPKI-ROV and ASPA validation algorithms. More nuanced behaviors that differ from the output of those other algorithms would require more machinery / data .... I guess it is all a tradeoff between fidelity / failure behaviors and complexity.
", "time": "2022-11-10T13:47:31Z"}, {"author": "Job Snijders", "text": "I understand and appreciate the desire to recycle existing components
", "time": "2022-11-10T13:49:42Z"}, {"author": "Rob Austein", "text": "And if the same data is in two places they can get out of sync, potential operational hairball.
", "time": "2022-11-10T13:50:21Z"}, {"author": "Doug Montgomery", "text": "I also have concern about creating variant downstream behaviors impacting the semantics of ROA creation. I think it would muddy the waters of understanding / confidence in ROA creation.
", "time": "2022-11-10T13:56:04Z"}, {"author": "Doug Montgomery", "text": "ASPA prototype and test tools here: https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-software-suite
", "time": "2022-11-10T14:02:33Z"}, {"author": "Keyur Patel", "text": "aspa should be reviewed by IDR folks
", "time": "2022-11-10T14:06:36Z"}, {"author": "Rob Austein", "text": "Perhaps because anybody who understands the semantics of what they're implementing won't make this mistake?
", "time": "2022-11-10T14:11:17Z"}, {"author": "Jared Mauch", "text": "I'm wondering why we would want to constrain the list of numbers, because the ASN.1 while it permits negatives, if we extend beyond 2^32 ASNs then we don't have to update this as well.
", "time": "2022-11-10T14:15:32Z"}, {"author": "Randy Bush", "text": "perhaps the measurements that no violations actually occur in the wild gives a hint re the necessity of specifying trivial details
", "time": "2022-11-10T14:16:13Z"}, {"author": "Chris Morrow", "text": "that sounds like an argument which is the same as:
\n \"first names are only ever seen as 5 chars (chris, randy, jared, jeyur)\"
but suddenly a nathalie appears... and we overflow/crash.
", "time": "2022-11-10T14:17:14Z"}, {"author": "Chris Morrow", "text": "in asn.1 maybe 'toss in the garbage' and then on the client/server side: \"well, names COULD be 10 chars long.... so....\"
", "time": "2022-11-10T14:17:48Z"}, {"author": "Rob Austein", "text": "I don't really care either way about the syntactic restrictions, they're harmless although not necessary. I am a little concerned by the notion of making this easy to implement for people who don't understand the semantics of what they're implementing :)
", "time": "2022-11-10T14:19:14Z"}, {"author": "Ties de Kock", "text": "\n\nperhaps the measurements that no violations actually occur in the wild gives a hint re the necessity of specifying trivial details
\n
Some of the cases (iirc the rfc3779 extension restriction) is present in some test objects. But otherwise, yeah, these are cases that will not happen if you do the obvious.
", "time": "2022-11-10T14:20:09Z"}, {"author": "Randy Bush", "text": "we can make new careers of codifying the obvious.
", "time": "2022-11-10T14:21:31Z"}, {"author": "Chris Morrow", "text": "randy, to use more words for you (I think you mean):
\n \"you can send a bunch of garbage across the wire, the sender should be nice, and the receiver SHOULD check the inbound against sane ideas\"
right?
", "time": "2022-11-10T14:22:46Z"}, {"author": "Rob Austein", "text": "ROA syntax deliberatley tracked RFC 3779 syntax
", "time": "2022-11-10T14:22:48Z"}, {"author": "Chris Morrow", "text": "(which is sort of what jeff said)
", "time": "2022-11-10T14:22:52Z"}, {"author": "Randy Bush", "text": "@chris: not exactly. more like, if you are coding an AS, if you do not know it is a 16 or 32 bit non-negative integer, you should find a different career.
", "time": "2022-11-10T14:24:44Z"}, {"author": "Jeffrey Haas", "text": "My interest in doing anything in the asn.1 stuff for rpki was heavily informed by the pain of trying to do so in the past. I have no need for additional brain injury from bad toolchains.
", "time": "2022-11-10T14:25:23Z"}, {"author": "Andrew Newton", "text": "You have to guard against input trash... so either do in the ASN.1 tool or do it in wrapping code. But it must be done.
", "time": "2022-11-10T14:26:23Z"}, {"author": "Rob Austein", "text": "128 bits is enough for anybody :)
", "time": "2022-11-10T14:26:23Z"}, {"author": "Randy Bush", "text": "we are having so much fun with AS 0, think of the possibilities we could have with AS -1
", "time": "2022-11-10T14:26:28Z"}, {"author": "Ties de Kock", "text": "@Randy Bush AS2^64+1 is fun for impementors using C, so is \\0 in IA5Strings
", "time": "2022-11-10T14:27:04Z"}, {"author": "Jeffrey Haas", "text": "Randy Bush said:
\n\n\nwe are having so much fun with AS 0, think of the possibilities we could have with AS -1
\n
Exactly my point. Or even -1 * yourAS
", "time": "2022-11-10T14:27:10Z"}, {"author": "Randy Bush", "text": "the idiots will throw put of range data at you no matter what the ASN.1 says. you think they actually read the ASN.1?
", "time": "2022-11-10T14:27:31Z"}, {"author": "Ties de Kock", "text": "But hypothetically, if you found a compiler in your language of choice, that supported the syntax __and__ did DER, you could use code generation.
", "time": "2022-11-10T14:28:07Z"}, {"author": "Ties de Kock", "text": "(I ended up hand-rolling parsers and that is frustrating)
", "time": "2022-11-10T14:28:25Z"}, {"author": "Rob Austein", "text": "Schema validation is sometimes a useful way of applying checks, yes
", "time": "2022-11-10T14:28:31Z"}, {"author": "Jeffrey Haas", "text": "I find deep reads of encoding specifications mostly useful for generating exception cases for crashing stuff.
", "time": "2022-11-10T14:28:36Z"}, {"author": "Jeffrey Haas", "text": "After all, why proscribe someone's SID over AS feature now?
", "time": "2022-11-10T14:30:12Z"}, {"author": "Jeffrey Haas", "text": "FWIW, I don't strongly avoid imposing the constraints as long as we intend to issue a new object if we leave ipv4/ipv6 + 4-byte AS land. I support George's comments that it helps the code. My main complaint remains \"parsing tools suck\", which is not an issue of the WG beyond \"it can discourage developers\".
", "time": "2022-11-10T14:32:46Z"}]