Subject: [Idr] draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr

From: "John G. Scudder" <[email-masked]>
Date: Thu, 20 Sep 2012 19:38:15 -0400

Folks,

FYI draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr. This draft, assuming it progresses, represents a significant update to the BGP protocol, notably in terms of AS_PATH handling. If you haven't looked at it already, please consider taking the time to do so. 

Comments should go to both the [email-masked] and [email-masked] mailing lists.

There has already been some discussion of the draft on the sidr mailing list. Archives are here http://www.ietf.org/mail-archive/web/sidr/current/msg05062.html

--John

P.S.: If you intend to review it but need more time, please speak up, and say how much more time you will need.

Begin forwarded message:

> From: "Murphy, Sandra" <[email-masked]>
> Subject: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05
> Date: September 15, 2012 7:45:13 AM EDT
> To: "[email-masked]" <[email-masked]>
> 
> This starts a working group last call for draft-ietf-sidr-bgpsec-protocol-05.  The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
> 
> Please review this draft to see if you think it is ready for publication.  Send end comments to the list.  
> 
> The WGLC will end on 29 September 2012.
> 
> --Sandy, speaking as wg co-chair
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Sep 2012 07:59:04 +0200

Hi John,

The proposal of dropping AS_PATH and the intention to completely replace 
it with AS_SEC_PATH attribute has been negatively commented so many 
times in the past both on idr and sidr that by bringing just one thread 
below seems like erasing all other comments.

The issues are not only related to routing .. they are also related to 
number of BGP monitoring stations deployed today which use AS_PATH 
attribute for real time BGP analysis. Do you expect all of those tools 
to change/be updated when IETF will publish path validation RFC ?

To only bring few past comments:

http://www.ietf.org/mail-archive/web/sidr/current/msg04693.html
http://www.ietf.org/mail-archive/web/sidr/current/msg04695.html
http://www.ietf.org/mail-archive/web/sidr/current/msg04701.html
http://www.ietf.org/mail-archive/web/sidr/current/msg04721.html
http://www.ietf.org/mail-archive/web/sidr/current/msg04722.html

Regards,
R.

> Folks,
>
> FYI draft-ietf-sidr-bgpsec-protocol-05 being WGLC'd in sidr. This
> draft, assuming it progresses, represents a significant update to the
> BGP protocol, notably in terms of AS_PATH handling. If you haven't
> looked at it already, please consider taking the time to do so.
>
> There has already been some discussion of the draft on the sidr
> mailing list. Archives are here
> http://www.ietf.org/mail-archive/web/sidr/current/msg05062.html
>
> --John
>
> P.S.: If you intend to review it but need more time, please speak up,
> and say how much more time you will need.
>
> Begin forwarded message:
>
>> From: "Murphy, Sandra" <[email-masked]> Subject: [sidr]
>> WGLC for draft-ietf-sidr-bgpsec-protocol-05 Date: September 15,
>> 2012 7:45:13 AM EDT To: "[email-masked]" <[email-masked]>
>>
>> This starts a working group last call for
>> draft-ietf-sidr-bgpsec-protocol-05.  The draft is available at
>> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-05 and
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>>
>> Please review this draft to see if you think it is ready for
>> publication.  Send end comments to the list.
>>
>> _______________________________________________ sidr mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sidr
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Neil J. McRae" <[email-masked]>
Date: Fri, 21 Sep 2012 06:27:39 +0000

+1 not clear that this change is valuable I are no need to replace AS_PATH at all.

Sent from my iPhone

On 21 Sep 2012, at 06:59, "Robert Raszuk" <[email-masked]> wrote:

> Hi John,
> 
> The proposal of dropping AS_PATH and the intention to completely replace it with AS_SEC_PATH attribute has been negatively commented so many times in the past both on idr and sidr that by bringing just one thread below seems like erasing all other comments.
> 
> The issues are not only related to routing .. they are also related to number of BGP monitoring stations deployed today which use AS_PATH attribute for real time BGP analysis. Do you expect all of those tools to change/be updated when IETF will publish path validation RFC ?
> 
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 05:07:57 -0400

On Fri, Sep 21, 2012 at 1:59 AM, Robert Raszuk <[email-masked]> wrote:
> Hi John,
>
> The proposal of dropping AS_PATH and the intention to completely replace it
> with AS_SEC_PATH attribute has been negatively commented so many times in
> the past both on idr and sidr that by bringing just one thread below seems
> like erasing all other comments.
>
> number of BGP monitoring stations deployed today which use AS_PATH attribute
> for real time BGP analysis. Do you expect all of those tools to change/be
> updated when IETF will publish path validation RFC ?

