Adam, > On Aug 20, 2019, at 23:29, Adam Roach via Datatracker <[email protected]> > wrote: > > §3.3: > > I believe I understand how the described Algorithm B, is applied by AS4, will > result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about > the means by which AS2 will accept them such that they could be delivered to > AS4. Is there an assumption that AS2 is employing an ACL-based approach? If > so, this should probably be stated explicitly. (This might be implied by text > elsewhere, in which case I apologize for my confusion; although it may still > be > worth explicitly explaining.)
For the examples, it's not important whether AS2 or AS3 are filtering. However, even if they are, there's sufficient information in the routing for it to work. BGP NO_EXPORT community means that routes received from AS1 at AS2 are not propagated to AS4. So, we can use one of the routing based mechanisms. BGP does have an additional community, NO_ADVERTISE that wouldn't work well for this example. This would prevent propagation of P1,P2 to other routers in AS2. However, even that may be fine depending on where uRPF is applied; typically that's only AS border routers. > > --------------------------------------------------------------------------- > > §3.5: > >> It is worth emphasizing that an indirect part of the proposal in the >> draft is that RPF filters may be augmented from secondary sources. > > Nit: "the draft" won't age gracefully. I suggest changing to "this document" > or somesuch. > > --------------------------------------------------------------------------- > > §3.6.1: > >> +---------------------------------+---------------------------------+ >> | Very Large Global ISP | 32392 | >> | ------------------------------- | ------------------------------- | >> | Very Large Global ISP | 29528 | >> | ------------------------------- | ------------------------------- | > > I suspect there was a transcription error copying these lines from the source > material, as the appearance of two rows with identical labels seems unlikely > to be intended. I skimmed the cited source material to see if I could figure > out what happened here, but found neither of these numbers (nor any mention of > "Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a > fix. I did find that adding the numbers in the first column on slide 6 > yielded 32393, which is tantalizingly close to the first number, but that > might just be a coincidence. I believe a proper reading of this is that each row is a distinct service provider. Perhaps updating the labeling to Very Large Global ISP1/2 would be helpful? -- Jeff _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
