Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Apr 2012 09:19:09 +0200

> Your analysis assumes that there a conventional BGP-4 AS_PATH field
> and then there is is BGPSEC_Path_Signatures from which AS path info
> can be inferred separately. This is not true in the latest BGPSEC
> update format as Matt presented it in Paris.

How an optional attribute replace well-known mandatory one ?

Sorry but for such step formal IDR WG approval is necessary if you 
choose to propose BGPSEC_Path_Signatures as mandatory attribute. This is 
major BGP protocol change.

Documentation of partial deployment is required as well as two 
interoperable implementations ;).

RFC4271:

5.1.2.  AS_PATH

    AS_PATH is a well-known mandatory attribute.  This attribute
    identifies the autonomous systems through which routing information
    carried in this UPDATE message has passed.  The components of this
    list can be AS_SETs or AS_SEQUENCEs.

draft-ietf-sidr-bgpsec-protocol-02.txt

    This document specifies a new optional (non-transitive) BGP path
    attribute, BGPSEC_Path_Signatures.

Best regards,
R.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 9 Apr 2012 12:15:15 -0400

The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e., unsigned).
In either case, the update necessarily has AS-path info.
If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandatory) in it.
If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Path" in it. 
The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, pCount-k}.
Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris.
The Secure Path is semantically equivalent to the BGP-4 AS_PATH.
When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island. 
Any prepend ASN that was collapsed in BGPSEC will be repeated pCount number of times,
and any transparent route server ASN (with pCount=0) in BGPSEC will be removed.
Is this semantic equivalence (of the Secure Path) and 
the guarantee of convertibility to BGP-4 AS_PATH not enough?
Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in a pristine way)
in addition to the Secure Path, albeit at the cost of duplication and associated 
processing cost/confusion? Just a honest question seeking people's opinion.

Sriram  

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
>Raszuk
>Sent: Monday, April 09, 2012 3:19 AM
>To: [email-masked]
>Cc: [email-masked] List
>Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
>
>
>Sorry but for such step formal IDR WG approval is necessary if you choose to
>propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP
>protocol change.
>
>Documentation of partial deployment is required as well as two interoperable
>implementations ;).
>
>RFC4271:
>
>5.1.2.  AS_PATH
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Apr 2012 18:29:41 +0200

Hi Sriram,

 > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge

What happens in the opposite direction ? How AS_PATH/AS4_PATH can be 
converted to BGPSEC_Path_Signatures without all necessary information 
present at the ASBR at any arbitrary Autonomous System ? Are you going 
to propose NULL signatures ?

How are you planning on a flag date where all ASBRs in the Internet are 
BGPSEC complaint ?

Why one needs to upgrade also all P routers (intra domain BGP speakers) 
to be BGPSEC complaint provided he is not using BGP as an overlay today?

If you think removal of AS_PATH/AS4_PATH is helpful in any way the much 
simpler would be to define new set of AFIs and call it "SECURED" leaving 
current AFI 1 and AFI 2 unchanged BGP protocol wise.

Thx,
R.

>> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&  lengthening
>>
>>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 9 Apr 2012 17:07:16 +0000

speaking as regular ol' member

There is no reverse direction.

Incoming paths that are unsigned are not propagated by bgpsec speakers as signed paths.

And intradomain BGP speakers do not use bgpsec (ebgp sessions only).

And AS4_PATH is not needed in bgpsec speakers - who are assumed to be 4-byte aware.

So no need to worry about ASBRs, flag days, etc.  Don't worry, no problem.

--Sandy, speaking as regular ol' member.

________________________________________
From: [email-masked] [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Monday, April 09, 2012 12:29 PM
To: Sriram, Kotikalapudi
Cc: [email-masked] List; [email-masked]
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &  lengthening

Hi Sriram,

Thx,
R.

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Apr 2012 19:22:22 +0200

Hi Sandy,

> There is no reverse direction.

What do you mean there is no reverse direction ?

Sriram said:

"When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of
the BGPSEC island."

That means that there is EBGP peering at the two ASes which on one side
supports BGPSEC on the other does not.

In order to establish any form of bidirectional communication sites on
the left need to know how to reach sites on the right and vice versa.

So your below "Don't worry, no problem" directly means "no 
reachability". I am afraid there is slight problem with that.

Best regards,
R.

> ________________________________________ From: [email-masked]
> [[email-masked]] on behalf of Robert Raszuk
> [[email-masked]] Sent: Monday, April 09, 2012 12:29 PM To: Sriram,
> Kotikalapudi Cc: [email-masked] List; [email-masked] Subject: Re: [sidr]
> [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&
> lengthening
>
> Hi Sriram,
>
>> When the update is to leave a BGPSEC island to go to a BGP-4 only
>> AS, then the Secure Path is easily converted to BGP-4 AS_PATH at
>> the edge of the BGPSEC island.
>
> converted to BGPSEC_Path_Signatures without all necessary
> information present at the ASBR at any arbitrary Autonomous System ?
> Are you going to propose NULL signatures ?
>
> How are you planning on a flag date where all ASBRs in the Internet
> are BGPSEC complaint ?
>
> Why one needs to upgrade also all P routers (intra domain BGP
> speakers) to be BGPSEC complaint provided he is not using BGP as an
> overlay today?
>
> If you think removal of AS_PATH/AS4_PATH is helpful in any way the
> much simpler would be to define new set of AFIs and call it "SECURED"
> leaving current AFI 1 and AFI 2 unchanged BGP protocol wise.
>
> Thx, R.
>
>
>> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or
>> BGP-4 (i.e., unsigned). In either case, the update necessarily has
>> AS-path info. If the update is BGP-4 (i.e., unsigned), it has the
>> BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e.,
>> signed), then it MUST have the "Secure Path" in it. The Secure Path
>> is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k,
>> pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC
>> Protocol) in Paris. The Secure Path is semantically equivalent to
>> the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to
>> go to a BGP-4 only AS, then the Secure Path is easily converted to
>> BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN
>> that was collapsed in BGPSEC will be repeated pCount number of
>> times, and any transparent route server ASN (with pCount=0) in
>> BGPSEC will be removed. Is this semantic equivalence (of the Secure
>> Path) and the guarantee of convertibility to BGP-4 AS_PATH not
>> enough? Should we really require in BGPSEC that the BGP-4 AS_PATH
>> be carried (in a pristine way) in addition to the Secure Path,
>> albeit at the cost of duplication and associated processing
>> cost/confusion? Just a honest question seeking people's opinion.
>>
>> Sriram
>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Robert Raszuk Sent:
>>> Monday, April 09, 2012 3:19 AM To: [email-masked] Cc: [email-masked]
>>> List Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path
>>> shortening&   lengthening
>>>
>>>
>>>> Your analysis assumes that there a conventional BGP-4 AS_PATH
>>>> field and then there is is BGPSEC_Path_Signatures from which AS
>>>> path info can be inferred separately. This is not true in the
>>>> latest BGPSEC update format as Matt presented it in Paris.
>>>
>>> Sorry but for such step formal IDR WG approval is necessary if
>>> you choose to propose BGPSEC_Path_Signatures as mandatory
>>> attribute. This is major BGP protocol change.
>>>
>>> identifies the autonomous systems through which routing
>>> information carried in this UPDATE message has passed.  The
>>> components of this list can be AS_SETs or AS_SEQUENCEs.
>>>
>>>
>>> Best regards, R.

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 9 Apr 2012 13:48:08 -0400

