Subject: [sidr] request for agenda items for interim meeting 6 Jun

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 16 May 2012 22:05:17 +0000

Potential agenda items for the 6 Jun interim meeting.

The agenda needs to be announced two weeks ahead of time, which is next Wednesday.

Please send suggested topics to the list.  Below are two suggestions to spark the discussion.

(1) AS_PATH

There was one agenda topic that we never directly addressed at the 30 Apr meeting.  That topic was the absence of the AS_PATH attribute from the bgpsec protocol.  (The info normally contained in the AS_PATH is contained in the bgpsec attributes.)

The absence of the AS_PATH did come up in discussing other topics (see the minutes), but we did not discuss it directly.

(2) router private key provisioning.

In the interim in San Diego, there were requests (from operators) that guidance to operators of how to provision a router with the needed keys would be a good idea.   We had some discussion in the Paris meeting of two drafts discussing provisioning the routers with their needed private keys.  There's also been a recent flurry of discussion on the list.

--Sandy, speaking as wg co-chair

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 21 May 2012 22:27:00 +0000

Agenda deadline is Wed 23 Jun (day after tomorrow).

Please send suggestions to the list.

--Sandy, speaking as wg co-chair
________________________________________
From: [email-masked] [[email-masked]] on behalf of Murphy, Sandra [[email-masked]]
Sent: Wednesday, May 16, 2012 6:05 PM
To: [email-masked]
Subject: [sidr] request for agenda items for interim meeting 6 Jun

(1) AS_PATH

--Sandy, speaking as wg co-chair
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 22 May 2012 14:08:25 +0000

An eagle eye reader points out that the agenda deadline before the June meeting is in May, not June, and the day after tomorrow is still May, not June.

Still.  Get any requests for topics in asap.  Agenda deadline is Wed 23 May (tomorrow).

--Sandy, speaking as wg co-chair
________________________________________
From: [email-masked] [[email-masked]] on behalf of Murphy, Sandra [[email-masked]]
Sent: Monday, May 21, 2012 6:27 PM
To: [email-masked]
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun

(1) AS_PATH

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 May 2012 07:52:31 -0700

Hi WG,

> Still.  Get any requests for topics in asap.  Agenda deadline is Wed 23 May (tomorrow).

I would like to add to this: if there are no topics to discuss, chairs reserve the right to cancel the interim. So in absence of new topics, some confirmation that what Sandy suggested as the agenda earlier would be good.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 22 May 2012 11:21:43 -0400

> I would like to add to this: if there are no topics to discuss, chairs reserve the right to cancel the interim. So in absence of new topics, some confirmation that what Sandy suggested as the agend…

Well, color me stoopid -- I have not been able to find "what Sandy suggested as the agenda earlier".

'tis not (AFAICS) on the wiki, the Interim Announcement doesn't have nothing agenda like, the list doesn't seem to have anything, etc.

W

-- 
With Feudalism, it's your Count that votes.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 May 2012 08:38:36 -0700

Hi,

> Well, color me stoopid -- I have not been able to find "what Sandy suggested as the agenda earlier".

Below (quoted text) :-)

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 22 May 2012 15:38:34 +0000

See the message from last week:

http://www.ietf.org/mail-archive/web/sidr/current/msg04632.html

Registration and location details will be on the wiki soon.

--Sandy

________________________________________
From: Warren Kumari [[email-masked]]
Sent: Tuesday, May 22, 2012 11:21 AM
To: Alexey Melnikov
Cc: [email-masked]; Murphy, Sandra
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun

W

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 22 May 2012 11:54:57 -0400

Sandy,

In my opinion the biggest open issue in the bgpsec protocol draft is the 
confederation issue that we discussed at the previous interim. (That is, 
if we don't include AS4_Path or AS_Path in a bgpsec signed update, then 
we need to somehow encode the information that would be in the 
AS_confed_sequence segments of the AS_Path.) At the April interim there 
were three possible solutions that people put forward to address this 
issue. However, we didn't decide on what was the best way forward. Now 
that people have had some more time to think about the issue, I would 
very much like to try and reach concensus at the Vancouver interim so 
that  we can close this issue. If it would be helpful, I'm happy to 
throw together a few slides for the interim summarizing the problem and 
the possible solutions discussed at the April interim.

