Subject: [sidr] route leaks message to IDR

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 13 Mar 2012 14:22:41 +0000

In the interim meeting, the consensus was that we needed idr to be involved in any definition and solution for route leaks.  It was decided to discuss a message to the idr wg on the sidr list.

Brian Dickson has submitted drafts about route leaks, as he offered in the meeting.

So here is a first draft at a messate to idr.  Comments please.

==============

The sidr interim meeting in February discussed the problem of route leaks.

While those in the room could recognize route leaks in a diagram, they could not determine a way to determine that from information communicated in BGP.

Proposals to stop route leaks add information to BGP updates that would be used to restrict the propagation of those updates by the neighbor onward to providers, customers, peers, etc.

This is a change to BGP behavior, which now relies on local configuration only to choose a best path and advertise it.  Adding features to stop route leaks would restrict that advertisement and restrict what local policy could choose.

The consensus in the room was that adding a new feature to a protocol as part of a security protection  (i.e., not just ensuring an already defined behavior but producing brand new behavior) is unwise and leads to problems.

The sidr working group requests that idr discuss the route leaks problem with sidr and determine the best path forward.

The idr wg should also be aware that drafts have been submitted about route leaks, so work is underway.

http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01
http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-01
http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02
http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01

===================

--Sandy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 13 Mar 2012 10:39:36 -0400

I think your message reads good.

Should Brian be encouraged to present his route-leak drafts in the IDR WG meeting?
Do we know if he is he planning to?

Sriram

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Murphy, Sandra
>Sent: Tuesday, March 13, 2012 10:23 AM
>To: [email-masked]
>Subject: [sidr] route leaks message to IDR
>
>In the interim meeting, the consensus was that we needed idr to be involved in
>any definition and solution for route leaks.  It was decided to discuss a message to
>the idr wg on the sidr list.
>
>While those in the room could recognize route leaks in a diagram, they could not
>determine a way to determine that from information communicated in BGP.
>
>Proposals to stop route leaks add information to BGP updates that would be used
>to restrict the propagation of those updates by the neighbor onward to providers,
>customers, peers, etc.
>
>This is a change to BGP behavior, which now relies on local configuration only to
>choose a best path and advertise it.  Adding features to stop route leaks would
>restrict that advertisement and restrict what local policy could choose.
>
>The consensus in the room was that adding a new feature to a protocol as part of
>a security protection  (i.e., not just ensuring an already defined behavior but
>producing brand new behavior) is unwise and leads to problems.
>
>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: "George, Wes" <[email-masked]>
Date: Wed, 14 Mar 2012 12:49:08 -0400

I'm basically fine with the wording below. The only thing I might add would be some mention of the reason why we're talking about route leaks, why they're considered a problem that should be solved in the context of SIDR, etc - mainly that there are those among the WG and operator community that believe BGPSec as currently proposed is incomplete without a method to prevent route leaks, and given the costs to deploy and manage BGPSec, the inability to protect against this problem limits its attractiveness for deployment.

This is covered in detail in the referenced drafts, but is worth including in the summary text.

Thanks,

Wes

> any definition and solution for route leaks.  It was decided to discuss a
> message to the idr wg on the sidr list.
>
> While those in the room could recognize route leaks in a diagram, they could
> not determine a way to determine that from information communicated in BGP.
>
> Proposals to stop route leaks add information to BGP updates that would be
> used to restrict the propagation of those updates by the neighbor onward to
> providers, customers, peers, etc.
>
> This is a change to BGP behavior, which now relies on local configuration only
> to choose a best path and advertise it.  Adding features to stop route leaks
> would restrict that advertisement and restrict what local policy could choose.
>
> The consensus in the room was that adding a new feature to a protocol as part
> of a security protection  (i.e., not just ensuring an already defined behavior
> but producing brand new behavior) is unwise and leads to problems.
>
> The sidr working group requests that idr discuss the route leaks problem with
> sidr and determine the best path forward.
>

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: Eric Osterweil <[email-masked]>
Date: Wed, 14 Mar 2012 19:38:06 +0100

I'd also like to add that (if I'm not mistaken) much of the BGPSEC work is _already_ proposing to "add information to BGP updates."  For example, I'm pretty sure there aren't any signatures in BGP right now, right?  I don't think this text is completely on the level, because my recollection of many of the sidr drafts is that they _ARE_ proposing to add data, semantics, and processes to the current operation of BGP.  By my reading of the text below, it sounds like we would only add these things if we were going to add route leak protection, and that sentiment seems wrong to me.  Moreover, the text below conflates the need for leak protection with some as-yet-unspecified approach that must use inline protocol changes.  I don't know that this has been openly agreed to by all (which is fine at this stage), but in reaching out to grow w/ this as a starting point I think we present both a problem and an unratified straw-man.  I think the text needs to be clarified.  

Also, I'd like to request in the 5th para (or the 6th sentence?):
	s/The consensus in the room was/The consensus in the room (though it is not clear what portion of the wg agrees) was/

Thanks,

Eric

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 14 Mar 2012 20:24:36 +0000

I am afraid that you missed the point that I was trying to make.

Adding information is not the problem.

Adding a new *routing feature* is the problem.

BGP presently has no feature that lets the sender restrict where the receiver might propagate a route.    So the security protections would have to invent the feature and secure it at the same time.

The consensus of the meeting was that this is a bad way to do design.  Adding a new feature as part of adding a new security protection has been found to lead to problems.  

Note that the current sidr work does not conflict with this.  The protections we are developing are there to protect features that already exist in the BGP spec, but are vulnerable to misuse.  The protections eliminate "bad" behavior, but they do not produce new routing features.

Wrt the interim meeting.  The minutes and jabber logs are available.  Commenting on the list is always possible.

The drafts were mentioned to show that people are actively beginning to work on this, not as pointers to a candidate.

The message below asks for idr's (not grow's) consideration of how to proceed.  Do you have some objection to idr being part of the definition of a new routing feature?

--Sandy

________________________________________
From: Eric Osterweil [[email-masked]]
Sent: Wednesday, March 14, 2012 2:38 PM
To: George, Wes
Cc: Murphy, Sandra; [email-masked]
Subject: Re: [sidr] route leaks message to IDR

Thanks,

Eric

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Mar 2012 16:50:20 -0400

At 7:38 PM +0100 3/14/12, Eric Osterweil wrote:
>I'd also like to add that (if I'm not mistaken) much of the BGPSEC 
>work is _already_ proposing to "add information to BGP updates." 
>For example, I'm pretty sure there aren't any signatures in BGP 
>right now, right?

The addition of sigs to provide integrity and authentication for 
AS_path info does not add new semantics to BGP. The sigs are used to 
secure the existing semantics. I think that's what Sandy meant to 
convey in her message, but maybe the wording needs to be improved.

>   I don't think this text is completely on the level, because my 
>recollection of many of the sidr drafts is that they _ARE_ proposing 
>to add data, semantics, and processes to the current operation of 
>BGP.

New data, yes, new semantics, no. We were heading in that direction with
the "beaconing" mechanism, but that seems to have gone away.

>   By my reading of the text below, it sounds like we would only add 
>these things if we were going to add route leak protection, and that 
>sentiment seems wrong to me.

Add which "things?"

>   Moreover, the text below conflates the need for leak protection 
>with some as-yet-unspecified approach that must use inline protocol 
>changes.

That is a fair observation, i.e., if there is agreement that route leaks
can be defined in a rigorous, unambiguous fashion, then it is appropriate
to explore various ways of detecting them.

>   I don't know that this has been openly agreed to by all (which is 
>fine at this stage), but in reaching out to grow w/ this as a 
>starting point I think we present both a problem and an unratified 
>straw-man.  I think the text needs to be clarified.

I think the message asks IDR to look into this, not GROW.

>	s/The consensus in the room was/The consensus in the room 
>(though it is not clear what portion of the wg agrees) was/

seems like a reasonable edit.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 14 Mar 2012 22:31:15 +0100

> BGP presently has no feature that lets the sender restrict where the receiver might propagate a route.    So the security protections would have to invent the feature and secure it at the same time.

This presumes the protections are to be incorporated into the control plane.  I don't know that everyone feels that way, which is why I suggested my second comment.

> The consensus of the meeting was that this is a bad way to do design.  Adding a new feature as part of adding a new security protection has been found to lead to problems.  

So, now maybe I'm confused... Is BGPSEC not adding a new feature, or is it a bad way to do design?

> Note that the current sidr work does not conflict with this.  The protections we are developing are there to protect features that already exist in the BGP spec, but are vulnerable to misuse.  The…

By adding information to BGP updates.  Again, this thread started with a statement to (as you corrected): idr.  I think the wording needs work...

> Wrt the interim meeting.  The minutes and jabber logs are available.  Commenting on the list is always possible.

I did not invalidate your summary of the minutes.  I simply clarified that those at the interim meeting do not (in this case) speak for all of us, and it's not clear how many of us agree.  Why is that not fair?

> The message below asks for idr's (not grow's) consideration of how to proceed.  Do you have some objection to idr being part of the definition of a new routing feature?

Nope, I think it's great, but lets not conflate issues and use vagaries where we can be specific. ;)

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 14 Mar 2012 22:35:07 +0100

On Mar 14, 2012, at 9:50 PM, Stephen Kent wrote:

>> I'd also like to add that (if I'm not mistaken) much of the BGPSEC work is _already_ proposing to "add information to BGP updates." For example, I'm pretty sure there aren't any signatures in BGP right now, right?
> 
> The addition of sigs to provide integrity and authentication for AS_path info does not add new semantics to BGP. The sigs are used to secure the existing semantics. I think that's what Sandy meant to convey in her message, but maybe the wording needs to be improved.

Yup, I do think the wording needs some work, thnx for the ack.

> 
>>  I don't think this text is completely on the level, because my recollection of many of the sidr drafts is that they _ARE_ proposing to add data, semantics, and processes to the current operation of BGP.
> 

So, what happens (for example) when a sig on an update can't be verified?  Is an update not processed and applied as it otherwise would be?  I guess it seems to me that the semantics of an update have changed if a new portion of that update (the sig) can cause interpretation of the meaning of that update to change (i.e. drop updates with unverifiable sigs, update RIB if the sigs are verifiable).

> 
>>  By my reading of the text below, it sounds like we would only add these things if we were going to add route leak protection, and that sentiment seems wrong to me.
> 
> Add which "things?"

When you break the paragraph up, the pronouns are not as easy to associate w/ their common nouns. ;)  "Things," was referring to "data, semantics, and processes."

> 
>>  Moreover, the text below conflates the need for leak protection with some as-yet-unspecified approach that must use inline protocol changes.
> 

I think we agree that defining leaks and discussing any mechanisms to remediate them are separate.

> 
>>  I don't know that this has been openly agreed to by all (which is fine at this stage), but in reaching out to grow w/ this as a starting point I think we present both a problem and an unratified straw-man.  I think the text needs to be clarified.
> 

Yup... I had a brain fart.  It's been a long week already... :-P

> seems like a reasonable edit.

Kewl, thanks again for the ack!

Eric

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Mar 2012 18:07:26 -0400

At 10:35 PM +0100 3/14/12, Eric Osterweil wrote:
>...
>
>So, what happens (for example) when a sig on an update can't be 
>verified?  Is an update not processed and applied as it otherwise 
>would be?  I guess it seems to me that the semantics of an update 
>have changed if a new portion of that update (the sig) can cause 
>interpretation of the meaning of that update to change (i.e. drop 
>updates with unverifiable sigs, update RIB if the sigs are 
>verifiable).

I see your point, but disagree. Let me try to explain.

Whenever we add secruity mechanisms to a protocol we create new ways 
to cause the protocol to fail to forward data, fail to establish a 
connection, etc. The model I have long (>30 years) employed is that 
if the secruity checks succeed, the protocol should operate as before 
(i.e., w/o the added secruity mechanisms), because the environment is 
seen as benign. If the checks fail, the protocol should behave 
differently, e.g., something should fail, because the environment is 
now perceived as hostile and the protocol (w/o benefit of the 
secruity mechanisms) was not engineered to work properly in a hostile 
environment.

Consider for example the fact that many protocols incorporate an 
integrity check. If the check fails, that causes a packet to be 
dropped. Typically the integrity check mechanism is not secure 
against attacks; is just a mechanism designed to detect benign 
errors. We frequently introduce crypto-based integrity mechanisms 
when we want to counter attacks. Those mechanisms will cause the 
protocol to behave differently in attack scenarios, e.g., an  attack 
that might have yielded a valid checksum will yield an invalid HMAC, 
and that will cause a packet to be dropped. This is generally viewed 
not as a change to the protocol semantics, but rather an appropriate 
and natural effect of operating the protocol in a secure manner.

I'd like to think that the BGPSEC mechanisms are being developed in a 
way that tries to adhere to this paradigm.

>...
>  >
>>  Add which "things?"
>
>When you break the paragraph up, the pronouns are not as easy to 
>associate w/ their common nouns. ;)  "Things," was referring to 
>"data, semantics, and processes."

I read the text before the paragraph was sliced and diced, and I felt 
that "things" was ambiguous. Now that the ambiguity is removed, I 
just disagree with your reading of the text :-).

>.

separate, but very interdependent. If the definition is squishy, 
countermeasures are likely to be messy, at best.

Steve

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 16 Mar 2012 00:22:13 +0000

speaking more as regular ol' member

On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil  said:

>> BGP presently has no feature that lets the sender restrict where the
>>receiver might propagate a route.  So the security protections would
>>have to invent the fea ture and secure it at the same time.

>This presumes the protections are to be incorporated into the control
>plane.  I don't know that everyone feels that way, which is why I
>suggested my second comment.

My understanding of the desired outcome is that the sending ISP wishes
to put restrictions on what the receiving ISP can do with the update.

Whether that restriction is communicated inband or outofband, the
intent to restrict BGP update propagation is the same.

That is a new feature for BGP.

>> 
>> The consensus of the meeting was that this is a bad way to do
>>design.  Adding a new feature as part of adding a new security
>>protection has been found to lead to problems.

>is it a bad way to do design?

BGPSEC is not a new *routing* feature.  It is protections for existing
routing features.  BGPSEC eliminates certain *bad* routing behavior,
but it should not create *new* routing features.

The ability to restrict where a receiver can propagate an update is
not presently BGP behavior.  Brand new routing behavior.  That's the
difference.

>By adding information to BGP updates.

The information added to BGP updates for BGPSEC is there only to
eliminate bad behaviors.  Adding information is not the same as
adding a new BGP routing feature.

>I did not invalidate your summary of the minutes.  I simply clarified
>that those a t the interim meeting do not (in this case) speak for all
>of us, and it's not clear how many of us agree.  Why is that not
>fair?

You spoke of those who might not agree with the interim meeting.
I was only suggesting that you and anyone not in attendance could
comment on the mailing list, by referring to the archive.

>> The message below asks for idr's (not grow's) consideration of how
>>to proceed.  Do you have some objection to idr being part of the
>>definition of a new routing feature?

>vagaries where we can be specific. ;)

Glad you agree with the strategy.

--Sandy, explaining a message sent as wg co-chair but giving my
         own regular ol' member opinion

---

From: Brian Dickson <[email-masked]>
Date: Fri, 16 Mar 2012 11:56:44 -0400

> to put restrictions on what the receiving ISP can do with the update.