>supports BGPSEC on the other does not.

Right.  BGPSEC doesn't support partially signed PATHS.  Thus a update
either starts off signed, or it is not signed at all.

You can take a signed path, strip the PATH-SIG, reconstruct the AS-PATH
and transmit it to a non-BGPSEC speaker.  But from that point on, the PATH
remains unsigned.

A path that starts off unsigned, will always remain unsigned.

Dougm

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Apr 2012 20:02:12 +0200

Hi,

> A path that starts off unsigned, will always remain unsigned.

Do you mean that:

"A path that starts off unsinged or transits via at least one non BGPSEC 
enabled BGP router (edge or core) will always remain unsigned."

?

Many thx,
R.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 9 Apr 2012 18:12:32 +0000

still speaking as regular ol' member

by "no reverse direction",  it was in answer to your question "What happens in the opposite direction ? ".  I should have used your words exactly.

I meant what I said in the second line I wrote.  "Incoming paths that are unsigned are not propagated by bgpsec speakers as signed paths.".    They are propagated as unsigned paths.

So there's no need to try to produce signatures for unsigned paths.  Routes that come in unsigned, stay unsigned.

There is no loss of reachability, because the routes are propagated.

--Sandy, speaking as regular ol' member

________________________________________
From: Robert Raszuk [[email-masked]]
Sent: Monday, April 09, 2012 1:22 PM
To: Murphy, Sandra
Cc: Sriram, Kotikalapudi; [email-masked] List; [email-masked]
Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &  lengthening

Hi Sandy,

Sriram said:

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 09 Apr 2012 20:50:06 +0200

Hi,

> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).

I do not understand. How a BGP Update will transit via an AS where each 
router is a real BGP speaker and where as some proposed BGP mandatory 
AS_PATH attribute is not present ?

Are you assuming each AS today is BGP Free with full mesh of MPLS/IP 
tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected 
directly or indirectly (RRs) via IBGP.

As you proposing to remove AS_PATH selection criteria from best path for 
updates which come over IBGP ? What happens if you need to compare paths 
received over EBGP and IBGP on a given BGP speaker ?

Many thx,
R.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 20:52:46 -0400

At 6:29 PM +0200 4/9/12, Robert Raszuk wrote:
>What happens in the opposite direction ?

you can't go in the opposite direction, i.e., from unsigned to signed.

Steve

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 00:59:10 -0400

> AS_PATH attribute is not present ?

The last sentence, it doesn't parse quite clearly for me... could you
re-state it?

>
> Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel
> ASBR to ASBR as transport ? Even in this case ASBRs are connected directly
> or indirectly (RRs) via IBGP.

no assumption was made of this sort.

> updates which come over IBGP ? What happens if you need to compare paths

no

> received over EBGP and IBGP on a given BGP speaker ?

I think what you want is actually sort of discussed in:
<http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-4>

-chris

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Apr 2012 12:07:06 -0400

On Apr 9, 2012, at 2:50 PM, Robert Raszuk wrote:

> I do not understand. How a BGP Update will transit via an AS where each router is a real BGP speaker and where as some proposed BGP mandatory AS_PATH attribute is not present ?

I must admit I'm having a hard time parsing the question. I'll take a stab though... This answer may be unrelated to what you are asking...

When an update leaves a BGPSEC speaker destined for a "legacy" speaker the BGPSEC bits are removed

> 
> Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected directly or indirectly (RRs) via IBGP.

Nope, not assuming that at all. The devices on the edge of the AS (those that do eBGP) need to speak BGPSEC, and if the AS is small, they will probably be in a full mesh. If the AS is not small (or has planned ahead :-)) they will talk to a RR or be part of a confed. If they talk through a RR (or set of RRs), these should also speak BGPSEC. If you prefer the confed flavor of scaling, well, the devices on the edge of the confed are kinda like eBGP speakers, and inside the confed they all mesh (or talk through a RR (see previous :-)))

