Subject: [sidr] Question about draft-ietf-sidr-pfx-validate-03

From: Danny McPherson <[email-masked]>
Date: Sat, 12 Nov 2011 11:54:44 -0500

My read of the current draft suggests that if there's a route generated by the 
local AS in BGP it could never have a "Valid" state, and by definition would 
either posses a "Not found" or "Invalid" state -- even though the local 
AS may well have a "ROA" and reside in the mapping table as well(!).

I do not believe the current text is Section 5 is sufficient to address this case, 
specifically with either this:

"Considering invalid routes for BGP decision process is 
a pure local policy matter and should be done with utmost care."

or this:

"In some cases (particularly when the selection algorithm is 
influenced by the adjustment of a route property that is not 
propagated into IBGP) it could be necessary for routing 
correctness to propagate the validation state to the IBGP 
peer.  This can be accomplished on the sending side by setting 
a community or extended community based on the validation 
state, and on the receiving side by matching the (extended) 
community and setting the validation state."

I could think of a number of way to address this, but for there to exist the 
possibility that an internally generated prefix (for which a ROA may well exists)
could NEVER have a "Valid" state needs to be corrected.

Also, S 4:  s/to rest of the network/to the rest of the network/

Thanks, 

-danny

---

From: Brian Dickson <[email-masked]>
Date: Sat, 12 Nov 2011 12:48:26 -0500

I think the current design of BGPsec as memorialized (love that word) in the
draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this.

I also believe that the result of the proposed tweak, will be a cleaner design
which is easier to implement and verify, as well as not incurring significant
operational cost in terms of signatures.

Local origination SHOULD occur within an AS on a permanent
basis, and only the announcements from the actual originating router need
to have unique signatures, regardless of whether they are iBGP or eBGP.

(Crypto geeks might suggest adding a random "nonce" to make the signature
a little harder to crack, since very little on the signature material
will change
over time - but that is another discussion.)

Here is the tweak:

                      Sequence of Octets to be Signed
                 +---------------------------------------+
                 | Expire Time (8 octets)                |
                 +---------------------------------------+
                 | Origin AS Number (4 octets)           |
                 +---------------------------------------+
                 | Algorithm Suite Identifier  (1 octet) |
                 +---------------------------------------+
                 | NLRI Length  (1 octet)                |
                 +---------------------------------------+
                 | NLRI Prefix  (variable)               |
                 +---------------------------------------+

The "Target AS" and "pCount" need to be added, meaning the minimum
number of signatures
changes to "one origin" and "one propagation" signature.

For iBGP within the originating AS, the signature would be "Target AS
== origin AS", and "pCount == 0".

For eBGP, it would be what you expect, "Target AS == neighbor", "pCount > 0".

I think that's all that is needed, and the rest of the validation
logic in the -protocol doc remain good,
the -ops-reqs doc allows validation for local AS, and pfx-validate also works.

Any detail or logic errors in the above can be attributed to not
enough caffeine... The gist of the above
should be solid enough, though.

Brian

On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson <[email-masked]> wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>
>

---

From: Pradosh Mohapatra <[email-masked]>
Date: Sat, 12 Nov 2011 23:36:37 -0800

> AS may well have a "ROA" and reside in the mapping table as well(!).

Is there a need to compute validation state of an IBGP path?

- Pradosh

---

From: Danny McPherson <[email-masked]>
Date: Sun, 13 Nov 2011 03:04:57 -0500

> Is there a need to compute validation state of an IBGP path?

I need some way to convey in iBGP it's preference relative to other 
BGP-learned paths - how do I do that today under this architecture, 
where if it were considered under the current algorithm it may well 
be labeled "Invalid", even if a mapping exists for the local AS and 
prefix in question?

-danny

---

From: John Scudder <[email-masked]>
Date: Sun, 13 Nov 2011 00:12:22 -0800

Brian,

Danny is talking about pfx-validate, which is not the same as BGPSEC.

--John

---

From: John Scudder <[email-masked]>
Date: Sun, 13 Nov 2011 00:17:06 -0800

Danny,

IMO the way to handle this is observe that all routes have a validity state attribute and that it needs to be settable in policy.  I believe the draft already says this (I will check though) and so it provides the necessary minimum toolset needed to apply a given state to local routes.  It might be worth saying something about what state a route should take by default, which I'm pretty sure we don't do now.  (If done this might need to be broken down into several cases, e.g. EBGP vs. IBGP vs. locally originated.)

--John

---

From: Danny McPherson <[email-masked]>
Date: Sun, 13 Nov 2011 06:37:51 -0500

> IMO the way to handle this is observe that all routes have a validity state attribute and that it needs to be settable in policy.  I believe the draft already says this (I will check though) and so…

Agreed, thanks John, 

-danny

---

From: Pradosh Mohapatra <[email-masked]>
Date: Sun, 13 Nov 2011 09:23:43 -0800

> be labeled "Invalid", even if a mapping exists for the local AS and

Implementations mark it as valid today (unless the validation state  
extcomm says otherwise). Re. John's reply, it probably makes sense to  
clarify in the doc. Thanks for the comment.

- Pradosh

---

From: Brian Dickson <[email-masked]>
Date: Sun, 13 Nov 2011 15:38:32 -0500

Correct, yes, I understand.

My point is, that because of the inter-relatedness of the various SIDR
documents, and because presumably the bgpsec-protocol document is not
set in stone, the issues raised in other documents (in SIDR) can be
considered as creating requirements to the protocol document.

As in, by making changes to the protocol (and necessarily the protocol
draft), the issues elsewhere can be designed away and made moot.

It is taking a holistic approach to the set of SIDR documents rather
than documenting around an existing pre-standards bgpsec
implementation.

I humbly suggest that the authors of the other documents take a closer
look at things I suggest, and perhaps voice them as concerns in the
-protocol discussion, as relates to the overall design and in
particular their own documents.

Some see the glass as half-full, some as half-empty. I see the glass
as too big. :-)

Brian

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Nov 2011 07:41:55 +0800

> clarify in the doc. Thanks for the comment.

workshop folk have asked to have intra-as generated routes marked.  it
is not clear to me that this would be bad.

randy