That is not correct, i.e. you misunderstand.

The desired outcome is that sender/receiver _negotiate_ what is or is not
to be sent,
and the protocol merely enforces what has been agreed upon. The automatic
enforcement
of this high-level policy, is what stops route leaks from being initiated
or propagated.
The policy is still determined by the operators at both ends of a peering
session.
Just like the IP addresses and ASNs, the policies have to match for BGP
session establishment.
Unilateral misconfiguration (whether by accident or deliberate act), which
could have introduced
or propagated route leaks, are prevented.

The proposal(s) provide all the mechanisms to express any
mutually-agreeable policy,
including "send all routes in both directions". They do not preclude other
refinements,
such as AS-path filters, prefix filters, communities-related processing, or
anything else.

Nothing is unilateral, in what is proposed, so saying that the sending ISP
puts restrictions
on what the receiver can do, is actually a gross mischaracterization. (No
intent is inferred,
of course - it is clearly just a misunderstanding of the purpose and intent
of the proposals.)

> intent to restrict BGP update propagation is the same.
(Incorrect.)

> That is a new feature for BGP.

Correct, although whether this is part of BGPSEC (itself a new feature)
or not, is the main thing to be discussed, inclusive of IDR's input.

> but it should not create *new* routing features.
Pot_ay_to, pot_ah_to.

It should fall to the _WG_ to determine whether BGPSEC _is_,
and/or _should_, be treated as a new feature.
I do not believe the charter explicitly forces
the WG onto one side of the line in the sand (feature/not-feature).

And, I believe fundamentally, it _needs_ to be a new feature (set)
on BGP, with all that goes along with it. There seems to be a strong
reluctance among a subset of folks, to say this is a new feature set.
This reluctance is appearing to fracture the WG into an us/them
dichotomy, which is antithetical to the IETF philosophy.

If BGPSEC were not a new feature, there would not be any need
to add the BGP options negotiation between peers doing BGPSEC.

And, if we acknowledge that it is a new feature, it then is incumbent
on the WG members and chairs, to listen to all the WG participants,
regarding what the requirements are in reaching the charter's goals,
whether they are explicitly in the charter, or implicit consequences
of what is necessary and sufficient in reaching those goals. This
would potentially include other attributes being added, other data
being cryptographically protected, and/or other negotiated peering
parameters.

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 16 Mar 2012 16:54:08 -0400

(behind on my reading, but...)

>> to put restrictions on what the receiving ISP can do with the update.

that's probably the high-level-goal... 'hi everyone, these routes are
from a "peer", fyi!' to which the further away bgp receiver could then
say: "Oh, I see "peer" routes between two other "peer" sets, that's
not valid according to my policy setup." ??

this seems, to me, to get very confusing very quickly. Policed at the
immediate transit/peer/customer boundaries it seems feasible to make
this sort of decision, but further away, ouch. Especially if the
attribute isn't mandated to be used, and if there's no place to check
that 'oh, they set that flag properly for that relationship, good!'.

> The desired outcome is that sender/receiver _negotiate_ what is or is not to
> be sent,

sender/receiver BGP SPEAKERS negotiate capabilities ('I have
larger-packet capability' || 'only small packets for me')

> and the protocol merely enforces what has been agreed upon. The automatic

bgp simply passes along the attributes (well, the protocol does, the
'process' does many other things, potentially).

> of this high-level policy, is what stops route leaks from being initiated or
> propagated.

policy per BGP PEER, right?

> Just like the IP addresses and ASNs, the policies have to match for BGP

If you mean 'ip addresses' and 'ASNs' of the BGP PEERs in question...
you're describing 2 different checks at 2 different layers, I think.

  ip-address is really a tcp-stack question here:
    "I tried to connect to 1.2.3.4 from 1.2.3.3, he expected 10.1.1.1
to connect to his 10.1.1.2"
  ASN is checked inside the BGP (application) process:
    "I am AS1 I am connecting to AS2, he said AS3 oops!"

> or propagated route leaks, are prevented.

So, your check would exist at the application above:
  "I am AS1, i provide transit to AS2, he says he's AS2 but that he
provides transit to me, OOPS!" ??

>
> The proposal(s) provide all the mechanisms to express any mutually-agreeable
> policy,

Those (aspath/prefix-filter/communities) happen on a per-session basis
today in 'configured policy' (operator configured for example) but do
not enter into the application 'session' setup, nor the tcp-stack
parts of the setup. Moving the proposed check into the application
'session' setup is interesting.

> on what the receiver can do, is actually a gross mischaracterization. (No

Imagining the CPE config for this, is a default 'send all routes'
desired here? (desired in all deployments with the assumption that CPE
folk just config as they do today with no extra settings, but
ISP/Transit folks have to do the 'complicated' part?)

>> intent to restrict BGP update propagation is the same.

how so? if you and I agree that I am a 'customer' and i want you to
'send all routes' from me, and I will 'not send all routes' from
you... that's 'restricting update propogation' isn't it?

I suppose the next step in the 'negotiate capabilities' in my simple
example above is:
  If 'send-all-routes'
    add community TRANSIT-CUSTOMER

followed by, at the isp/provider/transit edge:
  If community == TRANSIT-CUSTOMER:
    accept-route-to-externals

So, the capability itself doesn't 'restrict update propogation',
"local policy" does, which seems good/fine.

> and/or _should_, be treated as a new feature.

which WG? (you mention plural above, and singular here)

> the WG onto one side of the line in the sand (feature/not-feature).

no, the AD's had said (paraphrased):
  bgp-mechanics belong in idr
  security bgp belongs in Sidr

Sandy is arguing here that the proposal is 'mechanics' nor 'securing
of the idr' I think.

> reluctance among a subset of folks, to say this is a new feature set.

I'm not sure I see that, but ... how about this approach. Would adding
the transit/not-transit bit (simplification) to BGP independent of any
security be of interest to BGP/IDR people? Would it help to 'secure'
BGP?

> being cryptographically protected, and/or other negotiated peering

Sure, sort of like deprecating as-set usage... which happened in IDR,
but was a consequence of discussion in SIDR that said: "Hey, we have
no idea how to secure this, it's non-deterministic data and the
aggregator doesn't have required material in order to 'secure' the
as-set which is in the as-path. Beyond that the usage of AS-SET in the
wild is by and large broken/not-helpful, so deprecating this will not
harm existing users of the system."

Which I think is basically what's happening with this discussion, no?
perhaps we/wgfolk did a "Exercise is left to the reader, but for now
go talk to IDR"?

-chris
hoping to read the drafts during the next week...

---

From: Brian Dickson <[email-masked]>
Date: Fri, 16 Mar 2012 19:33:38 -0400

On Fri, Mar 16, 2012 at 4:54 PM, Christopher Morrow <[email-masked]
> wrote:

> > On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra <
> [email-masked]>
> > wrote:
> >>
Yes, you are correct on all counts. Especially the confusing bit.

It would need to be mandated (modulo peer capabilities negotiation).
It would need to be tracked/recorded 1:1 with AS hops.
It would need to be protected against clobbering, a la crypto.

But, with those provisos, you can then validate that the path is sane,
policy-wise, is consistent with your local peer/peer policy, and is
un-fooled-around-with.

Those together, give leak proofing.

> policy per BGP PEER, right?
Yep - where "peer" here means not just neighbor AS, but peering instance
with that AS.

>    "I am AS1 I am connecting to AS2, he said AS3 oops!"
Yep. Add to that, "We both want to do (leak-proofing + bgpsec), I'm her
transit provider, she's my transit customer, good."
Or, "She think's I'm a Peer, I think she's my transit provider, oops!".
It is a 4 x 4 matrix with only 4 "good" combos.

> provides transit to me, OOPS!" ??
Yes, except that "we are doing mutual transit" is one of the valid combos.
But, yes, strict transit both ways is "ooops!".

> ISP/Transit folks have to do the 'complicated' part?)
Yes, except now it becomes very easy on both parts while assuring the
"right stuff" happens.
(I would still advocate the complicated stuff until at least a couple of
revs of code are debugged by my competitors.)

CPE == "hey, I'm a noob. So I turn on BGP, it comes up, I'm your customer?"
ISP == "Yep."
CPE: neighbor IPv4|IPv6 as NNN.NNN transit
ISP: neighbor IPv4|IPv6 as MMM.MMM customer

where "customer" does leak-proofing by allowing properly colored routes
from the customer (only), and sends everything.
And "transit" does leak-proofing by allowing all routes and sending only
properly colored routes.
Coloring done on the links is: (self) == colored "customer"; (customer) ==
mark as non-customer on send, preserve color on receipt; (transit) ==
preserve color on receipt, preserve color on send.

> you... that's 'restricting update propogation' isn't it?
It is what happens today, it just changes the mechanics and enforcement of
this.
It is policy, reduced to an absolute minimum, baked into the
process/protocol.
It does not change the policy per se, so long as one of the options is
suitable, for every peering session. (It is.)

> "local policy" does, which seems good/fine.
Yep - except that you need to use extended communities, include the
ASN:TRANSIT-CUSTOMER in the community, and prevent modification or
stripping of communities.

Then, the logic becomes:
match extcommunity ^(*:TRANSIT-CUSTOMER)* (*:PEER)? (*:TRANSIT-PROVIDER)*$
  accept
else
  reject

(and more restrictive on peers and customers)

> which WG? (you mention plural above, and singular here)
SIDR.

> Sandy is arguing here that the proposal is 'mechanics' nor 'securing
What I'm suggesting is, implicit in the charter is that any mechanics
necessary to achieve "security", can be read as delegated to SIDR.
I'm not suggesting going overboard, but I do suggest that you can't make an
omlette (adding security to BGP) without breaking eggs (touching, however
slightly, BGP mechanics and semantics.)

> security be of interest to BGP/IDR people? Would it help to 'secure'
Yes, it would. There are only two problems I see with that, or maybe more
if you combine them.
(1) In order to achieve leak-proofing, the whole of the AS_PATH needs a
corresponding COLOR_PATH.
(Or, modulo information-hiding so no info leakage occurs via COLOR_PATH,
see the third ID for how & why).
That's a lot of overhead, and if the exact same kind of overhead is already
needed for BGPSEC, it'd be easier to piggy-back one bit on the sig block
(or encode via algorithm choice!!)

(2) You still have to secure the result, for adding protection against
malicious path manipulation, even in the case where BGPSEC signatures are
on the paths. Otherwise, the color could be manipulated, defeating both
leak-proofing and, to a lesser degree, BGPSEC.

So, I see it as both a target-of-opportunity (how much lower do you need
the fruit to hang??), and a synergistic way of making the added work of
either, more attractive when the two are combined.

> perhaps we/wgfolk did a "Exercise is left to the reader, but for now
I'm cool with that...

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 16 Mar 2012 20:21:51 -0400

quick response to a single point... below.

On Fri, Mar 16, 2012 at 7:33 PM, Brian Dickson
<[email-masked]> wrote:
>
>
> On Fri, Mar 16, 2012 at 4:54 PM, Christopher Morrow
> <[email-masked]> wrote:

This part, I think, gets to the meat of the process part which really
is that if the bit being done is not directly 'security' (which to
some extent SIDR should have the say-so on) it ought to be done in
IDR. It seems that having the sidr side folks discuss this and agree
on direction is the right thing to do (which mostly happened
here/on-list so far).

Perhaps with at least some discussion in paris/sidr we'll circle to
the answer completely.

thanks!
-chris
(again, just a regular sidr person, which I forgot to say last time :( )

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Mar 2012 17:40:52 -0400

Brian,

...

>The desired outcome is that sender/receiver _negotiate_ what is or 
>is not to be sent,
>and the protocol merely enforces what has been agreed upon. The 
>automatic enforcement
>of this high-level policy, is what stops route leaks from being 
>initiated or propagated.
>The policy is still determined by the operators at both ends of a 
>peering session.
>Just like the IP addresses and ASNs, the policies have to match for 
>BGP session establishment.
>Unilateral misconfiguration (whether by accident or deliberate act), 
>which could have introduced

Pairwise enforcement may be useful, in general, but the bigger issue 
seems to be whether ASes farther along a path see the propagation as 
a violation of the pairwise agreement. So, it might be useful to view 
this in two parts:

	- adding a new feature to BGP that allows explicit 
negotiation of route marking to support detection of route leaks on a 
pairwise basis

	- adding a mechanism to enable ASes father along a path to detect when
a route has been propagated in a fashion contrary to the pairwise agreement

But, that work is appropriate relative to a later version of the 
charter (if I may skip ahead to what appears to be your major 
concern, cited below).

>the WG onto one side of the line in the sand (feature/not-feature).

The SIDR charter talks about "security enhancement for inter-domain 
routing protocols" which, IMHO, supports the not new features, just 
securing extant features, perspective.

>dichotomy, which is antithetical to the IETF philosophy.

At this stage it seems that at most a subset of folks believe these need
to be a set of new features, so whose responsible for the "fracture?"

Also, I'm curious; what part of the IETF philosophy do you cite as 
being violated when not everyone in a WG sees eye-to-eye on the scope 
of the WG?
As a WG co-chair I see this problem arise periodically.

This WG has a reasonably well-specified charter, which was updated 
after the first charter (which was very narrow) was satisfied. Your 
argument seems to be that you don't like the scope of the charter.

>to add the BGP options negotiation between peers doing BGPSEC.

That's one way to look at it. But, in my response to Eric I explained why
one might not view these as new features per se, but rather as just 
security mechanisms added to the protocol to secure the semantics of 
the existing feature set in hostile environments.

>being cryptographically protected, and/or other negotiated peering

The WG charter defines what we're doing now. It specifies the two 
vulnerabilities that we are to address, and it specifies some 
parameters re what tools we are to use in addressing these 
vulnerabilities.

So, for example, if "other data being cryptographically protected" is 
not directly related to the  two vulnerabilities cited in the 
charter, then it's out of scope for now.

Discussing whether the security mechanisms being discussed constitute 
new features for BGP is not relevant to the charter scope.

Steve

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 19 Mar 2012 23:42:15 +0100

Hi Brian,

> The desired outcome is that sender/receiver _negotiate_ what is or is not to be sent,
> and the protocol merely enforces what has been agreed upon. The automatic enforcement
> of this high-level policy, is what stops route leaks from being initiated or propagated.
> The policy is still determined by the operators at both ends of a peering session.
> Just like the IP addresses and ASNs, the policies have to match for BGP session establishment.
> Unilateral misconfiguration (whether by accident or deliberate act), which could have introduced

I have read your drafts reg route leaks however I would like to clarify 
one very basic question.

When any provider creates a BGP peering relation to his customer it is a 
common best practice among most if not all ISPs that there is a strict 
BGP policy applied over the session to make sure only legitimate 
customer blocks are advertised.

If such policy would be required to be share one could use prefix ORF.

With this in mind I am really not clear what practical vs theoretical 
problems you are attempting to solve ?

Best regards,
R.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 19 Mar 2012 19:18:21 -0400

Hi, Robert,

The problem being solved is, that the current methodology places the entire
onus on not allowing route leaks, on the immediate upstream provider - who
may be small and inexperienced.

What is being solved, in particular, is the ability to identify and block
route-leaks when one is _more_ than one AS-hop away from the leak, in a
guaranteed fashion.

Blocking, or even noticing, route leaks via one's peers, can be difficult
(or nearly impossible) today.

Best practices are good, but consider the level of adoption of BCP-38.
Clearly, best practices are not good enough, or we wouldn't have any
interest in the "route leak" problem.

Reducing the best practice to a "pick one of these four settings (and don't
use #4 unless you REALLY know what you are doing)", is a deliberate choice.
Make it easy.
And, for the most part, the party benefiting significantly, is the person
_using_ that setting. Route leaks _hurt_ the leaker/leakee probably as much
or more than anyone else.

If route filters are seat-belts, then this is an air-bag. Either is good,
both is best. Especially when used.

Brian

On Mon, Mar 19, 2012 at 6:42 PM, Robert Raszuk <[email-masked]> wrote:

> common best practice among most if not all ISPs that there is a strict BGP
> policy applied over the session to make sure only legitimate customer
> blocks are advertised.
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 19 Mar 2012 23:35:25 -0400

>The model I have long (>30 years) employed is that if the secruity checks succeed, 
>the protocol should operate as before (i.e., w/o the added secruity mechanisms), 
>because the environment is seen as benign. 
---snip---
>I'd like to think that the BGPSEC mechanisms are being developed in a way that tries to adhere to this paradigm.

Steve,

In light of the your above observations, how do you reflect on the pCount field in BGPSEC?
It is not part of the current BGP-4. 
In BGPSEC, pCount = 0 is used to denote a transparent IXP AS, and
the transparent IXP AS number is included in the BGPSEC update 
(whereas BGP-4 practice was not to include it in the update).
And the sum of pCounts for all ASs must now be used to determine the AS path length.

Also, in the latest bgpsec-protocol document, we have eliminated the AS_PATH attribute.
There are only the NLRI and Signature-Segment fields. 
The ASNs and the pCounts need to be pulled from the various Signature-Segments
in order to construct the AS path.

Would you or would you not characterize all this as a change in how the protocol operates
(when the security checks have succeeded)?

Sriram

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 20 Mar 2012 11:04:52 +0000

I see in the exchange a suggestion that rewording of the message is needed:

>> The addition of sigs to provide integrity and authentication for AS_path info does not 
>>add new semantics to BGP. The sigs are used to secure the existing semantics. I think 
>>that's what Sandy meant to convey in her message, but maybe the wording needs to be 
>>improved.

>Yup, I do think the wording needs some work, thnx for the ack.

I saw a suggestion from Eric to add a caveat about the acceptance of the interim working group consensus.

I saw no other provided text, or suggestions of which exact wording is unclear.

Please send suggested rewording.

--Sandy, speaking as wg co-chair
--sent 7:04amEDT, 11:04UTC

________________________________________
From: Eric Osterweil [[email-masked]]
Sent: Wednesday, March 14, 2012 5:35 PM
To: Stephen Kent
Cc: George, Wes; Murphy, Sandra; [email-masked]
Subject: Re: [sidr] route leaks message to IDR

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 20 Mar 2012 13:26:18 -0400

On Mar 15, 2012, at 6:07 PM, Stephen Kent wrote:

> Whenever we add secruity mechanisms to a protocol we create new ways to cause the protocol to fail to forward data, fail to establish a connection, etc. The model I have long (>30 years) employed is that if the secruity checks succeed, the protocol should operate as before (i.e., w/o the added secruity mechanisms), because the environment is seen as benign. If the checks fail, the protocol should behave differently, e.g., something should fail, because the environment is now perceived as hostile and the protocol (w/o benefit of the secruity mechanisms) was not engineered to work properly in a hostile environment.
> 
> Consider for example the fact that many protocols incorporate an integrity check. If the check fails, that causes a packet to be dropped. Typically the integrity check mechanism is not secure against attacks; is just a mechanism designed to detect benign errors. We frequently introduce crypto-based integrity mechanisms when we want to counter attacks. Those mechanisms will cause the protocol to behave differently in attack scenarios, e.g., an  attack that might have yielded a valid checksum will yield an invalid HMAC, and that will cause a packet to be dropped. This is generally viewed not as a change to the protocol semantics, but rather an appropriate and natural effect of operating the protocol in a secure manner.
> 

This is being pedantic in a case where I do not think it is helpful.  You're saying, ``yeah, we changed semantics OUTSIDE of the BGP protocol, so that once _our_ semantics have decided it is ok to proceed, we can let BGP do its thing...'' but the you basically go on to say ``oh yeah, and we put our semantics _in_ BGP (thus changing it), and the results of our process can greatly impact the global routability of BGP... but those aren't changing BGP semantics...''  This falls right into the basic definition of semantics...

Also, the caveat that this is >30 year old thinking does not seem convincing of its correctness (maybe that's just me).

> I read the text before the paragraph was sliced and diced, and I felt that "things" was ambiguous. Now that the ambiguity is removed, I just disagree with your reading of the text :-).

Well, I'm glad we got that cleared up... ;)

> separate, but very interdependent. If the definition is squishy, countermeasures are likely to be messy, at best.

Strongly disagree:
If a system is repeatedly subverted along a specific attack vector, the fact that you can see evidence of subversion, but you can't model it with a closed form equation or a formal proof does _not_ mean you should withhold the development of protections!  That's like saying: I haven't got a formal proof for what a local escalation of privileges is, on my Linux box... I hope Linus comes up w/ a formal definition soon so that I stop getting pwnd!

Ignoring route leaks as security threats is ludicrous.  If someone _does_ formally define them, then great!  Until then, the system is vulnerable and being exploited, and the bgpsec protections will _not_ protect it...  If you want evidence that a solution addresses observed problems, then take them on specifically!  That is the heart of the foo-sidr-simple-leak-attack-bgpsec-no-help draft: an example of something that we need to fix.

tbqh, the thinking that we need to formally define all threats and completely/comprehensively quantify them before we acknowledge and address them is an extremely antiquated way to address the rapidly evolving threatscape, imho...

Eric

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Mar 2012 14:16:13 -0400

At 11:35 PM -0400 3/19/12, Sriram, Kotikalapudi wrote:
>>I'd like to think that the BGPSEC mechanisms are being developed in 
>>a way that tries to adhere to this paradigm.
>
>Steve,
>

Sriram,

That's a fair, but slightly complicated question.

The current BGPSEC protocol design replaces the AS_PATH info with its 
own data structure. I don't see this syntactic difference as 
necessarily changing the semantics or features of the protocol. But, 
one needs to examine the data elements in the BGPSEC structure to see 
whether they constitute such changes.

pCount is a data element used to do two things. It provides a 
shorthand way for an AS to indicate that its ASN should be counted 
multiple times when computing path length. This replicates the 
capability that BGP already offers, through repeated insertion of 
one's own ASN, so it does not change the features/semantics of BGP.

The ability to set pCount to "0" for one's own ASN does diverge from 
the repeated ASN capability that BGP already embodied. The intended 
use of this convention is to accommodate transparent route servers at 
IXPs. The goal is to enable BGPSEC to operate in a fashion that does 
not penalize ISPs operating at IXPs with such route servers. The 
mechanism preserves a feature of how BGP is used today. I argue that 
this is not a new feature, just a way to preserve an existing 
operational capability that has been deemed important and that is not 
viewed as a security problem per se. However, allowing a pCount value 
of "0" creates a potential problem relative to the BGP path security 
features that BGPSEC strives to secure, if it is used in other 
contexts. That's an unfortunate side-effect of this mechanism, and 
the WG will need to decide whether the possible security problems are 
acceptable as a cost of accommodating transparent route servers. Part 
of the analysis will need to take into account suggested 
countermeasures for dealing with the potential vulnerabilities 
associated with pCount=0.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Mar 2012 16:50:59 -0400

Eric,
>...
>
>This is being pedantic in a case where I do not think it is helpful.

Well, I guess it's nice to know that you believe that being pedantic 
can sometimes be helpful :-).

>   You're saying, ``yeah, we changed semantics OUTSIDE of the BGP 
>protocol, so that once _our_ semantics have decided it is ok to 
>proceed, we can let BGP do its thing...'' but the you basically go 
>on to say ``oh yeah, and we put our semantics _in_ BGP (thus 
>changing it), and the results of our process can greatly impact the 
>global routability of BGP... but those aren't changing BGP 
>semantics...''  This falls right into the basic definition of 
>semantics...

So, just for the record, I didn't say what you said above. (And I 
think you left off "... the end of civilization as we know it.") I 
may have a big mouth, but it's very inappropriate to stuff other 
people's words into it.