> 
> As you proposing to remove AS_PATH selection criteria from best path for updates which come over IBGP ?

Goodness, no....

> What happens if you need to compare paths received over EBGP and IBGP on a given BGP speaker ?
> 
> Many thx,
> R.
> 

P.S: Crossposting left in, as it seems like that is what was wanted, but....

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Apr 2012 18:34:41 +0200

Hi Warren,

Many thx for your comment. It clarifies my question very well.

So you are effectively confirming that as long as there is one ASBR, one 
RR or one confederation edge which does not yet speak BGPSEC anywhere in 
the UPDATE path the peer sending to him over ebgp or ibgp will convert 
BGP_SIGNED_PATH to AS_PATH/AS4_PATH attributes and from now on that path 
will remain unsigned.

Likewise each RR/confed peer will need to convert BGP_SIGNED_PATH to set 
of AS_PATH/AS4_PATH attributes when sending to "legacy" BGP speakers.

I do not know what is the rationale for recommendation of not sending 
mandatory BGP attributes any longer even if their content could be 
already contained with new BGP_SIGNED_PATH attribute.

Anyhow my doubt has been answered and I stay by my opinion that not 
sending AS_PATH and AS4_PATH is a terrible idea.

Perhaps one could depreciate it in 20 years when world is upgraded to 
BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not 
helpful for any even potential BGPSEC deployment model.

Best regards,
R.

> Nope, not assuming that at all. The devices on the edge of the AS
> (those that do eBGP) need to speak BGPSEC, and if the AS is small,
> they will probably be in a full mesh. If the AS is not small (or has
> planned ahead :-)) they will talk to a RR or be part of a confed. If
> they talk through a RR (or set of RRs), these should also speak
> BGPSEC. If you prefer the confed flavor of scaling, well, the devices
> on the edge of the confed are kinda like eBGP speakers, and inside
> the confed they all mesh (or talk through a RR (see previous :-)))

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 12:52:57 -0400

On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <[email-masked]> wrote:
> Anyhow my doubt has been answered and I stay by my opinion that not sending
> AS_PATH and AS4_PATH is a terrible idea.

So... we can send the data along, but in the case of BGPSEC speakers
the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
Carrying extra bits isn't actually helpful is it? (the implementers
drove the design decision here I believe)

> helpful for any even potential BGPSEC deployment model.

is it helpful for the folks that write bgp code though? "Hey, you will
need to re-synthesize the as-path at sec->non-sec boundaries. you need
to also create sec-path at none->sec boundaries."

-chris

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Apr 2012 19:00:38 +0200

> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).

So far I have always heard that BGPSEC is just providing the hint to the 
operator and does not change how BGP works.

Here you are saying that now AS_PATH length should be calculated from 
completely different (and optional) attribute.

You are also saying that now multipath code which computes which path 
are eligible to be multipath needs to look/parse/decrypt totally 
different attribute.

All BGP monitoring tools need to be upgraded to now understand BGPSEC 
attribute too. And surprise .. here BMP will not convert it like it will 
to "legacy" speakers.

You may think that if we stuff all "data" in the new attribute and drop 
the other one everything else will work. This may be so in theory, but 
it is clearly not a case in practice.

Regards,
R.

> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<[email-masked]>  wrote:

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Apr 2012 13:37:34 -0400

> drove the design decision here I believe)

I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same?

There has been much good work in IDR to better handle bugs / implementations issues, and these considerations probably had much to do with this...

For example, I'm a BGPSEC speaker. In the BGPSEC bits I see:

AS1 AS2 AS3 AS4 AS5  All this checks out, the magic crypto says all is happy, etc.
but, in the AS_PATH I see:
AS1 AS 100 AS17 AS6

What do I do here? Do I a: drop the update or b: ignore the issue or c: reset the session or d: prefer the singed or unsigned or e: nasal demons?  
Someone who's opinion I really respect once said: Never test for an error condition you don't know how to handle.

This idea extends this by simply not allowing the error condition to occur.

You have all of the information to recreate the AS_PATH / AS4_PATH when you leave a BGPSEC domain, and because it is only in one place, you sidestep all sorts of weird error corner cases...

W

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 10 Apr 2012 13:42:47 -0400

On 4/10/12 1:37 PM, "Warren Kumari" <[email-masked]> wrote:

>I think that sone of the biggest issues to keep in mind with carrying the
>"same" data in two places is what to do when you suddenly discover that
>they are not actually the same?

Do the same thing you do when you find that the that a PATH_SIG SKI points
to a CERT for an ASN that does not match the ASN in the PATH_SIG.

Proceed from there ... Problem is no different... The data meant to
validate the PATH, does not match the PATH.
Dougm

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 13:47:41 -0400

> operator and does not change how BGP works.

ok.

> completely different (and optional) attribute.

to the operator (and the implementation) there's not a difference....

> You are also saying that now multipath code which computes which path are
> eligible to be multipath needs to look/parse/decrypt totally different
> attribute.

I didn't say anything about multipath. I presume it'd do the right
thing with the meta-attribute it knows about way deep inside bgp
processing on platforms that do bgp processing.

> attribute too. And surprise .. here BMP will not convert it like it will to
> "legacy" speakers.

sure, they'd have to do that anyway, or they just are
'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
other words, tomorrow for them is the same as today, the world keeps
on going round.

> You may think that if we stuff all "data" in the new attribute and drop the
> other one everything else will work. This may be so in theory, but it is
> clearly not a case in practice.