Also, recently submitted a new version of 
draft-ietf-sidr-bgpsec-protocol (the -03 version). This document has 
significant changes from the (-02) version. Most, if not all of the 
changes were discussed at the Paris sidr meeting, so it probably isn't 
necessary to present them again. However, I would encourage anyone who 
is able to read Section 3 (the format for the BGPSEC_Path_Signatures 
attribute) of  the -03 version before Vancouver. There may be places in 
the draft where the foolish document editor failed to produce text that 
reflects what the working group agreed to in Paris, and it would be good 
to get those issues (if they exist) resolved sooner rather than later.

- Matt Lepinski

---

From: Warren Kumari <[email-masked]>
Date: Tue, 22 May 2012 11:59:13 -0400

>> Well, color me stoopid -- I have not been able to find "what Sandy suggested as the agenda earlier".

Ok, color me *very stooped* then -- my mail client helpfully collapsed the earlier stuff and hid it under a "See more…" label…

Apologies for the grumpy tone, going to go hide under a rock now…

Oh, and the agenda looks good to me…

W

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 May 2012 06:25:05 +0900

> AS_confed_sequence segments of the AS_Path.)

i thought we were cheerily dumping as_confed_seq and thereby getting rid
of the last sequence.  essentially 
  o you are at the border about to send to an external peer
  o stepping back down the sigs, possibly zero times
  o there will be a sig from an external peer to the confed as
  o strip off all sigs subsequent to that one, if any
  o sign from the confed as to the external peer

randy

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 22 May 2012 17:46:30 -0400

Randy,

Personally, I'm fine with the solution you outlined.

However, I didn't think that everyone in the room for the last interim 
was on-board with this. That being said, I wasn't in the room, so I'm 
not a good one to gauge consensus (or lack there of) ... I guess it 
wasn't clear to me from the minutes whether or not this issue was 
resolved, so I didn't stick into the -03 version of the document.

Note: If this issue is indeed resolved, then I'm happy to put the 
solution in the -04 version of the document.

Other than confeds are there any other potentially open issues related 
to the removal of AS_Path?

- Matt Lepinski

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 May 2012 06:55:54 +0900

> was on-board with this.                     ^logical 

well, i definitely look forward to reading a bright(er) idea on list.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 22 May 2012 18:13:17 -0400

In addition to the items suggested so far, I think we should also spend some time on 
performance considerations and resource sizing requirements for a BGPSEC router.
 
Some of the performance and resource sizing questions are:

