Subject: [sidr] draft-ietf-sidr-pfx-validate-04.txt

From: Randy Bush <[email-masked]>
Date: Mon, 26 Mar 2012 16:12:05 +0200

at this afternoon's sidr ssion, i presented two open issue with
draft-ietf-sidr-pfx-validate-04.txt

1 - Should updates learned via iBGP be marked?

2 - Should updates injected into BGP on this router be marked?

i think yes because:
  o i want support of incremental deployment
  o i do not want to find out I am announcing garbage when my neighbor’s
    NOC calls, mis-originations should be stopped at the source

there was fear that, if used at other than edge routers, this allowed
creation of loops, as setting local pref etc, do.

i think there was general agreement that this was ok on edge routers
and the point of injection, as that is logically an edge router.

would like to see convergence on this

thanks

randy

---

From: Jay Borkenhagen <[email-masked]>
Date: Mon, 26 Mar 2012 14:15:23 -0400

Randy Bush writes:
 >   o i do not want to find out I am announcing garbage when my neighbor$,1ry(Bs

I could not hear the discussion in the room today because the utter
webex fail prevented my remote participation.  So let me ask about
today's discussion.

Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than just
at ingress edge routers, and if the policy is broken it can result in
loops.  It's something to watch out for when designing a policy, but I
am thankful that this kind of flexibility exists, because not all
policies that manipulate attributes other than at ingress edges are
broken.

Regarding pfx-validate: 

I hope the agreement in the room was that a sane network design would
probably involve setting a local 'origin has been checked' community
on the first router inside the AS where that check occurred.

I hope the agreement was _not_ that pfx-validate implementations
should be hard-coded to assess validation state only at the ingress
edge router.

---

From: Pradosh Mohapatra <[email-masked]>
Date: Wed, 28 Mar 2012 10:07:29 -0700

Hi Jay,

> on the first router inside the AS where that check occurred.

like draft-ietf-sidr-origin-validation-signaling ?

> should be hard-coded to assess validation state only at the ingress

I couldn't go to IETF either. The argument is over what the default
behavior should be (spec'ed). My vote is that origin validation should
NOT be performed on IBGP learnt prefixes by default as there is  
potential
for loops and inconsistency. For everything else, there are knobs.

- Pradosh

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 Mar 2012 19:13:39 +0200

> potential for loops and inconsistency. For everything else, there are 
> knobs.

you mean like there is with local pref?

one should only set these at the edge.

randy

---

From: Pradosh Mohapatra <[email-masked]>
Date: Wed, 28 Mar 2012 10:18:36 -0700

> you mean like there is with local pref?

No - knob to turn on IBGP validation.

This is what pfx-validate says:

This procedure SHOULD NOT be performed for Routes learned from peers  
of types other than EBGP.
    (Any of these MAY be overridden by configuration.)

---

From: Randy Bush <[email-masked]>
Date: Wed, 28 Mar 2012 19:26:22 +0200

> No - knob to turn on IBGP validation.

how many knobs will i have to turn to get policy control of my router?

randy

---

From: Kannan Varadhan <[email-masked]>
Date: Fri, 30 Mar 2012 17:14:21 -0700

On Mar 28, 2012, at 10:07 AM, Pradosh Mohapatra wrote:

> NOT be performed on IBGP learnt prefixes by default as there is potential

Given that this is trying to enable "security" hooks, I'd argue that the default should be for a router to behave as if it would validate all prefixes at a router, including those learned via iBGP.  THis would allow for an implementation to work in conjunction with the origin-validation-signalling to optimize iBGP handling as appropriate.

This would allow not just the incremental deployment scenarios, but also behaves correctly if a router in the AS were misconfigured and leaked invalidated prefixes---in those cases, only the misconfigured router is affected, and all other routers would behave as expected.

The only scenario where I see the possibility for loops or other bad behaviors would be if a router learned of two prefixes, one known good and one bad according to its ROA database, and some of the other routers in the AS were not doing prefix validation.  In such as case, it seems to be a good thing to actually admit that scenario and correct for it.

Kannan