maybe? so far you've not convinced me... you can feel free to keep
trying though? email is cheap.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Apr 2012 19:49:25 +0200

Hi Warren,

Not seeing the problem/error does not mean it is not there.

I would in fact encourage in the initial years of deployment to use both 
to easily detect bugs and inconsistency issues.

In my view we should do all BGP processing based on "legacy" attributes 
and BGPSEC should be a hint to the local operator on how to treat the 
update.

Actually I am of the opinion (I think similar to some research voices in 
US) that secured BGP (or for that matter even origin validation) should 
be handled by few BGP Route Controllers providing AS based overlay 
certificate processing rather then by each individual BGP speaker in the 
network. BGP should be able to transport it as purely opaque information 
which could after automatic detection be used as best path 
decision/preference factor in a given AS.

Regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Apr 2012 19:57:45 +0200

> other words, tomorrow for them is the same as today, the world keeps

No. You are breaking things. BMP is not ibgp nor it is ebgp ! The 
station which works today and get's BGP sessions over BMP will now be 
useless as AS_PATH will not be there.

I assumed you know, but BMP idea is to replay what you are receiving (as 
verbatim as implementation allows).

> trying though? email is cheap.

I am not sure there is point in "convincing". Removing mandatory path 
attribute from BGP would be something IDR WG has to formally approve. 
And it will be an interesting precedence in any case ;)

Cheers,
R.

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 10 Apr 2012 14:22:25 -0400

> drove the design decision here I believe)

I think it was along the lines of:
2 AS paths will create the opportunity for an error if they differ
and we don't want to go around the error-handling block again.

I agree with Robert. Today, there are many tools that interact
with BGP messages. If the AS_PATH disappears, they will all break.

-- 
Jakob Heitz.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 16:56:54 -0400

On Tue, Apr 10, 2012 at 1:49 PM, Robert Raszuk <[email-masked]> wrote:
> In my view we should do all BGP processing based on "legacy" attributes and
> BGPSEC should be a hint to the local operator on how to treat the update.

i think that's the point of the current spec though... inbound updates
(on BGPSEC capable bgp sessions) which include BGPSEC information get
validated by the local router and 'colored' by route-map/policy as the
operator sees fit.
  route-map in-cust permit 10
    match bgpsec valid
    add community 2914:valid

this is the functionality you are asking for, yes?

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 17:03:49 -0400

On Tue, Apr 10, 2012 at 1:57 PM, Robert Raszuk <[email-masked]> wrote:
>>> to
> No. You are breaking things. BMP is not ibgp nor it is ebgp ! The station
> which works today and get's BGP sessions over BMP will now be useless as
> AS_PATH will not be there.

great, so ... bmp can either:
  1) be treated as a non-BGPSEC speaker (synthesize on the output to
bmp listener)
  2) be updated to include the BGPSEC relevant data in payload

downstream tools using the BMP stream(s) of course would have to be
updated. This doesn't seem like a huge deal though, and certainly is
expected.

> verbatim as implementation allows).

sure, so it has to know about new bits/pieces, nothing new here. If
you catch larry you might get this change/addition into his
final/final version before rfc-editor cuts the rfc.

> attribute from BGP would be something IDR WG has to formally approve. And it
> will be an interesting precedence in any case ;)

sure... once things settle out on the SIDR side, I'm positive we'll
have this discussion in IDR. You seem to be working through the
machinations of 'how do I deploy bgpsec in a network', is that the
case? would you be willing to document/presentation-style (or wiki or
...) the process for this? It seems like something other folks are
going to want to reference/use/discuss as well, so having a few worked
examples would be nice.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 17:05:00 -0400

> with BGP messages. If the AS_PATH disappears, they will all break.

aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker.
If the tools in question are updated to understand BGPSEC (and
negotiate that capability with the bgp speaker) then ... they'd
obviously have to know how to deal with this situation, right?

-chris

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 10 Apr 2012 17:51:24 -0400

> obviously have to know how to deal with this situation, right?

This will be a hurdle on the way to adoption.
I can see the network operator now: "My tools won't run. Let's
not turn BGPSEC on today".

The error-checking excuse looks real lame to me.

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Apr 2012 08:20:32 +0900

>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).

it might help if the poster actually read the drafts

>> drove the design decision here I believe)

this is considered a feature, not a bug

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Apr 2012 08:22:20 +0900

> not turn BGPSEC on today".

perhaps a good implementation will present the bgpsec as-path to the
operator in the traditional manner?

randy

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Apr 2012 09:25:41 +0200

> operator in the traditional manner?

perhaps it would be great if poster would recognize that we are no 
longer in the screen scraping era, and got familiar with BMP draft.

r.

---

From: Paul Jakma <[email-masked]>
Date: Wed, 11 Apr 2012 15:12:08 +0100 (BST)

On Tue, 10 Apr 2012, Jakob Heitz wrote:

> I agree with Robert. Today, there are many tools that interact with BGP 
> messages. If the AS_PATH disappears, they will all break.

Indeed. If mandatory, well-known attributes are removed, then the BGP 
protocol version number needs to be bumped.

There's near-0-cost in doing that for those interested in implementing the 
new functionality, and it avoids a world of hurt for all the various tools 
(sometimes in-house/home-grown) out there that believe they know what 
they're getting when the version says 4.

regards,
-- 
Paul Jakma  [email-masked]  twitter: @pjakma  PGP: 64A2FF6A
Fortune:
Genius may have its limitations, but stupidity is not thus handicapped.
 		-- Elbert Hubbard

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Apr 2012 10:20:53 -0400