Q1: What is an acceptable convergence time after a BGPSEC peering session reset? 
(See Wes George's question (in Paris) and some thoughts shared by Geoff with me below.)
 
Q2: What degree of peering is reasonable to assume for various router scenarios 
such as Provider Edge (PE), Route Reflector (RR), Route Server (RS), etc.? 
(The convergence time and the RIB size would naturally depend on the number 
of BGPSEC peering sessions that the PE, RR, or RS needs to handle.)

Q3: Is there any difference in how the RIBs (RIB-in, RIB-out, etc.) are managed at a 
RR or RS as compared to how it is done at the PE router? 

Q4: Is a large percentage of the clients of an RS consists of stub routers, i.e., 
they do not require signed updates in receive direction?

I did get some inputs on PE and RR peering degrees from a large Tier 1 ISP 
and used them in my RIB modeling work earlier. It would be good to revisit this 
and try to get a good handle on such measurements for PE, RR, and also RS. 
See slide 4 of this study (I did about a year ago) for the measurement 
numbers I got from the large Tier 1 ISP. 

http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf 

They shared the numbers for their typical PE and RR.
(They actually did not share # peerings exactly but simply the measurements 
of the # total paths and the # unique prefixes at their PE and their RR.)  

I have the following notes to tease a discussion based on some earlier 
questions/conversations at the Paris meeting:

Wes George (question at the Paris SIDR meeting): Are the 30 sec and 70 sec type 
of numbers (for convergence after BGPSEC peering reset) small enough?  May not be.
(This question followed my presentation:
http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf )

As a counter point, Geoff shared the following with me during a coffee break (in Paris): 
[Note: I think I am stating the intent of his comments correctly; I request Geoff to 
jump in if this does not capture accurately enough what he shared with me.]
The way to think about those delays is that the data packets 
would traverse a possibly suboptimal path for the period of T seconds or minutes -- 
whatever the BGPSEC re-convergence delay number is -- 
but they are not dropped on the floor. That is a property of BGP.
The data packets may incur a small extra delay due to the suboptimal path 
for that (BGPSEC re-convergence) period, and most of the time 
users don't even notice that extra data packet delay (if any) at the application layer. 

Sriram

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 May 2012 07:08:51 +0900

> (1) AS_PATH
> 
> There was one agenda topic that we never directly addressed at the 30
> Apr meeting.  That topic was the absence of the AS_PATH attribute from
> the bgpsec protocol.  (The info normally contained in the AS_PATH is
> contained in the bgpsec attributes.)

well, actually, the discussion in april was walking around many of the
implications thereof.  it is hard to discuss "do we keep/replace
AS[4]_PATH" as it is abstract and draws deep philosophical discourse
with no hard handles on technical decision points.

otoh, i would be really interested in hearing/discussing if anyone sees
any show-stoppers to the current draft doing so.

i am amused that the current draft says, in the intro,

   2.  Every AS listed in the AS_Path attribute of the update explicitly
       authorized the advertisement of the route to the subsequent AS in
       the AS_Path.

when there is no bgpsec as_path. :)

> The absence of the AS_PATH did come up in discussing other topics (see
> the minutes), but we did not discuss it directly.

see above

> In the interim in San Diego, there were requests (from operators) that
> guidance to operators of how to provision a router with the needed
> keys would be a good idea.  We had some discussion in the Paris
> meeting of two drafts discussing provisioning the routers with their
> needed private keys.  There's also been a recent flurry of discussion
> on the list.

no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt.
would appreciate some now or we can ask for wglc.

there have been no comments on list to confed and aliasing.  may we call
them done?

randy

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 May 2012 18:54:29 -0600

Randy,

> there have been no comments on list to confed and aliasing.  may we call

Can you expound more what you mean by "aliasing" above?  Do you mean local-as, etc. 'hacks' to the AS_PATH attribute?

-shane

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 May 2012 09:55:57 +0900

>> there have been no comments on list to confed and aliasing.  may we
>> call them done?
> 
> Can you expound more what you mean by "aliasing" above?  Do you mean
> local-as, etc.

yep

randy

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 May 2012 19:04:34 -0600

>> Can you expound more what you mean by "aliasing" above?  Do you mean

That's strange.  Why doesn't the following comment to the list back in March of this year count as "no comments on list to ... aliasing"?
http://www.ietf.org/mail-archive/web/sidr/current/msg04093.html

-shane

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 May 2012 10:08:53 +0900

> That's strange.  Why doesn't the following comment to the list back in
> March of this year count as "no comments on list to ... aliasing"?

it counted so much we spent a good bit of time on it in the april
meeting.  we, possibly foolishly, thought we had local convergence.

randy

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 May 2012 19:14:28 -0600

> meeting.  we, possibly foolishly, thought we had local convergence.

For those of us who did not attend the April interim meeting, can you point to where the list was asked if they agreed with the "local convergence"?

-shane

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 May 2012 10:18:43 +0900

>>>>> Can you expound more what you mean by "aliasing" above?  Do you
>>>>> mean local-as, etc.
>>>> yep
>>> That's strange.  Why doesn't the following comment to the list back
>>> in March of this year count as "no comments on list to ...
>>> aliasing"?
> For those of us who did not attend the April interim meeting, can you
> point to where the list was asked if they agreed with the "local
> convergence"?

i thought i just did that :)

but, to be fair, i find the minutes lacking, to be kind.  and this is
really the chairs' job.  and i am nose deep in tex with a journal paper
drealine tomorrow.

randy

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 May 2012 21:50:18 -0600

> really the chairs' job.  and i am nose deep in tex with a journal paper

I did look through the minutes and would agree that they are "lacking".  Although I see some discussion of the issue under the "AS aliasing Replace AS Local AS" and "Replace as - AS migration" sections, on p. 7, all I (mainly) see are: "One way is use pcount=0" and "Going to have to be knob".  It's unclear, to me, if there were (are?) other suggested solutions made and/or how the pCount=0 suggestion is thought to work, in practice.  Are these written down in detail somewhere in a draft, ideally, or in the mean time can the WG chairs, or folks who suggested the idea(s), share them with the list?  In particular, I'm curious about the potential security implications of now allowing anyone to turn on this "feature" and allowing them to dump anything they want into the BGPSEC_Path_Signature attribute, (assuming that any ASN they put in with pCount=0 in the BGPSEC_Path_Signature has valid signatures of course).

