Re: [Sidrops] Opsdir last call review of draft-ietf-sidrops-ov-egress-01

[Chris Morrow <[e-mail]>]

Just sniping a reply... which may be out to left (or right!) field :)

On Tue, 17 Mar 2020 21:53:35 +0000,
Linda Dunbar via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Not Ready
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> The document claims that it highlights an important use case of origin
> validation in eBGP egress policies, explaining specifics of correct
> implementation in this context. But I don't see where the "Use Case" is
> described. It seems to me that the document should have more sections to
> describe the Use Case and the procedure of Egress Export of the RPKI validated
> Origins.
> 
> Section 3 Egress Processing only has one sentence stating that
> "When applied to egress policy, validation state MUST be determined using the
> effective origin AS of the route as it will (or would) be announced to the
> peer." What other choices there are ?   Are there any routers that support  RFC
> 6480 RPKI  not performing this step? how?
>

I think the sense of this sentence is really:

  "Your router may have configured ASXXX and present itself
  (confedaration) as ASYYY to peer1 and ASBBB to peer2
  (merger/acquisition issues). Please make sure that you validate the
  origin accordingly"


There are a few example networks in the real world where this sort of
thing could be super relevant. Particularly look at recent 'network
that merges a bunch' Level3/CenturyLink/Savvis/GlobalCrossing/etc...
AS3356/AS209/AS<iforget>/AS3459/AS3549. A single edge device
terminating customers on the 3356 backbone may plausibly have
customers that haven't swapped over to 3356 and are actually expecting
the remote peer to be any of 6 or more ASN.

It's important that the 'i originated this prefix, I'm 3356, wait
3549, want 3459...' decision is backed up in ROA content as well
as validation logic.

Looking at the abstract to maybe dig a little deeper:
  "For egress policy, it is important that the
   classification uses the effective origin AS of the processed route,
   which may specifically be altered by the commonly available knobs
   such as removing private ASs, confederation handling, and other
   modifications of the origin AS."

So somewhere deep in my network, bb01.pop01 has:
  192.0.2.0/24

staticly routed, redistributed in BGP and marked for external
announcement (community/etc). That route, internally has an origin-AS of:
  65507

because that's one of the several private ASN that make up my
confederation: ASBAR. So, when I announce:
  192.0.2.0/24 - origin 65507

I need to both swap the origin in the bgp announcement and validate
against the local-as the peer sees me as.
   192.0.2/0/24 - origin 3356
   192.0.2.0/24 - origin 3549
   ...etc...

This will require me to make ROA for all of these origins, as well.

I think anyway that's the goal of the document, really.
though, also, I could have missed the forest for the trees here.

-chris

> My two cents.
> 
> Linda Dunbar
> 
>