only if they are going to participate in the bgpsec specific parts...
but then they'd already be set using just as_sec_path, right?

we had this discussion (we == sidr-wg and I think idr?) several times
already, essentially the as_sec_path only matters in the bubble that
is 'bgpsec'. outside that bubble as_path still remains, and is
re-manufactured as you cross the border by the exit-router at the
bubble edge.

The idea behind as_sec_path is really just a convenience of
implementations so we don't have to maintain 2 identical (mostly) data
structures in a device. Use as_path where you are not in the bubble,
convert to as_sec_path at the bubble ingress, convert back to as_path
at bubble exit.

I don't see why this is as much of an issue, particularly for any
monitoring code/station/system... if they don't do bgpsec, they just
see the same data as they do today. no changes are required,
operations continue, people stay happy... win?

-chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Sep 2012 18:13:48 +0900

> operations continue, people stay happy... win?

<pedantry>

sometimes, we will want to monitor the bgpsec aspects as well.  and
those monitors will do the capability negotiation for bgpsec, so will
get bgpsec as_sec_paths, which is cool.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 05:21:40 -0400

> get bgpsec as_sec_paths, which is cool.

I thought I said that:
"only if they are going to participate in the bgpsec specific parts...
but then they'd already be set using just as_sec_path, right?"

your pedantry is, of course, welcome...

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 21 Sep 2012 10:00:14 -0400

The data that is forwarded does not need to follow the exact reverse path of the update message that carried the route. The update message can traverse a different set of ASs than the update message. The BGP_SEC_PATH MUST describe the path that the update message took. The AS_PATH describes the path of the data, the chain of nexthops.

Do we want to constrain the data path to be the same as the signaling path?
That's like the Plain Old Telephone Signaling (POTS). In modern networks, like SS7, the signaling takes a different path than the data.

--
Jakob Heitz.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 21 Sep 2012 10:13:54 -0400

On Fri, Sep 21, 2012 at 10:00 AM, Jakob Heitz <[email-masked]> wrote:
> The data that is forwarded does not need to follow the exact reverse path of the update message that carried

none of the SIDR work is about 'data that is forwarded', it's about
the routing system, not the data path.

> the route. The update message can traverse a different set of ASs than the update message. The

this sentence isn't correct, did you mean: "The update message can
traverse a different set of ASs than what is represented in the update
message" ?

I'd agree with that, you can, today, lie/cheat/steal in the AS_PATH
attribute. I don't think that's a proper thing to do, no.

> BGP_SEC_PATH MUST describe the path that the update message took. The AS_PATH describes the path
> of the data, the chain of nexthops.

no, the AS_PATH today, describes MOST OFTEN (but not ALWAYS) the path
that the update message took through the routing system. People can
(and do, sometimes) wrangle with the AS_PATH for their own reasons,
without anyone else being the wiser.

You are correct that the intent of BGPSEC is to provide a validated
path on which the update message passed.

> Do we want to constrain the data path to be the same as the signaling path?

this isn't constraining the data path.

> That's like the Plain Old Telephone Signaling (POTS). In modern networks, like SS7, the signaling takes a different path than the data.

this isn't POTS, nor SS7... this is bgp and the internet.

-chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Sep 2012 23:21:53 +0900

> Do we want to constrain the data path to be the same as the signaling

ideally as an option, sure.  send code :)

randy

---

From: Danny McPherson <[email-masked]>
Date: Sat, 22 Sep 2012 14:08:37 -0400

> P.S.: If you intend to review it but need more time, please speak up, and say how much more time you will need.

I intend to review it, but would prefer that the SIDR WG complete the threat and requirements documents before progressing the solutions specifications that muck considerably with BGP.

I also think the work on BGPSEC might be better done in IDR, where IDR expertise and a wider set of perspectives exists to give appropriate consideration to things that will certainly impact the security and stability of the global routing system, whether specific elements are BGPSEC enabled or not.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Wed, 26 Sep 2012 12:27:04 -0400

On Sep 26, 2012, at 4:01 AM, [email-masked] wrote:

> Danny:
> 
> I would suggest the following  things prior to accepting this change
> 
> 1) Your proposal for threat analysis and requirements,
> 2) Deployments reports on interoperability on this feature,
> 3) Transition reports - in and out of bgpsecure zone.
> 4) Scaling in deployment
> 
> What do think?

Besides not being sure what "bgpsecure zone" is, yes -- these certainly seem like the kind of things that IDR and folks that operate BGP-speaking routers that this work _will impact should be asking.  

-danny