Let me try another, more concise phrasing. When one adds secruity to 
a protocol, the goal is to enable it to operate in a hostile 
environment with the same  semantics that it offered in a non-hostile 
environment. Of course a secure version of a protocol will exhibit 
some differences in its operation from an insecure version, 
especially when one compares the two version in attacks scenarios. If 
that were not the case, we would not bother adding security to a 
protocol. The relevant question is whether the fundamental nature of 
the protocol is altered by the addition of security.

>Also, the caveat that this is >30 year old thinking does not seem 
>convincing of its correctness (maybe that's just me).

Well I am older than 30, so at least one interpretation of you 
critical comment above is accurate :-).

And, yes, maybe it is just you.

Steve

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 20 Mar 2012 22:54:05 +0100

Hi Stephen,

> pCount is a data element used to do two things. It provides a shorthand
> way for an AS to indicate that its ASN should be counted multiple times
> when computing path length. This replicates the capability that BGP
> already offers, through repeated insertion of one's own ASN, so it does
> not change the features/semantics of BGP.

I have one clarifying question on the topic of pCount > 0.

You are correct that the example you stated will address the typical 
as-prepend case.

However I am not clear how it will deal with "replace as-path" 
functionality of BGP policies where operator can replace today any 
arbitrary sequence of ASes in the AS_PATH with his own AS number. There 
are some legitimate uses for this policy enhancement.

Ref: http://goo.gl/xVToJ

Example for policy applied by AS 100:

Incoming AS_PATH: 10, 20, 30, 35, 60

Policy: replace as-path '30 35'

Outgoing AS_PATH: 100, 10, 20, 100, 100, 60

Question: What would be the basic analogy of BGPSEC_Path_Signatures 
attribute? Would we just see one new signature segment for AS 100 with 
the pCount of 3 ? Can signature segments be just removed and replaced by 
prepend analogy ?

Many thx,
R.

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 20 Mar 2012 18:03:22 -0400

>the pCount of 3 ? Can signature segments be just removed and replaced by

The forward/backward chaining of PATH_SIGs would prevent AS100 from doing
this in a way that would validate ... Unless 100 had the private keys for
20 and 60 to patch up the chain.

Dougm

---

From: Russ White <[email-masked]>
Date: Tue, 20 Mar 2012 21:59:38 -0400

> not presently BGP behavior.  Brand new routing behavior.  That's the

So, just to ask... Suppose you have this:

A---B---C---D
    |       |
    +---E---+

A sends an advertisement to B, B sends it to C, but B does not send it
to E. Your argument is that BGPSEC prevents D from using the path
through E by including in the update a series of signatures.

Correct? So:

1. The existence of the link from B to E is a fact within the topology
shown.
2. Choosing not to use that link is an expression of policy, and a
policy that cannot be expressed within BGP itself (on the wire protocol
wise) today. Today, in other words, there is no way for B to communicate
to D what it's policy is in regards to receiving transit traffic through
E from D.
3. So the ability to remove the B to E link from the possible paths
available to reach A, enforcable by D, is actually a new feature in BGP.

The signatures suggested will actually provide D with information about
B's policy towards E --something which is not currently carried in BGP.
Hence BGPSEC is a new feature in BGP, and should be treated as such.

Russ

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 20 Mar 2012 22:48:32 -0400

On Mar 20, 2012, at 4:50 PM, Stephen Kent wrote:

> Well, I guess it's nice to know that you believe that being pedantic can sometimes be helpful :-).

For one: pedantic compilers are often helpful when it comes to static analysis.  By extension, _sometimes_ one can make the same argument (about static analysis) to justify being pedantic for technical discussions... I'm kinda surprised that you didn't know that... ;)

> 
>>   You're saying, ``yeah, we changed semantics OUTSIDE of the BGP protocol, so that once _our_ semantics have decided it is ok to proceed, we can let BGP do its thing...'' but the you basically go on to say ``oh yeah, and we put our semantics _in_ BGP (thus changing it), and the results of our process can greatly impact the global routability of BGP... but those aren't changing BGP semantics...''  This falls right into the basic definition of semantics...
> 
> So, just for the record, I didn't say what you said above. (And I think you left off "... the end of civilization as we know it.") I may have a big mouth, but it's very inappropriate to stuff other people's words into it.

Indeed, I was attempting to paraphrase. To clarify, this was how I interpreted your words, but our audit trail should clearly indicate that you did _not_ say these things and that I was merely paraphrasing the message I interpreted from you.  Please accept my apologies for any misunderstanding about this.

> 
> Let me try another, more concise phrasing. When one adds secruity to a protocol, the goal is to enable it to operate in a hostile environment with the same  semantics that it offered in a non-hostile environment. Of course a secure version of a protocol will exhibit some differences in its operation from an insecure version, especially when one compares the two version in attacks scenarios.

Exactly!  This is exactly what a semantic difference is! :)

> If that were not the case, we would not bother adding security to a protocol.

Very debatable.  I wouldn't necessarily impugn the addition of security semantics to a protocol (sometimes additional expressiveness is needed).

> The relevant question is whether the fundamental nature of the protocol is altered by the addition of security.

That may be a question you care about... It might even be one that the rest of us care about, but that is different than claiming you have not added semantics (which is where this started).  This comment is changing the subject.

> Well I am older than 30, so at least one interpretation of you critical comment above is accurate :-).

Speaking of malformed sentences:
	s/you/your/

;)

> And, yes, maybe it is just you.

Or maybe a line of thought (``thinking'' as you put it) that has gone unchanged in over 30 years is overdue for having its assumptions challenged.  Security (in particular) is a field in which the landscape changes, and stale vision can lead to myopia...  Many things in the Internet security theater have obviously changed in 30 years, so the age of lessons does not necessarily correlate with their relevance. :)

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 20 Mar 2012 23:22:32 -0400

On Tue, Mar 20, 2012 at 9:59 PM, Russ White <[email-masked]> wrote:
>      +-E-+