Thanks,

-shane

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 24 May 2012 09:07:08 +0000

Randy,

> with no hard handles on technical decision points.

I think you should remove the [4] from the discussion. 4 bytes ASN is mandatory for BGPSEC speakers. So, there should be no AS4_PATH attributes between BGPSEC routers to keep/replace.

Roque

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 May 2012 18:18:15 +0900

>> well, actually, the discussion in april was walking around many of
>> the implications thereof.  it is hard to discuss "do we keep/replace
> I think you should remove the [4] from the discussion. 4 bytes ASN is
> mandatory for BGPSEC speakers. So, there should be no AS4_PATH
> attributes between BGPSEC routers to keep/replace.

i agree.  but every time i say AS_PATH someone whacks me with AS4_PATH.
maybe this is why i like the NO_EXPLICIT_PATH :)

randy

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 24 May 2012 12:16:25 +0000

> maybe this is why i like the NO_EXPLICIT_PATH :)

well, you are normally consistent at asking people to read the documents :-).

r.

---

From: "George, Wes" <[email-masked]>
Date: Thu, 24 May 2012 09:19:56 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Wednesday, May 23, 2012 6:09 PM
> To: Murphy, Sandra
> Cc: [email-masked]

[WEG] We're again having an interim collocated with NANOG, ostensibly to gain additional operator participation (as well as batch travel).
However, in order to gain any benefit from the location, we probably need to publicize the interim on the NANOG list, though the window for doing it before travel plans are made is probably closing/closed.
Wasn't it on the NANOG agenda in SD? It's not this time...
It may even be useful to have a set of questions to fire off in a lightning talk regarding the things we plan to discuss in more detail over the course of the interim, so that people who have opinions on the matters can weigh in.

Wes George

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

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 24 May 2012 15:38:54 -0400

> Wasn't it on the NANOG agenda in SD? It's not this time...

I sent a note to the nanog list... hopefully folk will be able to
attend either physically or virtually.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 14:21:33 -0400

On May 22, 2012, at 5:46 PM, Matt Lepinski wrote:

> Other than confeds are there any other potentially open issues related to the removal of AS_Path?