I'm not at my usual spot in the week to catch up on IETF mail, but this
thread is noisy enough that it's caught my attention anyway. :-)

> I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same?

The apparent issue in this thread is basically, "what happens to AS_PATH?"
Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not thoroughly reading
it), there's commentary about what should be done with the AS_PATH.  That
commentary is mostly correct in the sense that all of the path loop
detection is already present.  (And the mostly is important.)  

IMO, there are two specific issues with regard to removing the AS_PATH and
one with keeping it.

1. What do you do about confederations?  These ASes are not only typically
internal but would have to use some sort of internal certs if we decided to
cover the confederation case.  Additionally, the current encoding format
doesn't include AS_PATH segment type as part of the signature.  

Note in particular that confederation segments MUST be stripped when
crossing an eBGP boundary.

2. More generally, what do you do about incremental deployment *within* the
AS?  One presumption I've been working on that I *thought* was shared by the
WG was that BGPSEC procedures only had to be done at eBGP edges.  While this
is primarily true for signature validation purposes, a desired side effect
of having the signature as a optional,transitive that paralleled the AS_PATH
was that iBGP speakers don't have to even be BGPSEC aware.  This lets you
upgrade your network from the outside first and get benefit.

As John Scudder likes to say, "a hard, crunchy shell". :-)

IMO, we should keep the AS_PATH.

3. Which brings us to the third point - what do we do when the signature and
the AS_PATH disagree with each other?  Note that this was also a problem for
4-byte ASes (RFC 4893).  That spec chose to simply trust the 4-byte path
beyond a certain point.  (I don't necessarily agree with it, but that's what
consensus was.)  Exactly what we do here needs to be specified, and some of
that specification will come from deciding what we want to do about some things.

For example, we want to prevent the path from being shortened.  As long as
the ASes involved in both signature and path are congruent, we can use the
length in the signature if the number of ASes in the path are shorter than
the signature.

In the case where the paths are still congruent but the AS_PATH has a longer
prepend (see my ingress prepending use case from a few sessions back), it
may be fine to use the AS_PATH (and its length for route selection
purposes).  Yes, I understand there isn't consensus here.

In the case where the paths are not congruent (which shouldn't happen unlike
the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across other BGP), we
probably have some sort of hard error case.  One reasonable assumption is
that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP speaker
doing path manipulations for policy.  IMO, the proper behavior here is to
*not* propagate the route at a BGPSEC ASBR boundary; any BGP speaker that
manipulates the AS_PATH in such a way as to break the congruency of ASes
between AS_PATH and signature MUST be a BGPSEC speaker.

The above still doesn't deal with common deployment considerations such as
as-override, replace-as and remove-private.  I see there's a thread about
proxy signing and perhaps that discussion is over there.  I'll hopefully get
to it in a few days.

(And if you're not familiar with those three features and their deployment
scenarios, please take some time to become familiar.  Not dealing with them
will be a significant deployment hurdle.)

-- Jeff

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 11:22:39 -0400

> they're getting when the version says 4.

"if you don't ask for the 'bgpsec capability' then ... you get what
you get today."

also

"if you ask for the 'bgpsec capabiltiy' then ... you get (and can
presumably handle) the changes"

so, everything you do today, ought to just keep right on working, or
that's the plan.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 11 Apr 2012 12:17:40 -0400

Confeds are out of scope.

VPN address families are out of scope.

If the BGPSEC path does not match the AS_PATH, the update
is invalid.

The validity of an update is used as an input to route selection.
If you have been replace/override/removing ASNs, you are free to
use that information in route selection too.

IOW, the BGPSEC validity of an update does not necessarily
prevent you from using the update if you have inside knowledge
about AS path mucking. How you use the BGPSEC validity in
your route selection is a private matter.

On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote:

>> I think that sone of the biggest issues to keep in mind with
>> carrying the "same" data in two places is what to do when you
>> suddenly discover that they are not actually the same?  
> 
> The apparent issue in this thread is basically, "what happens to
> AS_PATH?" Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not
> thoroughly reading 
> it), there's commentary about what should be done with the AS_PATH. 
> That commentary is mostly correct in the sense that all of the path
> loop 
> 1. What do you do about confederations?  These ASes are not only
> typically internal but would have to use some sort of internal certs
> if we decided to cover the confederation case.  Additionally, the
> current encoding format doesn't include AS_PATH segment type as part
> of the signature. 
> 
> of having the signature as a optional,transitive that paralleled the
> AS_PATH was that iBGP speakers don't have to even be BGPSEC aware. 
> This lets you upgrade your network from the outside first and get
> benefit. 
> 
> 3. Which brings us to the third point - what do we do when the
> signature and the AS_PATH disagree with each other?  Note that this
> was also a problem for 4-byte ASes (RFC 4893).  That spec chose to
> simply trust the 4-byte path 
> beyond a certain point.  (I don't necessarily agree with it, but
> that's what consensus was.)  Exactly what we do here needs to be
> specified, and some of that specification will come from deciding
> what we want to do about some things. 
> 
> the ASes involved in both signature and path are congruent, we can
> use the length in the signature if the number of ASes in the path are
> shorter than 
> the signature.
> 
> In the case where the paths are still congruent but the AS_PATH has a
> longer prepend (see my ingress prepending use case from a few
> sessions back), it 
> In the case where the paths are not congruent (which shouldn't happen
> unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across
> other BGP), we probably have some sort of hard error case.  One
> reasonable assumption is 
> that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP
> speaker doing path manipulations for policy.  IMO, the proper
> behavior here is to *not* propagate the route at a BGPSEC ASBR
> boundary; any BGP speaker that manipulates the AS_PATH in such a way
> as to break the congruency of ASes between AS_PATH and signature MUST
> be a BGPSEC speaker. 
> 
> The above still doesn't deal with common deployment considerations
> such as as-override, replace-as and remove-private.  I see there's a
> thread about 
> (And if you're not familiar with those three features and their
> deployment scenarios, please take some time to become familiar.  Not
> dealing with them will be a significant deployment hurdle.)
> 
> -- Jeff

-- 
Jakob Heitz.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 12:28:32 -0400

> Confeds are out of scope.

how are confeds out of scope?
if you want path validation for ibgp/originated-by-you routes and the
originating router is in one of the confed sub-ases you have that
router sign with the confed-external/public asn, no? I'm fairly
certain we planned to support this sort of activity... though I could
be missing the part which is out-of-scope?

> your route selection is a private matter.

yes, which is, I think, nice.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Apr 2012 12:40:58 -0400

On Tue, Apr 10, 2012 at 1:47 PM, Christopher Morrow <[email-masked]
> wrote:

> the
Okay, I'll bite...

Suppose someone wants to take an existing tool which speaks BGP, and writes
out full tables and updates to files. Call it "bgpmon". :-)