(fixed, I think, the ascii-art, which didn't survive at least for me)

paths: a-b-c-d
          a-b-e-c-d
      both exist in the  pict above.

> through E by including in the update a series of signatures.

I think the arguement is that D never sees the path that includes E...
because B decided not to let that happen (by not sending E the path
which it could also decide not to send to C and thus on to D)

> 1. The existence of the link from B to E is a fact within the topology

yes

> to D what it's policy is in regards to receiving transit traffic through

yes

> available to reach A, enforcable by D, is actually a new feature in BGP.

i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'.

> Hence BGPSEC is a new feature in BGP, and should be treated as such.

no, I don't think so. The signature data from B -> c -> d doesn't say
anything about E, you could infer (if you knew the topology) that B
has some policy in place to prevent routes traversing E to be made
available... Well, really you'd know that between B and E there
existed (on some side of the fence, though perhaps at E->C even!) some
policy which decided to not send routes of this ilk along.

Even more complicated, C could simply not choose to send the E path to
D... another policy enforcement point:(

or even more.... C could choose to not accept the route from E
because, there was some business logic in place (expressed in policy)
that said E was a 'customer' of E but was not elligible to transit
routes from B and A across this link between C and E!

-chris

(I think I drove the train off the rails...)

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 07:18:18 -0400

> i don't think so, it's a 'feature' of bgp in general, isn't it? not 'new'.

Not advertising something already exists --telling a remote AS that the
advertisement shouldn't exist because of policy is something you can't
do in BGP today, and hence is a new feature.

Of course, I don't quite believe that these signatures won't be used to
enforce NO_EXPORT along the way, either --it's much to simple to
implement, was included in the original proposal, is still being
discussed in private, etc.

IMHO, we always fall back to the same point --wanting to enforce policy
without telling anyone what that policy is. BGP is designed to tell
people how to get from point A to point B, not whether or not this
particular path is only available to people who qualify under carpool
rules.

Break the problem into two pieces:

1. What paths exist.
2. What policies exist.

And I think it becomes tractable, with the real ability to trade off
between hiding policy, etc. As it is, we're trying to trade off
fundamental security against hiding policy --which is always going to
leave us spinning around in circles. There may be ways to tell people
what is in violation of your policy without telling them what that
policy is, but so far we've not found that solution, nor have we even
spent time thinking through and defining that sort of problem.

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 07:37:46 -0400

> do in BGP today, and hence is a new feature.

i don't think the case you outline is one of actually telling the
remote-as that the path doesn't exist because of policy. the /fact of
policy/ can be inferred, and I outlined 3 (or more) places you could
infer at D that there was some policy decision happening. I don't
think it's at all clear that you can determine where that policy
removed the path though.

> discussed in private, etc.

I suppose: "So what if this is used for no-export" or "so what if this
is used to ignore no-export" ? The signatures are there so you can
say: "The NLRI I see travelled along the ASPATH shown in the
announcement."

The policy in place isn't relevant to that... or I don't see that it's
relevant.

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 07:46:26 -0400

> think it's at all clear that you can determine where that policy

If the advertisement is passed on by the intermediate AS (in this case,
E), then you're telling the remote AS that path shouldn't exist --this
is carrying policy within the protocol.

> The policy in place isn't relevant to that... or I don't see that it's

I do --because we're sneaking policy into BGP under the cover of path
security. Again, it would be much simpler to break the problem into two
pieces, publicly work out which policies need to be enforced, work out
what hiding needs to be done, and then work out a solution to those
problems.

Hiding one complex problem within another is never a good idea over the
long term.

For instance, because of the WG's insistence on solving a policy problem
in a way that can be hidden, while insisting on not calling that problem
a policy problem, we've ended up with a solution that is not deployable
and doesn't solve a basic AS Path problem. This is, in my experience,
exactly what happens when you don't start with a well thought out set of
definitions and categories.

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 07:51:37 -0400

> is carrying policy within the protocol.

your example:

A---B---C---D
   |       |
   +---E---+

"A sends an advertisement to B, B sends it to C, but B does not send it
to E. Your argument is that BGPSEC prevents D from using the path
through E by including in the update a series of signatures."

You state that the path isn't known to E, so he can't possibly send
along something he doesn't know.

Did I mis-read your example? "A sends to B, B sends to C but NOT E ...
D sees only 1 path: C->B->A"

I don't see this putting policy in BGP, I don't think anyone has
stated that you should send along alternate path info with: "Hey, but
don't use this" bits set.

Did someone say that?

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 08:06:10 -0400

> Let me try another, more concise phrasing. When one adds secruity to a protocol, the goal is to enable it to operate in a hostile environment with the same  semantics that it offered in a non-hosti…

So, this theory of semantics is interesting --and worth thinking about a
little.

What is the "semantic of a protocol?" In saying this, we could mean
several things.

1. We are trying to secure the semantics of the protocol in terms of
what the protocol actually tells us.

2. We are trying to secure the semantics of the protocol in terms of the
way in which it tells us something.

So compare this to a telephone conversation. In the first sense, I'm
told over the telephone that it is raining today. To check, I put my
hand out the window to see if the person on the other end of the phone
is right. I've used an out of band mechanism to check the validity of
the information itself. Or I could encrypt the data path. I've now used
an in-band system to verify the information was received correctly (as
transmitted).

Which semantic is it we're supposed to be securing here? The validity of
the database, or the correct transmission of the information end-to-end?
If it's the correct transmission of the information, then why have we
left some information out? Because it's "too hard?" How hard it is isn't
a question on the table --if you're going to validate the transmission
of the data, then you need to validate the transmission of all the data.
"Too hard" isn't a valid excuse. But other times we seem to be talking
about the validity of the database -the so-called "man in the middle
attack."

What I see happen is the range of semantics we're talking about slips
back and forth quite a bit. Most attacks are, I think, simply movements
in the semantic range --so you've protected the door, I'll now attack
the human with the key.

Either:

1. We're trying to secure the bits on the wire end-to-end (even though
they don't exist end-to-end). Okay, so leave out the "man in the middle
attack" as a requirement, because this has nothing to do with securing
the bits on the wire.

2. We're trying to secure the validity of the database. Okay, so leave
out the problem of ensuring the data itself isn't changed on the wire,
and find a way to validate the database --policy and all.

We're playing to the middle here, and the middle is rather muddled.

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 08:10:49 -0400

> don't use this" bits set.

What is the signature's existence in the advertisement from C, but it's
non-existence in the advertisement from E, supposed to mean to D? Not to
use the path through E.

By adding the signature to the path through C, you've told D not to use
other paths, even if they really exist. Without the signature, D would
have to pick the phone up and ask. With the signature, they don't need
the phone call. If you don't need the phone call to know what B's policy
is, you've added the policy to the protocol.

The point is you've gone beyond the existence of the path here to the
rightful use of the path --and that is policy.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Mar 2012 13:59:32 +0100

> 1. The existence of the link from B to E is a fact within the topology

nope, it is not.  A is a peer of B and E is a peer of B, so there is no
path between B and E for A's prefixes.  sorry charlie.

randy

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 09:10:32 -0400

> path between B and E for A's prefixes.  sorry charlie.

I can't even begin to make sense out of this --can you explain? If A/B,
B/E, and E/D are valid peering pairs, then the path exist. If B chooses
not to advertise some route from A to E, that's a local policy decision.

If you modify the protocol so D can tell B didn't intend to send a
specific set of destinations to E, then you've injected policy into the
protocol. There's no way to escape the conclusion that BGPSEC injects
policy into BGP itself.

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 09:12:28 -0400

> non-existence in the advertisement from E, supposed to mean to D? Not to

but in your example, B never sends the route to E. There is no route,
there is no signature... unless you mistyped and meant that it didn't
sign toward E but still sent a route toward E?

> other paths, even if they really exist. Without the signature, D would

hrm, well... I think you really (backing up and assuming you MEANT
'did not SIGN to E, but sent to E' originally) tell E "Hi, you don't
do security-foo, so you get a plain route", the follow on receipt at C
from E is also not signed (once unsigned, can not resign) C can say:
"Hrm, I prefer Signed over unsigned, except for Customer over Peer" or
some version of that... In any case C has to select the E path as
'better' in some way for it to send the route along to D. At D, again:
"Signed over Unsigned" or whatever their policy is rules the day.

> is, you've added the policy to the protocol.

again, your example was B never sends anything to E, " B does not send
it to E" (your words, where 'it' refered to the 'advertisement').
So... you can infer all the policy you want at several points in the
picture (as I outlined in my initial response) but... the other bits
about signature are not applicable.

> rightful use of the path --and that is policy.

don't think so.

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 09:43:57 -0400

> don't think so.

Yes, you have.

Because you've insisted on making the solution work per prefix, you've
moved the problem out of the realm of path validation and into the realm
of per prefix policy. Paths don't exist per prefix. Paths either exist
or don't. Only policies can tell you whether or not a particular path is
available for a particular prefix.

Since you're signing per prefix/per path, you're actually adding a
policy semantic into the protocol that simply didn't exist before BGPSEC.

If you backed up to validating the path at the path level, then this
problem would go away --but then you're justification for signatures in
the packets based on the so call "man in the middle attack," would go
away, as well, and the field would be open for a number of different
solutions. At that point, you'd actually have to break policy apart as a
separate problem, and address it by analyzing the policy problems to be
addressed.

The problem is you started with a solution, then designed requirements
to fit that solution. That the requirements slip this way and that to
rule out alternate solutions while keeping your solution as the only
viable alternative is a clear symptom of what actually happened.

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 09:53:13 -0400

> available for a particular prefix.

clearly there's something I'm missing... if we remove the ideas of
SIDR form the table, how does your picture change? how does the
outcome change? it SEEMS (to me) that the situation is exactly the
same... there's no idea of policy in protocol, there is only bgp, and
the local decision by B to NOT send a route to E.

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 10:08:36 -0400

> the local decision by B to NOT send a route to E.

But D has no way of knowing this in band without SIDR. With SIDR, it's a
matter of looking at the signatures --by the design specs of SIDR
itself. When you provide information about who should be advertising to
whom across multiple hops, rather than who is connected to whom, then
you've moved from existence proofs to policy implementation.

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 10:15:03 -0400

> matter of looking at the signatures --by the design specs of SIDR

no, you never sent anything of this route to E so E never had anything
to pass along to C and then to D ... knowledge of this path is not
there, in both the SIDR and non-SIDR cases. All D knows in both SIDR
and non-SIDR cases is: "Look at that, a path through C to B to A,
joy!"

In the SIDR case, assuming full secure path along from A -> B -> C -> D, D sees:
"Hey lookie! a 'signed' path from C to B to A!"

The conversation about E never happens, because .... D has no
information about E.

> whom across multiple hops, rather than who is connected to whom, then

where is this information? about 'advertising' ? there's no concept in
SIDR of 'you advertise to ..' or 'you are supposed to advertise to X'.

> you've moved from existence proofs to policy implementation.

no, again this isn't the case. Now I think i'm not the confused one...

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 10:52:25 -0400

> and non-SIDR cases is: "Look at that, a path through C to B to A,

If E makes up a route and sends it to D, how does D know which route to
choose?

Without SIDR --pick up the phone, look at contracts, etc.
With SIDR --look at the signature.

Clearly you've included information that didn't exist before, and that
information is in the form of a policy.

> SIDR of 'you advertise to ..' or 'you are supposed to advertise to X'.

Because you've attempted to define it out of existence --but that
doesn't make it any less real in actual implementations or deployments.

You're playing games with hermeneutics here --"That signature isn't
about policy, even I've insisted that it be per prefix, and I mean for
you to use it to tell you whether or not someone intended to send a
route to someone else (and not whether or not such a path exists). But
because I'm only trying to prove the positive, and not the negative, I'm
not talking about policy."

Not being a postmodernist, I still think words actually mean something
--they actually correlate to some reality--, and they should mean the
same thing from the beginning of the conversation to the end of it.

> Now I think i'm not the confused one...

We're starting from different presuppositions. You're assuming per
prefix policy isn't really policy (because you're not signing something
saying not to advertise x), and doesn't need to be dealt with as policy.

I'm stating that failure to advertise is a policy decision, and hence
when you go about _proving_ someone didn't intend to advertise
something, then you're still making a statement of policy. If you're
going to deal with policy at all, then deal with policy in total, as
policy, in the open, rather than sneaking it in through the back door.

Russ

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 21 Mar 2012 10:59:46 -0400

I think we are chasing our tails around the use of path as an abstraction
of the set of peering relationships and PATH as a specific sequence of
announcements of a given prefix (I.e., the AS_PATH attribute).

Not that the debate isn't amusing, but sorting out those terms out might
allow it to move forward.

dougm
-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 11:13:55 -0400

> allow it to move forward.

Precisely! Which "protocol semantic" are we trying to get right?

Are we trying to secure the bits of the protocol on the wire? If so,
then why not all the bits? Is there an argument other than, "the rest of
the bits are too hard to secure?" If so, then why do we much care about
"man in the middle attacks" at the database level?

Or are we trying to secure the database --the path itself as an abstract
object? If so, how do we deal with policy that should hang off the path?

The second way allows us to break the problem into multiple pieces,
examine each, and make independent tradeoffs. The first --so far, I
don't see where it's led us anyplace useful --partly because we keep
munging different pieces of the two ways of looking at the problem
together into one "thing" --"we're just securing the semantics of the
protocol on the wire, but we really want to secure this and that piece
of database integrity by doing so."

Russ

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Mar 2012 09:32:03 -0600

Chris,

> The conversation about E never happens, because .... D has no

But, this is the fundamental problem.  Or, more succinctly, the problem that's not being recognizing here is one of "scoping" (and, not scoping) of routing announcements.

To take a step back, with respect to Route Origin Authentication, the principle there is that only the Origin ASN(s) bound to a specific IP prefix is allowed to _inject_ that IP prefix into BGP.  In effect, a ROA is a (out-of-band) policy that defines the scope of a particular IP prefix as having a root of one, or more, specific Origin ASN's.  The Origin ASN(s) for that IP prefix are effectively the root of a tree that _COULD_ extend outward through several dozen downstream ASN's.  Today, it's the _policy_ implemented within the individual downstream ASN's that further _refine_ the scope of that announcement, by expanding or trimming the branches of the tree of downstream ASN's.  Furthermore, as pointed out in the route-leaks draft, the default (out-of-the-box) behavior of vanilla BGP is for it to propagate all learned routing routing information to all parties, i.e.: BGP's default scope = global.  Thus, if we're talking about changing BGP to /automatically/ restrict the 'announcement scope' of a particular prefix, (or set of paths), then we seem to be talking about a fundamental change to BGP.

-shane

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 21 Mar 2012 11:37:06 -0400

By "we" I assume you are asking the bigger question about what the broad
requirements / objectives should be.

The current BGPSEC design, chooses to only focus on the protocol on the
wire, and starts with the attributes that had both an identified threat
and a existence proof of a reasonable mechanism to address that threat.

Discussing if there are other attributes that meet that rubric is an
incremental discussion relative to the current proposal.

Stepping back to the bigger question if we should be securing something
other than what is on the wire (or can be put on the wire with new IDR
tweaks) is a much broader discussion of our basic goals.

dougm

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 11:44:19 -0400

> If E makes up a route and sends it to D, how does D know which route to

you are changing your scenario now, fine.

In the non-SIDR case... 'as path length wins' (presuming same prefix
size). (also presuming that C does not filter E's routes...)

In the SIDR case, if E forges the origin AND E -> C (or E->B) is a
'secured' path then origin validation may fail. prefix-filtering could
still kick-in, path validation may also fail.

Of course, if any of the parts B/C/D accept 'invalid' or 'unknown' (or
not-signed) then the SIDR version also gets messy to follow/predict.

In either case, the extra information passed along for SIDR-version is
just metric-like data to be used at the next hop, or ignored.

> With SIDR --look at the signature.

sure.

> information is in the form of a policy.

nope, it's bits that you can choose to use or not.

> doesn't make it any less real in actual implementations or deployments.

no, there is no concept (in the sidr world) of publishing 'who you
should advertise to' or 'what you should advertise to whom'.

> route to someone else (and not whether or not such a path exists). But

I really don't think I've said anything about 'intended'. I certainly
did not say anything about 'intended to send to someone else'.

yes

> policy, in the open, rather than sneaking it in through the back door.

I'm really not trying to sneak anything.  we seem to be at an impasse.

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 11:47:08 -0400

> To take a step back, with respect to Route Origin Authentication, the principle there is that only the Origin ASN(s) bound to a specific IP prefix is allowed to _inject_ that IP prefix into BGP.  I…

but we're not... you can still decide to ignore the origin information
and signature information. you COULD decide to check origins and
simply remark internally (with a community say) about the status of
that origin authentication. You could decide, internally, to simply
mark with a community the routes which fail (in several forms) path
validation.

-chris

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Mar 2012 11:50:55 -0400

> and a existence proof of a reasonable mechanism to address that threat.
If that statement were true, I think there would be much more support and
progress
for the bgpsec-protocol component of the SIDR WG.

However, the current interpretation (by whom, is not clear) seems to be,
that only certain attributes (AS-path and nothing else?) are included in
what is protected.

Any attempt to discuss inclusion of other attributes, and reasonable
mechanisms
for including those in the protection regime, has been shouted down by a
small group
which includes a self-selected group of implementers.

I agree that the design _should_ start with examining threat models against
attributes
which are used in path selection, and on identifying reasonable
mechanism(s) to address
those threats.

Doing so would require, at a minimum, stopping forward progress on
-protocol docs,
until the -reqs- and -threat- are adequately addressed.

BTW - I am in favor of this, and suggest that this proposal be submitted to
the WG
to establish general consensus (or not).

Chairs?

Respectfully,
Brian Dickson

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Mar 2012 16:53:20 +0100

> I can't even begin to make sense out of this --can you explain?

nope.  i don't play russ white ping pong

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 12:10:20 -0400

> which includes a self-selected group of implementers.

you seem to want to read:
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01

> which are used in path selection, and on identifying reasonable mechanism(s)
> to address
> those threats.
>
> Doing so would require, at a minimum, stopping forward progress on -protocol
> docs,

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Mar 2012 12:36:11 -0400

> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01
Yes, I have read that, and the relevant bits are pretty much as follows:

"It was decided..." (in a number of places).

The section on "what is signed" lists a few attributes, and focuses on the
"how"
rather than the "what" or "why".

The only place where what is not signed is discussed is in 2.4.1, where it
basically
says, "are local, or lack clear security needs."

This is a conclusion, not supported by any analysis, and refuted
(repeatedly) by a number
of folks in the WG.

This is the crux of the issue. The logic applied by a few folks is
circular, in that the design
choices and protocol design have been made without input from the WG, and
in fact
are ignoring significant threat model issues.

The threat model discussion is excluding real threat issues, on the basis
of saying
that the WG charter is limited to protecting only the AS path.

However, the charter does not say "AS path", and the (real) threat models
definitely
extend beyond AS-path forgery.

And, I believe, there may have been some assertions that there is no way to
protect
attributes which might change in flight (legitimately), and using that as a
reason not to
include other attributes in the -design- doc or -threat- doc.

So, I will make a counter-assertion.

I will claim it is possible to protect attributes which change, and that
discussion on which
attributes should be signed, should be open for discussion.

Brian

> mechanism(s)
> -protocol

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 12:45:01 -0400

On Wed, Mar 21, 2012 at 12:36 PM, Brian Dickson
<[email-masked]> wrote:
>
>
> On Wed, Mar 21, 2012 at 12:10 PM, Christopher Morrow

yup, part of that could be more explanatory.

> says, "are local, or lack clear security needs."

I think sriram means really that each of these items are actually
modified/modifiable at each router hop (each bgp peer), and if they
get signed how does that make any sense at all if on one hop you sign:
community 701:666 but at the next 701:666 7018:12 and at the next ''.
??

localpref, similarly is meaningless outside the local ASN, metric as
well can get fudged with at each hop (peer) so signing that is ...
problematic/impossible.

> This is a conclusion, not supported by any analysis, and refuted

sure, got text ?

> The threat model discussion is excluding real threat issues, on the basis of
> saying

along with: "Show the math" (or equivalent in the case of the leaks problem)

> attributes should be signed, should be open for discussion.

curious how that'd be done, got examples?

-chris

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Mar 2012 13:07:35 -0400

> curious how that'd be done, got examples?

Gladly.

While it may not be terribly efficient (but then, information theory says
"duh"), here goes:

It basically uses the same kind of methods that "rsync" uses for arbitrary
binary data, or rcs/cvs/sccs use for source code.

It requires a new attribute type to stuff the data. It would be a block of
things, each which corresponds to one AS-hop.

Each "hop" would have two counts, for the two elements for that hop.

The two elements would be as follows.
The first is things that were deleted or changed. This can be a block of
attribute types and values, all the ones that were deleted or changed, in
there entirety.
The second is things that were added. Also in their entirety. (These would
be attributes that did not exist when the update was received.)

Validation would work backwards, by validating the last hop based on
current values and signature.
Then, working back one hop at a time, remove the things added, add or
change the things deleted or changed. Validate with this new set of values.
Lather, rinse, repeat.

For updates where little or nothing changed, the overhead (in processing
and space) is negligible.
For updates where a lot changes once, the overhead is slightly more.
Only where every hop involves lots of change, does stuff start to become
bloated. However, given the average number of AS-hops, and the proportion
of those where values change, I think this is manageable.

Additionally, lots of prefix/path combos will share attributes, and likely
also share attribute "stacks", so in-router storage isn't terribly bloated.

Ugly, but manageable, IMHO.

Brian

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2012 13:40:16 -0400

At 11:50 AM -0400 3/21/12, Brian Dickson wrote:
>On Wed, Mar 21, 2012 at 11:37 AM, Montgomery, Douglas 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>If that statement were true, I think there would be much more 
>support and progress
>that only certain attributes (AS-path and nothing else?) are 
>included in what is protected.

The WG charter states which BGP vulnerabilities are to be addressed. 
The choice of which attributes need to be protected is, I believe, 
consistent with the charter.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Mar 2012 13:56:10 -0400

On Wed, Mar 21, 2012 at 1:40 PM, Stephen Kent <[email-masked]> wrote:

> **
> The WG charter states which BGP vulnerabilities are to be addressed. The
> choice of which attributes need to be protected is, I believe, consistent
> with the charter.
>
>
>
I disagree (vehemently, I might add.)

Here's the charter:

*The purpose of the SIDR working group is to reduce vulnerabilities in *
* the inter-domain routing system.* The two vulnerabilities that will be
addressed are:

* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path through
which the NLRI traveled

*The SIDR working group will take practical deployability into
consideration. *

Building upon the already completed and implemented framework:

* Resource Public Key Infrastructure (RPKI)
* Distribution of RPKI data to routing devices and its use in
operational networks
* Document the use of certification objects within the secure
routing architecture

*This working group will specify security enhancements for inter-domain *
* routing protocols. *

I have added emphasis (bold) to illustrate that the charter does not
_exhaustively_ state which vulnerabilities are to be addressed.

It does mandate two specific required vulnerabilities, but does not exclude
anything.

In fact, and I believe I am far from alone in this regard, the bold items
in the charter give license to address other vulnerabilities.

I would also opine, that _not_ addressing other, identifiable and
identified vulnerabilities, would be seen by the rest of the IETF and by
the "users" of BGP (operators of the >>30k ASNs) as a massive #FAIL.

This can be reduced to english semantics:
"The two vulnerabilities", is semantically distinct from "The _only_ two
vulnerabilities".

You (SK) seem to be arguing that the latter is the case. The charter says
the former.

If someone (e.g. the AD) is exercising some authority over the WG to
restrict us to the latter, I believe the appropriate way to resolve this is
to re-charter to remove all ambiguity in the matter, one way or the other.

That is, unless it is merely a matter of interpreting the words of the
charter incorrectly, in which case, let's just get on with updating the
threat model and finding solutions.

Brian

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 14:08:42 -0400

>>> http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01

Actually, with respect, I think the first stop really ought to be coming to consensus on a requirements document.  My experience has been that doing design work without solid requirements can lead to a great deal of rework.

Eric

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2012 14:06:58 -0400

At 10:48 PM -0400 3/20/12, Eric Osterweil wrote:
>For one: pedantic compilers are often helpful when it comes to 
>static analysis.  By extension, _sometimes_ one can make the same 
>argument (about static analysis) to justify being pedantic for 
>technical discussions... I'm kinda surprised that you didn't know 
>that... ;)

I am not familiar with the term in the compiler context, only in the 
context of people, i.e., are being referred to as teachers, i.e., to 
be a pedagogue.
>...
>
>Indeed, I was attempting to paraphrase. To clarify, this was how I 
>interpreted your words, but our audit trail should clearly indicate 
>that you did _not_ say these things and that I was merely 
>paraphrasing the message I interpreted from you.  Please accept my 
>apologies for any misunderstanding about this.

OK.

>  > Let me try another, more concise phrasing. When one adds secruity 
>to a protocol, the goal is to enable it to operate in a hostile 
>environment with the same  semantics that it offered in a 
>non-hostile environment. Of course a secure version of a protocol 
>will exhibit some differences in its operation from an insecure 
>version, especially when one compares the two version in attacks 
>scenarios.
>

I think I see how we disagree. Historically (here comes those 
annoying 30+ years of experience again) designers of most protocols 
have not considered how assumed a benign (or at least 
non-adversarial) environment for protocol operation. In the today's 
world that is not a good assumption. So, when we add security 
mechanisms to a protocol to try to allow it to operate successfully 
in a hostile environment, one ought to expect the behavior to differ 
in attacks scenarios.  I assert that this does not change the 
semantics, because protocol behavior outside of the benign 
environment was out of scope for the non-secure protocol design.

>Very debatable.  I wouldn't necessarily impugn the addition of 
>security semantics to a protocol (sometimes additional 
>expressiveness is needed).

impugn? I am not assailing the addition of secruity semantics. I am 
asserting that the semantics associated with the additional of 
security mechanisms does not constitute a violation of the semantics 
associated with the original, non-secure version of a protocol.

>
>>  The relevant question is whether the fundamental nature of the 
>>protocol is altered by the addition of security.
>
>That may be a question you care about... It might even be one that 
>the rest of us care about, but that is different than claiming you 
>have not added semantics (which is where this started).  This 
>comment is changing the subject.

OK, where we started, to be brutally honest, was an attempt by you 
and Brian to find a way for Brian's proposal on route leaks to be 
considered in scope for SIDR. The SIDR charter is clear about the 
scope, and route leaks are not part of what we are currently 
chartered to do. So we really ought not be having this discussion. 
I'll do my part to help, by not replying to further messages on this 
topic.

>Or maybe a line of thought (``thinking'' as you put it) that has 
>gone unchanged in over 30 years is overdue for having its 
>assumptions challenged.  Security (in particular) is a field in 
>which the landscape changes, and stale vision can lead to myopia... 
>Many things in the Internet security theater have obviously changed 
>in 30 years, so the age of lessons does not necessarily correlate 
>with their relevance. :)

