[{"author": "John Scudder", "text": "<p>Nit, I see no reason for naming these \"1\", \"2\" and \"3\" instead of using descriptive names.</p>", "time": "2024-11-05T18:10:05Z"}, {"author": "Job Snijders", "text": "<p><span class=\"user-mention silent\" data-user-id=\"263\">George Michaelson</span> <a href=\"#narrow/stream/197-sidrops/topic/ietf-121/near/140573\">said</a>:</p>\n<blockquote>\n<p>I think Job may overstate \"can never happen\" because companies can relocate resource management without transfers. So there is a context where 44/8 can appear in APNIC.</p>\n</blockquote>\n<p>the current <code>apnic.constraints</code> file would <a href=\"https://github.com/openbsd/src/blob/master/etc/rpki/apnic.constraints#L984\">permit</a> 44/8 to appear under APNIC TA</p>", "time": "2024-11-05T18:10:15Z"}, {"author": "Jeffrey Haas", "text": "<p>+1 to john. I'm old and tired of remembering what type-N magic thing in a protocol is.</p>", "time": "2024-11-05T18:12:03Z"}, {"author": "Jeffrey Haas", "text": "<p>There seems to be a lot of energy being spent to simply not publish the as-graph relationships.  A has a neighbor relationship with B. B has with A.  Yes, this is effectively much of what soBGP did.  But it addresses much of this space and always did.</p>", "time": "2024-11-05T18:24:50Z"}, {"author": "Jeffrey Haas", "text": "<p>Similarly, much as discussed during soBGP analysis, all we're doing is iterating toward the as-paths that are viable and thus what you would need to spoof as an active attacker.  everything else requires bgpsec (or similar)</p>", "time": "2024-11-05T18:26:14Z"}, {"author": "George Michaelson", "text": "<p>@job I'm not saying a constraints file model cannot accomodate this, I am saying the statement \"not permitted\" is true, but incomplete to why resources move. movement of resources is not solely due to transfers and movement of resources happened before transfer policy was normal. thats all I'm saying.</p>", "time": "2024-11-05T18:26:26Z"}, {"author": "Jeffrey Haas", "text": "<p>Am I reading most of this presentation correctly as \"route filtering can happen, and CIDR means that less specifics are a problem?\"</p>", "time": "2024-11-05T18:33:14Z"}, {"author": "John Scudder", "text": "<p>That's what I'm getting too, but I'm still waiting for the punchline.</p>", "time": "2024-11-05T18:34:16Z"}, {"author": "Chris Morrow", "text": "<p>Oh, I thought I was alone in figuring that this wsa: \"Look route hijacks because of other filteirng\"</p>", "time": "2024-11-05T18:35:49Z"}, {"author": "Jeffrey Haas", "text": "<p>By \"hidden danger\", he means \"I am not interested in carrying traffic for this destination\". :-P</p>", "time": "2024-11-05T18:38:25Z"}, {"author": "Jeffrey Haas", "text": "<p>That said, the presentation summarizes again to \"if we know the security properties of the address space, we know what to attack\"</p>", "time": "2024-11-05T18:39:14Z"}, {"author": "Chris Morrow", "text": "<p>I think I'm surprised that this seems to be not known? (as a problem)</p>", "time": "2024-11-05T18:40:31Z"}, {"author": "Tim Bruijnzeels", "text": "<p>Was the punch line that VRPs can become loose wrt max length because not all specifics are seen anymore (even if they exist elsewhere)</p>", "time": "2024-11-05T18:40:38Z"}, {"author": "Jeffrey Haas", "text": "<p>perhaps a nod towards a need for negative attestations for less specific address space. \"these less specifics will not exist and are invalid\"</p>", "time": "2024-11-05T18:41:29Z"}, {"author": "Jeffrey Haas", "text": "<p>as if we needed another push towards \"proxy aggregation considered harmful\"</p>", "time": "2024-11-05T18:41:53Z"}, {"author": "Chris Morrow", "text": "<p>I announce jeff's /16, he has a roa that says /18s only thx!<br>\nmy route is not accepted everywhere, but because I'm cool it gets some distribution.<br>\none of jeff's mean transits/peers filters 1 of his /18s.</p>\n<p>now jeff's remote customers sometimes send traffic and I see it! win!<br>\n(there's a ton of reasons why this can/does happen already without RPKI though)</p>", "time": "2024-11-05T18:43:43Z"}, {"author": "Jeffrey Haas", "text": "<p>if you're the owner of the /16, all's good.</p>", "time": "2024-11-05T18:44:40Z"}, {"author": "Chris Morrow", "text": "<p>i am because I announced your /16! :)</p>", "time": "2024-11-05T18:50:35Z"}, {"author": "John Scudder", "text": "<p>Did you forge Jeff's ASN behind yours as the origin?</p>", "time": "2024-11-05T18:51:43Z"}, {"author": "Chris Morrow", "text": "<p>i did not, my announcement is false and no one should listen to me.. but som peple did.</p>", "time": "2024-11-05T18:53:10Z"}, {"author": "Chris Morrow", "text": "<p>enough did for me to get some of his traffic.</p>", "time": "2024-11-05T18:53:22Z"}, {"author": "Jeffrey Haas", "text": "<p>again, the indirect point is that under some of these types of situation negative attestation covering that address space might be helpful.</p>", "time": "2024-11-05T18:53:57Z"}, {"author": "John Scudder", "text": "<p>\"Doctor, it hurts when I do this.\"<br>\n\"Don't do that!\"</p>", "time": "2024-11-05T18:54:06Z"}, {"author": "Chris Morrow", "text": "<p>i agree with both of you.</p>", "time": "2024-11-05T18:54:26Z"}, {"author": "George Michaelson", "text": "<p>Hmm. \"only approved PP will be used\" flavours here. I don't want to be in the game of badging a PP as approved or not, but I can see some people might want to do this, and might want to limit the set. Surely the current state of mostly in &lt;10 is .. ok? do we have a good number in mind?</p>", "time": "2024-11-05T18:56:48Z"}, {"author": "Tom Harrison", "text": "<p>there is less reason today to set up a pp than in the past, because more rirs now offer publication services and apis</p>", "time": "2024-11-05T18:57:46Z"}, {"author": "Tom Harrison", "text": "<p>just can't see the number increasing much from here</p>", "time": "2024-11-05T18:58:12Z"}, {"author": "George Michaelson", "text": "<p>I think the Q goes to OPS forums not RPKI forums</p>", "time": "2024-11-05T18:59:22Z"}, {"author": "George Michaelson", "text": "<p>wrong room for the story basically. this should be in NANOG/SANOG and see operators respond not spec people</p>", "time": "2024-11-05T18:59:46Z"}]