The obvious thing to do for that tool, would be for it to advertise that it
speaks BGPSEC, and record the updates that come from BGPSEC speakers.

Clearly, this tool is not a router, nor does it need to do validation. In
fact, you *don't* want to validate, since you want to record all updates,
*including* invalid updates.

The ability to do quick-and-dirty comparisons between BGP-vanilla and
BGPSEC data, from archived data, would be significantly hampered if the
AS_PATH had to be reconstructed from this data.

Duplicate bits should really not be a huge deal.

Perhaps, at minimum, there should be a negotiated option on whether or not
the AS_PATH is included in updates, on a per-neighbor basis?

That would allow both sides to win, and even better, provide some measure
of interoperability testing, including possibly passing the opaque
attribute through non-believers to far-end systems that want to see *all*
the BGPSEC data, even when it has crossed outside of the BGPSEC bubble.

In particular, this would be very helpful during the incremental deployment
phases, where there are *multiple* islands of BGPSEC.

Brian

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Apr 2012 15:48:09 -0400

> be missing the part which is out-of-scope?

Functionally, confed segments are stripped prior to the global AS being
added to the path.  The box performing this function is the one that needs
to amend the BGPSEC signature, not some box in the middle of the
confederation.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Apr 2012 15:52:45 -0400

> VPN address families are out of scope.

Meaning that the AS_PATH has to be present.  No?

(I suspect you mean yes.  That's the matter at hand.)

> If the BGPSEC path does not match the AS_PATH, the update

You mean a 1:1 match of ASes including prepend counts?  If so, that's at
least an opinion. :-)

> use that information in route selection too.

That depends on path validity.  If you require that the AS_PATH and the
signature are identical (or potentially accommodate transparent ASes of
length 0), you can't do a number of those things without rendering the route
invalid.  Again, deployment issues.

> your route selection is a private matter.

In general, I agree.  The particulars have consequences.

-- Jeff

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 15:53:29 -0400

> to amend the BGPSEC signature, not some box in the middle of the

I suppose you could re-sign... the case I was thinking of was
attempting to validate inside your domain a prefix supposedly
originated by an iBGP speaker inside your domain.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Apr 2012 15:52:29 +0200

I very much agree with both Paul and Wes that new BGP version number or 
at least new set of AFIs would be the best way to smoothly migrate 
unsecure BGP to secure one.

I have not seem anyone resisting that idea yet with real technical 
arguments against it ;)

Rgs,
R.

> [WEG] Why*are*  we so resistant to incrementing the BGP version? I
> think that there's some merit to the idea that this suite of things
> represents a significant enough change to BGP that a change in
> version number might be a cleaner way to do the capability
> negotiation, perhaps even incorporating other secondary capabilities
> so that there isn't so much individual capability negotiation for all
> of the things that we've tacked onto BGP4 over the years. In other
> words, if you support BGPv5, you support the a list of capabilities
> (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to
> be negotiated separately. Even if we move directly from version 4 to
> 6 as it seems we are wont to do, I think this bears some
> consideration (by IDR, of course);-)
>
> Wes George

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Apr 2012 10:50:33 -0400

On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote:
> I very much agree with both Paul and Wes that new BGP version number
> or at least new set of AFIs would be the best way to smoothly
> migrate unsecure BGP to secure one.

If it's not backward compatible, sure.

> I have not seem anyone resisting that idea yet with real technical

See my migration comments earlier.  If you think you can get a given SP that
might be willing to install BGPSEC at the edges also willing to upgrade
every other BGP speaker inside their AS... you're more optimistic than I.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Apr 2012 10:52:58 -0400

On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote:
> > added to the path. ?The box performing this function is the one that needs

If you don't trust your own boxes to originate, I think you have a  bigger
problem. :-)

That said, there's little stopping you from using RPKI (perhaps with a local
view) data to provide prefix sanity checking.  Internally the signature
piece is probably excessive.

-- Jeff

---

From: "George, Wes" <[email-masked]>
Date: Thu, 12 Apr 2012 08:07:43 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 12:29 PM
> To: Jakob Heitz
> Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC
> intradomain ?)
>

[WEG] There was discussion on the SIDR list on November 12 (subject line "various") specifically regarding private ASNs and confeds and their discussion in the bgpsec-ops draft. I am writing offline and therefore can't provide a more specific pointer to the message itself nor confirm (as memory of the more previous versions that I've reviewed fails) that the product of that discussion has made it to an updated version, but I'm pretty sure that it has. I'd encourage you to look back at this and see if you have additional feedback regarding in/out of scope and implementation.