Your comment suggests that no wisdom has accrued, at least to me, 
with 30 years of experience. I beg to differ. When someone proposes 
an approach that has been proposed and rejected previously, I usually 
ask myself "why did we reject this before, and what has changed that 
might make the decision be different this time?"  Usually the answer 
is that the reasons for rejecting an approach are still valid, but 
the proposer of the "new" approach was unaware of the history. On 
some occasions the answer is yes, we ought to revisit the decision 
(which may of may not still be correct). I am fortunate to have had 
firsthand experiences over the last 3 decades that allow me to have 
this perspective.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2012 15:01:23 -0400

At 1:56 PM -0400 3/21/12, Brian Dickson wrote:
>On Wed, Mar 21, 2012 at 1:40 PM, Stephen Kent 
><<mailto:[email-masked]>[email-masked]> wrote:
>...
>

you have added emphasis to the text trying to show why your topic is 
not excluded.  The generic phrase that applies here is "taking text 
out of context."

>It does mandate two specific required vulnerabilities, but does not 
>exclude anything.

The text says "The two vulnerabilities that will be  addressed are: 
..." In normal English use, "the" implies that only the listed items 
are in scope. If one wanted to suggest otherwise, one could say, for 
example, "Vulnerabilities that will be  addressed include:" or 
"Vulnerabilities that will be  addressed include but are not limited 
to:"

>In fact, and I believe I am far from alone in this regard, the bold 
>items in the charter give license to address other vulnerabilities.

we are far apart.

>identified vulnerabilities, would be seen by the rest of the IETF 
>and by the "users" of BGP (operators of the >>30k ASNs) as a massive 
>#FAIL.

Every WG operates based on inputs from its members, not on inputs 
from every user of the Internet, every vendors, every network 
operator, etc. When a WG reaches rough consensus that reflects the 
views of its members, the work product is published to the IETF list 
as a whole, offering an opportunity for broader comment. Even that 
does not ensure that every affected entity has been consulted. yet, 
we persist ...

>"The two vulnerabilities", is semantically distinct from "The _only_ 
>two vulnerabilities".
>
>You (SK) seem to be arguing that the latter is the case. The charter 
>says the former.

We disagree on how one should read the charter. You should ask the 
WGs chairs.  If you don't like the answer they provide, then you can 
ask the cognizant AD, then the IESG, then the IAB.

>restrict us to the latter, I believe the appropriate way to resolve 
>this is to re-charter to remove all ambiguity in the matter, one way 
>or the other.

nice try, but no cigar. the right response is that first we finish 
the work we are chartered to do, THEN we can apply to re-charter. 
That's how WGs proceed.

>That is, unless it is merely a matter of interpreting the words of 
>the charter incorrectly, in which case, let's just get on with 
>updating the threat model and finding solutions.

The threat model was updated to reflect SIDR list comments on 2/3, 6 
weeks ago, and it garnered no responses. A new version was posted on 
2/22, mostly to replace cites of I-Ds with cites to RFCs. It also 
garnered no comments.

Steve

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 15:19:36 -0400

While I am enjoying our rendition of Mr. Toad's Wild Ride (i.e. the meanderings of this thread, http://en.wikipedia.org/wiki/Mr._Toad%27s_Wild_Ride#Disneyland_version ), I suspect others on the list may be growing tired of it.  I will try to prune my blow-by-blow to just what seems important:

On Mar 21, 2012, at 2:06 PM, Stephen Kent wrote:

> I think I see how we disagree. Historically (here comes those annoying 30+ years of experience again) designers of most protocols have not considered how assumed a benign (or at least non-adversarial) environment for protocol operation. In the today's world that is not a good assumption. So, when we add security mechanisms to a protocol to try to allow it to operate successfully in a hostile environment, one ought to expect the behavior to differ in attacks scenarios.  I assert that this does not change the semantics, because protocol behavior outside of the benign environment was out of scope for the non-secure protocol design.

How about we turn this around with a simple question:
Suppose two different feasible paths are being evaluated for a single prefix/origin pair and one was delivered via a signed bgpsec update, and the other was delivered via an unsigned update.  What annotations/influencers/considerations/etc. does the bgpsec design suggest when the router is making its path selection between these two?

> OK, where we started, to be brutally honest, was an attempt by you and Brian to find a way for Brian's proposal on route leaks to be considered in scope for SIDR. The SIDR charter is clear about the scope, and route leaks are not part of what we are currently chartered to do. So we really ought not be having this discussion. I'll do my part to help, by not replying to further messages on this topic.