(I think this just recapitulates what I said at the interim, but maybe it's worth saying again for the list.)

Philosophically, the thing that makes me worry the most is that we're cutting out one of BGP's fundamental elements and replacing it with one which provides only a subset of its semantics. Specific things missing include:

- Confederations. But we are discussing ways to fix this.
- Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementations will treat them as fatal errors.

And actually, that's it for my list of specifics. I think we can check off the "done, in principle" box for confeds. So the remaining issue is extensibility. One may or may not find the "extensibility doesn't work anyway" argument compelling, I'm not entirely sure *I* do. In any case, I think this deserves a good airing before we commit.

The other issue is one Shane already brought up on this thread -- the fact that some of the more egregious AS_PATH editing hacks that exist in the wild may not be supportable in the AS_PATH-less new world order. (Many of the less egregious ones seem to be OK with appropriate pcount gyrations.) The pros and cons are a bit slippery here since even if we continue to carry AS_PATH, if the BGPSEC_Path_Signatures attribute can't represent the semantics of what's in that AS_PATH, then validation will fail. But at least there's scope for a network operator on the receiving end to tolerate the validation failure and use the route anyway, if desired. In the case where there's no AS_PATH, the data are just gone with no chance for appeal. 

It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH clearly could have been left out. In the remaining cases, what is the implementation supposed to do? It would be necessary to carefully specify. The easiest cop-out would be to say that in all such cases, the route fails validation. But I have a feeling that it's not that easy. Leaving AS_PATH out reduces that particular maze of twisty passages, although it replaces it with another: making sure it was really OK to axe AS_PATH to begin with (i.e., the discussion above).

I'm going to forward this to IDR to ensure that those who aren't following SIDR are aware there's a proposal to phase out AS_PATH in favor of a simplified replacement in BGPSEC. 

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 14:24:50 -0400

IDR folks,

BGPSEC (in the SIDR WG) includes a path attribute, BGPSEC_Path_Signatures, that substantially overlaps the semantics of AS_PATH. For reasons discussed in the forwarded note below, it proposes that updates carrying BGPSEC_Path_Signatures should NOT carry AS_PATH. 

Since this would represent a fairly major change to the protocol, I wanted to make sure those not following SIDR were aware of it. Please cross-post any comments to [email-masked].

(See http://tools.ietf.org/html/ietf-sidr-bgpsec-protocol-03 Section 3.)

--John

Begin forwarded message:

> From: "John G. Scudder" <[email-masked]>
> Date: May 29, 2012 2:21:33 PM EDT
> To: Matt Lepinski <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 17:22:04 -0400

> It's also worth noting that leaving AS_PATH in would not be without cost. In the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Path_Signatures, there's no problem -- but in tho…

In an offline follow-up with Robert Raszuk, he pointed out that when one applies a knob that results in an AS_PATH that can't be represented as a BGPSEC_Path_Signatures [*] there is a third option, that of downgrading from BGPSEC to unsigned BGP. That is to say, you convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to the AS_PATH, and propagate the route with the AS_PATH and not the BGPSEC_Path_Signatures. This is functionally equivalent to "in all such cases, the route fails validation" but is more straightforward and seems to make a lot of sense: everything that can be represented signed, should be. If you insist on doing something that can't be signed, you can fall back to unsigned BGP and hope for the best.

This leaves me feeling a little more sanguine about the drop-the-AS_PATH idea, although I still think some more attention to enumerating what knobs will fall by the wayside is advisable. 

--John

[*] The name of this attribute makes for awkward prose since it has no natural singular. How about calling it BGPSEC_Path_Signature instead? Or Signed_Path or Signed_AS_Path sans brand name?

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 29 May 2012 17:23:00 -0400

[Once more from proper account, sigh.]

--John

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 May 2012 08:45:39 +0900

> This leaves me feeling a little more sanguine about the
> drop-the-AS_PATH idea, although I still think some more attention to
> enumerating what knobs will fall by the wayside is advisable.

as folk keep inventing new knobs, one question would seem to be whether
the knob inventors will understand and accept the trust/threat model
implications of knobs which force downgrade to non-sec.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 29 May 2012 20:01:42 -0400

AS_PATH is used to specify the path that the payload takes.
Signed_AS_PATH is to verify the path that the update message takes.

There is no reason they can not be different. Let the verifying
function take both as input and let it decide based on policy.

An AS could forward an update with a third party nexthop of a third
party AS. The update message does not need to traverse the third
party AS at all, but the payload will. The third party ASN might just
be another ASN that the first party is using: it might be renumbering.
The first party might like to include the third party ASN for
loop detection.

I don't have a specific feature in mind. Just "what if".

On Tuesday, May 29, 2012 2:22 PM, John G. Scudder <> wrote:

>> It's also worth noting that leaving AS_PATH in would not be without
>> cost. In the cases where the content of AS_PATH is isomorphic to
>> that of BGPSEC_Path_Signatures, there's no problem -- but in those
>> cases AS_PATH clearly could have been left out. In the remaining
>> cases, what is the implementation supposed to do? It would be
>> necessary to carefully specify. The easiest cop-out would be to say
>> that in all such cases, the route fails validation. But I have a
>> feeling that it's not that easy. Leaving AS_PATH out reduces that
>> particular maze of twisty passages, although it replaces it with
>> another: making sure it was really OK to axe AS_PATH to begin with
>> (i.e., the discussion above).          
> 
> In an offline follow-up with Robert Raszuk, he pointed out that when
> one applies a knob that results in an AS_PATH that can't be
> represented as a BGPSEC_Path_Signatures [*] there is a third option,
> that of downgrading from BGPSEC to unsigned BGP. That is to say, you
> convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to
> the AS_PATH, and propagate the route with the AS_PATH and not the
> BGPSEC_Path_Signatures. This is functionally equivalent to "in all
> such cases, the route fails validation" but is more straightforward
> and seems to make a lot of sense: everything that can be represented
> signed, should be. If you insist on doing something that can't be
> signed, you can fall back to unsigned BGP and hope for the best.     
> 
> [*] The name of this attribute makes for awkward prose since it has
> no natural singular. How about calling it BGPSEC_Path_Signature
> instead? Or Signed_Path or Signed_AS_Path sans brand name

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 May 2012 09:29:23 +0900

> AS_PATH is used to specify the path that the payload takes.

really?  i thought it was a routing loop detection mechanism.
it's been a while since folk wrote research papers describing
schemes for routing by AS.

i would phrase it as

AS_PATH specifies the ASs through which the routing announcement has
passed.

> Signed_AS_PATH is to verify the path that the update message takes.

and then this works really nicely.

> There is no reason they can not be different.

and here i thought that detecting that they differ, as an attack, is the
core goal of as-path validation.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 29 May 2012 20:47:36 -0400

On Tuesday, May 29, 2012 5:29 PM, Randy Bush <mailto:[email-masked]> wrote:

> and here i thought that detecting that they differ, as an attack, is
> the core goal of as-path validation.

I thought it was to prevent an AS from
announcing an update that it was not authorised  to.

An entirely different thing.

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 May 2012 09:52:05 +0900

> I thought it was to prevent an AS from announcing an update that it
> was not authorised to.

nope.  that is rpki-based origin validation.  we are now talking about
as-path validation.

from a note to some gov folk:

To be clear, as people keep calling BGP security 'RPKI'

In the current taxonomy, there are three pieces, the RPKI, RPKI-based
origin validation, and then path validation.

RPKI is the X.509 based hierarchy with is congruent with the internet IP
address allocation administration, the IANA, RIRS, ISPs, ...  It is the
substrate on which the next two are based.  It is currently deployed in
four of the five administrative regions, ARIN in North America being the
sad and embarrassing exception.

RPKI-based origin validation uses some of the RPKI data to allow a
router to verify that the autonomous system announcing an IP address
prefix is in fact authorized to do so.  This is not crypto checked so
can be violated.  But it prevents the vast majority of accidental
'hijackings' on the internet today, e.g. the famous Pakastani accidental
announcement of YouTube's address space.  RPKI-based origin validation
is in shipping code from Cisco, and will be shipping by Juniper soon.

Path validation uses the full crypto information of the RPKI to make up
for the embarrassing mistake that, like much of the internet BGP was
designed with no thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to formally
cryptographically validate that the originating autonomous system was
truely authorized to announce the IP address prefix, and that the
systems through which the announcement passed were indeed those which
the sender/forwarder at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 29 May 2012 21:05:59 -0400

On Tuesday, May 29, 2012 5:52 PM, Randy Bush <mailto:[email-masked]> wrote:

> RPKI is the X.509 based hierarchy with is congruent with the internet
> IP address allocation administration, the IANA, RIRS, ISPs, ...  It
> is the substrate on which the next two are based.  It is currently
> deployed in four of the five administrative regions, ARIN in North
> America being the sad and embarrassing exception.
> 
> 'hijackings' on the internet today, e.g. the famous Pakastani
> accidental announcement of YouTube's address space.  RPKI-based
> origin validation 
> Path validation uses the full crypto information of the RPKI to make
> up for the embarrassing mistake that, like much of the internet BGP
> was designed with no thought to securing the BGP protocol itself from
> being gamed/violated.  It allows a receiver of a BGP announcement to
> formally cryptographically validate that the originating autonomous
> system was truely authorized to announce the IP address prefix, and
> that the 

Apology accepted.
Note, I said "announcing", not "originating".

Here is my view of the difference:

Origin validation does not stop anyone from announcing an update.
It only requires the first AS in that update to be the
owner of the prefix.

Path validation prevents anyone from announcing an update unless
it was sent to them by an authorised AS. And they are authorised,
because it was sent to them by an authorised AS and so on, back
to the authorised originator.

-- 
Jakob Heitz.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 May 2012 14:01:37 +0200

Let's observe that mangling with AS_PATH is usually done for a reason .. 
to achieve reachability to some set of prefixes which otherwise would be 
dropped.

So with this in mind a better question to think about from customer 
perspective is to choose either:

- unsecure but reachable Internet destinations
- secure Internet routing but unreachable destinations

Rgs,
R.

PS. I believe I have a solution to address both sides. Let me write it 
up and share in a week or two.

> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 May 2012 10:06:57 -0400

Randy,

Thanks for the nicely articulated description of these elements of routing
security work in  SIDR.

Steve

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 30 May 2012 16:10:16 +0000

Speaking as regular ol' wg member:

Thanks for all of this John.  Excellent thoughts.

>Philosophically, the thing that makes me worry the most is that we're 
>cutting out one of BGP's fundamental elements and replacing it with one 
>which provides only a subset of its semantics. Specific things missing 
>include:

I'm very interested in exploring semantics of the AS_PATH that the signature attribute does not capture.

As for the particular uses you note:

>- Extensibility to include new segment types. In principle this is a fairly 
>serious omission, but one can argue that new segment types can't be 
>introduced in practice, since existing implementations will treat them 
>as fatal errors.

As you note, there was a good discussion at the Apr 30 interim about confederations.  We probably need to document it, a minor question being where it belongs (what document).

About extensibility - as you say, any new segment type not built into implementations would result in fatal errors.  So any new segment type would need to be built into implementations before use.  The question then becomes - can the signature attributes also be augmented at the same time to deal with the new segment types?

If a new segment type has a trust model, then there could be a simultaneously developed new security attribute to protect it.  If the new type's trust model matches the existing AS_PATH trust model, then new protections could be a new type or version of the existing  signature attribute.

So the AS_PATH extensibility could be maintained in the security protections - as long as the new extension is "protectable".

>The other issue is one Shane already brought up on this thread -- 
>the fact that some of the more egregious AS_PATH editing hacks 
>that exist in the wild may not be supportable in the AS_PATH-less 
>new world order. 

I am quite sure I don't know the complete list of AS_PATH knobs!

But some of those I do know are hacks that would allow attacks as well.  The fact that the security protections prohibit the attacks is a good thing.  If there's a way to identify good, not evil, uses, then we can design for that.  But in cases where there's no real way to distinguish the good from the evil, we're in a hard place.  Shoot a hole in the protection to allow the hack or prohibit the hack.

--Sandy, speaking as regular ol' wg member

________________________________________
From: [email-masked] [[email-masked]] on behalf of John G. Scudder [[email-masked]]
Sent: Tuesday, May 29, 2012 2:21 PM
To: Matt Lepinski
Cc: [email-masked] list
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun

--John

---

From: Matt Lepinski <[email-masked]>
Date: Wed, 30 May 2012 13:18:30 -0400

Roque,

Yes, there has been some confusion about AS4_Path, I think my text in 
the protocol draft (both the current version, but especially in previous 
versions) is in part responsible for this.

I agree that even if we included AS_Path in BGPSEC update messages 
BGPSEC speakers MUST support 4-byte AS numbers and so there would never 
be any reason to include AS4_Path. My apologies for lack of clarity in 
the spec, I'll attempt to remove any lingering ambiguity in the next 
update to the draft.

- Matt Lepinski

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 30 May 2012 16:52:19 -0400

[added IDR to cc]

On May 30, 2012, at 12:10 PM, Murphy, Sandra wrote:

...
> About extensibility - as you say, any new segment type not built into implementations would result in fatal errors.  So any new segment type would need to be built into implementations before use.…
...
> So the AS_PATH extensibility could be maintained in the security protections - as long as the new extension is "protectable".

OK, as long as it's practical to extend the BGPSEC_Path_Signatures attribute. I confess to not having given this much thought but it doesn't appear to be as easily extensible as AS_PATH, because the latter has a TLV structure and the former doesn't. I guess your answer is that since AS_PATH extensions are in practice a big deal, you'll just introduce a new, incompatible format of BGPSEC_Path_Signatures to match? If this is the plan, BGPSEC_Path_Signatures should include a version number, since it would be a little rude to consume another code point from the one-byte BGP path attribute code point space for this purpose. Also, for generality you'll need to think about whether you want to be able to support different subsets of extensions -- this is easy in a TLV-encoded attribute but hard if all you've got is a version number. (Another answer might be that Additional_info will serve as the extensibility placeholder, but if so its length field is too small.)

...
> I am quite sure I don't know the complete list of AS_PATH knobs!

Nor do I, from memory. But we probably should plan to enumerate a list of them so that we can categorize them as "we can do this", "this is formally an attack and therefore will never be supported", or "other", and then iterate on "other".

> But some of those I do know are hacks that would allow attacks as well.  The fact that the security protections prohibit the attacks is a good thing.  If there's a way to identify good, not evil, u…

Right, and agreed (see "formally an attack" above). But to repeat my further point, if the AS_PATH is present (even if not secured): "at least there's scope for a network operator on the receiving end to tolerate the validation failure and use the route anyway, if desired. In the case where there's no AS_PATH, the data are just gone with no chance for appeal."

--John

---

From: Russ White <[email-masked]>
Date: Wed, 30 May 2012 19:07:08 -0400

>> Signed_AS_PATH is to verify the path that the update message takes.

....

> core goal of as-path validation.

Okay, I seem to be confused. The AS Path isn't about where the update
has passed through, but the same attribute, when signed, is a mechanism
to provide security. And while the AS Path isn't about showing the path
of the update or the traffic, when it doesn't match the new attribute
that is supposed to show the path of the update this means there is an
attack of some sort.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 30 May 2012 20:02:44 -0400

>
>Right, and agreed (see "formally an attack" above). But to repeat my further
>point, if the AS_PATH is present (even if not secured): "at least there's scope for a
>network operator on the receiving end to tolerate the validation failure and use
>the route anyway, if desired. In the case where there's no AS_PATH, the data are
>just gone with no chance for appeal."
>

John,

I do not agree that in the event of "validation failure" the route becomes unusable
in BGPSEC as currently specified.
The operator has a choice to consider and select a route as best path (or as add-path)
even if the update failed validation or validation was deferred.
(Note: Validation may not be deferred sometimes due to 
processor overload, or known RPKI staleness, etc.)

You seem to be suggesting that when there is "validation failure",
then "BGPSEC_Path_Signatures" as whole is unusable. 
That is not the case.

"BGPSEC_Path_Signatures" is just a name given to the outer shell of
the BGPSEC update. (BGPSEC need not give the outer shell any name at all.) 
Within it, we have these segments: Secure_Path, Sig_Block, and Additional_Info.
Each of these segments has its own proper semantics.
Even if the Sig_Block were to have an invalid signature, 
the Secure_Path segment is still usable as it provides the AS path info.
If the operator chose an _Invalid_ update for lack of a better choice, 
then it is still the Secure_Path that provides the AS path info,
and also the update SHOULD be signed and propagated to other BGPSEC peers.
Also, if a specific eBGP neighbor is a non-bgpsec speaker, then the selected
BGPSEC update (valid or invalid) is converted to a regular BGP-4 update wherein 
the AS_PATH attribute is constructed from the Secure_Path. 
So validation failure in BGPSEC does not mean that "the data are just gone."

In fact, for clarity sake I would like to suggest that in the spec we consider
Secure_Path, Sig_Block, and Additional_Info as distinct BGPSEC attributes.
(That is to say we should not lump them together as one attribute.)

Sriram

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 May 2012 13:34:46 -0400

Missed one:

>> - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementatio…

- AS_SETs. SIDR has decided not to support these, and IDR has published RFC 6472 / BCP 172 "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP". Nonetheless, they remain part of the protocol and have not (yet) been formally deprecated, so I mention them for completeness.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 May 2012 13:31:29 -0400

> So validation failure in BGPSEC does not mean that "the data are just gone."

My point is not that validation failure causes this. It's that absent AS_PATH, a semantically non-representable AS_PATH will be lost if forced through BGPSEC_Path_Signatures.

To reiterate, the options to address the case where a feature wants to produce output that can't be represented in BGPSEC_Path_Signatures are:

- Don't solve it. Effectively forbid any such feature.
- Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules for reconciliation would be required.
- Downgrade BGPSEC update to BGP update. 
- Extend BGPSEC_Path_Signatures format to be able to represent the needed feature. (As Sandy noted, this only makes sense insofar as the feature isn't formally an attack, so this option is incomplete.)

The validation failure I spoke of is a potential *consequence* of the middle two options above, and as you say, the operator can then decide what to do.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 May 2012 13:37:57 -0400

[Sigh. Again with the right source email address.]

Missed one:

--John

---

From: Russ White <[email-masked]>
Date: Thu, 31 May 2012 19:17:02 -0400

>>> - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementati…

Doesn't this also impact 2 octet to 4 octet transition?

IMHO, this is a huge problem --much larger than we might imagine at this
particular moment in time.

Russ

-- 
<><
[email-masked]
[email-masked]