FWIW, confeds being truly out of scope may make BGPSec a no-op in my network, as I can't guarantee that confeds will be gone (unless you are suggesting that they should be deprecated a la AS_SETs). My earlier recommendation is that we have to be specific about how BGPSec handles signing and stripping to manage an ASPath including confeds, whether it only signs at the external side and previous signatures (if exist) are dropped, or if it is capable of handling something like this:

Origin ASN (public) -> Transit ASN1 (public) -> [confed ASN(s) (private)] -> confed ASN42 (public) -> confed ASN55 -- in that example, if the entire path is BGPSec capable, what does ASN42 send as the signed path? You have several ASNs that maybe need path count 0 in their signature so that they are signed but don't interfere with the externally-visible path, or the Transit ASN1 has to forward sign its updates as if they are directly connected to confed ASN42 (public), meaning that we are potentially allowing it to transit multiple ASNs within the confed unsigned. Randy had said previously that confed ASNs shouldn't sign towards each other, so maybe that answers that question, but since it has come back up, please give it some thought.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 12 Apr 2012 08:31:44 -0400

Trying again without the signature block. Sorry about that, hit send too soon. *blush*
> > Sent: Wednesday, April 11, 2012 11:23 AM
> > To: Paul Jakma
> > Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
> >
> [WEG] Why *are* we so resistant to incrementing the BGP version? I think that
> there's some merit to the idea that this suite of things represents a
> significant enough change to BGP that a change in version number might be a
> cleaner way to do the capability negotiation, perhaps even incorporating other
> secondary capabilities so that there isn't so much individual capability
> negotiation for all of the things that we've tacked onto BGP4 over the years.
> In other words, if you support BGPv5, you support the a list of capabilities
> (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to be
> negotiated separately. Even if we move directly from version 4 to 6 as it
> seems we are wont to do, I think this bears some consideration (by IDR, of
> course) ;-)
>
> Wes George
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 12 Apr 2012 11:28:44 -0400

> If you don't trust your own boxes to originate, I think you have a  bigger

yes... where's that box in $HOSTILE_COUNTRY ? are we SURE that no one
has tampered with it during the recent 'unscheduled power outage' ? :(
darned crapblarghistan and it's ongoing power grid problems!

> piece is probably excessive.

this is all from another frequent-poster to this list (the requirement
I mean)... I'm just parroting it back for the record. (though I do see
a valid case to sign on origination as well, and check internally)

you don't seem to disagree that the functionality could be there, so
... 'violent agreement'!

-chris

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Apr 2012 11:39:16 -0400

> you don't seem to disagree that the functionality could be there, so

I think what I'd be saying is "if you want this to be done at point of
origination", there's significant work to be done.

- Jeff

---

From: "George, Wes" <[email-masked]>
Date: Thu, 12 Apr 2012 13:07:38 -0400

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Thursday, April 12, 2012 10:51 AM
> To: Robert Raszuk
> Cc: George, Wes; Paul Jakma; [email-masked] List; [email-masked]
> Subject: Re: [Idr] [sidr] No BGPSEC intradomain ?
>
[WEG] that's sort of the point -- there are a lot of factors to consider when determining what "backward compatible" truly means as far as BGPSec is concerned, especially when it comes to monitoring tools and other things that need to know the data but not necessarily make routing decisions on it.
> every other BGP speaker inside their AS... you're more optimistic than I.

[WEG] I'm not totally sure which message you're referring to, but I think that may be a red herring. I'm not seeing how incrementing the BGP version automatically means that all routers in an ASN must upgrade to it. This isn't exactly the same flag day sort of driver as the move between v3 and v4. BGP speakers that support BGPv5 also SHOULD support BGPv4, and would determine which they should use on initial capability negotiation. Same way as they would do if BGPSec (and any other option) is a standalone capability to negotiate. Even if you look at this from a scaling perspective (the BGPv5 speaker would have to craft and send out two different versions of update) we've already sort of said that this is acceptable collateral damage because of the fact that it can't send the same updates to neighbors of multiple different ASNs because it has to sign them all differently.
What am I missing?

Wes George

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Apr 2012 14:21:23 -0400

On Thu, Apr 12, 2012 at 01:07:38PM -0400, George, Wes wrote:
> [WEG] I'm not totally sure which message you're referring to, but I think that may be a red herring. I'm not seeing how incrementing the BGP version automatically means that all routers in an ASN must upgrade to it.

Fish aside, given prior statements that once you leave a BGPSEC domain that
you stop doing BGPSEC, then it seems reasonable that you can't have bgp-4
inside of bgpsec.

I suspect that's not what some people are meaning by BGPSEC domains or
versions or what have you.  But this is all fall-out of what does it mean to
do BGPSEC in an AS that won't have some number of routers that can do it.

The original model discussed was BGPSEC signature operations at eBGP
borders.  In that model, iBGP considerations are largely irrelevant to the
signatures.  Where they become important is the edge cases where iBGP may
alter AS_PATH data. 

If iBGP speakers are expected to participate in signature operations, we
need to figure out what that means.  Chris M. suggests signing at
origination - signing to what exactly?  When there's confederations, is
there signing?  What do those certs look like in the RPKI especially when AS
numbers are re-used (private ASes)?  How do you handle confederation AS
stripping signature-wise?

If you don't believe each router in an AS needs an upgrade, you obviously
have protocol behavior in mind.  Write it down, please.  Keep in mind the
answer will change based on whether BGPSEC operations are done in iBGP or
not.