*sigh*  This again?  You have to be kidding me...  
1) I have no involvement w/ Brian's route leak work.  
2) Honestly, if I _were_ involved in Brian's work, I would be happy to announce it, and I would have asked to be listed as a coauthor.  I really don't think there would be any value in pretending _not_ to be involved, as I have always felt that my ideas stand on their own merit.  I don't hide my involvement in ideas. :)

Why not keep the discussion on topic for a while?

> Your comment suggests that no wisdom has accrued, at least to me, with 30 years of experience. I beg to differ. When someone proposes an approach that has been proposed and rejected previously, I usually ask myself "why did we reject this before, and what has changed that might make the decision be different this time?"  Usually the answer is that the reasons for rejecting an approach are still valid, but the proposer of the "new" approach was unaware of the history. On some occasions the answer is yes, we ought to revisit the decision (which may of may not still be correct). I am fortunate to have had firsthand experiences over the last 3 decades that allow me to have this perspective.

``Wisdom ceases to be wisdom when it becomes too proud to weep, too grave to laugh, and too selfish to seek other than itself.''  -- Kahlil Gibran

I (for one) certainly respect experience, but I don't think it should earn a blank check.  If the approach is so sound, it should stand on its own technical merit without needing to be vetted by the pedigree of its designer, right? ;)

Eric

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 15:33:52 -0400

> and a existence proof of a reasonable mechanism to address that threat.

BGPSEC:

1. Fails to actually protect the bits on the wire in a way that meets
BGP's actual on the wire protocol semantics (see the addition of timers
to prevent replay attacks).
2. Attempts to add policy to the mix (see the so-called "man in the
middle attack") without actually calling it policy.

Given these failures, maybe it's time to start with requirements (rather
than a solution) first, and see if we come to a better outcome.

Russ

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 15:40:11 -0400

> than a solution) first, and see if we come to a better outcome.

+1

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 15:40:20 -0400

Sorry to interject, but...

On Mar 21, 2012, at 3:01 PM, Stephen Kent wrote:

<snip>

> 
>> I  would also opine, that _not_ addressing other, identifiable and identified vulnerabilities, would be seen by the rest of the IETF and by the "users" of BGP (operators of the >>30k ASNs) as a massive #FAIL.
> 
> Every WG operates based on inputs from its members, not on inputs from every user of the Internet, every vendors, every network operator, etc. When a WG reaches rough consensus that reflects the views of its members, the work product is published to the IETF list as a whole, offering an opportunity for broader comment. Even that does not ensure that every affected entity has been consulted. yet, we persist ...

My input is that the current work that does not address the real route leak threat, and it is therefore insufficient.  Since you said that you want your work to reflect views that include mine, I'm just making my views clear... again.  Also, I think it would behoove us to strive towards producing work that will be accepted by operators (as I think I see Brian saying).  I think it's less about consulting everyone in the world and more about being realistic.  For our work to be relevant, it has be operationally feasible...

<snip>

> 
>> That is, unless it is merely a matter of interpreting the words of the charter incorrectly, in which case, let's just get on with updating the threat model and finding solutions.
> 
> The threat model was updated to reflect SIDR list comments on 2/3, 6 weeks ago, and it garnered no responses. A new version was posted on 2/22, mostly to replace cites of I-Ds with cites to RFCs. It also garnered no comments.

Indeed, I'm printing it now...

Eric

---

From: Russ White <[email-masked]>
Date: Wed, 21 Mar 2012 15:51:20 -0400

> nope, it's bits that you can choose to use or not.

In other words, you've added another set of "wiggle words" to your
definition. "It's not policy because it's not signing something saying
you shouldn't do x, and because anyone can ignore the signature anyway."

Sorry, I don't buy it.

You are adding bits that allow (even demand) a receiver to discern the
intent of the transmitter about the usability of a specific path. I
don't care how many wiggle words you put around it --it's still policy.

Now if you're going to dive into policy, then dive into policy. There's
nothing wrong with diving into policy, so long as you actually address
the issue. That means determining which policies should be protected,
and what the tradeoffs are for protecting each one.

> I'm really not trying to sneak anything.  we seem to be at an impasse.

I've seen more than a small number of presentations on BGPSEC. I've read
more than a small number of drafts. I've had more than a small number of
private conversations about BGPSEC/S-BGP. In _every_ conversation I've
ever had, in _every_ presentation I've ever seen, the one singular
reason given for signing the BGP update is this: So a remote AS can
determine whether or not some previous AS _intended_ to allow
reachability through a particular peer for a particular prefix.

Perhaps the way to resolve the impasse is to accept that what you are
trying to do goes beyond simple "bits on the wire" security, bring the
policy problems out into the open, and have a discussion about them.

Or to come to the realization that you simply can't secure any routing
protocol by simply "signing the bits on the wire," because many of the
semantics everyone is so concerned about are actually not in the "bits
on the wire" to be signed in the first place.

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Mar 2012 20:56:24 +0100

> On 2012-03-21 16:50, Brian Dickson wrote:
> ...
> -protocol docs, until the -reqs- and -threat- are adequately addressed.

On 2012-03-21 20:33, Russ White wrote:
 > ...
 > Given these failures, maybe it's time to start with requirements
 > (rather than a solution) first, and see if we come to a better
 > outcome.

Having a reasonable requirements document which defines what is that 
should be protected seem like a very reasonable thing. Clearly for some 
who "make/made decisions on the protocol" this may be a bit 
uncomfortable as their design choices now would need to compete with 
design proposals from others.

The requirement should explicitly list elements to provide ability for 
gradual deployment .. maybe co-existence for some time. Clearly ideas of 
removing AS_PATH or AS4_PATH and replacing it with PATH_SIG are not 
really helping gradual deployment.

Decent requirement document should also specifically prohibit use of any 
tools which can be controlled by politicians/courts to decide who stays 
in the internet and who becomes uncomfortable and needs to be cut out.

So: +1

Rgs,
R.

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Mar 2012 14:51:25 -0600

On Mar 21, 2012, at 1:56 PM, Robert Raszuk wrote:
> Having a reasonable requirements document which defines what is that should be protected seem like a very reasonable thing. Clearly for some who "make/made decisions on the protocol" this may be a bit uncomfortable as their design choices now would need to compete with design proposals from others.
> 
> The requirement should explicitly list elements to provide ability for gradual deployment .. maybe co-existence for some time. Clearly ideas of removing AS_PATH or AS4_PATH and replacing it with PATH_SIG are not really helping gradual deployment.
> 
> Decent requirement document should also specifically prohibit use of any tools which can be controlled by politicians/courts to decide who stays in the internet and who becomes uncomfortable and needs to be cut out.
> 
> So: +1
> 
> Rgs,
> R.

+1 more.

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 16:57:47 -0400

> Suppose two different feasible paths are being evaluated for a single prefix/origin pair and one was delivered via a signed bgpsec update, and the other was delivered via an unsigned update.  What…

ideall, I think, the process is something like:
  1) first path gets evaluated, is it 'good' (next-hop reachable, not
discarded by prefix-list/etc)
  2) second path gets evaluated, is it 'good' (same as above +
origin-validate + path-validation)

If both 1 and 2 come out 'ok', assume each path was received from a
different peer on the same device:
  1) 1 - 2 - 701 - you
  2) 1 - 3 - 7018 - you

If you decide that your network's policy is 'prefer signed and valid
over unsigned' paths, you'd pick #2. It could be that your method of
doing this is saying:
  route-map inbound-bgp permit 10
    if route-signed and verified
    set localpref 100

 Which ideally would let localpref on the #1 route stay normal == 80
and magically you'd just use the 'right' (from your perspective) path.
(signed and verified).

of course, in the beginning of this you may choose a more conservative:
   route-map inbound-bgp permit 10
      if route-signed and verified
        set community you:verified

so you could measure the deployment state of your customers + rest-o-interwebs.

In the end, I think 'bgpsec suggests' that the operator would make
some decision... ideally the same decision across the network.

does that make sense? (the policy is deliberately short and simple,
obviously real policy is longer/stranger, but the end result is the
same)
-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 17:00:39 -0400

On Wed, Mar 21, 2012 at 3:40 PM, Eric Osterweil <[email-masked]> wrote:
> My input is that the current work that does not address the real route leak threat, and it is therefore insufficient.

and many, many times ... 'how would you do this, really, show me the
math' has been asked. the closest so far is Brian's set of 3 id's
which are being chattered about in IDR and some in SIDR as well.

btw, Is 'the real route leak threat' different in some way than other
(what other?) route-leak-threats? and is it the only thing you care
about? (I think there are others, is this the only uncovered hole in
the pasture? or are you worried about breaking your leg on something
else as well?)

-chris

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 17:04:21 -0400

> obviously real policy is longer/stranger, but the end result is the

Indeed, this makes sense, thanks for the detailed response.  However, this also illustrates an evolution of semantics under non-attack circumstances. :)

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 17:06:03 -0400

> Indeed, this makes sense, thanks for the detailed response.  However, this also illustrates an evolution of semantics under non-attack circumstances. :)

expand please.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 17:07:44 -0400

> you shouldn't do x, and because anyone can ignore the signature anyway."

no, I don't think we can enforce any one use this... no matter how
shiney it may seem.
I think if we offer more data to the bgp-user, in a fashion they can
digest and use, they may make a better decision.

we can not, today, publish or require publishing 'you can only
advertise to X'. Certainly a single  operator can decide 'I will only
advertise to X' or 'I will only accept Y advertisements from Z' (this
happens today, outside of any concept of 'security' and the protocol).

-chris

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Mar 2012 15:13:59 -0600

On Mar 21, 2012, at 3:00 PM, Christopher Morrow wrote:
> math' has been asked.

Answer: Evaluate policy.

-shane

> the closest so far is Brian's set of 3 id's

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 21 Mar 2012 17:15:52 -0400

>in the internet and who becomes uncomfortable and needs to be cut out.

OK, so we have existence proofs that DNS based solutions are out .... ;^)

I think it wise before making strategic decisions based upon such
requirements, one should carefully examine what the real risk scenarios
are, what techniques might mitigate them, and then examine if the
remaining risks are substantially different than those that already exist
in the system. 

So far, most of the concerns I have heard are no different than any other
globally distributed hierarchical system where individual components are
subject to local laws.

Dougm

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 17:17:44 -0400

Hey Chris,

> which are being chattered about in IDR and some in SIDR as well.

As I mentioned to Steve, ``If a system is repeatedly subverted along a specific attack vector, the fact that you can see evidence of subversion, but you can't model it with a closed form equation or a formal proof does _not_ mean you should withhold the development of protections!  That's like saying: I haven't got a formal proof for what a local escalation of privileges is, on my Linux box... I hope Linus comes up w/ a formal definition soon so that I stop getting pwnd!''

I don't know that math (or any other formalism) is generally considered a requirement for the incorporation of security protections when they are needed.  Indeed, the notion that security protections must be predicated on some form of formal analysis seems like a severe/unnecessary hindrance.  I don't know that the current BGPSEC design is evolvable to remediate the threats we currently face, but that does _not_ mean we should avoid addressing the problem.

> the pasture? or are you worried about breaking your leg on something

1) Sorry, 'real' was only added to emphasize that this is an existing problem.  Nothing more...
2) I am actually listening to what those operators that I talk to are worried about.  I've heard many issue warnings about the threat that route leaks pose, and some of my own research tends to underscore some more subtle (but I think very dangerous) threats that I think route leaks enable quite nicely.  Thus, this is my view of what I've heard many people say and what I have seen.  I'm sure there are others, but that's where an accepted requirements doc would be helpful.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 17:17:51 -0400

Hey Chris,

>> Indeed, this makes sense, thanks for the detailed response.  However, this also illustrates an evolution of semantics under non-attack circumstances. :)

Sure, there is now a new element in the BGP update (the sig(s)) whose presence, nature, or absence causes the interpretation of the update to differ.  While I still disagree with the earlier caveat that all bets are off during an attack, that statement clearly does cover this case where one update simply isn't signed.  That's what I meant, though I didn't mean to be cavalier when I said it before... Sorry if it came off as a barb. :)

Eric

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Mar 2012 22:19:10 +0100

Hi Chris,

> some decision... ideally the same decision across the network.

Such decision is inherently per prefix. So even assuming ideal case and 
such policy like in your example would be the same across given AS how 
would you see such policy to be the same across the entire path given 
update traverses ?

Aren't you afraid about swiss cheese effect for end-to-end connectivity 
if some ASes prefer signed and some other non signed paths ?

What happens in your example if singed comes with PATH_SIG listing 4 
ASes (pCount=1 of each) and real AS_PATH is length of 3 ?

If you set local pref on inbound (just like shipping code allows for 
origin validation) you will deliberately choose longer path as best 
since LOC_PREF is checked much earlier in BGP Best path then AS_PATH 
length (even assuming those would be comparable across two attributes).

Thx,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 17:21:02 -0400

>> and many, many times ... 'how would you do this, really, show me the

'apply prefix lists' you mean?

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Mar 2012 15:26:57 -0600

> 'apply prefix lists' you mean?

No.  Evaluate _policy_.  Policy is about whether an ASN /intended/ to announce a path to another ASN _or_ not.  More succinctly: one needs input to verify output, (since you said "show me the math").

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 17:37:42 -0400

> No.  Evaluate _policy_.  Policy is about whether an ASN /intended/ to announce a path to another ASN _or_ not.  More succinctly: one needs input to verify output, (since you said "show me the math"…

smarty... :)

someone reminded me that I shouldn't be quite so flip 'show me the
math' is really, 'how can I tell from 2 as-hops away that:

  1 -> 2 -> 3 -> me

is a leak?'

Randy posted on nanog (to you/shane, I think) a message with content like:
  "to do this rigorously, i
would need to form the transitive closure of the business policies of
every inter-provider link on the internet."

in this: <http://mailman.nanog.org/pipermail/nanog/2012-February/045941.html>
message. This is what you mean as well, yes?

-chris

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Mar 2012 22:37:56 +0100

> No.  Evaluate _policy_.  Policy is about whether an ASN /intended/ to
> announce a path to another ASN _or_ not.  More succinctly: one needs
> input to verify output, (since you said "show me the math").

From: Randy Bush <[email-masked]>
Subject: Re: do not filter your customers
To: Shane Amante <[email-masked]>
Cc: North American Network Operators' Group <[email-masked]>
Date: Sat, 25 Feb 2012 15:22:35 +0530

> as would be solving world hunger, war, bad cooking, especially bad
> cooking.
> 
> route leaks, as much as i understand them
>  o are indeed bad ops issues
>  o are not security per se
>  o are a violation of business relationshiops
>  o and 20 years of fighting them have not given us any significant
>    increase in understanding, formal definition, or prevention.

let me try to express how i see the problem.  to do this rigorously, i
would need to form the transitive closure of the business policies of
every inter-provider link on the internet.

why i say it is per-link and not just inter-as (which would be hard
enough) is that i know a *lot* of examples where two ass have different
business policies on different links.  [ i'll exchange se asian routes
with you in hong kong, but only sell you transit in tokyo.  we have two
links in frankfurt, one local peering and one international transit. ]

it is not just one-hop because telstra was 'supposed to' pass some
customers' customers' routes to optus.

i find this daunting.  but i would *really* like to be able to
rigorously solve it.  please please please explain to me how it is
simpler than this.

randy

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Mar 2012 15:42:17 -0600

> message. This is what you mean as well, yes?

Yes.  And, to answer Randy's question in that message ... I'm not asserting that this is a _simple_ problem to be solved, but we should not ignore the problem b/c it's "hard" ... otherwise, we wouldn't have the Internet, as it exists today, nor a lot of other things.

-shane

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2012 16:54:12 -0400

As I said in my prior message, I'm not going to continue contributing 
to a thread that seems pointless at this stage.

Steve

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Mar 2012 22:47:37 +0100

>> in this:
>> <http://mailman.nanog.org/pipermail/nanog/2012-February/045941.html>
> Yes.  And, to answer Randy's question in that message ... I'm not
> asserting that this is a _simple_ problem to be solved, but we should
> not ignore the problem b/c it's "hard" ... otherwise, we wouldn't have
> the Internet, as it exists today, nor a lot of other things.

actually, there is a solution to that problem.  it's called bgp.  bgpsec
is an attempt to protect that solution from some demonstrated attacks.

if you have another solution, do tell us.  but ranting that world hunger
should be solved does not feed anyone.

randy

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 21 Mar 2012 17:48:51 -0400

Many moons ago (IETF attendance was <100) there was an effort to solve
this problem (Open Routing Working Group).

Stable refs are hard to find ... But the following gives a decent summary
of an approach to such a solution.

http://research.cens.ucla.edu/people/estrin/resources/journals/1991jan-Estr
in-Streenstrup-InterDomain.pdf

A long long way from BGP ... But maybe that is where you wan to go?
dougm
-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

On 3/21/12 5:42 PM, "Shane Amante" <[email-masked]> wrote:

>>>>>>> My input is that the current work that does not address the real
>>>>>>>route leak threat, and it is therefore insufficient.
>>>>>> 
>asserting that this is a _simple_ problem to be solved, but we should not
>ignore the problem b/c it's "hard" ... otherwise, we wouldn't have the
>Internet, as it exists today, nor a lot of other things.
>
>-shane

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 17:56:38 -0400

On Wed, Mar 21, 2012 at 5:19 PM, Robert Raszuk <[email-masked]> wrote:
> Such decision is inherently per prefix. So even assuming ideal case and such

yes

> policy like in your example would be the same across given AS how would you
> see such policy to be the same across the entire path given update traverses
> ?

is the policy supposed to be the same across the whole of the path?
does, today, 2914 have the same policy for prefix 128.2.35.0/24 as
as701 as as7018 as as4134 ?

The policy wrt any bgp learned (AND ANNOUNCED!) route is per-operator,
'per asn' at best. In reality there are even cases where where the
policy is 'per link in an ASN'.

I'm not sure why expecting this to be different in SIDR is a good thing to do.

> Aren't you afraid about swiss cheese effect for end-to-end connectivity if
> some ASes prefer signed and some other non signed paths ?

In general, today there is no coherent policy across ASN's. EXCEPT
'make sure packets get as close to the destination as is possible for
my asn to do.' I suspect that over the course of ~7-10 years BGPSEC
(or similar) would rollout across enough ASN's to ensure 'good enough'
security for a large portion of destinations/prefixes on the network.
I hope that would be the case.

I believe that, as I said before (perhaps not on sidr?) that the
process looks something like (for an individual operator):
  0) hear about bgpsec
  1) figure out which end is up
  2) upgrade code/etc to support this function after deciding it's
worth your while.
  3) start collecting stats on internal usage + customer usage +
customer-certification-of-resources
  4) action fixes to customer setup and internal setup
  5) start signing your prefixes as you can
  6) use metrics to judge success

there's likely a few middle steps skipped there... I'm sure someone
else could find other bits to add.

(really jayb@att has done a lot of work on this planning...)

>
> What happens in your example if singed comes with PATH_SIG listing 4 ASes
> (pCount=1 of each) and real AS_PATH is length of 3 ?

so, pcount I'm not a fan of.... but, you're suggesting a path that's
invalid? or impossible?

> If you set local pref on inbound (just like shipping code allows for origin
> validation) you will deliberately choose longer path as best since LOC_PREF
> is checked much earlier in BGP Best path then AS_PATH length (even assuming
> those would be comparable across two attributes).

'use the appropriate knob' I made an example, make it better.

> Thx,
you too!
-chris

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 21 Mar 2012 17:56:35 -0400

> Yes.  And, to answer Randy's question in that message ... I'm not asserting that this is a _simple_ problem to be solved, but we should not ignore the problem b/c it's "hard" ... otherwise, we woul…

Sorry to butt in again, but to follow that up: I'm not sure that "to do this _rigorously_" was the right phrasing.  I think in order to "completely" model all of the Internet's BGP policies across the entire AS topology you would need to form the transitive closure over everything, but it would still be a rigorous exercise to model more restricted topologies.  For example, you might want to scope your analysis: your adjacencies, or islands of security, or $n$ hops out from a source, etc... I'm not claiming to have considered all of the relative benefits or drawbacks of that, but it would still (imho) be a rigorous process... Maybe it would even be useful to some...

Just sayin'

Eric

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 21 Mar 2012 18:03:17 -0400

On 3/21/12 5:56 PM, "Christopher Morrow" <[email-masked]> wrote:

>>such
>>if
>>ASes

In the current BGPSEC spec, there is only a PATH_SIG element (with AS hops
encoded within), so this specific scenario could not occur.  But even if
the protocol carried both fields, I think the basic design of the protocol
would label the AS_PATH "Invalid" under the simple primise that the SIG
data does not validate the AS_PATH data (no matter where/how it is
encoded).

What your local policy does with that "Invalid" label, is up to you.

Dougm

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 21 Mar 2012 23:05:07 +0100

> so, pcount I'm not a fan of.... but, you're suggesting a path that's

Worse .. in my example both paths are valid, crystal clear and pass all 
validations one can apply.

> 'use the appropriate knob' I made an example, make it better.

It is not the question of knob. It is a question of expected behaviour.

Thx,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 21 Mar 2012 18:22:17 -0400

> Sure, there is now a new element in the BGP update (the sig(s)) whose presence, nature, or absence causes the interpretation of the update to differ.  While I still disagree with the earlier caveat…

I didn't take it as a barb:) you seemed to have in mind a problem, you
showed it above as well, i was curious what the problem was.

You highlight a problem that, of course, looks to me like a dnssec
sort of thing? "Hey, this domain is supposed to have sigs, it didn't?"

I think in this case you could change the simple example above as:
  1) unsigned path, everything 'ok'
  2) unsigned path, everything 'ok' except there is a prefix with ROA
data and no sigs

is that right?

---

From: Shane Amante <[email-masked]>
Date: Wed, 21 Mar 2012 16:27:13 -0600

On Mar 21, 2012, at 3:47 PM, Randy Bush wrote:
> actually, there is a solution to that problem.  it's called bgp.

No, it's not.  Today, BGP is a mechanism that was strictly designed for distributing reachability information <period, full-stop>.  Any change in that is a fundamental change to the way the BGP protocol is operated, currently.

> bgpsec

... which have not been enumerated, in detail, in any SIDR WG drafts.  As I look at <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-02> there is /a lot/ of discussion around threats posed to everything surrounding BGPSEC & the RPKI, but no substance to at least the one "headline" threat that BGPSEC is supposedly designed to mitigate against, the so-called "Pilosov/Kapela" attack.  Heck, there's not even a _link_ or _reference_ in the threats document to the Pilosov/Kapela attack.  I can't even find one in <http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-03> either.

Heck, if even the attacks you allude to are not enumerated (in detail), then IMHO there are much bigger problems here ...

-shane

---

From: Brian Dickson <[email-masked]>
Date: Wed, 21 Mar 2012 18:33:34 -0400

The drafts (three of them, together) are an attempt to define, constrain,
and solve the problem.

Yes, it is tricky and difficult. I'm not saying that the solutions (two of
them to choose from) are the only way to do it.
But, I believe that either of them actually solves the problem.

In a nutshell, here's how it works:
Mark the path "intent" in one of two ways (customer or non-customer),
(based on mutual agreement between adjacent peers)
Incorporate some kind of mechanism to detect/prevent fudging (a la bgpsec
sig)
Apply a simple set of rules based on route color vs peering "type", plus
"v-free" type logic.

Everything is in-band, and the transitive closure _is_ the transitive
closure.

ASCII art is not adequate for presenting complex ideas, IMHO. I will
attempt to provide a richer presentation for Paris.

Please, if anyone is interested, for the love of $deity, read the drafts
and provide feedback.

Thanks,
Brian

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Wed, 21 Mar 2012 18:34:51 -0400

>validations one can apply.

If you are talking about BGPSEC as currently proposed, this can't happen.
The definition of validity of a PATH_SIG is that valid signatures exactly
correspond to AS_PATH data.

See: 
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5.1

Once again, given the encoding of AS_PATH directly in PATH_SIG attribute,
the exact scenario is moot (a BGPSEC update will never contain both
AS_PATH and PATH_SIG attributes), but the spirit is the same, the
validation algorithm will return "Invalid"

Dougm

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Mar 2012 23:58:54 +0100

brian, i scanned some time ago and am reading (trying to get other work
done too).  i think you are too good a typist:) i think your ideas could
be reduced to a page.  this is a feature, not a bug.

but i think you are on a constructive path as opposed to screaming that
someone else should solve it for you.

[ of course i worry that not all relationships are customer/provider or
  peer/peer.  the droids are amazingly inventive.  but let's leave that
  aside for a while. ]

i wonder if i have the prerogative to enforce a business relationship
violation that is three hops from me when the op two hops from me chose
not to do so.  i am still trying to wrap my head around these aspects.

but i do agree that, if we get your semantics nailed down simply and
well understood, we would want to sign the signals.  downright have to.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Mar 2012 00:11:52 +0100

Maybe there is misunderstanding ...

Chris example was stating:

One path comes without signature the other one with signature .. AS 
PATHs they traverse is disjoined at some point.

Are you saying this can not happen ?

Many thx,
R.

> On 3/21/12 6:05 PM, "Robert Raszuk"<[email-masked]>  wrote:
>
>>

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Thu, 22 Mar 2012 09:48:09 -0400

Sorry, my bad.  I somehow thought you were talking about two different
PATH elements in the same update.  That assumption made your questions
sound bizarre.   I am sure my misunderstanding made my answers sound
equally bizarre.

So, yes if they are different updates for the same prefix received from
different peers ... Then of course this will happen all the time.

As for if you somehow prefer the signed path over the unsigned path, in
the end that is a local decision.  I think there is/will be strong wording
that one SHOULD choose the signed and valid path because at the moment
there is no explicit way of distinguishing that a path should have been
signed, and as a result, there is a simple downgrade attack to strip the
PATHSIG, if one is not strictly preferring signed over unsigned paths.

One could think of fixing this, by having AS's push and object in the RPKI
that says "I am signing my paths", then it would be possible to detect the
simple downgrade attack.   I guess one might think of AS_CERTS as such a
signal, but that is a bit problematic WRT timing issues.  The right way to
do it would be some other explicit object.

Anyway, to answer your question below, one SHOULD choose the second path,
but I doubt the specs will ever say you MUST choose the second path.

dougm

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 22 Mar 2012 14:57:06 +0000

This has become a long and tortuous rat hole, leading off into branching rat holes.

It all started with prospective text to the idr wg about the route leaks problem.

The furor started over the suggested text's stated motivation for asking.

But there have been no objections to conferring with idr and some expressions of agreement.

So can we go just please discuss what the message to idr should say?

How about something along the lines of:

There is agreement that route leaks is a problem.
There is agreement that a change to bgp might provide a solution, but concern about sidr undertaking the solution without idr participation.
Would the idr be willing to work with sidr in (a) defining the route leaks problem, (b) devising a solution and (c) securing that solution?  
The actual home for the work (idr, sidr, both, something else) would be discussed.

--Sandy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Mar 2012 11:00:03 -0400

> The actual home for the work (idr, sidr, both, something else) would be discussed.

sounds good to me.
-chris

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 22 Mar 2012 11:02:33 -0400

+1

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 22 Mar 2012 11:27:20 -0400

I am aware of a number of ebgp relationships where the two parties
disagree on the nature of their connections: 

- the first party believes the second is a transit customer

- the second party believe the first is a peer

Today the two parties agree to disagree, and yet the proper routing
works. 

I am also aware of a number of intricate routing policies, along the
lines of in-country transit, per-continent peer, world-wide customer.  

I'm afraid these kinds of things could make it tricky or even
impossible to categorize links in black-and-white terms as is done in
these leaks drafts.

Brian Dickson writes:
 > The drafts (three of them, together) are an attempt to define, constrain, and solve the problem.<br><br>Yes, it is tricky and difficult. I&#39;m not saying that the solutions (two of them to choose from) are the only way to do it.<br>
 > But, I believe that either of them actually solves the problem.<br><br>In a nutshell, here&#39;s how it works:<br>Mark the path &quot;intent&quot; in one of two ways (customer or non-customer), (based on mutual agreement between adjacent peers)<br>
 > Incorporate some kind of mechanism to detect/prevent fudging (a la bgpsec sig)<br>Apply a simple set of rules based on route color vs peering &quot;type&quot;, plus &quot;v-free&quot; type logic.<br><br>Everything is in-band, and the transitive closure _is_ the transitive closure.<br>
 > <br>ASCII art is not adequate for presenting complex ideas, IMHO. I will attempt to provide a richer presentation for Paris.<br><br>Please, if anyone is interested, for the love of $deity, read the drafts and provide feedback.<br>
 > <br>Thanks,<br>Brian<br><br><div class="gmail_quote">On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 > <div class="im">&gt;&gt;&gt; Answer: Evaluate policy.<br>
 > &gt;&gt; &#39;apply prefix lists&#39; you mean?<br>
 > &gt; No.  Evaluate _policy_.  Policy is about whether an ASN /intended/ to<br>
 > &gt; announce a path to another ASN _or_ not.  More succinctly: one needs<br>
 > &gt; input to verify output, (since you said &quot;show me the math&quot;).<br>
 > <br>
 > </div>From: Randy Bush &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
 > Subject: Re: do not filter your customers<br>
 > To: Shane Amante &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
 > Cc: North American Network Operators&#39; Group &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
 > Date: Sat, 25 Feb 2012 15:22:35 +0530<br>
 > <br>
 > &gt; as would be solving world hunger, war, bad cooking, especially bad<br>
 > &gt; cooking.<br>
 > &gt;<br>
 > &gt; route leaks, as much as i understand them<br>
 > &gt;  o are indeed bad ops issues<br>
 > &gt;  o are not security per se<br>
 > &gt;  o are a violation of business relationshiops<br>
 > &gt;  o and 20 years of fighting them have not given us any significant<br>
 > &gt;    increase in understanding, formal definition, or prevention.<br>
 > <br>
 > let me try to express how i see the problem.  to do this rigorously, i<br>
 > <div class="im">would need to form the transitive closure of the business policies of<br>
 > every inter-provider link on the internet.<br>
 > <br>
 > </div>why i say it is per-link and not just inter-as (which would be hard<br>
 > enough) is that i know a *lot* of examples where two ass have different<br>
 > business policies on different links.  [ i&#39;ll exchange se asian routes<br>
 > with you in hong kong, but only sell you transit in tokyo.  we have two<br>
 > links in frankfurt, one local peering and one international transit. ]<br>
 > <br>
 > it is not just one-hop because telstra was &#39;supposed to&#39; pass some<br>
 > customers&#39; customers&#39; routes to optus.<br>
 > <br>
 > i find this daunting.  but i would *really* like to be able to<br>
 > rigorously solve it.  please please please explain to me how it is<br>
 > simpler than this.<br>
 > <span class="HOEnZb"><font color="#888888"><br>
 > randy<br>
 > </font></span><div class="HOEnZb"><div class="h5"><br>
 > _______________________________________________<br>
 > sidr mailing list<br>
 > <a href="mailto:[email-masked]">[email-masked]</a><br>
 > <a href="https://www.ietf.org/mailman/listinfo/sidr" target="_blank">https://www.ietf.org/mailman/listinfo/sidr</a><br>
 > </div></div></blockquote></div><br>

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Thu, 22 Mar 2012 11:34:25 -0400