> This isn't exactly the same flag day sort of driver as the move between v3 and v4. BGP speakers that support BGPv5 also SHOULD support BGPv4, and would determine which they should use on initial capability negotiation.

If you can do the work via capability negotiation, I'd argue you don't
really need a new version number.

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Thu, 12 Apr 2012 20:01:37 +0100 (BST)

> so, everything you do today, ought to just keep right on working, or

Capability negotiation does not mean everything keeps on working. It means 
the session between the BGP speakers keeps working, sure. However, that's 
_not_ everything.

The BGP UPDATE message is no longer context-complete (wrt to the 
well-known attributes at least). If a 3rd-party wishes to be able to 
validate the message as cortrect (in the case of missing attributes) or 
even decode it correctly (in the case where well-known attributes are 
incompatibly redefined in syntax, like AS_PATH has been), it has to have 
seen the opening negotiation - which may have happened days or weeks or 
more before - or it has to be manually configured or make intelligent 
guesses.

It should be quite possible to keep BGP as completely parse-able at the 
message granularity - it just needs a modicum of care. It's a shame that 
ever more proposals are coming along that are overloading message formats, 
dependent on context that may only be exchanged very infrequently...

regards,
-- 
Paul Jakma	[email-masked]	@pjakma	Key ID: 64A2FF6A
Fortune:
static from plastic slide rules

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 12 Apr 2012 23:59:30 -0400

On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote:

> such as as-override, replace-as and remove-private.

This just highlights the semantic difference between the BGPSEC
path and the AS_PATH.

They may be different legitimately. This is why we need both.

A receiver can make its own decision whether the difference
between the paths should cause path invalidation or not.
If a sender is legitimately manipulating an AS_PATH, then the
receiver should know about it and use this knowledge to help
in the decision.

-- 
Jakob Heitz.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Apr 2012 18:05:44 -0400

At the risk of opening a can of worms (or at least seeing a cylindrical
hollow metal labeled "Caution: contains worms")...

I believe the larger issue is, that Authentication is orthogonal to
Authorization.

As it currently stands, only Authentication has been given any
consideration, per se.

The two things being Authenticated are:
o  Origination (prefix + ASN, and maybe other identifying elements such as
IP addresses of routers), and
o   ASNs in the AS_PATH.

What is not explicitly being discussed, is, the question of "What is $foo
Authorized to do?".

E.g. The implicit assumption is, Only ASN==X is allowed to originate
prefixes whose AS_PATH "starts" (ends) with X.
And, the other implicit assumption is, the only thing any ASN is permitted
to do, is to prepend its own ASN to the AS_PATH, (zero or) one or more
times.

However, it may be worth considering all the other things that are done by
ASNs currently:
o   Private ASNs being stripped (private leaf ASNs)
o   Confederations
o   Route Servers
o   ECMP and friends
o   other vendor-specific or multi-vendor stuff being done to the AS-Path
(replace-as, as-sets, etc.)

Rather than dogmatically ignoring these issues, or declare them "out of
scope!!!",
I would prefer to see a rational discussion on whether there is a suitable
place in the system,
to facilitate some way of handling these cases, in a way that does not
weaken the security model.

Basically, rather than just say, "Okay, if you want to do this, turn off
BGPSEC", I think there is
value in saying, "To do this, you need to add $X to $Y to authorize this
activity", so that
RPs are able to reconcile what they receive, with what the RPKI-encoded
data says they
should expect.

For example:
Say that ASs A, B, and C, exchange routes via a route-server AS S.
Each of A, B, and C encode something that says, roughly:
"I am okay with NLRIs I send to S, have S omitted from the AS_PATH", and,
"I am okay with S sending me NLRIs that have S omitted, so long as the
immediate AS after S, also allows S to omit itself".
So, a signature block "R B S C Q" can be reconciled with an AS_PATH of "R B
C Q", by seeing the S sig,
and the rules for C->S and S->B allow this, established respectively by all
of C, S, and B.

The difference between this, and the whole "pCount==0" thing, is that the
above is an explicit policy encoded in the RPKI,
which can be validated more than one hop away from S.

The "pCount==0" logic is only truly verifiable by the immediate recipient,
and then only by the operator's personal implementation for enforcing local
policy (which itself be weak or faulty).

A recipient of an BGPSEC_Signatures_Block which has any pCount==0 in the
middle, currently has no way of ascertaining the legitimacy of that
occurrence.
The Signature Block (AS/N) of "R/1 B/1 S/0 C/1 Q/1" is consistent with an
AS_PATH of "R B C Q", but there is no way to know if this is in fact
sensible.

For other examples:
Private ASNs are, by definition, not unique.
However, it would still be nice to be able to identify their owners, e.g.
by IP address, and validate ASN substitutions by RPKI, based on
Origination/Signature data.

Proxy Origination would also be nice to have Authorization of Delegation
(to sign), possibly chained.
E.g. A delegates signature_origination to B, who delegates
signature_origination to C.
Prefixes assigned to A, could be signed by C, but would validate only if
the signed AS_PATH was "C B A".

I'm sure there are plenty of other use cases, which match up with actual
operator practices today.

If the mechanics of this can be done in a scalable and secure manner, this
will greatly enhance deployment likelihood, and ease deployment itself.

(This is where the IETF in general, can redeem itself for its past sins.
Don't ignore real needs, regardless of how tempting it is to keep designs
"pure".)

IMHO.

Brian

P.S. This kind of complex stuff really begs face-to-face meeting time. It
is hard to convey intent via messages. Oh, the irony...