>impossible to categorize links in black-and-white terms as is done in

I would suggest categorizing directed links as they appear in AS_PATH.

It is not clear to me that A->B has to be labeled the same way as B-->A.

Given that we are discussing control of further distribution, I think the
sender of an UPDATE would label the link with its view of the relationship.

Dougm

---

From: Brian Dickson <[email-masked]>
Date: Thu, 22 Mar 2012 12:09:37 -0400

Hi, Jay,

Out of curiosity, have you had a chance to read (or skim over) the drafts?

Basically, what they do is say, "how can we categorize the link, with four
options to choose from".

The categories do not need to handle all the subtleties, they only need to
be consistent with whatever local policy is.

E.g. Your first example - having the "second party" configure the link as
"transit-customer" does not in any way obligate them to apply a transit
_policy_ on the link. The link coloring is technically orthogonal to all
existing policy mechanisms. It simply adds a mechanism to automatically
stop route leaks.

The three drafts together have a simple rule of thumb: if all three
"standard" link type categorizations would block routes that the peers
mutually agree should not be blocked, the fourth, "mutual transit" allows
anything to pass. It just so happens that the way "mutual transit" handles
customer and non-customer routes, prevents route leaks from crossing the
other three types of link (customer, transit, peer).

If the "local policy" applied to a given link can fit within one of the
three "standard" classes (as a proper subset) without blocking routes that
should be sent, then that "standard" class should be used.

It is meant to be easy to use, and easy to figure out classification.
The question "Am I sending _any_ non-customer routes?", from the
perspective of both peers, leads to the correct answer:
No/No == Peer
Yes/No == Transit
No/Yes == Customer
Yes/Yes == "mutual transit" (generic for "oddball")

This suggests I need to make the docs a little clearer in this regard -- I
definitely will.

Thanks for your feedback.

Brian

On Thu, Mar 22, 2012 at 11:27 AM, Jay Borkenhagen <[email-masked]> wrote:

>  > The drafts (three of them, together) are an attempt to define,
> constrain, and solve the problem.<br><br>Yes, it is tricky and difficult.
> I&#39;m not saying that the solutions (two of them to choose from) are the
> only way to do it.<br>
>  > But, I believe that either of them actually solves the
> problem.<br><br>In a nutshell, here&#39;s how it works:<br>Mark the path
> &quot;intent&quot; in one of two ways (customer or non-customer), (based on
> mutual agreement between adjacent peers)<br>
>  > Incorporate some kind of mechanism to detect/prevent fudging (a la
> bgpsec sig)<br>Apply a simple set of rules based on route color vs peering
> &quot;type&quot;, plus &quot;v-free&quot; type logic.<br><br>Everything is
> in-band, and the transitive closure _is_ the transitive closure.<br>
>  > <br>ASCII art is not adequate for presenting complex ideas, IMHO. I
> will attempt to provide a richer presentation for Paris.<br><br>Please, if
> anyone is interested, for the love of $deity, read the drafts and provide
> feedback.<br>
>  > <br>Thanks,<br>Brian<br><br><div class="gmail_quote">On Wed, Mar 21,
> 2012 at 5:37 PM, Randy Bush <span dir="ltr">&lt;<a href="mailto:
> [email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote
> class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
> solid;padding-left:1ex">
>  > Cc: North American Network Operators&#39; Group &lt;<a href="mailto:
> [email-masked]">[email-masked]</a>&gt;<br>
>  > <a href="https://www.ietf.org/mailman/listinfo/sidr" target="_blank">
> https://www.ietf.org/mailman/listinfo/sidr</a><br>

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 22 Mar 2012 12:21:46 -0400

> Out of curiosity, have you had a chance to read (or skim over) the drafts?

Um, yes.  That's where I found your text:

---------------------------------------------

Neighbor is:

   a.  Transit Provider - T

   b.  (Transit) Customer - C

   c.  Peer - P

   d.  Mutual Transit

   In any neighbor relationship, the roles of the parties on either
   end of the link would be:

      T-C

      C-T

      P-P

      Mc-Mtp

      Mtp-Mc

   (where the last two, Mc/Mtp are a semantic and/or coloring
   distinction on routes, rather than two separate links.)

---------------------------------------------

"P-T" and "T-P" were not listed among the choices.

If bi-lateral agreement is not a requirement, then I would suggest
modifying the text to not imply that it is.

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Mar 2012 19:08:55 +0100

> - the second party believe the first is a peer

yep.  as i said, i will save this part of the mess until we have shown
that brian's approach at least deals with the basics, the gao-rexford
fantasy that the world is flat.  then we can see if we can stretch the
solution to deal with these cases.

> lines of in-country transit, per-continent peer, world-wide customer.

that may be simpler.  it may just be different policies for different
prefixes.  and we know it's all per prefix anyway.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Mar 2012 19:09:30 +0100

> Basically, what they do is say, "how can we categorize the link,

you can't.  it has to be per prefix.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Mar 2012 19:28:53 +0100

> There is agreement that a change to bgp might provide a solution, but
> concern about sidr undertaking the solution without idr participation.
> Would the idr be willing to work with sidr in (a) defining the route
> leaks problem, (b) devising a solution and (c) securing that solution?

route leaks s/is/are/ a problem :)

<aol>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Mar 2012 21:40:17 +0100

Hi Doug,

Actually I am not that concerned what spec will recommend for the 
operator to do. I am more concerned what should be the router's default?

Considering the example below should it be: To prefer signed longer path 
versus unsigned shorter ?

Specifically I am asking - where does the signed vs unsigned decision 
step inserts itself into today's BGP best path decision ?

Should it be complete haos by allowing full freedom for local operator's 
configuration ? Should the default be "Do not care" if this is signed or 
unsigned ... just run your BGP best path as today ?

Thx,
R.

---

From: Ruediger Volk <[email-masked]>
Date: Thu, 22 Mar 2012 22:31:16 +0100

> operator to do. I am more concerned what should be the router's default?
NO change to current rules!

  > versus unsigned shorter ?
leave it entirely to operator to define policy for mapping signed/unsigned/
recieved from friend/received from foe/etc. onto the attribute set used
in the path selection algorithm

  > step inserts itself into today's BGP best path decision ?
at exactly the same point where the not well known community attributes
are used  (i.e. NOT in the scope of the standrad bgp path selection algorithm)

  > unsigned ... just run your BGP best path as today ?
don't interfere with whatever chaos (you think) the operator is working with.
Just provide the operator with trustworthy information and do not force
any nanny on him to help...
This does not preclude offering cookbook recipes and providing advice on
healthy or unhealthy (e.g. opening opportunities for downgrade attacks...)
ways of preparation...

Some may feel that offering ways of more flexible or granular decision
criteria in the path selection algorithm would be helpful, but that quite
certainly should be considered and provided from a more general point of view
(as extension in IDR) rather than being a special purpose extension for
AS path authenticity.

Ruediger

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 23 Mar 2012 00:28:20 +0100

Hello Ruediger,

Many thx for your reply.

> don't interfere with whatever chaos (you think) the operator is working with.

By chaos I meant complete autonomous selection of what paths are 
preferred to be chosen as best on an AS by AS basis. In the case of 
mixed SIGNED and UNSIGNED paths being consider in this _local_ decision 
as you stated it seems to me just like it is the case with bad 
uncorrelated policies more harm can be accomplished then good.

Are you guaranteeing that such local autonomy how to prefer signed vs 
unsigned paths is safe in the bigger picture ?

> Just provide the operator with trustworthy information

While signed BGP information may be made trustworthy I think the end 
goal is that your customers will get service they pay for meaning that 
their packets will reach the destination. How singed BGP updates are 
sufficient to accomplish such goal if anyone on the path by simple 
static route may overwrite directly in the data plane such trustworthy 
information and redirect your customer packets left and right without 
you knowing about it ?

Note that such overwrite would not happen if BGP would _always_ 
advertise only RIB/FIB active routes, but we all know that this is not 
always the case in some major implementations.

Regards,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Mar 2012 21:26:00 -0400

On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk <[email-masked]> wrote:
> By chaos I meant complete autonomous selection of what paths are preferred
> to be chosen as best on an AS by AS basis. In the case of mixed SIGNED and

how is the above any different that what happens today? (inside a
single ASN, each router decides what it thinks is 'best', hopefully
with a coordinated policy across all devices, but ... that is not
guaranteed!)

> UNSIGNED paths being consider in this _local_ decision as you stated it
> seems to me just like it is the case with bad uncorrelated policies more
> harm can be accomplished then good.

sure... should someone say: "ACHTUNG!! OPENZ PEEPERZ!! USE THE SAME
POLICY ON ALL DEVICES!!" ?

I think, I thought, I hope that the above message is (perhaps less
comically) stated to all network engineers when they graduate and get
their striped hats... (so thus NOT a required statement in an RFC-like
document)

-chris

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 22 Mar 2012 21:58:30 -0400

I think this question is more about what step in the route selection
process (rfc 4271, 9.1.2.2) at which to consider the verification state.

I would answer: nowhere.

The verification state should be used as an input to the policy.
For example, something for a route-map to match on.
The policy would then set another attribute, such as the
LOCAL_PREF or deny the path altogether.
It may also set a cost community as described in
draft-ietf-idr-custom-decision.

This resulting attribute would then be used in the route
selection process as normal.

Exactly how the verification state is used would be up
to the network operator. By default, it would not be
considered at all.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Thursday, March 22, 2012 6:26 PM
To: [email-masked]
Cc: [email-masked] list
Subject: Re: [sidr] Signed vs unsgned and bgp best path decision

-chris

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 23 Mar 2012 11:30:33 +0100

Chris,

I am talking about inter-domain policy not intra-domain. "ACHTUNG" may 
not help as folks around seem very reluctant to share their internal 
policies outside.

When compared to what is today I don't think folks are mandated by any 
RFC to make a choice between two attributes which carry the same metric 
to decide which one should win on a per AS basis.

Jakob,

> process (rfc 4271, 9.1.2.2) at which to consider the verification state.

Really ? Assume there is no policy set by the operator. You have 
received on your ASBR a net with two paths from two different upstreams. 
One SIGNED containing sequence of embedded paths with pCounts hacks and 
the other path with just old plane AS_PATH.

First you need to expand internally the signed path to mimic the old 
AS_PATH format for comparison (both length and content for multipath).

So you can't just clearly do nothing with the signed path - I hope we 
all agree on that.

Now let's talk policy. An operator would like to express his policy to 
mean: "PREFER SIGNED PATHS ONLY IF NOT LONGER THEN NOT SIGNED PATHS"

How do you express such policy with local_pref or with cost_community 
today ?

---

While I think it is very easy to say BGPSEC just works as enhancement to 
today's policy I think I have illustrated above that it is not right 
analogy in all case.

---

Also on the topic of other email reg replace-as functionality I 
described in http://goo.gl/7aT5c what is router supposed to do when it 
receives signed as_path and replace-as is in the in/out policy ?

Thx,
R.

> On Thu, Mar 22, 2012 at 7:28 PM, Robert Raszuk<[email-masked]>  wrote:

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 23 Mar 2012 06:44:28 -0400

On Fri, Mar 23, 2012 at 6:30 AM, Robert Raszuk <[email-masked]> wrote:
> Chris,
>
> I am talking about inter-domain policy not intra-domain. "ACHTUNG" may not
> help as folks around seem very reluctant to share their internal policies
> outside.

sure, interdomain policies today differ between domains... nothing
has/will change(d).

> When compared to what is today I don't think folks are mandated by any RFC
> to make a choice between two attributes which carry the same metric to
> decide which one should win on a per AS basis.

they are not, and in the future the 'mandate' is I believe a 'SHOULD',
not a 'MUST' so not really a 'mandate', but a 'suggestion', eh?

It seems that the intent of the effort here is really just to provide
an informational blob to the operators which they can use as they see
fit... much like other optional transitive attributes today.

-chris

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 23 Mar 2012 11:59:38 +0100

> fit... much like other optional transitive attributes today.

Ok that sounds very reasonable indeed.

However number of folks have stated that bgpsec protocol proposal calls 
for replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig 
attribute. In particular this text from 
/draft-ietf-sidr-bgpsec-protocol-02 sort of suggests that:

    The other option is that the BGPSEC speaker
    discards anything in the AS_PATH attribute and reconstructs the
    AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
    believe that there are no interoperability problems if the choice
    between these two options is left up to the BGPSEC speaker.

Also it says in the same section 5:

    One option the
    BGPSEC speaker checks the AS_PATH attribute against the information
    in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
    two do not match.

That means that if AS_PATH for example contains AS_SET that someone 
doing BGP multipath (across non identical paths) has correctly inserted 
into AS_PATH or as mentioned before did replace-as the update will be 
dropped as BGPSEC just can not handle those ....

Meta question:

Can optional attribute result in such drastic actions (nothing to do 
with operator's choice of local behavior) against mandatory attribute(s) ?

Best,
R.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 23 Mar 2012 07:32:54 -0400

On Fri, Mar 23, 2012 at 6:59 AM, Robert Raszuk <[email-masked]> wrote:
>>> RFC

progress!

> However number of folks have stated that bgpsec protocol proposal calls for
> replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig attribute. In
> particular this text from /draft-ietf-sidr-bgpsec-protocol-02 sort of
> suggests that:
>

'other option'

>   discards anything in the AS_PATH attribute and reconstructs the

I believe this means: "You could just ignore AS_PATH and reconstruct
the content there from ..."
(or that's how I read the clipping)

>   between these two options is left up to the BGPSEC speaker.

probably in this last sentence they mean "bgpsec listener" (since this
is on the receiver, not the sender?)

> Also it says in the same section 5:

'option'

> That means that if AS_PATH for example contains AS_SET that someone doing
> BGP multipath (across non identical paths) has correctly inserted into
> AS_PATH or as mentioned before did replace-as the update will be dropped as
> BGPSEC just can not handle those ....

sure. 'option' I don't think if there were an AS_SET in the update
coming from the BGPSEC speaking peer there would be sig parts to worry
about (since the inclusion of AS_SET means you can't secure the
path...So, I suppose if this condition exists the path is invalid by
default? and likely spoof/bad/malicious?)

>
>
> Meta question:
>
> Can optional attribute result in such drastic actions (nothing to do with
> operator's choice of local behavior) against mandatory attribute(s) ?

I think you created a situation which is actually in violation of the
standard... or which would be seen as a malicious update and which
should be dropped, so I'm not sure your meta-question follows properly
here?

-chris