From bashandy@cisco.com Mon Apr 2 16:36:06 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A9721F8747 for ; Mon, 2 Apr 2012 16:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnL2EhlAPHr5 for ; Mon, 2 Apr 2012 16:36:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7A39121F874A for ; Mon, 2 Apr 2012 16:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=9314; q=dns/txt; s=iport; t=1333409764; x=1334619364; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+vufTPsCO1VTfjA+0Qz1tsyZnM8EI22Ol4thOoaxipg=; b=LswrqpDYAH6Ny6ckB1Bx/BNUBjThNNekeO+A18kE5TTxnerEy8Q8tQ08 NbOdCm31NSXRLIVq8oNrlXT4Ra87ulOhVlnSWMsBz/lnWkgX/7N1Tfo+s 3rvFJAOWnU4516w+Rx9oHoZZsLgoPJsbKH6nU2AAp41jMxiONS+pA4j8g E=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="asc'?scan'208,217";a="35652753" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 23:36:02 +0000 Received: from [171.71.138.240] (dhcp-171-71-138-240.cisco.com [171.71.138.240]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q32Na2ma015378; Mon, 2 Apr 2012 23:36:02 GMT Message-ID: <4F7A37E1.1010706@cisco.com> Date: Mon, 02 Apr 2012 16:36:01 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3@szxeml525-mbs.china.huawei.com> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB9AA8A958A369115D1E9BDA" Cc: "idr@ietf.org" Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:36:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB9AA8A958A369115D1E9BDA Content-Type: multipart/alternative; boundary="------------030503060009030501040601" This is a multi-part message in MIME format. --------------030503060009030501040601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The concept of PE-CE protection is not new. AFAIK it, was introduced in the paper titled "Achieving sub-second IGP convergence in large IP Networks" published in ACM SIGCOMM Computer Communication Review, 35(3):33-44, July 2005. the idea of having a special label was also mentioned in the paper draft-bashandy-idr-bgp-repair-label-03 specifies PE-CE protection using repair label in a very concrete manner so that it can be implemented. That is why draft-bashandy-idr-bgp-repair-label-03 is a standards track draft. For example some of the concrete information in draft-bashandy-idr-bgp-repair-label-03 : - proposes advertising the repair label as an optional non-transitive attribute. - specifies the syntax of the proposed attribute section 3.1.2. - Unambiguously specifies the semantics of the repair label and the forwarding behavior on the nodes participating in the scheme - recommends using per-CE repair label allocation In addition, the loop prevention specified in draft-bashandy-idr-bgp-repair-label-03 is independent of the method of choosing a repair path. For example, the repair path can be ECMP, best external, or some other future mechanism. Besides, the concept of repair label is very general and can be used in other BGP FRR mechanisms such as draft-bashandy-bgp-edge-node-frr-02. Thanks Ahmed On 3/26/2012 1:20 AM, Xuxiaohu wrote: > > Hi co-authors of the abvove draft, > > =20 > > In you draft, it said"As usual, each PE allocates a local label for > each prefix it can reach through an external neighbor CE. This is the > primary label used for normal traffic forwarding." and "To provide > repair path information to all PEs, the PE also allocates a repair > label to the prefix if it can reach that prefix via an external > neighbor." > > =20 > > Does it mean the external path which the repair label is associated > with is a best external path? If so, could you explain what's > difference between the above draft and this draft > (http://tools.ietf.org/html/ > draft-xu-idr-best-external-loop-avoidance-00 > ). > > =20 > > BR, > > Xiaohu > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------030503060009030501040601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The concept of PE-CE protection is not new. AFAIK it, was introduced in the paper titled "Achieving sub-second IGP convergence in large IP Networks” published in ACM SIGCOMM Computer Communication Re= view, 35(3):33-44, July 2005. the idea of having a special label was also mentioned in the paper

draft-bashandy-idr-bgp-repair-label-03 specifies PE-CE protection using repair label in a very concrete manner so that it can be implemented. That is why draft-bashandy-idr-bgp-repair-label-03 is a standards track draft. For example some of the concrete information in draft-bashandy-idr-bgp-repair-label-03 :
- proposes advertising the repair label as an optional non-transitive attribute.
- specifies the syntax of the proposed attribute section 3.1.2.
- Unambiguously specifies the semantics of the repair label and the forwarding behavior on the nodes participating in the scheme
- recommends using per-CE repair label allocation

In addition, the loop prevention specified in draft-bashandy-idr-bgp-repair-label-03 is independent of the method of choosing a repair path. For example, the repair path can be ECMP,  best external, or some other future mechanism.

Besides, the concept of repair label is very general and can be used in other BGP FRR mechanisms such as draft-bashandy-bgp-edge-node-frr-02.

Thanks

Ahmed


On 3/26/2012 1:20 AM, Xuxiaohu wrote:

Hi co-authors of the abvove draft,

 

In you draft, it said"As usual, each PE allocates a local label for each prefix it can reach through an external neighbor CE. This is the primary label used for normal tra= ffic forwarding." and "To provide repair path information to all PEs, the PE also allocates a repair label to the prefix if= it can reach that prefix via an external neighbor."

 

Does it mean the external path which the repair label is associated with is a best external path? If so, could you explain what's difference between the above draft and this draft (http://tools.ietf.org/html/draft-xu-idr-best-external-loop-avoidance-00).

 

BR,

Xiaohu



_______________________________________________
Idr mailing list
Idr@ie=
tf.org
https://www.ietf.org/mailman/listinfo/idr
--------------030503060009030501040601-- --------------enigFB9AA8A958A369115D1E9BDA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPejfh+G19kFA5zIYRAtv3AJ0RScJU9WgDTOIusvSP9APNjU6n1QCfSwR6 4w10FEEbT1JADiggHydQods= =GzaQ -----END PGP SIGNATURE----- --------------enigFB9AA8A958A369115D1E9BDA-- From bashandy@cisco.com Mon Apr 2 20:36:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF00821F8437 for ; Mon, 2 Apr 2012 20:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJeBw1KJlL0e for ; Mon, 2 Apr 2012 20:36:17 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1F73721F876D for ; Mon, 2 Apr 2012 20:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=10469; q=dns/txt; s=iport; t=1333424176; x=1334633776; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7a20T44We4y3fXgMlgazN6Vnl5lpxYpwMFlQW9FGJ9Y=; b=ATPQGRypxMxKUZDVYyoRjA0u3lVIqJ5loXwoBZvwlx3HLYc1ERl601OF Lyc0ywaDWM/STZ/xFsod7v2hJLblugxx8ZBpHX0hEd5i6wrAWgIPQaBPb mknjqMwWS+d47BrlQQLKIjfDNjdDd6IonNLO/riOAinbpdIVlYpa5M5kP 8=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.75,361,1330905600"; d="asc'?scan'208,217";a="35677993" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Apr 2012 03:36:16 +0000 Received: from [10.21.115.227] (sjc-vpn2-995.cisco.com [10.21.115.227]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q333aFUF008673; Tue, 3 Apr 2012 03:36:16 GMT Message-ID: <4F7A7027.7030702@cisco.com> Date: Mon, 02 Apr 2012 20:36:07 -0700 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02CDF6D3@szxeml525-mbs.china.huawei.com> <4F7A37E1.1010706@cisco.com> In-Reply-To: <4F7A37E1.1010706@cisco.com> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2FBAB36D01EE58F63BFB414B" Cc: idr@ietf.org Subject: Re: [Idr] draft-bashandy-idr-bgp-repair-label-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 03:36:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2FBAB36D01EE58F63BFB414B Content-Type: multipart/alternative; boundary="------------070502090400000709080108" This is a multi-part message in MIME format. --------------070502090400000709080108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The correct reference is for PE-CE link protection is the paper titled "Achieving sub-50 milliseconds recovery upon bgp peering link failures," published in IEEE/ACM Transactions on Networking, 15(5):1123--1135, 2007 Thanks Ahmed On 4/2/2012 4:36 PM, Ahmed Bashandy (bashandy) wrote: > > The concept of PE-CE protection is not new. AFAIK it, was introduced > in the paper titled "Achieving sub-second IGP convergence in large IP > Networks" published in ACM SIGCOMM Computer Communication Review, > 35(3):33-44, July 2005. the idea of having a special label was also > mentioned in the paper > > draft-bashandy-idr-bgp-repair-label-03 specifies PE-CE protection > using repair label in a very concrete manner so that it can be > implemented. That is why draft-bashandy-idr-bgp-repair-label-03 is a > standards track draft. For example some of the concrete information in > draft-bashandy-idr-bgp-repair-label-03 : > - proposes advertising the repair label as an optional non-transitive > attribute. > - specifies the syntax of the proposed attribute section 3.1.2. > - Unambiguously specifies the semantics of the repair label and the > forwarding behavior on the nodes participating in the scheme > - recommends using per-CE repair label allocation > > In addition, the loop prevention specified in > draft-bashandy-idr-bgp-repair-label-03 is independent of the method of > choosing a repair path. For example, the repair path can be ECMP,=20 > best external, or some other future mechanism. > > Besides, the concept of repair label is very general and can be used > in other BGP FRR mechanisms such as draft-bashandy-bgp-edge-node-frr-02= =2E > > Thanks > > Ahmed > > > On 3/26/2012 1:20 AM, Xuxiaohu wrote: >> >> Hi co-authors of the abvove draft, >> >> =20 >> >> In you draft, it said"As usual, each PE allocates a local label for >> each prefix it can reach through an external neighbor CE. This is the >> primary label used for normal traffic forwarding." and "To provide >> repair path information to all PEs, the PE also allocates a repair >> label to the prefix if it can reach that prefix via an external >> neighbor." >> >> =20 >> >> Does it mean the external path which the repair label is associated >> with is a best external path? If so, could you explain what's >> difference between the above draft and this draft >> (http://tools.ietf.org/html/ >> draft-xu-idr-best-external-loop-avoidance-00 >> ). >> >> =20 >> >> BR, >> >> Xiaohu >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr --------------070502090400000709080108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The correct reference is for PE-CE link protection is the paper titled “Achieving sub-50 milliseconds recovery upon bgp peering= link failures,” published in IEEE/ACM Transactions on Networking, 15(5):1123–1135, 2007

Thanks

Ahmed

On 4/2/2012 4:36 PM, Ahmed Bashandy (bashandy) wrote:

The concept of PE-CE protection is not new. AFAIK it, was introduced in the paper titled "Achieving sub-second IGP convergence in large IP Networks” published in ACM SIGCOMM Computer Communication Review, 35(3):33-44, July 2005. the idea of having a special label was also mentioned in the paper

draft-bashandy-idr-bgp-repair-label-03 specifies PE-CE protection using repair label in a very concrete manner so that it can be implemented. That is why draft-bashandy-idr-bgp-repair-label-03 is a standards track draft. For example some of the concrete information in draft-bashandy-idr-bgp-repair-label-03 :
- proposes advertising the repair label as an optional non-transitive attribute.
- specifies the syntax of the proposed attribute section 3.1.2.
= - Unambiguously specifies the semantics of the repair label and the forwarding behavior on the nodes participating in the scheme - recommends using per-CE repair label allocation

In addition, the loop prevention specified in draft-bashandy-idr-bgp-repair-label-03 is independent of the method of choosing a repair path. For example, the repair path can be ECMP,  best external, or some other future mechanism.

Besides, the concept of repair label is very general and can be used in other BGP FRR mechanisms such as draft-bashandy-bgp-edge-node-frr-02.

Thanks

Ahmed


On 3/26/2012 1:20 AM, Xuxiaohu wrote:

Hi co-authors of the abvove draft,

 

In you draft, it said"As usual, each PE allocates a local label for each prefix it can reach through an external neighbor CE. This is the primary label used for normal traffic forwarding." and "To provide repair path information to all PEs, the PE also allocates a repair label to the prefix if it can reach that prefix via an external neighbor."

 

Does it mean the external path which the repair label is associated with is a best external path? If so, could you explain what's difference between the above draft and this draft (http://tools.ietf.org/html/draft-xu-idr-best-external-loop-avoidance-00).

 

BR,

Xiaohu



_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listin=
fo/idr
--------------070502090400000709080108-- --------------enig2FBAB36D01EE58F63BFB414B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPenAt+G19kFA5zIYRAg7pAJ0byVlYR4ydXIo/LEB6fcGrhkDHLgCfYy12 7iqm/ryAt9Us4WfWG3oWPLc= =IIZc -----END PGP SIGNATURE----- --------------enig2FBAB36D01EE58F63BFB414B-- From david.freedman@uk.clara.net Tue Apr 3 01:34:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBB721F860D for ; Tue, 3 Apr 2012 01:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt88uHYDacqC for ; Tue, 3 Apr 2012 01:34:40 -0700 (PDT) Received: from staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [IPv6:2001:a88:0:fff7::68]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44021F847A for ; Tue, 3 Apr 2012 01:34:39 -0700 (PDT) Received: from [195.157.10.59] (port=8879 helo=SRVGREXCAS02.claranet.local) by staff00.mail.eu.clara.net (staff00.mail.eu.clara.net [80.168.65.68]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1SEzCH-0007vQ-36 for idr@ietf.org (return-path ); Tue, 03 Apr 2012 08:34:38 +0000 Received: from SRVGREXMB02.claranet.local ([10.75.5.12]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.01.0339.001; Tue, 3 Apr 2012 09:34:37 +0100 From: David Freedman To: "idr@ietf.org" Thread-Topic: Operational Message and Multiple-Sessions Thread-Index: AQHNEXSa/ykDQJl4pECinsgF5WWS5g== Date: Tue, 3 Apr 2012 08:34:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <460D140D78AD69438D5161D92E3F3275@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: [Idr] Operational Message and Multiple-Sessions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:34:40 -0000 Folks,=20 Now that draft-ietf-idr-operational-message is a WG document, we could do with your valuable input! We'd like to put in some wording concerning dealing with OPERATIONAL messaging over multiple sessions, where we define these as sessions between the same pair of router identifiers. (This could cover the multisession and non-multisession cases) We would like to make sure that only one session at a time is transmitted over (but not preclude this happening in the future, perhaps looking at use cases with fast control failover) and allow for messages to be received over multiple sessions (but suggest that the implementation if it does this, de-duplicate the received information) For the moment, we're not concerned about which OPERATIONAL message type is used, since we're decoupling the request from the session type (for example, we request the AFI/SAFI in the STATE queries), even in the case of the MUP/DUP/DUMP messages, it shouldn't matter which session the bad data was transmitted over, only that we get the relevant information back to the other side (feel free to should loudly if you think this decoupling is a bad idea, we think from a simplicity PoV this would be appropriate) We're toying with adding wording like this: ------------ Multiple Sessions: Where multiple sessions are established between the same peer, OPERATIONAL messages SHOULD be transmitted over a single ESTABLISHED session only, at any one time. OPERATIONAL messages MAY be received over multiple ESTABLISHED sessions from the peer, an implementation SHOULD ensure that no duplicate information=20 is reported to the operator of the system. ------------ We could add the caveat that the transmit session is the oldest established, in order to gain some symmetry (do people feel that symmetry is important?) Dave. From robert@raszuk.net Mon Apr 9 00:19:12 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5968011E8073 for ; Mon, 9 Apr 2012 00:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+wpRjySqWG3 for ; Mon, 9 Apr 2012 00:19:11 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7657411E807F for ; Mon, 9 Apr 2012 00:19:11 -0700 (PDT) Received: (qmail 6015 invoked by uid 399); 9 Apr 2012 07:19:10 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.9.57) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 07:19:10 -0000 X-Originating-IP: 83.9.9.57 Message-ID: <4F828D6D.10907@raszuk.net> Date: Mon, 09 Apr 2012 09:19:09 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:19:12 -0000 > Your analysis assumes that there a conventional BGP-4 AS_PATH field > and then there is is BGPSEC_Path_Signatures from which AS path info > can be inferred separately. This is not true in the latest BGPSEC > update format as Matt presented it in Paris. How an optional attribute replace well-known mandatory one ? Sorry but for such step formal IDR WG approval is necessary if you choose to propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP protocol change. Documentation of partial deployment is required as well as two interoperable implementations ;). RFC4271: 5.1.2. AS_PATH AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs or AS_SEQUENCEs. draft-ietf-sidr-bgpsec-protocol-02.txt This document specifies a new optional (non-transitive) BGP path attribute, BGPSEC_Path_Signatures. Best regards, R. From kotikalapudi.sriram@nist.gov Mon Apr 9 09:15:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD3021F876A; Mon, 9 Apr 2012 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCdc+QxR3wly; Mon, 9 Apr 2012 09:15:19 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CC34A21F8659; Mon, 9 Apr 2012 09:15:18 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 12:15:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 12:15:17 -0400 From: "Sriram, Kotikalapudi" To: "robert@raszuk.net" , "sidr@ietf.org" Date: Mon, 9 Apr 2012 12:15:15 -0400 Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening Thread-Index: Ac0WIP7poYzIWIsYQjeyKyGlcjPvLQAQ5cwg Message-ID: References: <4F828D6D.10907@raszuk.net> In-Reply-To: <4F828D6D.10907@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:15:20 -0000 The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e., unsigned). In either case, the update necessarily has AS-path info. If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Path" in it. The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris. The Secure Path is semantically equivalent to the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to go to a BGP-4 only AS, then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN that was collapsed in BGPSEC will be repeated pCount number of times, and any transparent route server ASN (with pCount=0) in BGPSEC will be removed. Is this semantic equivalence (of the Secure Path) and the guarantee of convertibility to BGP-4 AS_PATH not enough? Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in a pristine way) in addition to the Secure Path, albeit at the cost of duplication and associated processing cost/confusion? Just a honest question seeking people's opinion. Sriram >-----Original Message----- >From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Robert >Raszuk >Sent: Monday, April 09, 2012 3:19 AM >To: sidr@ietf.org >Cc: idr@ietf.org List >Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening > > >> Your analysis assumes that there a conventional BGP-4 AS_PATH field >> and then there is is BGPSEC_Path_Signatures from which AS path info >> can be inferred separately. This is not true in the latest BGPSEC >> update format as Matt presented it in Paris. > >How an optional attribute replace well-known mandatory one ? > >Sorry but for such step formal IDR WG approval is necessary if you choose to >propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP >protocol change. > >Documentation of partial deployment is required as well as two interoperable >implementations ;). > >RFC4271: > >5.1.2. AS_PATH > > AS_PATH is a well-known mandatory attribute. This attribute > identifies the autonomous systems through which routing information > carried in this UPDATE message has passed. The components of this > list can be AS_SETs or AS_SEQUENCEs. > > >draft-ietf-sidr-bgpsec-protocol-02.txt > > This document specifies a new optional (non-transitive) BGP path > attribute, BGPSEC_Path_Signatures. > > >Best regards, >R. From robert@raszuk.net Mon Apr 9 09:29:44 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01021F8757 for ; Mon, 9 Apr 2012 09:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtyI9t8LBDhi for ; Mon, 9 Apr 2012 09:29:43 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 32DB121F872D for ; Mon, 9 Apr 2012 09:29:43 -0700 (PDT) Received: (qmail 20314 invoked by uid 399); 9 Apr 2012 16:29:42 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 16:29:42 -0000 X-Originating-IP: 83.9.123.224 Message-ID: <4F830E75.70606@raszuk.net> Date: Mon, 09 Apr 2012 18:29:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <4F828D6D.10907@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:29:44 -0000 Hi Sriram, > When the update is to leave a BGPSEC island to go to a BGP-4 only AS, > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge > of the BGPSEC island. What happens in the opposite direction ? How AS_PATH/AS4_PATH can be converted to BGPSEC_Path_Signatures without all necessary information present at the ASBR at any arbitrary Autonomous System ? Are you going to propose NULL signatures ? How are you planning on a flag date where all ASBRs in the Internet are BGPSEC complaint ? Why one needs to upgrade also all P routers (intra domain BGP speakers) to be BGPSEC complaint provided he is not using BGP as an overlay today? If you think removal of AS_PATH/AS4_PATH is helpful in any way the much simpler would be to define new set of AFIs and call it "SECURED" leaving current AFI 1 and AFI 2 unchanged BGP protocol wise. Thx, R. > The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e., unsigned). > In either case, the update necessarily has AS-path info. > If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandatory) in it. > If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Path" in it. > The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, pCount-k}. > Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris. > The Secure Path is semantically equivalent to the BGP-4 AS_PATH. > When the update is to leave a BGPSEC island to go to a BGP-4 only AS, > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island. > Any prepend ASN that was collapsed in BGPSEC will be repeated pCount number of times, > and any transparent route server ASN (with pCount=0) in BGPSEC will be removed. > Is this semantic equivalence (of the Secure Path) and > the guarantee of convertibility to BGP-4 AS_PATH not enough? > Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in a pristine way) > in addition to the Secure Path, albeit at the cost of duplication and associated > processing cost/confusion? Just a honest question seeking people's opinion. > > Sriram > >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Robert >> Raszuk >> Sent: Monday, April 09, 2012 3:19 AM >> To: sidr@ietf.org >> Cc: idr@ietf.org List >> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening& lengthening >> >> >>> Your analysis assumes that there a conventional BGP-4 AS_PATH field >>> and then there is is BGPSEC_Path_Signatures from which AS path info >>> can be inferred separately. This is not true in the latest BGPSEC >>> update format as Matt presented it in Paris. >> >> How an optional attribute replace well-known mandatory one ? >> >> Sorry but for such step formal IDR WG approval is necessary if you choose to >> propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP >> protocol change. >> >> Documentation of partial deployment is required as well as two interoperable >> implementations ;). >> >> RFC4271: >> >> 5.1.2. AS_PATH >> >> AS_PATH is a well-known mandatory attribute. This attribute >> identifies the autonomous systems through which routing information >> carried in this UPDATE message has passed. The components of this >> list can be AS_SETs or AS_SEQUENCEs. >> >> >> draft-ietf-sidr-bgpsec-protocol-02.txt >> >> This document specifies a new optional (non-transitive) BGP path >> attribute, BGPSEC_Path_Signatures. >> >> >> Best regards, >> R. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From Sandra.Murphy@sparta.com Mon Apr 9 10:07:20 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840C621F8773; Mon, 9 Apr 2012 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkAvo1U6JYvs; Mon, 9 Apr 2012 10:07:19 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8115F21F876C; Mon, 9 Apr 2012 10:07:19 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q39H7HE1013235; Mon, 9 Apr 2012 12:07:17 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q39H7G1a025926; Mon, 9 Apr 2012 12:07:16 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 13:07:16 -0400 From: "Murphy, Sandra" To: "robert@raszuk.net" , "Sriram, Kotikalapudi" Thread-Topic: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening Thread-Index: AQHNFm38jP+kiH4DhkCDobXjHWi/RJaSt/9z Date: Mon, 9 Apr 2012 17:07:16 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> References: <4F828D6D.10907@raszuk.net> , <4F830E75.70606@raszuk.net> In-Reply-To: <4F830E75.70606@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:07:20 -0000 speaking as regular ol' member=0A= =0A= There is no reverse direction.=0A= =0A= Incoming paths that are unsigned are not propagated by bgpsec speakers as s= igned paths.=0A= =0A= And intradomain BGP speakers do not use bgpsec (ebgp sessions only).=0A= =0A= And AS4_PATH is not needed in bgpsec speakers - who are assumed to be 4-byt= e aware.=0A= =0A= So no need to worry about ASBRs, flag days, etc. Don't worry, no problem.= =0A= =0A= --Sandy, speaking as regular ol' member.=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Ras= zuk [robert@raszuk.net]=0A= Sent: Monday, April 09, 2012 12:29 PM=0A= To: Sriram, Kotikalapudi=0A= Cc: idr@ietf.org List; sidr@ietf.org=0A= Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortenin= g & lengthening=0A= =0A= Hi Sriram,=0A= =0A= > When the update is to leave a BGPSEC island to go to a BGP-4 only AS,=0A= > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge=0A= > of the BGPSEC island.=0A= =0A= What happens in the opposite direction ? How AS_PATH/AS4_PATH can be=0A= converted to BGPSEC_Path_Signatures without all necessary information=0A= present at the ASBR at any arbitrary Autonomous System ? Are you going=0A= to propose NULL signatures ?=0A= =0A= How are you planning on a flag date where all ASBRs in the Internet are=0A= BGPSEC complaint ?=0A= =0A= Why one needs to upgrade also all P routers (intra domain BGP speakers)=0A= to be BGPSEC complaint provided he is not using BGP as an overlay today?=0A= =0A= If you think removal of AS_PATH/AS4_PATH is helpful in any way the much=0A= simpler would be to define new set of AFIs and call it "SECURED" leaving=0A= current AFI 1 and AFI 2 unchanged BGP protocol wise.=0A= =0A= Thx,=0A= R.=0A= =0A= =0A= > The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e= ., unsigned).=0A= > In either case, the update necessarily has AS-path info.=0A= > If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandat= ory) in it.=0A= > If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Pat= h" in it.=0A= > The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., AS= N-k, pCount-k}.=0A= > Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris= .=0A= > The Secure Path is semantically equivalent to the BGP-4 AS_PATH.=0A= > When the update is to leave a BGPSEC island to go to a BGP-4 only AS,=0A= > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of = the BGPSEC island.=0A= > Any prepend ASN that was collapsed in BGPSEC will be repeated pCount numb= er of times,=0A= > and any transparent route server ASN (with pCount=3D0) in BGPSEC will be = removed.=0A= > Is this semantic equivalence (of the Secure Path) and=0A= > the guarantee of convertibility to BGP-4 AS_PATH not enough?=0A= > Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in = a pristine way)=0A= > in addition to the Secure Path, albeit at the cost of duplication and ass= ociated=0A= > processing cost/confusion? Just a honest question seeking people's opinio= n.=0A= >=0A= > Sriram=0A= >=0A= >> -----Original Message-----=0A= >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of = Robert=0A= >> Raszuk=0A= >> Sent: Monday, April 09, 2012 3:19 AM=0A= >> To: sidr@ietf.org=0A= >> Cc: idr@ietf.org List=0A= >> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening& = lengthening=0A= >>=0A= >>=0A= >>> Your analysis assumes that there a conventional BGP-4 AS_PATH field=0A= >>> and then there is is BGPSEC_Path_Signatures from which AS path info=0A= >>> can be inferred separately. This is not true in the latest BGPSEC=0A= >>> update format as Matt presented it in Paris.=0A= >>=0A= >> How an optional attribute replace well-known mandatory one ?=0A= >>=0A= >> Sorry but for such step formal IDR WG approval is necessary if you choos= e to=0A= >> propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP= =0A= >> protocol change.=0A= >>=0A= >> Documentation of partial deployment is required as well as two interoper= able=0A= >> implementations ;).=0A= >>=0A= >> RFC4271:=0A= >>=0A= >> 5.1.2. AS_PATH=0A= >>=0A= >> AS_PATH is a well-known mandatory attribute. This attribute=0A= >> identifies the autonomous systems through which routing information= =0A= >> carried in this UPDATE message has passed. The components of this= =0A= >> list can be AS_SETs or AS_SEQUENCEs.=0A= >>=0A= >>=0A= >> draft-ietf-sidr-bgpsec-protocol-02.txt=0A= >>=0A= >> This document specifies a new optional (non-transitive) BGP path=0A= >> attribute, BGPSEC_Path_Signatures.=0A= >>=0A= >>=0A= >> Best regards,=0A= >> R.=0A= > _______________________________________________=0A= > Idr mailing list=0A= > Idr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/idr=0A= >=0A= >=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From robert@raszuk.net Mon Apr 9 10:22:26 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62B721F87A8 for ; Mon, 9 Apr 2012 10:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F14v2OxmwAb for ; Mon, 9 Apr 2012 10:22:25 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED3621F87A3 for ; Mon, 9 Apr 2012 10:22:24 -0700 (PDT) Received: (qmail 24973 invoked by uid 399); 9 Apr 2012 17:22:23 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 17:22:23 -0000 X-Originating-IP: 83.9.123.224 Message-ID: <4F831ACE.8090903@raszuk.net> Date: Mon, 09 Apr 2012 19:22:22 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Murphy, Sandra" References: <4F828D6D.10907@raszuk.net> , <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:22:27 -0000 Hi Sandy, > There is no reverse direction. What do you mean there is no reverse direction ? Sriram said: "When the update is to leave a BGPSEC island to go to a BGP-4 only AS, then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island." That means that there is EBGP peering at the two ASes which on one side supports BGPSEC on the other does not. In order to establish any form of bidirectional communication sites on the left need to know how to reach sites on the right and vice versa. So your below "Don't worry, no problem" directly means "no reachability". I am afraid there is slight problem with that. Best regards, R. > speaking as regular ol' member > > There is no reverse direction. > > Incoming paths that are unsigned are not propagated by bgpsec > speakers as signed paths. > > And intradomain BGP speakers do not use bgpsec (ebgp sessions only). > > And AS4_PATH is not needed in bgpsec speakers - who are assumed to be > 4-byte aware. > > So no need to worry about ASBRs, flag days, etc. Don't worry, no > problem. > > --Sandy, speaking as regular ol' member. > > > ________________________________________ From: sidr-bounces@ietf.org > [sidr-bounces@ietf.org] on behalf of Robert Raszuk > [robert@raszuk.net] Sent: Monday, April 09, 2012 12:29 PM To: Sriram, > Kotikalapudi Cc: idr@ietf.org List; sidr@ietf.org Subject: Re: [sidr] > [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening& > lengthening > > Hi Sriram, > >> When the update is to leave a BGPSEC island to go to a BGP-4 only >> AS, then the Secure Path is easily converted to BGP-4 AS_PATH at >> the edge of the BGPSEC island. > > What happens in the opposite direction ? How AS_PATH/AS4_PATH can be > converted to BGPSEC_Path_Signatures without all necessary > information present at the ASBR at any arbitrary Autonomous System ? > Are you going to propose NULL signatures ? > > How are you planning on a flag date where all ASBRs in the Internet > are BGPSEC complaint ? > > Why one needs to upgrade also all P routers (intra domain BGP > speakers) to be BGPSEC complaint provided he is not using BGP as an > overlay today? > > If you think removal of AS_PATH/AS4_PATH is helpful in any way the > much simpler would be to define new set of AFIs and call it "SECURED" > leaving current AFI 1 and AFI 2 unchanged BGP protocol wise. > > Thx, R. > > >> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or >> BGP-4 (i.e., unsigned). In either case, the update necessarily has >> AS-path info. If the update is BGP-4 (i.e., unsigned), it has the >> BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e., >> signed), then it MUST have the "Secure Path" in it. The Secure Path >> is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, >> pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC >> Protocol) in Paris. The Secure Path is semantically equivalent to >> the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to >> go to a BGP-4 only AS, then the Secure Path is easily converted to >> BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN >> that was collapsed in BGPSEC will be repeated pCount number of >> times, and any transparent route server ASN (with pCount=0) in >> BGPSEC will be removed. Is this semantic equivalence (of the Secure >> Path) and the guarantee of convertibility to BGP-4 AS_PATH not >> enough? Should we really require in BGPSEC that the BGP-4 AS_PATH >> be carried (in a pristine way) in addition to the Secure Path, >> albeit at the cost of duplication and associated processing >> cost/confusion? Just a honest question seeking people's opinion. >> >> Sriram >> >>> -----Original Message----- From: sidr-bounces@ietf.org >>> [mailto:sidr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >>> Monday, April 09, 2012 3:19 AM To: sidr@ietf.org Cc: idr@ietf.org >>> List Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path >>> shortening& lengthening >>> >>> >>>> Your analysis assumes that there a conventional BGP-4 AS_PATH >>>> field and then there is is BGPSEC_Path_Signatures from which AS >>>> path info can be inferred separately. This is not true in the >>>> latest BGPSEC update format as Matt presented it in Paris. >>> >>> How an optional attribute replace well-known mandatory one ? >>> >>> Sorry but for such step formal IDR WG approval is necessary if >>> you choose to propose BGPSEC_Path_Signatures as mandatory >>> attribute. This is major BGP protocol change. >>> >>> Documentation of partial deployment is required as well as two >>> interoperable implementations ;). >>> >>> RFC4271: >>> >>> 5.1.2. AS_PATH >>> >>> AS_PATH is a well-known mandatory attribute. This attribute >>> identifies the autonomous systems through which routing >>> information carried in this UPDATE message has passed. The >>> components of this list can be AS_SETs or AS_SEQUENCEs. >>> >>> >>> draft-ietf-sidr-bgpsec-protocol-02.txt >>> >>> This document specifies a new optional (non-transitive) BGP path >>> attribute, BGPSEC_Path_Signatures. >>> >>> >>> Best regards, R. From dougm@nist.gov Mon Apr 9 10:48:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6FA21F8796; Mon, 9 Apr 2012 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OP6Nv7JZ38e; Mon, 9 Apr 2012 10:48:24 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAFE21F8793; Mon, 9 Apr 2012 10:48:23 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 13:48:20 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 13:48:22 -0400 From: "Montgomery, Douglas" To: "robert@raszuk.net" , "Murphy, Sandra" Date: Mon, 9 Apr 2012 13:48:08 -0400 Thread-Topic: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening Thread-Index: Ac0WeNTw+xkeBDfiTiWJaKyynRKoYw== Message-ID: In-Reply-To: <4F831ACE.8090903@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Apr 2012 10:50:54 -0700 Cc: "idr@ietf.org List" , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:48:25 -0000 On 4/9/12 1:22 PM, "Robert Raszuk" wrote: >Hi Sandy, > >> There is no reverse direction. > >What do you mean there is no reverse direction ? > >Sriram said: > >"When the update is to leave a BGPSEC island to go to a BGP-4 only AS, >then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of >the BGPSEC island." > >That means that there is EBGP peering at the two ASes which on one side >supports BGPSEC on the other does not. Right. BGPSEC doesn't support partially signed PATHS. Thus a update either starts off signed, or it is not signed at all. You can take a signed path, strip the PATH-SIG, reconstruct the AS-PATH and transmit it to a non-BGPSEC speaker. But from that point on, the PATH remains unsigned. A path that starts off unsigned, will always remain unsigned. Dougm From robert@raszuk.net Mon Apr 9 11:02:18 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A105421F8666 for ; Mon, 9 Apr 2012 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yii94pHV5FRC for ; Mon, 9 Apr 2012 11:02:18 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id CD95521F87CC for ; Mon, 9 Apr 2012 11:02:17 -0700 (PDT) Received: (qmail 12797 invoked by uid 399); 9 Apr 2012 18:02:14 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 18:02:14 -0000 X-Originating-IP: 83.9.123.224 Message-ID: <4F832424.1090104@raszuk.net> Date: Mon, 09 Apr 2012 20:02:12 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:02:18 -0000 Hi, > A path that starts off unsigned, will always remain unsigned. Do you mean that: "A path that starts off unsinged or transits via at least one non BGPSEC enabled BGP router (edge or core) will always remain unsigned." ? Many thx, R. From Sandra.Murphy@sparta.com Mon Apr 9 11:12:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0D21F87B3; Mon, 9 Apr 2012 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpR7RA2X-2-x; Mon, 9 Apr 2012 11:12:36 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D9DFB21F8764; Mon, 9 Apr 2012 11:12:35 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q39ICYrM014152; Mon, 9 Apr 2012 13:12:34 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q39ICXUq028551; Mon, 9 Apr 2012 13:12:33 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 14:12:33 -0400 From: "Murphy, Sandra" To: "robert@raszuk.net" Thread-Topic: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening Thread-Index: AQHNFnVVP+4RrE3i6E+YFR9dt0xcTpaSxY54 Date: Mon, 9 Apr 2012 18:12:32 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2586@Hermes.columbia.ads.sparta.com> References: <4F828D6D.10907@raszuk.net> , <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>, <4F831ACE.8090903@raszuk.net> In-Reply-To: <4F831ACE.8090903@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:12:37 -0000 still speaking as regular ol' member=0A= =0A= by "no reverse direction", it was in answer to your question "What happens= in the opposite direction ? ". I should have used your words exactly.=0A= =0A= I meant what I said in the second line I wrote. "Incoming paths that are u= nsigned are not propagated by bgpsec speakers as signed paths.". They ar= e propagated as unsigned paths.=0A= =0A= So there's no need to try to produce signatures for unsigned paths. Routes= that come in unsigned, stay unsigned.=0A= =0A= There is no loss of reachability, because the routes are propagated.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= ________________________________________=0A= From: Robert Raszuk [robert@raszuk.net]=0A= Sent: Monday, April 09, 2012 1:22 PM=0A= To: Murphy, Sandra=0A= Cc: Sriram, Kotikalapudi; idr@ietf.org List; sidr@ietf.org=0A= Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortenin= g & lengthening=0A= =0A= Hi Sandy,=0A= =0A= > There is no reverse direction.=0A= =0A= What do you mean there is no reverse direction ?=0A= =0A= Sriram said:=0A= =0A= "When the update is to leave a BGPSEC island to go to a BGP-4 only AS,=0A= then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of=0A= the BGPSEC island."=0A= =0A= That means that there is EBGP peering at the two ASes which on one side=0A= supports BGPSEC on the other does not.=0A= =0A= In order to establish any form of bidirectional communication sites on=0A= the left need to know how to reach sites on the right and vice versa.=0A= =0A= So your below "Don't worry, no problem" directly means "no=0A= reachability". I am afraid there is slight problem with that.=0A= =0A= Best regards,=0A= R.=0A= =0A= =0A= > speaking as regular ol' member=0A= >=0A= > There is no reverse direction.=0A= >=0A= > Incoming paths that are unsigned are not propagated by bgpsec=0A= > speakers as signed paths.=0A= >=0A= > And intradomain BGP speakers do not use bgpsec (ebgp sessions only).=0A= >=0A= > And AS4_PATH is not needed in bgpsec speakers - who are assumed to be=0A= > 4-byte aware.=0A= >=0A= > So no need to worry about ASBRs, flag days, etc. Don't worry, no=0A= > problem.=0A= >=0A= > --Sandy, speaking as regular ol' member.=0A= >=0A= >=0A= > ________________________________________ From: sidr-bounces@ietf.org=0A= > [sidr-bounces@ietf.org] on behalf of Robert Raszuk=0A= > [robert@raszuk.net] Sent: Monday, April 09, 2012 12:29 PM To: Sriram,=0A= > Kotikalapudi Cc: idr@ietf.org List; sidr@ietf.org Subject: Re: [sidr]=0A= > [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&=0A= > lengthening=0A= >=0A= > Hi Sriram,=0A= >=0A= >> When the update is to leave a BGPSEC island to go to a BGP-4 only=0A= >> AS, then the Secure Path is easily converted to BGP-4 AS_PATH at=0A= >> the edge of the BGPSEC island.=0A= >=0A= > What happens in the opposite direction ? How AS_PATH/AS4_PATH can be=0A= > converted to BGPSEC_Path_Signatures without all necessary=0A= > information present at the ASBR at any arbitrary Autonomous System ?=0A= > Are you going to propose NULL signatures ?=0A= >=0A= > How are you planning on a flag date where all ASBRs in the Internet=0A= > are BGPSEC complaint ?=0A= >=0A= > Why one needs to upgrade also all P routers (intra domain BGP=0A= > speakers) to be BGPSEC complaint provided he is not using BGP as an=0A= > overlay today?=0A= >=0A= > If you think removal of AS_PATH/AS4_PATH is helpful in any way the=0A= > much simpler would be to define new set of AFIs and call it "SECURED"=0A= > leaving current AFI 1 and AFI 2 unchanged BGP protocol wise.=0A= >=0A= > Thx, R.=0A= >=0A= >=0A= >> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or=0A= >> BGP-4 (i.e., unsigned). In either case, the update necessarily has=0A= >> AS-path info. If the update is BGP-4 (i.e., unsigned), it has the=0A= >> BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e.,=0A= >> signed), then it MUST have the "Secure Path" in it. The Secure Path=0A= >> is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k,=0A= >> pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC=0A= >> Protocol) in Paris. The Secure Path is semantically equivalent to=0A= >> the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to=0A= >> go to a BGP-4 only AS, then the Secure Path is easily converted to=0A= >> BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN=0A= >> that was collapsed in BGPSEC will be repeated pCount number of=0A= >> times, and any transparent route server ASN (with pCount=3D0) in=0A= >> BGPSEC will be removed. Is this semantic equivalence (of the Secure=0A= >> Path) and the guarantee of convertibility to BGP-4 AS_PATH not=0A= >> enough? Should we really require in BGPSEC that the BGP-4 AS_PATH=0A= >> be carried (in a pristine way) in addition to the Secure Path,=0A= >> albeit at the cost of duplication and associated processing=0A= >> cost/confusion? Just a honest question seeking people's opinion.=0A= >>=0A= >> Sriram=0A= >>=0A= >>> -----Original Message----- From: sidr-bounces@ietf.org=0A= >>> [mailto:sidr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent:=0A= >>> Monday, April 09, 2012 3:19 AM To: sidr@ietf.org Cc: idr@ietf.org=0A= >>> List Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path=0A= >>> shortening& lengthening=0A= >>>=0A= >>>=0A= >>>> Your analysis assumes that there a conventional BGP-4 AS_PATH=0A= >>>> field and then there is is BGPSEC_Path_Signatures from which AS=0A= >>>> path info can be inferred separately. This is not true in the=0A= >>>> latest BGPSEC update format as Matt presented it in Paris.=0A= >>>=0A= >>> How an optional attribute replace well-known mandatory one ?=0A= >>>=0A= >>> Sorry but for such step formal IDR WG approval is necessary if=0A= >>> you choose to propose BGPSEC_Path_Signatures as mandatory=0A= >>> attribute. This is major BGP protocol change.=0A= >>>=0A= >>> Documentation of partial deployment is required as well as two=0A= >>> interoperable implementations ;).=0A= >>>=0A= >>> RFC4271:=0A= >>>=0A= >>> 5.1.2. AS_PATH=0A= >>>=0A= >>> AS_PATH is a well-known mandatory attribute. This attribute=0A= >>> identifies the autonomous systems through which routing=0A= >>> information carried in this UPDATE message has passed. The=0A= >>> components of this list can be AS_SETs or AS_SEQUENCEs.=0A= >>>=0A= >>>=0A= >>> draft-ietf-sidr-bgpsec-protocol-02.txt=0A= >>>=0A= >>> This document specifies a new optional (non-transitive) BGP path=0A= >>> attribute, BGPSEC_Path_Signatures.=0A= >>>=0A= >>>=0A= >>> Best regards, R.=0A= =0A= =0A= From robert@raszuk.net Mon Apr 9 11:50:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4496121F8743 for ; Mon, 9 Apr 2012 11:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX2Nn27-VK+p for ; Mon, 9 Apr 2012 11:50:08 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 844C321F86F6 for ; Mon, 9 Apr 2012 11:50:08 -0700 (PDT) Received: (qmail 19889 invoked by uid 399); 9 Apr 2012 18:50:08 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 18:50:08 -0000 X-Originating-IP: 83.9.123.224 Message-ID: <4F832F5E.9030903@raszuk.net> Date: Mon, 09 Apr 2012 20:50:06 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Murphy, Sandra" , sidr wg list References: <4F828D6D.10907@raszuk.net> , <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: [Idr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:50:09 -0000 Hi, > And intradomain BGP speakers do not use bgpsec (ebgp sessions only). I do not understand. How a BGP Update will transit via an AS where each router is a real BGP speaker and where as some proposed BGP mandatory AS_PATH attribute is not present ? Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected directly or indirectly (RRs) via IBGP. As you proposing to remove AS_PATH selection criteria from best path for updates which come over IBGP ? What happens if you need to compare paths received over EBGP and IBGP on a given BGP speaker ? Many thx, R. From kent@bbn.com Mon Apr 9 18:35:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A17411E807F; Mon, 9 Apr 2012 18:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azqEToXjsI37; Mon, 9 Apr 2012 18:35:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D602811E8079; Mon, 9 Apr 2012 18:35:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57555 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHPzM-0009FY-D2; Mon, 09 Apr 2012 21:35:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F830E75.70606@raszuk.net> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> Date: Mon, 9 Apr 2012 20:52:46 -0400 To: robert@raszuk.net From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "idr@ietf.org List" , "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:35:40 -0000 At 6:29 PM +0200 4/9/12, Robert Raszuk wrote: >Hi Sriram, > >> When the update is to leave a BGPSEC island to go to a BGP-4 only AS, >> then the Secure Path is easily converted to BGP-4 AS_PATH at the edge >> of the BGPSEC island. > >What happens in the opposite direction ? you can't go in the opposite direction, i.e., from unsigned to signed. Steve From internet-drafts@ietf.org Mon Apr 9 19:10:00 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4311E8096; Mon, 9 Apr 2012 19:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w0mZhW8Erud; Mon, 9 Apr 2012 19:09:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823321F867F; Mon, 9 Apr 2012 19:09:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410020959.19426.50357.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 19:09:59 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-link-bandwidth-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 02:10:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Link Bandwidth Extended Community Author(s) : Pradosh Mohapatra Rex Fernando Filename : draft-ietf-idr-link-bandwidth-04.txt Pages : 5 Date : 2012-04-09 This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-04.txt From christopher.morrow@gmail.com Mon Apr 9 21:59:11 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E707D21F875E; Mon, 9 Apr 2012 21:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXtvQmKir76b; Mon, 9 Apr 2012 21:59:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5499421F875B; Mon, 9 Apr 2012 21:59:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so7609817obb.31 for ; Mon, 09 Apr 2012 21:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KTgEja/96FzWQIz6Qo1OvhIb8X2TJIWJDcmvmAiyeUQ=; b=dWsO+3vAnfwyd6YIthp2xIou2MuOvQ39BMzacFNJFAVmUJQw9D1y4zZBVc2TQ8My6l xbEsIIOwtFEs1YrRMwov+i3GY0alMKbRm6y67vhgSzOjrW8EPK6k1R4TjGIlMYnysbNG WM0oDQGIxLPGNMjhJmmaY4882MEjHFeyStWRWzjgRE1kwciTixqOptvbiS8xIFyuLc03 dF6KQ5YTPog8W8aTgpM40MLkSc+V5Oo5AHv7dJDbpBs3IJgiv4CquRN/biZ+mXtWzXdD sVnMkq6ZQgLWryT2Dnr01jUErBirXulJekw3B+7iC1k4jMnPVZhAs9yTqZWQcQgPdVO4 JVig== MIME-Version: 1.0 Received: by 10.182.159.41 with SMTP id wz9mr13759348obb.69.1334033950934; Mon, 09 Apr 2012 21:59:10 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Mon, 9 Apr 2012 21:59:10 -0700 (PDT) In-Reply-To: <4F832F5E.9030903@raszuk.net> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> Date: Tue, 10 Apr 2012 00:59:10 -0400 X-Google-Sender-Auth: uJVQJ9W_HRLVn57atFNG5YoK38c Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , "Murphy, Sandra" , sidr wg list Subject: Re: [Idr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 04:59:12 -0000 On Mon, Apr 9, 2012 at 2:50 PM, Robert Raszuk wrote: > Hi, > >> And intradomain BGP speakers do not use bgpsec (ebgp sessions only). > > > I do not understand. How a BGP Update will transit via an AS where each > router is a real BGP speaker and where as some proposed BGP mandatory > AS_PATH attribute is not present ? The last sentence, it doesn't parse quite clearly for me... could you re-state it? > > Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel > ASBR to ASBR as transport ? Even in this case ASBRs are connected directly > or indirectly (RRs) via IBGP. no assumption was made of this sort. > As you proposing to remove AS_PATH selection criteria from best path for > updates which come over IBGP ? What happens if you need to compare paths no > received over EBGP and IBGP on a given BGP speaker ? I think what you want is actually sort of discussed in: -chris From jgs@juniper.net Tue Apr 10 08:17:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2981511E80BE for ; Tue, 10 Apr 2012 08:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZycxNsOWX6B for ; Tue, 10 Apr 2012 08:17:38 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE521F8504 for ; Tue, 10 Apr 2012 08:17:37 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT4RPDaiOSXrp2HmyCODwA/bRCH38SYdc@postini.com; Tue, 10 Apr 2012 08:17:38 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 10 Apr 2012 08:16:53 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 10 Apr 2012 08:16:52 -0700 Thread-Topic: IDR minutes for IETF-83 posted Thread-Index: Ac0XLPVymAKrEM8EQSOQCzrwkJZbyQ== Message-ID: <357DA095-95EA-4C58-A585-A6E215DED18B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] IDR minutes for IETF-83 posted X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:17:39 -0000 The minutes of our last meeting can be found at http://www.ietf.org/proceedings/83/minutes/minutes-83-idr.txt Please send any comments or corrections. Thanks again to Shane for taking n= otes. --John= From warren@kumari.net Tue Apr 10 09:07:09 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A721F85FD; Tue, 10 Apr 2012 09:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pZ1IskKCj52; Tue, 10 Apr 2012 09:07:08 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C27E621F85F9; Tue, 10 Apr 2012 09:07:08 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id CFF9A1B40018; Tue, 10 Apr 2012 12:07:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4F832F5E.9030903@raszuk.net> Date: Tue, 10 Apr 2012 12:07:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> References: <4F828D6D.10907@raszuk.net> , <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:07:09 -0000 On Apr 9, 2012, at 2:50 PM, Robert Raszuk wrote: > Hi, >=20 >> And intradomain BGP speakers do not use bgpsec (ebgp sessions only). >=20 > I do not understand. How a BGP Update will transit via an AS where = each router is a real BGP speaker and where as some proposed BGP = mandatory AS_PATH attribute is not present ? I must admit I'm having a hard time parsing the question. I'll take a = stab though... This answer may be unrelated to what you are asking... When an update leaves a BGPSEC speaker destined for a "legacy" speaker = the BGPSEC bits are removed >=20 > Are you assuming each AS today is BGP Free with full mesh of MPLS/IP = tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected = directly or indirectly (RRs) via IBGP. Nope, not assuming that at all. The devices on the edge of the AS (those = that do eBGP) need to speak BGPSEC, and if the AS is small, they will = probably be in a full mesh. If the AS is not small (or has planned ahead = :-)) they will talk to a RR or be part of a confed. If they talk through = a RR (or set of RRs), these should also speak BGPSEC. If you prefer the = confed flavor of scaling, well, the devices on the edge of the confed = are kinda like eBGP speakers, and inside the confed they all mesh (or = talk through a RR (see previous :-))) >=20 > As you proposing to remove AS_PATH selection criteria from best path = for updates which come over IBGP ? Goodness, no.... > What happens if you need to compare paths received over EBGP and IBGP = on a given BGP speaker ? >=20 > Many thx, > R. >=20 P.S: Crossposting left in, as it seems like that is what was wanted, = but.... > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From robert@raszuk.net Tue Apr 10 09:34:43 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B0311E812C for ; Tue, 10 Apr 2012 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADyTOABpimFw for ; Tue, 10 Apr 2012 09:34:43 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A9E2D11E8128 for ; Tue, 10 Apr 2012 09:34:42 -0700 (PDT) Received: (qmail 21358 invoked by uid 399); 10 Apr 2012 16:34:42 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 16:34:42 -0000 X-Originating-IP: 83.31.51.142 Message-ID: <4F846121.2050408@raszuk.net> Date: Tue, 10 Apr 2012 18:34:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: sidr@ietf.org, "idr@ietf.org List" References: <4F828D6D.10907@raszuk.net> , <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> In-Reply-To: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:34:44 -0000 Hi Warren, Many thx for your comment. It clarifies my question very well. So you are effectively confirming that as long as there is one ASBR, one RR or one confederation edge which does not yet speak BGPSEC anywhere in the UPDATE path the peer sending to him over ebgp or ibgp will convert BGP_SIGNED_PATH to AS_PATH/AS4_PATH attributes and from now on that path will remain unsigned. Likewise each RR/confed peer will need to convert BGP_SIGNED_PATH to set of AS_PATH/AS4_PATH attributes when sending to "legacy" BGP speakers. I do not know what is the rationale for recommendation of not sending mandatory BGP attributes any longer even if their content could be already contained with new BGP_SIGNED_PATH attribute. Anyhow my doubt has been answered and I stay by my opinion that not sending AS_PATH and AS4_PATH is a terrible idea. Perhaps one could depreciate it in 20 years when world is upgraded to BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not helpful for any even potential BGPSEC deployment model. Best regards, R. > Nope, not assuming that at all. The devices on the edge of the AS > (those that do eBGP) need to speak BGPSEC, and if the AS is small, > they will probably be in a full mesh. If the AS is not small (or has > planned ahead :-)) they will talk to a RR or be part of a confed. If > they talk through a RR (or set of RRs), these should also speak > BGPSEC. If you prefer the confed flavor of scaling, well, the devices > on the edge of the confed are kinda like eBGP speakers, and inside > the confed they all mesh (or talk through a RR (see previous :-))) From christopher.morrow@gmail.com Tue Apr 10 09:53:04 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464F621F8661; Tue, 10 Apr 2012 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqodVhTnhPuP; Tue, 10 Apr 2012 09:53:01 -0700 (PDT) Received: from mail-yw0-f52.google.com (mail-yw0-f52.google.com [209.85.213.52]) by ietfa.amsl.com (Postfix) with ESMTP id 920E821F8684; Tue, 10 Apr 2012 09:52:59 -0700 (PDT) Received: by yhpp61 with SMTP id p61so2388946yhp.25 for ; Tue, 10 Apr 2012 09:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UduqRddfpLr69NErUcQy3z7+FsvHQAP3D4UEUAkJ7YY=; b=wTbczWO+zQKLMaEq3YGz6ZiKYqVKP/SsWTqVBq7lWWJad6Wzz/ED6c2nVC3/FdFFUV p0zX9IGbWnDRTY403Af3Z2TTX38HyQeXMcFthHMHB+G8FtvqFlXD/ks4sn/Rauqi0Ykd WxvMLnc138JwJOE12FEQ1zdPN7LhlNjpYtRLWIC87x5di1vLGvECY5L1yH2AJjjXdsgg Pkz6TZMH/MSZNoNrwbJODLJ3cYu1esps5oyGszb0XCHM8ogkNRWM5xoHsYO/8GFuRuHD gkNGBllAa44Os1DqjAHWOiC/69nlDDjbiie8mO+xnqGXKwbUH+H0sJRaLNuvc7OYYxgd r3cg== MIME-Version: 1.0 Received: by 10.60.24.201 with SMTP id w9mr16750567oef.49.1334076777708; Tue, 10 Apr 2012 09:52:57 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 09:52:57 -0700 (PDT) In-Reply-To: <4F846121.2050408@raszuk.net> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> Date: Tue, 10 Apr 2012 12:52:57 -0400 X-Google-Sender-Auth: GgUjAXP7ezF2eMb3pb8xanU6NFo Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:53:04 -0000 On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk wrote: > Anyhow my doubt has been answered and I stay by my opinion that not sending > AS_PATH and AS4_PATH is a terrible idea. So... we can send the data along, but in the case of BGPSEC speakers the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). Carrying extra bits isn't actually helpful is it? (the implementers drove the design decision here I believe) > Perhaps one could depreciate it in 20 years when world is upgraded to > BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not > helpful for any even potential BGPSEC deployment model. is it helpful for the folks that write bgp code though? "Hey, you will need to re-synthesize the as-path at sec->non-sec boundaries. you need to also create sec-path at none->sec boundaries." -chris From robert@raszuk.net Tue Apr 10 10:00:39 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D244111E8128 for ; Tue, 10 Apr 2012 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfQlxQ+gyDpu for ; Tue, 10 Apr 2012 10:00:39 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBF11E80E8 for ; Tue, 10 Apr 2012 10:00:39 -0700 (PDT) Received: (qmail 31084 invoked by uid 399); 10 Apr 2012 17:00:38 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 17:00:38 -0000 X-Originating-IP: 83.31.51.142 Message-ID: <4F846736.2060604@raszuk.net> Date: Tue, 10 Apr 2012 19:00:38 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:00:40 -0000 > So... we can send the data along, but in the case of BGPSEC speakers > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). So far I have always heard that BGPSEC is just providing the hint to the operator and does not change how BGP works. Here you are saying that now AS_PATH length should be calculated from completely different (and optional) attribute. You are also saying that now multipath code which computes which path are eligible to be multipath needs to look/parse/decrypt totally different attribute. All BGP monitoring tools need to be upgraded to now understand BGPSEC attribute too. And surprise .. here BMP will not convert it like it will to "legacy" speakers. You may think that if we stuff all "data" in the new attribute and drop the other one everything else will work. This may be so in theory, but it is clearly not a case in practice. Regards, R. > On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk wrote: >> Anyhow my doubt has been answered and I stay by my opinion that not sending >> AS_PATH and AS4_PATH is a terrible idea. > > So... we can send the data along, but in the case of BGPSEC speakers > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). > Carrying extra bits isn't actually helpful is it? (the implementers > drove the design decision here I believe) > >> Perhaps one could depreciate it in 20 years when world is upgraded to >> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not >> helpful for any even potential BGPSEC deployment model. > > is it helpful for the folks that write bgp code though? "Hey, you will > need to re-synthesize the as-path at sec->non-sec boundaries. you need > to also create sec-path at none->sec boundaries." > > -chris > > From warren@kumari.net Tue Apr 10 10:37:38 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37221F866D; Tue, 10 Apr 2012 10:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pktSovE8s6J; Tue, 10 Apr 2012 10:37:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E499221F866B; Tue, 10 Apr 2012 10:37:37 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AB4391B402FA; Tue, 10 Apr 2012 13:37:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 10 Apr 2012 13:37:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf.org List" , robert@raszuk.net, sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:37:38 -0000 On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote: > On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk = wrote: >> Anyhow my doubt has been answered and I stay by my opinion that not = sending >> AS_PATH and AS4_PATH is a terrible idea. >=20 > So... we can send the data along, but in the case of BGPSEC speakers > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). > Carrying extra bits isn't actually helpful is it? (the implementers > drove the design decision here I believe) I think that sone of the biggest issues to keep in mind with carrying = the "same" data in two places is what to do when you suddenly discover = that they are not actually the same? There has been much good work in IDR to better handle bugs / = implementations issues, and these considerations probably had much to do = with this... For example, I'm a BGPSEC speaker. In the BGPSEC bits I see: AS1 AS2 AS3 AS4 AS5 All this checks out, the magic crypto says all is = happy, etc. but, in the AS_PATH I see: AS1 AS 100 AS17 AS6 What do I do here? Do I a: drop the update or b: ignore the issue or c: = reset the session or d: prefer the singed or unsigned or e: nasal = demons? =20 Someone who's opinion I really respect once said: Never test for an = error condition you don't know how to handle. This idea extends this by simply not allowing the error condition to = occur. You have all of the information to recreate the AS_PATH / AS4_PATH when = you leave a BGPSEC domain, and because it is only in one place, you = sidestep all sorts of weird error corner cases... W >=20 >> Perhaps one could depreciate it in 20 years when world is upgraded to >> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO = not >> helpful for any even potential BGPSEC deployment model. >=20 > is it helpful for the folks that write bgp code though? "Hey, you will > need to re-synthesize the as-path at sec->non-sec boundaries. you need > to also create sec-path at none->sec boundaries." >=20 > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From dougm@nist.gov Tue Apr 10 10:42:52 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0D21F86E8; Tue, 10 Apr 2012 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQz79bWQ8W6D; Tue, 10 Apr 2012 10:42:51 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id AC26321F86E4; Tue, 10 Apr 2012 10:42:51 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Apr 2012 13:42:35 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 10 Apr 2012 13:42:50 -0400 From: "Montgomery, Douglas" To: Warren Kumari , Christopher Morrow Date: Tue, 10 Apr 2012 13:42:47 -0400 Thread-Topic: [sidr] [Idr] No BGPSEC intradomain ? Thread-Index: Ac0XQTaVmbg3QKfCRI6aryVBbFegkg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:42:52 -0000 On 4/10/12 1:37 PM, "Warren Kumari" wrote: > >On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote: > >> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk >>wrote: >>> Anyhow my doubt has been answered and I stay by my opinion that not >>>sending >>> AS_PATH and AS4_PATH is a terrible idea. >> >> So... we can send the data along, but in the case of BGPSEC speakers >> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). >> Carrying extra bits isn't actually helpful is it? (the implementers >> drove the design decision here I believe) > >I think that sone of the biggest issues to keep in mind with carrying the >"same" data in two places is what to do when you suddenly discover that >they are not actually the same? Do the same thing you do when you find that the that a PATH_SIG SKI points to a CERT for an ASN that does not match the ASN in the PATH_SIG. Proceed from there ... Problem is no different... The data meant to validate the PATH, does not match the PATH. Dougm From christopher.morrow@gmail.com Tue Apr 10 10:47:42 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9119D21F860D; Tue, 10 Apr 2012 10:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2n-IBLSlahd; Tue, 10 Apr 2012 10:47:42 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E510E21F85D4; Tue, 10 Apr 2012 10:47:41 -0700 (PDT) Received: by yhkk25 with SMTP id k25so42186yhk.31 for ; Tue, 10 Apr 2012 10:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cBnrA/Wo6JIm9UjLbxhntEM57Seu6uN3YCHKKGUGkp8=; b=Ry+2fyXX3i3NghZTpncbbFLRHWHV/6nggINkRezL/EKShs7Fhkxx1cm8Ng+U3w8kGm V5oa6o4lwckyV3/HLRwGQ/nG3cMnnUuAQWLHdKG47Wr3bxc3V0j+220FOEjY3NNXemoE ZjXsqdZ/14WQZNZdwTtuCcSr6Ol3vVELYSgt7rwablWyQRUsB6YwLe1dfL5r5peDtleC Y8rM2lI0UzpPTPPAKgFRVLoRipaumgzsrFs+2pmOkwHKOVJqKWm2dcP7C6boVGXeHQix EoTiiG9C5a9wupfxsqqqChPT3zsAUFN4TKqLlFvVDZBuTmAxXzvUaIWKGvPnSyV1pSrL Bplw== MIME-Version: 1.0 Received: by 10.60.24.201 with SMTP id w9mr17022206oef.49.1334080061340; Tue, 10 Apr 2012 10:47:41 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 10:47:41 -0700 (PDT) In-Reply-To: <4F846736.2060604@raszuk.net> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <4F846736.2060604@raszuk.net> Date: Tue, 10 Apr 2012 13:47:41 -0400 X-Google-Sender-Auth: 07VGFi-0uDlgB4aozWUDOSBeoh8 Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:47:42 -0000 On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk wrote: > >> So... we can send the data along, but in the case of BGPSEC speakers >> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). > > So far I have always heard that BGPSEC is just providing the hint to the > operator and does not change how BGP works. ok. > Here you are saying that now AS_PATH length should be calculated from > completely different (and optional) attribute. to the operator (and the implementation) there's not a difference.... > You are also saying that now multipath code which computes which path are > eligible to be multipath needs to look/parse/decrypt totally different > attribute. I didn't say anything about multipath. I presume it'd do the right thing with the meta-attribute it knows about way deep inside bgp processing on platforms that do bgp processing. > All BGP monitoring tools need to be upgraded to now understand BGPSEC > attribute too. And surprise .. here BMP will not convert it like it will = to > "legacy" speakers. sure, they'd have to do that anyway, or they just are 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In other words, tomorrow for them is the same as today, the world keeps on going round. > You may think that if we stuff all "data" in the new attribute and drop t= he > other one everything else will work. This may be so in theory, but it is > clearly not a case in practice. maybe? so far you've not convinced me... you can feel free to keep trying though? email is cheap. > > Regards, > R. > > > >> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk =A0wr= ote: >>> >>> Anyhow my doubt has been answered and I stay by my opinion that not >>> sending >>> AS_PATH and AS4_PATH is a terrible idea. >> >> >> So... we can send the data along, but in the case of BGPSEC speakers >> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). >> Carrying extra bits isn't actually helpful is it? (the implementers >> drove the design decision here I believe) >> >>> Perhaps one could depreciate it in 20 years when world is upgraded to >>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not >>> helpful for any even potential BGPSEC deployment model. >> >> >> is it helpful for the folks that write bgp code though? "Hey, you will >> need to re-synthesize the as-path at sec->non-sec boundaries. you need >> to also create sec-path at none->sec boundaries." >> >> -chris >> >> > From robert@raszuk.net Tue Apr 10 10:49:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E8911E80E8 for ; Tue, 10 Apr 2012 10:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvXysL+ptDMT for ; Tue, 10 Apr 2012 10:49:26 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC621F85D4 for ; Tue, 10 Apr 2012 10:49:26 -0700 (PDT) Received: (qmail 12845 invoked by uid 399); 10 Apr 2012 17:49:25 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 17:49:25 -0000 X-Originating-IP: 83.31.51.142 Message-ID: <4F8472A5.5000700@raszuk.net> Date: Tue, 10 Apr 2012 19:49:25 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Warren Kumari References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:49:27 -0000 Hi Warren, Not seeing the problem/error does not mean it is not there. I would in fact encourage in the initial years of deployment to use both to easily detect bugs and inconsistency issues. In my view we should do all BGP processing based on "legacy" attributes and BGPSEC should be a hint to the local operator on how to treat the update. Actually I am of the opinion (I think similar to some research voices in US) that secured BGP (or for that matter even origin validation) should be handled by few BGP Route Controllers providing AS based overlay certificate processing rather then by each individual BGP speaker in the network. BGP should be able to transport it as purely opaque information which could after automatic detection be used as best path decision/preference factor in a given AS. Regards, R. > On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote: > >> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk wrote: >>> Anyhow my doubt has been answered and I stay by my opinion that not sending >>> AS_PATH and AS4_PATH is a terrible idea. >> >> So... we can send the data along, but in the case of BGPSEC speakers >> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). >> Carrying extra bits isn't actually helpful is it? (the implementers >> drove the design decision here I believe) > > I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same? > > There has been much good work in IDR to better handle bugs / implementations issues, and these considerations probably had much to do with this... > > For example, I'm a BGPSEC speaker. In the BGPSEC bits I see: > > AS1 AS2 AS3 AS4 AS5 All this checks out, the magic crypto says all is happy, etc. > but, in the AS_PATH I see: > AS1 AS 100 AS17 AS6 > > What do I do here? Do I a: drop the update or b: ignore the issue or c: reset the session or d: prefer the singed or unsigned or e: nasal demons? > Someone who's opinion I really respect once said: Never test for an error condition you don't know how to handle. > > This idea extends this by simply not allowing the error condition to occur. > > You have all of the information to recreate the AS_PATH / AS4_PATH when you leave a BGPSEC domain, and because it is only in one place, you sidestep all sorts of weird error corner cases... > > W > > >> >>> Perhaps one could depreciate it in 20 years when world is upgraded to >>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not >>> helpful for any even potential BGPSEC deployment model. >> >> is it helpful for the folks that write bgp code though? "Hey, you will >> need to re-synthesize the as-path at sec->non-sec boundaries. you need >> to also create sec-path at none->sec boundaries." >> >> -chris >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Tue Apr 10 10:57:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DD111E8123 for ; Tue, 10 Apr 2012 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuyG5J+Aa9AV for ; Tue, 10 Apr 2012 10:57:46 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEB411E80FD for ; Tue, 10 Apr 2012 10:57:46 -0700 (PDT) Received: (qmail 26923 invoked by uid 399); 10 Apr 2012 17:57:45 -0000 Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 17:57:45 -0000 X-Originating-IP: 83.31.51.142 Message-ID: <4F847499.9040105@raszuk.net> Date: Tue, 10 Apr 2012 19:57:45 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Christopher Morrow References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <4F846736.2060604@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:57:47 -0000 >> All BGP monitoring tools need to be upgraded to now understand BGPSEC >> attribute too. And surprise .. here BMP will not convert it like it will to >> "legacy" speakers. > > sure, they'd have to do that anyway, or they just are > 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In > other words, tomorrow for them is the same as today, the world keeps > on going round. No. You are breaking things. BMP is not ibgp nor it is ebgp ! The station which works today and get's BGP sessions over BMP will now be useless as AS_PATH will not be there. I assumed you know, but BMP idea is to replay what you are receiving (as verbatim as implementation allows). > maybe? so far you've not convinced me... you can feel free to keep > trying though? email is cheap. I am not sure there is point in "convincing". Removing mandatory path attribute from BGP would be something IDR WG has to formally approve. And it will be an interesting precedence in any case ;) Cheers, R. From jakob.heitz@ericsson.com Tue Apr 10 11:22:32 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0F311E80D9; Tue, 10 Apr 2012 11:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b2rU8Rf8wjk; Tue, 10 Apr 2012 11:22:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD111E80B8; Tue, 10 Apr 2012 11:22:30 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3AIMA24028002; Tue, 10 Apr 2012 13:22:28 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 10 Apr 2012 14:22:26 -0400 From: Jakob Heitz To: Christopher Morrow , "robert@raszuk.net" Date: Tue, 10 Apr 2012 14:22:25 -0400 Thread-Topic: [Idr] [sidr] No BGPSEC intradomain ? Thread-Index: Ac0XOnGsHWavn2A9Q7i3S2WmYqcpNwACgtBQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:22:32 -0000 On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote: > On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk > wrote:=20 >> Anyhow my doubt has been answered and I stay by my opinion that not >> sending AS_PATH and AS4_PATH is a terrible idea. >=20 > So... we can send the data along, but in the case of BGPSEC speakers > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). > Carrying extra bits isn't actually helpful is it? (the implementers > drove the design decision here I believe) I think it was along the lines of: 2 AS paths will create the opportunity for an error if they differ and we don't want to go around the error-handling block again. I agree with Robert. Today, there are many tools that interact with BGP messages. If the AS_PATH disappears, they will all break. --=20 Jakob Heitz.= From christopher.morrow@gmail.com Tue Apr 10 13:56:55 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768EC21F860D; Tue, 10 Apr 2012 13:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgA6Y97dBAc6; Tue, 10 Apr 2012 13:56:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9902B21F85AF; Tue, 10 Apr 2012 13:56:54 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so291481obb.31 for ; Tue, 10 Apr 2012 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fElM47FuFncv6UBiXHR3Dj4MgwXLI0iRMX2mQKu3mmk=; b=ixWH8J8mQXxc5Q72zIElcdkLTLuRNmllZ02BDN7oworjjoMfkAMAXGKu4ACvaHkgWe 1gEwWVV9gmVnFp5vVMrnKqswTY+49dyRRVuaN2Khxwn0svGDoS05hfVeOaSJmBFtTkz0 YkZwBXW8U2rTRb6JKxXEKZKyOggrg2N4OotoksXf4wNpu4kjiVM4vj4IBZHLsaB63vJA ejkD61q2njEMf3oh7/DPkmYyRNIkEmrGUsolCurPkSADCwy66DLRs71oQWWjHTelzumx PuPQhQXAaXy8C2RwUAL9pKq7wd5ZDN1CqGEBFX1j8kRkeGUEv7SgKltJwOk8LxWJjI2F gXAg== MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr18335719obp.49.1334091414230; Tue, 10 Apr 2012 13:56:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 13:56:54 -0700 (PDT) In-Reply-To: <4F8472A5.5000700@raszuk.net> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <4F8472A5.5000700@raszuk.net> Date: Tue, 10 Apr 2012 16:56:54 -0400 X-Google-Sender-Auth: j6ngf-_FLcXWGSJxXO0unxwQWi4 Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:56:56 -0000 On Tue, Apr 10, 2012 at 1:49 PM, Robert Raszuk wrote: > In my view we should do all BGP processing based on "legacy" attributes and > BGPSEC should be a hint to the local operator on how to treat the update. i think that's the point of the current spec though... inbound updates (on BGPSEC capable bgp sessions) which include BGPSEC information get validated by the local router and 'colored' by route-map/policy as the operator sees fit. route-map in-cust permit 10 match bgpsec valid add community 2914:valid this is the functionality you are asking for, yes? From christopher.morrow@gmail.com Tue Apr 10 14:04:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485A311E8154; Tue, 10 Apr 2012 14:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.239 X-Spam-Level: X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b1EXNzWDUZd; Tue, 10 Apr 2012 14:04:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D606C11E8149; Tue, 10 Apr 2012 14:03:49 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so299308obb.31 for ; Tue, 10 Apr 2012 14:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XyCcvNNjWVn0i12Aadq51jNhmVDwqGmlC960LF2KPMo=; b=HAPzioIanN0ippIjbqRpAlYnOuVWVK8XMdjd8mvLHVgtU/J/Rq1i6sH0nHmGX8nMYg x564Ssx67swdiFcFKTUu+BBhVpXaPNazVaBOhzL+iqEEmEzGypt1Lg/qPVQTZYGLnPL2 NRJ07oK4SyirQXzZQRXQxjDlf7le/7iDH65ROZ2pRUjTKzhmMvokOfB8xqBiSAKGwlEJ X7UxZLSjOau7SIg3e8d9iQjX8xQdO4pVDOECmf/cOhCCERgtoBObkCVwkR/kVk3uhmnO 9jQ7zMF3EvfZv8LGOghOF/C4xupV+Kjzz40GqdFw4fFAZn7/WeV7ZZ22gCpIKs5BOZBd K3Lg== MIME-Version: 1.0 Received: by 10.182.74.4 with SMTP id p4mr11080644obv.79.1334091829513; Tue, 10 Apr 2012 14:03:49 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 14:03:49 -0700 (PDT) In-Reply-To: <4F847499.9040105@raszuk.net> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <4F846736.2060604@raszuk.net> <4F847499.9040105@raszuk.net> Date: Tue, 10 Apr 2012 17:03:49 -0400 X-Google-Sender-Auth: FqFpbysZ4c5069eYSxJ9q-eg_SU Message-ID: From: Christopher Morrow To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:04:36 -0000 On Tue, Apr 10, 2012 at 1:57 PM, Robert Raszuk wrote: > >>> All BGP monitoring tools need to be upgraded to now understand BGPSEC >>> attribute too. And surprise .. here BMP will not convert it like it will >>> to >>> "legacy" speakers. >> >> >> sure, they'd have to do that anyway, or they just are >> 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In >> other words, tomorrow for them is the same as today, the world keeps >> on going round. > > > No. You are breaking things. BMP is not ibgp nor it is ebgp ! The station > which works today and get's BGP sessions over BMP will now be useless as > AS_PATH will not be there. great, so ... bmp can either: 1) be treated as a non-BGPSEC speaker (synthesize on the output to bmp listener) 2) be updated to include the BGPSEC relevant data in payload downstream tools using the BMP stream(s) of course would have to be updated. This doesn't seem like a huge deal though, and certainly is expected. > I assumed you know, but BMP idea is to replay what you are receiving (as > verbatim as implementation allows). sure, so it has to know about new bits/pieces, nothing new here. If you catch larry you might get this change/addition into his final/final version before rfc-editor cuts the rfc. > >> maybe? so far you've not convinced me... you can feel free to keep >> trying though? email is cheap. > > > I am not sure there is point in "convincing". Removing mandatory path > attribute from BGP would be something IDR WG has to formally approve. And it > will be an interesting precedence in any case ;) sure... once things settle out on the SIDR side, I'm positive we'll have this discussion in IDR. You seem to be working through the machinations of 'how do I deploy bgpsec in a network', is that the case? would you be willing to document/presentation-style (or wiki or ...) the process for this? It seems like something other folks are going to want to reference/use/discuss as well, so having a few worked examples would be nice. -chris From christopher.morrow@gmail.com Tue Apr 10 14:05:07 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587DB11E8154; Tue, 10 Apr 2012 14:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ6T9ysqvlqr; Tue, 10 Apr 2012 14:05:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46111E814B; Tue, 10 Apr 2012 14:05:01 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so300604obb.31 for ; Tue, 10 Apr 2012 14:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pc3SLTC8lbIAIiJBVG86JKWNtWQoMima21Vve0j5x68=; b=DlaUX5A7Q+eA/90XIrSxQ1UqZoCH3YW+YCV336AAmbPvpFHmb3Qq4ImC6NTenoSqkq u5EbDOOCSlH3LVK6+0xi4j9vGuPoo1RF9M1Jv4jTMVRK5eHevDw9/BdaMdTPFhKVd8Jy IjcQ5/VaA8nuEuqvLJsJI4AaCxAZEnVTFmnGAQ+sYzn8wiG8WEZKa5GkSqHVrLNk/BsR HdLc6jjPMryuxe+y0dSegUUzE29puoHQUvDezkz95knf1Sz7v47i9XSko+ygGns89Pgq TvfOvQX61i2q0wcImpuNyq397CS0q0IqjpuibHPsHCCOax3BP5uAWUH9h5LGELy4t00R fAEQ== MIME-Version: 1.0 Received: by 10.182.159.41 with SMTP id wz9mr17995065obb.69.1334091900958; Tue, 10 Apr 2012 14:05:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 14:05:00 -0700 (PDT) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 10 Apr 2012 17:05:00 -0400 X-Google-Sender-Auth: RkJR20gO2KACrvNk4MCNaJqaQPQ Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , "robert@raszuk.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:05:07 -0000 On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz wrote: > On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote: > >> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk >> wrote: >>> Anyhow my doubt has been answered and I stay by my opinion that not >>> sending AS_PATH and AS4_PATH is a terrible idea. >> >> So... we can send the data along, but in the case of BGPSEC speakers >> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). >> Carrying extra bits isn't actually helpful is it? (the implementers >> drove the design decision here I believe) > > I think it was along the lines of: > 2 AS paths will create the opportunity for an error if they differ > and we don't want to go around the error-handling block again. > > I agree with Robert. Today, there are many tools that interact > with BGP messages. If the AS_PATH disappears, they will all break. aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker. If the tools in question are updated to understand BGPSEC (and negotiate that capability with the bgp speaker) then ... they'd obviously have to know how to deal with this situation, right? -chris From jakob.heitz@ericsson.com Tue Apr 10 14:51:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90111E80DF; Tue, 10 Apr 2012 14:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k31aGmiBXMZQ; Tue, 10 Apr 2012 14:51:35 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7811E80D2; Tue, 10 Apr 2012 14:51:35 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3ALpV3l009585; Tue, 10 Apr 2012 16:51:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 10 Apr 2012 17:51:26 -0400 From: Jakob Heitz To: Christopher Morrow Date: Tue, 10 Apr 2012 17:51:24 -0400 Thread-Topic: [Idr] [sidr] No BGPSEC intradomain ? Thread-Index: Ac0XXpPBlalJJAgKTW6BRADxpxuq2gABNbSg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "robert@raszuk.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:51:37 -0000 On Tuesday, April 10, 2012 2:05 PM, Christopher Morrow <> wrote: > On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz > wrote:=20 >> On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote: >>=20 >>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk >>> wrote: >>>> Anyhow my doubt has been answered and I stay by my opinion that not >>>> sending AS_PATH and AS4_PATH is a terrible idea. >>>=20 >>> So... we can send the data along, but in the case of BGPSEC speakers >>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). >>> Carrying extra bits isn't actually helpful is it? (the implementers >>> drove the design decision here I believe) >>=20 >> I think it was along the lines of: >> 2 AS paths will create the opportunity for an error if they differ >> and we don't want to go around the error-handling block again. >>=20 >> I agree with Robert. Today, there are many tools that interact >> with BGP messages. If the AS_PATH disappears, they will all break. >=20 > aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker. > If the tools in question are updated to understand BGPSEC (and > negotiate that capability with the bgp speaker) then ... they'd > obviously have to know how to deal with this situation, right? >=20 > -chris This will be a hurdle on the way to adoption. I can see the network operator now: "My tools won't run. Let's not turn BGPSEC on today". The error-checking excuse looks real lame to me. --=20 Jakob Heitz.= From randy@psg.com Tue Apr 10 16:20:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACE721F85DD; Tue, 10 Apr 2012 16:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anKx0xWEgiGl; Tue, 10 Apr 2012 16:20:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4321F85BB; Tue, 10 Apr 2012 16:20:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHkMT-000E0s-WC; Tue, 10 Apr 2012 23:20:34 +0000 Date: Wed, 11 Apr 2012 08:20:32 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" , robert@raszuk.net, sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:20:37 -0000 > On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk wrote: >> So... we can send the data along, but in the case of BGPSEC speakers >> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH). it might help if the poster actually read the drafts >> Carrying extra bits isn't actually helpful is it? (the implementers >> drove the design decision here I believe) this is considered a feature, not a bug randy From randy@psg.com Tue Apr 10 16:22:25 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0821F8630; Tue, 10 Apr 2012 16:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnBn2ILaV+aV; Tue, 10 Apr 2012 16:22:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A40C521F862F; Tue, 10 Apr 2012 16:22:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHkOE-000E1S-1i; Tue, 10 Apr 2012 23:22:22 +0000 Date: Wed, 11 Apr 2012 08:22:20 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" , "robert@raszuk.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 23:22:25 -0000 > I can see the network operator now: "My tools won't run. Let's > not turn BGPSEC on today". perhaps a good implementation will present the bgpsec as-path to the operator in the traditional manner? randy From robert@raszuk.net Wed Apr 11 00:25:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C816B21F85D8 for ; Wed, 11 Apr 2012 00:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LFRNcthLBLR for ; Wed, 11 Apr 2012 00:25:33 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id ED4D521F85D2 for ; Wed, 11 Apr 2012 00:25:32 -0700 (PDT) Received: (qmail 30968 invoked by uid 399); 11 Apr 2012 07:25:32 -0000 Received: from unknown (HELO ?192.168.1.55?) (pbs:robert@raszuk.net@83.9.118.191) by mail1310.opentransfer.com with ESMTPM; 11 Apr 2012 07:25:32 -0000 X-Originating-IP: 83.9.118.191 Message-ID: <4F8531F5.7010805@raszuk.net> Date: Wed, 11 Apr 2012 09:25:41 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Jakob Heitz References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:25:33 -0000 On 4/11/2012 1:22 AM, Randy Bush wrote: >> I can see the network operator now: "My tools won't run. Let's >> not turn BGPSEC on today". > > perhaps a good implementation will present the bgpsec as-path to the > operator in the traditional manner? > > randy perhaps it would be great if poster would recognize that we are no longer in the screen scraping era, and got familiar with BMP draft. r. From paul@jakma.org Wed Apr 11 07:12:15 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3771221F8582 for ; Wed, 11 Apr 2012 07:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3fkQ5Te7cfl for ; Wed, 11 Apr 2012 07:12:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFF421F857A for ; Wed, 11 Apr 2012 07:12:13 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so623569wgb.13 for ; Wed, 11 Apr 2012 07:12:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=CKGanJvoWtC7L9hg13kYwnMgGXwv69duiC13Zbn/0kU=; b=MC9jvD4Vfwi0dmWnynDOTwxiVKOf2gh7TdjevjC66udUBspZVWOrKu5OuQAlsDe/R2 Y4aqOooHbgljNLIlKVERGLZ416LwOBe7XVz5lqZDPzUyVnVa8vH6DzckveJd7yFi5a4Q o0pkwVLpvMGU2LrNcvnpD6sNRpwSzaFoQA36PSyJwEuK4czGk2OoOLh1Z2Z0Va51xWEs TsKS8LbtgtanwYtHbpcfQTyWNAxsTPGYj4Ey8d9TNYzpY8kkPTGEL0bOY11u6/+mBMzp gonEiT2Isxa7FGYPsM8tbAONSJwmxQPCWy4q3TojAS4vWZPE3jqIPT65xoeD5+OKyA2q +q/w== Received: by 10.216.145.209 with SMTP id p59mr8985334wej.50.1334153532577; Wed, 11 Apr 2012 07:12:12 -0700 (PDT) Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id fz9sm45180121wib.3.2012.04.11.07.12.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 07:12:09 -0700 (PDT) Date: Wed, 11 Apr 2012 15:12:08 +0100 (BST) From: Paul Jakma X-X-Sender: paul@jamaica.dcs.gla.ac.uk To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQmfotzSQFNrsyrP4FMZf2XALKRcEM8Bc/xSANgk/9wZk4YesLdCV1WHz0oxL4cWS2nIwQgx Cc: "idr@ietf.org List" , "robert@raszuk.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:12:15 -0000 On Tue, 10 Apr 2012, Jakob Heitz wrote: > I agree with Robert. Today, there are many tools that interact with BGP > messages. If the AS_PATH disappears, they will all break. Indeed. If mandatory, well-known attributes are removed, then the BGP protocol version number needs to be bumped. There's near-0-cost in doing that for those interested in implementing the new functionality, and it avoids a world of hurt for all the various tools (sometimes in-house/home-grown) out there that believe they know what they're getting when the version says 4. regards, -- Paul Jakma paul@jakma.org twitter: @pjakma PGP: 64A2FF6A Fortune: Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard From jhaas@slice.pfrc.org Wed Apr 11 07:20:54 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666BA11E809C; Wed, 11 Apr 2012 07:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.215 X-Spam-Level: X-Spam-Status: No, score=-101.215 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alhdU2jfulXh; Wed, 11 Apr 2012 07:20:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BC85521F8584; Wed, 11 Apr 2012 07:20:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 15CDD1703D7; Wed, 11 Apr 2012 10:20:53 -0400 (EDT) Date: Wed, 11 Apr 2012 10:20:53 -0400 From: Jeffrey Haas To: Warren Kumari Message-ID: <20120411142053.GA1283@slice> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , robert@raszuk.net, sidr@ietf.org Subject: [Idr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:20:54 -0000 I'm not at my usual spot in the week to catch up on IETF mail, but this thread is noisy enough that it's caught my attention anyway. :-) On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote: > I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same? The apparent issue in this thread is basically, "what happens to AS_PATH?" Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not thoroughly reading it), there's commentary about what should be done with the AS_PATH. That commentary is mostly correct in the sense that all of the path loop detection is already present. (And the mostly is important.) IMO, there are two specific issues with regard to removing the AS_PATH and one with keeping it. 1. What do you do about confederations? These ASes are not only typically internal but would have to use some sort of internal certs if we decided to cover the confederation case. Additionally, the current encoding format doesn't include AS_PATH segment type as part of the signature. Note in particular that confederation segments MUST be stripped when crossing an eBGP boundary. 2. More generally, what do you do about incremental deployment *within* the AS? One presumption I've been working on that I *thought* was shared by the WG was that BGPSEC procedures only had to be done at eBGP edges. While this is primarily true for signature validation purposes, a desired side effect of having the signature as a optional,transitive that paralleled the AS_PATH was that iBGP speakers don't have to even be BGPSEC aware. This lets you upgrade your network from the outside first and get benefit. As John Scudder likes to say, "a hard, crunchy shell". :-) IMO, we should keep the AS_PATH. 3. Which brings us to the third point - what do we do when the signature and the AS_PATH disagree with each other? Note that this was also a problem for 4-byte ASes (RFC 4893). That spec chose to simply trust the 4-byte path beyond a certain point. (I don't necessarily agree with it, but that's what consensus was.) Exactly what we do here needs to be specified, and some of that specification will come from deciding what we want to do about some things. For example, we want to prevent the path from being shortened. As long as the ASes involved in both signature and path are congruent, we can use the length in the signature if the number of ASes in the path are shorter than the signature. In the case where the paths are still congruent but the AS_PATH has a longer prepend (see my ingress prepending use case from a few sessions back), it may be fine to use the AS_PATH (and its length for route selection purposes). Yes, I understand there isn't consensus here. In the case where the paths are not congruent (which shouldn't happen unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across other BGP), we probably have some sort of hard error case. One reasonable assumption is that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP speaker doing path manipulations for policy. IMO, the proper behavior here is to *not* propagate the route at a BGPSEC ASBR boundary; any BGP speaker that manipulates the AS_PATH in such a way as to break the congruency of ASes between AS_PATH and signature MUST be a BGPSEC speaker. The above still doesn't deal with common deployment considerations such as as-override, replace-as and remove-private. I see there's a thread about proxy signing and perhaps that discussion is over there. I'll hopefully get to it in a few days. (And if you're not familiar with those three features and their deployment scenarios, please take some time to become familiar. Not dealing with them will be a significant deployment hurdle.) -- Jeff From christopher.morrow@gmail.com Wed Apr 11 08:22:41 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21E821F8565; Wed, 11 Apr 2012 08:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6QfyogJ6jql; Wed, 11 Apr 2012 08:22:40 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 340F221F8564; Wed, 11 Apr 2012 08:22:40 -0700 (PDT) Received: by ghbg16 with SMTP id g16so572925ghb.31 for ; Wed, 11 Apr 2012 08:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Cjty43SZKN9D/BGuS/UdOIRdSnjEXRRYQv0Atn3IDSQ=; b=pCGyERgCMuKcizXjIbXtgqv3WZ5DQqQtnKgZAiOONKRFYaTCSjQ+5J5K6vb2fkZI/y tZBZ+1CpBtUis+QzPYQ0LfXiqLTJgvPBaVo78JVFPk5OqQIXfg1Ls2nXypjVtmnuOSgf XfEjxOi3o8Lk3qT9ug86UVmsZO2ePkiGZfKEtv933ZFV0/erYYHK32o69T3oSGOVbazP IbynM11ulClGEskVIiN8hIV1Wb/TglN/b886J7Mcubz4faa0Xpzt8X1afkyegvbzFgK1 SwIj2Kp0n7Fpqtj6GQNiRisoXKXOrJwWKJSNIyVEFtpWtw9Fnl0r8XgU5sPxgESbjhET yOiw== MIME-Version: 1.0 Received: by 10.60.22.138 with SMTP id d10mr3059397oef.69.1334157759726; Wed, 11 Apr 2012 08:22:39 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 08:22:39 -0700 (PDT) In-Reply-To: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 11 Apr 2012 11:22:39 -0400 X-Google-Sender-Auth: 0A1hMHoSzC92RA-AWvo3URoOZ6Y Message-ID: From: Christopher Morrow To: Paul Jakma Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , "robert@raszuk.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:22:41 -0000 On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma wrote: > On Tue, 10 Apr 2012, Jakob Heitz wrote: > >> I agree with Robert. Today, there are many tools that interact with BGP >> messages. If the AS_PATH disappears, they will all break. > > > Indeed. If mandatory, well-known attributes are removed, then the BGP > protocol version number needs to be bumped. > > There's near-0-cost in doing that for those interested in implementing the > new functionality, and it avoids a world of hurt for all the various tools > (sometimes in-house/home-grown) out there that believe they know what > they're getting when the version says 4. "if you don't ask for the 'bgpsec capability' then ... you get what you get today." also "if you ask for the 'bgpsec capabiltiy' then ... you get (and can presumably handle) the changes" so, everything you do today, ought to just keep right on working, or that's the plan. From jakob.heitz@ericsson.com Wed Apr 11 09:17:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07A311E8083; Wed, 11 Apr 2012 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK9+If0m5X38; Wed, 11 Apr 2012 09:17:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 25EDC11E8074; Wed, 11 Apr 2012 09:17:46 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3BGHhSj008408; Wed, 11 Apr 2012 11:17:45 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 11 Apr 2012 12:17:41 -0400 From: Jakob Heitz To: Jeffrey Haas , Warren Kumari Date: Wed, 11 Apr 2012 12:17:40 -0400 Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) Thread-Index: Ac0X7mp45WFSp501Qb+tTgo50fNyTwADu/SQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> In-Reply-To: <20120411142053.GA1283@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:17:47 -0000 Confeds are out of scope. VPN address families are out of scope. If the BGPSEC path does not match the AS_PATH, the update is invalid. The validity of an update is used as an input to route selection. If you have been replace/override/removing ASNs, you are free to use that information in route selection too. IOW, the BGPSEC validity of an update does not necessarily prevent you from using the update if you have inside knowledge about AS path mucking. How you use the BGPSEC validity in your route selection is a private matter. On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote: > I'm not at my usual spot in the week to catch up on IETF mail, but > this=20 > thread is noisy enough that it's caught my attention anyway. :-) >=20 > On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote: >> I think that sone of the biggest issues to keep in mind with >> carrying the "same" data in two places is what to do when you >> suddenly discover that they are not actually the same? =20 >=20 > The apparent issue in this thread is basically, "what happens to > AS_PATH?" Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not > thoroughly reading=20 > it), there's commentary about what should be done with the AS_PATH.=20 > That commentary is mostly correct in the sense that all of the path > loop=20 > detection is already present. (And the mostly is important.) >=20 > IMO, there are two specific issues with regard to removing the > AS_PATH and=20 > one with keeping it. >=20 > 1. What do you do about confederations? These ASes are not only > typically internal but would have to use some sort of internal certs > if we decided to cover the confederation case. Additionally, the > current encoding format doesn't include AS_PATH segment type as part > of the signature.=20 >=20 > Note in particular that confederation segments MUST be stripped when > crossing an eBGP boundary. >=20 > 2. More generally, what do you do about incremental deployment > *within* the=20 > AS? One presumption I've been working on that I *thought* was shared > by the=20 > WG was that BGPSEC procedures only had to be done at eBGP edges.=20 > While this=20 > is primarily true for signature validation purposes, a desired side > effect=20 > of having the signature as a optional,transitive that paralleled the > AS_PATH was that iBGP speakers don't have to even be BGPSEC aware.=20 > This lets you upgrade your network from the outside first and get > benefit.=20 >=20 > As John Scudder likes to say, "a hard, crunchy shell". :-) >=20 > IMO, we should keep the AS_PATH. >=20 > 3. Which brings us to the third point - what do we do when the > signature and the AS_PATH disagree with each other? Note that this > was also a problem for 4-byte ASes (RFC 4893). That spec chose to > simply trust the 4-byte path=20 > beyond a certain point. (I don't necessarily agree with it, but > that's what consensus was.) Exactly what we do here needs to be > specified, and some of that specification will come from deciding > what we want to do about some things.=20 >=20 > For example, we want to prevent the path from being shortened. As > long as=20 > the ASes involved in both signature and path are congruent, we can > use the length in the signature if the number of ASes in the path are > shorter than=20 > the signature. >=20 > In the case where the paths are still congruent but the AS_PATH has a > longer prepend (see my ingress prepending use case from a few > sessions back), it=20 > may be fine to use the AS_PATH (and its length for route selection > purposes). Yes, I understand there isn't consensus here. >=20 > In the case where the paths are not congruent (which shouldn't happen > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across > other BGP), we probably have some sort of hard error case. One > reasonable assumption is=20 > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP > speaker doing path manipulations for policy. IMO, the proper > behavior here is to *not* propagate the route at a BGPSEC ASBR > boundary; any BGP speaker that manipulates the AS_PATH in such a way > as to break the congruency of ASes between AS_PATH and signature MUST > be a BGPSEC speaker.=20 >=20 > The above still doesn't deal with common deployment considerations > such as as-override, replace-as and remove-private. I see there's a > thread about=20 > proxy signing and perhaps that discussion is over there. I'll > hopefully get=20 > to it in a few days. >=20 > (And if you're not familiar with those three features and their > deployment scenarios, please take some time to become familiar. Not > dealing with them will be a significant deployment hurdle.) >=20 > -- Jeff --=20 Jakob Heitz.= From christopher.morrow@gmail.com Wed Apr 11 09:28:33 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18721F8593; Wed, 11 Apr 2012 09:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r7LTCFjecVF; Wed, 11 Apr 2012 09:28:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4E21F8547; Wed, 11 Apr 2012 09:28:33 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1654283obb.31 for ; Wed, 11 Apr 2012 09:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=N8UNhmj6U9DlOJtoltE8HaCjvzXuXR+prNCujyh5JBA=; b=M8Lnm72CXn/wZi12YnwBdAoliTXcXIGlDWJU4xgy0hucmu1TLkdzKz91Vdbdh21+gL iw6d/PA3DsQGpjdmouc4KtfL3K3vznJVCgnbWDB80UPjJWrCD3dVTOq/S5hIAX4nJlCw TGiTW4vf/i2mLtjHX3itQo2Yo+EML2KnMHrypRKr+8GvSrqZEqZNY+cleQHZKUKnX2+C Rq9l3EZtdCNj8G8T9t3FXaGtmpd4RdAaWZNC/VtmJQiQbrsHzG+lZ253sP7uI8aAjUAN 11BgwcbCeusG8EAjVwNu0DkoGSpjXGdiXld3OuxFfHL7s1bnpAlmVJ+mS5UCKSszWu10 F0pg== MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr20797593obp.49.1334161712752; Wed, 11 Apr 2012 09:28:32 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 09:28:32 -0700 (PDT) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 11 Apr 2012 12:28:32 -0400 X-Google-Sender-Auth: yGCbaCBHjo8XcEXtaTjHEamy0Dg Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:28:33 -0000 On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz wrote: > Confeds are out of scope. how are confeds out of scope? if you want path validation for ibgp/originated-by-you routes and the originating router is in one of the confed sub-ases you have that router sign with the confed-external/public asn, no? I'm fairly certain we planned to support this sort of activity... though I could be missing the part which is out-of-scope? > IOW, the BGPSEC validity of an update does not necessarily > prevent you from using the update if you have inside knowledge > about AS path mucking. How you use the BGPSEC validity in > your route selection is a private matter. yes, which is, I think, nice. From brian.peter.dickson@gmail.com Wed Apr 11 09:41:01 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C47D11E809A; Wed, 11 Apr 2012 09:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvweNEz+lYTy; Wed, 11 Apr 2012 09:41:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42911E8089; Wed, 11 Apr 2012 09:40:59 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so727435wgb.13 for ; Wed, 11 Apr 2012 09:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ic4sarfmTwxzIqasiM4WyQ3ROK/JqUSaHXk1gq1/I2g=; b=YT+cMSaCx/7E7YKalpUIAOdJ5pirfaTQ9tVcfLS7WjQ2GFmYAHlXEapK27hQD/FxEW 1YjPYRg2kfCCGrZEpMapIT85+6fFL4vSLmvyLFKDIjmcuczFUwKam+ZO0/pSQbdWBHe8 mc5hGcu0tigs4zMVpWuE3Sq2BJlTbz7tZPAdNeGFkyxmiepaO5vyW8VXr1zcRvNuDAYN LLU+5FOfYxQpMq34lXeJtXgmKZoBv+mUHuz0g4lZBPLt6dsDisBbjzP9WcjPocH9pwwc XAjgWVmrtYKwckNqRMrtTAumS2gZkeJRANKCQMIgRO432bOGpUz0x1ZnDBkhDgWHHdle yXsw== MIME-Version: 1.0 Received: by 10.216.132.6 with SMTP id n6mr9578669wei.26.1334162459060; Wed, 11 Apr 2012 09:40:59 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Wed, 11 Apr 2012 09:40:58 -0700 (PDT) In-Reply-To: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <4F846736.2060604@raszuk.net> Date: Wed, 11 Apr 2012 12:40:58 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=0016e6d784fd71e86704bd69e7f5 Cc: "idr@ietf.org List" , robert@raszuk.net, sidr@ietf.org Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:41:01 -0000 --0016e6d784fd71e86704bd69e7f5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 1:47 PM, Christopher Morrow wrote: > On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk wrote: > > > All BGP monitoring tools need to be upgraded to now understand BGPSEC > > attribute too. And surprise .. here BMP will not convert it like it will > to > > "legacy" speakers. > > sure, they'd have to do that anyway, or they just are > 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In > other words, tomorrow for them is the same as today, the world keeps > on going round. > > > You may think that if we stuff all "data" in the new attribute and drop > the > > other one everything else will work. This may be so in theory, but it is > > clearly not a case in practice. > > maybe? so far you've not convinced me... you can feel free to keep > trying though? email is cheap. > > Okay, I'll bite... Suppose someone wants to take an existing tool which speaks BGP, and writes out full tables and updates to files. Call it "bgpmon". :-) The obvious thing to do for that tool, would be for it to advertise that it speaks BGPSEC, and record the updates that come from BGPSEC speakers. Clearly, this tool is not a router, nor does it need to do validation. In fact, you *don't* want to validate, since you want to record all updates, *including* invalid updates. The ability to do quick-and-dirty comparisons between BGP-vanilla and BGPSEC data, from archived data, would be significantly hampered if the AS_PATH had to be reconstructed from this data. Duplicate bits should really not be a huge deal. Perhaps, at minimum, there should be a negotiated option on whether or not the AS_PATH is included in updates, on a per-neighbor basis? That would allow both sides to win, and even better, provide some measure of interoperability testing, including possibly passing the opaque attribute through non-believers to far-end systems that want to see *all* the BGPSEC data, even when it has crossed outside of the BGPSEC bubble. In particular, this would be very helpful during the incremental deployment phases, where there are *multiple* islands of BGPSEC. Brian --0016e6d784fd71e86704bd69e7f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 1:47 PM, Christo= pher Morrow <morrowc.lists@gmail.com> wrote:
On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <robert@raszuk.net> wrote:
=A0
> All BGP monitoring tools need to be upgraded to now understand BGPSEC<= br> > attribute too. And surprise .. here BMP will not convert it like it wi= ll to
> "legacy" speakers.

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

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

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


Okay, I= 'll bite...

Suppose someone wants to take an e= xisting tool which speaks BGP, and writes out full tables and updates to fi= les. Call it "bgpmon". :-)

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

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

The ability to do quick-and-dirty comparisons between B= GP-vanilla and BGPSEC data, from archived data, would be significantly hamp= ered if the AS_PATH had to be reconstructed from this data.

Duplicate bits should really not be a huge deal.

<= /div>
Perhaps, at minimum, there should be a negotiated option on wheth= er or not the AS_PATH is included in updates, on a per-neighbor basis?

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

In particular, this would be very helpful during the in= cremental deployment phases, where there are *multiple* islands of BGPSEC.<= /div>

Brian
--0016e6d784fd71e86704bd69e7f5-- From jhaas@slice.pfrc.org Wed Apr 11 12:48:10 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9BC11E80C6; Wed, 11 Apr 2012 12:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.278 X-Spam-Level: X-Spam-Status: No, score=-101.278 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9J3mfEM2I1w; Wed, 11 Apr 2012 12:48:09 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B7F0C11E80B8; Wed, 11 Apr 2012 12:48:09 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 42F78170234; Wed, 11 Apr 2012 15:48:09 -0400 (EDT) Date: Wed, 11 Apr 2012 15:48:09 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120411194809.GE1283@slice> References: <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sidr@ietf.org" , "idr@ietf.org List" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:48:10 -0000 On Wed, Apr 11, 2012 at 12:28:32PM -0400, Christopher Morrow wrote: > On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz wrote: > > Confeds are out of scope. > > how are confeds out of scope? > if you want path validation for ibgp/originated-by-you routes and the > originating router is in one of the confed sub-ases you have that > router sign with the confed-external/public asn, no? I'm fairly > certain we planned to support this sort of activity... though I could > be missing the part which is out-of-scope? Functionally, confed segments are stripped prior to the global AS being added to the path. The box performing this function is the one that needs to amend the BGPSEC signature, not some box in the middle of the confederation. -- Jeff From jhaas@slice.pfrc.org Wed Apr 11 12:52:48 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E7711E8075; Wed, 11 Apr 2012 12:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.315 X-Spam-Level: X-Spam-Status: No, score=-101.315 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbqubd5z2X6Z; Wed, 11 Apr 2012 12:52:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BA67521F8458; Wed, 11 Apr 2012 12:52:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 857461703E4; Wed, 11 Apr 2012 15:52:45 -0400 (EDT) Date: Wed, 11 Apr 2012 15:52:45 -0400 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20120411195245.GF1283@slice> References: <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:52:48 -0000 On Wed, Apr 11, 2012 at 12:17:40PM -0400, Jakob Heitz wrote: > Confeds are out of scope. > > VPN address families are out of scope. Meaning that the AS_PATH has to be present. No? (I suspect you mean yes. That's the matter at hand.) > If the BGPSEC path does not match the AS_PATH, the update > is invalid. You mean a 1:1 match of ASes including prepend counts? If so, that's at least an opinion. :-) > The validity of an update is used as an input to route selection. > If you have been replace/override/removing ASNs, you are free to > use that information in route selection too. That depends on path validity. If you require that the AS_PATH and the signature are identical (or potentially accommodate transparent ASes of length 0), you can't do a number of those things without rendering the route invalid. Again, deployment issues. > IOW, the BGPSEC validity of an update does not necessarily > prevent you from using the update if you have inside knowledge > about AS path mucking. How you use the BGPSEC validity in > your route selection is a private matter. In general, I agree. The particulars have consequences. -- Jeff From christopher.morrow@gmail.com Wed Apr 11 12:53:37 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE7311E80E8; Wed, 11 Apr 2012 12:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ4KazCy2Nmy; Wed, 11 Apr 2012 12:53:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A59D111E80DB; Wed, 11 Apr 2012 12:53:33 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1889345obb.31 for ; Wed, 11 Apr 2012 12:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z9X+ISKgcZEcinaxXemvKeEcjS20OX6a4Iat8jE8fiM=; b=wtuvnjVePlNbEMjl1PtNB9OYGfn1EsUBWXMIiZSFvgRIcr7ZcJ4Tfvrmpz4MKkbfRH BPNSuKmBulA0bOjmmJ6H2d2LGEaCCr/drRIwJlrelV1i4m9YSHWHM0qxwwmAvCFwRk8u kWvsCoLnLsIpCf68FxxaEiAT5nbaS65aiWtwXMQtfqxz+Egv9MCu4FWndDR8dvRjAUZL ystCn70mDBO5CHADl0128Lz2KhRkTheyUiZ0KVxpL2C2WfLUTObEnva3WaXVs3neFGkE dvXoidmqLQHjFM5Gm4rtdDriZk+O++EtYDUN0BLTkkcr8RDp/66C1a/0fQUqt8wWFVB9 FzfQ== MIME-Version: 1.0 Received: by 10.182.52.104 with SMTP id s8mr21500861obo.59.1334174009075; Wed, 11 Apr 2012 12:53:29 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 12:53:29 -0700 (PDT) In-Reply-To: <20120411194809.GE1283@slice> References: <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <20120411194809.GE1283@slice> Date: Wed, 11 Apr 2012 15:53:29 -0400 X-Google-Sender-Auth: -o3XdKshdP1Mca-PvcfhsWqipzw Message-ID: From: Christopher Morrow To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:53:37 -0000 On Wed, Apr 11, 2012 at 3:48 PM, Jeffrey Haas wrote: > On Wed, Apr 11, 2012 at 12:28:32PM -0400, Christopher Morrow wrote: >> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz = wrote: >> > Confeds are out of scope. >> >> how are confeds out of scope? >> if you want path validation for ibgp/originated-by-you routes and the >> originating router is in one of the confed sub-ases you have that >> router sign with the confed-external/public asn, no? I'm fairly >> certain we planned to support this sort of activity... though I could >> be missing the part which is out-of-scope? > > Functionally, confed segments are stripped prior to the global AS being > added to the path. =A0The box performing this function is the one that ne= eds > to amend the BGPSEC signature, not some box in the middle of the > confederation. I suppose you could re-sign... the case I was thinking of was attempting to validate inside your domain a prefix supposedly originated by an iBGP speaker inside your domain. From robert@raszuk.net Thu Apr 12 06:52:29 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4386521F85A1 for ; Thu, 12 Apr 2012 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAAGQRpbomxe for ; Thu, 12 Apr 2012 06:52:29 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E4FE621F8566 for ; Thu, 12 Apr 2012 06:52:18 -0700 (PDT) Received: (qmail 17535 invoked by uid 399); 12 Apr 2012 13:52:18 -0000 Received: from unknown (HELO ?172.20.31.168?) (pbs:robert@raszuk.net@64.197.120.3) by mail1310.opentransfer.com with ESMTPM; 12 Apr 2012 13:52:18 -0000 X-Originating-IP: 64.197.120.3 Message-ID: <4F86DE1D.4020505@raszuk.net> Date: Thu, 12 Apr 2012 15:52:29 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "George, Wes" , Paul Jakma References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 13:52:29 -0000 I very much agree with both Paul and Wes that new BGP version number or at least new set of AFIs would be the best way to smoothly migrate unsecure BGP to secure one. I have not seem anyone resisting that idea yet with real technical arguments against it ;) Rgs, R. > [WEG] Why*are* we so resistant to incrementing the BGP version? I > think that there's some merit to the idea that this suite of things > represents a significant enough change to BGP that a change in > version number might be a cleaner way to do the capability > negotiation, perhaps even incorporating other secondary capabilities > so that there isn't so much individual capability negotiation for all > of the things that we've tacked onto BGP4 over the years. In other > words, if you support BGPv5, you support the a list of capabilities > (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to > be negotiated separately. Even if we move directly from version 4 to > 6 as it seems we are wont to do, I think this bears some > consideration (by IDR, of course);-) > > Wes George From jhaas@slice.pfrc.org Thu Apr 12 07:50:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6655E21F8683; Thu, 12 Apr 2012 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.74 X-Spam-Level: X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uogph6M2NH+H; Thu, 12 Apr 2012 07:50:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0389221F8681; Thu, 12 Apr 2012 07:50:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9BCAE1703CC; Thu, 12 Apr 2012 10:50:33 -0400 (EDT) Date: Thu, 12 Apr 2012 10:50:33 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20120412145033.GA9700@slice> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <4F86DE1D.4020505@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F86DE1D.4020505@raszuk.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , "George, Wes" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:50:34 -0000 On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote: > I very much agree with both Paul and Wes that new BGP version number > or at least new set of AFIs would be the best way to smoothly > migrate unsecure BGP to secure one. If it's not backward compatible, sure. > I have not seem anyone resisting that idea yet with real technical > arguments against it ;) See my migration comments earlier. If you think you can get a given SP that might be willing to install BGPSEC at the edges also willing to upgrade every other BGP speaker inside their AS... you're more optimistic than I. -- Jeff From jhaas@slice.pfrc.org Thu Apr 12 07:53:02 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC321F8647; Thu, 12 Apr 2012 07:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.415 X-Spam-Level: X-Spam-Status: No, score=-101.415 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zxFCVVhiMLb; Thu, 12 Apr 2012 07:53:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8B21F8666; Thu, 12 Apr 2012 07:52:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1D9A31703E7; Thu, 12 Apr 2012 10:52:58 -0400 (EDT) Date: Thu, 12 Apr 2012 10:52:58 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120412145258.GB9700@slice> References: <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <20120411194809.GE1283@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sidr@ietf.org" , "idr@ietf.org List" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:53:02 -0000 On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote: > > Functionally, confed segments are stripped prior to the global AS being > > added to the path. ?The box performing this function is the one that needs > > to amend the BGPSEC signature, not some box in the middle of the > > confederation. > > I suppose you could re-sign... the case I was thinking of was > attempting to validate inside your domain a prefix supposedly > originated by an iBGP speaker inside your domain. If you don't trust your own boxes to originate, I think you have a bigger problem. :-) That said, there's little stopping you from using RPKI (perhaps with a local view) data to provide prefix sanity checking. Internally the signature piece is probably excessive. -- Jeff From wesley.george@twcable.com Thu Apr 12 05:08:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8521F865A; Thu, 12 Apr 2012 05:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSjGIvM2gCam; Thu, 12 Apr 2012 05:08:35 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74521F85C2; Thu, 12 Apr 2012 05:08:35 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="366668114" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:07:10 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 12 Apr 2012 08:07:44 -0400 From: "George, Wes" To: Christopher Morrow , Jakob Heitz Date: Thu, 12 Apr 2012 08:07:43 -0400 Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) Thread-Index: Ac0YADE6kaxr3F1XQ5+wa5TqtHNd3QAOgBhg Message-ID: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Apr 2012 08:10:08 -0700 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:08:36 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Wednesday, April 11, 2012 12:29 PM > To: Jakob Heitz > Cc: idr@ietf.org List; sidr@ietf.org > Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSE= C > intradomain ?) > > On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz > wrote: > > Confeds are out of scope. > > how are confeds out of scope? > if you want path validation for ibgp/originated-by-you routes and the > originating router is in one of the confed sub-ases you have that > router sign with the confed-external/public asn, no? I'm fairly > certain we planned to support this sort of activity... though I could > be missing the part which is out-of-scope? > [WEG] There was discussion on the SIDR list on November 12 (subject line "v= arious") specifically regarding private ASNs and confeds and their discussi= on in the bgpsec-ops draft. I am writing offline and therefore can't provid= e a more specific pointer to the message itself nor confirm (as memory of t= he more previous versions that I've reviewed fails) that the product of tha= t discussion has made it to an updated version, but I'm pretty sure that it= has. I'd encourage you to look back at this and see if you have additional= feedback regarding in/out of scope and implementation. FWIW, confeds being truly out of scope may make BGPSec a no-op in my networ= k, as I can't guarantee that confeds will be gone (unless you are suggestin= g that they should be deprecated a la AS_SETs). My earlier recommendation i= s that we have to be specific about how BGPSec handles signing and strippin= g to manage an ASPath including confeds, whether it only signs at the exter= nal side and previous signatures (if exist) are dropped, or if it is capabl= e of handling something like this: Origin ASN (public) -> Transit ASN1 (public) -> [confed ASN(s) (private)] -= > confed ASN42 (public) -> confed ASN55 -- in that example, if the entire p= ath is BGPSec capable, what does ASN42 send as the signed path? You have se= veral ASNs that maybe need path count 0 in their signature so that they are= signed but don't interfere with the externally-visible path, or the Transi= t ASN1 has to forward sign its updates as if they are directly connected to= confed ASN42 (public), meaning that we are potentially allowing it to tran= sit multiple ASNs within the confed unsigned. Randy had said previously tha= t confed ASNs shouldn't sign towards each other, so maybe that answers that= question, but since it has come back up, please give it some thought. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Thu Apr 12 05:31:59 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013F521F8663; Thu, 12 Apr 2012 05:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkEXY90G1kka; Thu, 12 Apr 2012 05:31:58 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8D21F865B; Thu, 12 Apr 2012 05:31:57 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="350188953" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:31:03 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 12 Apr 2012 08:31:45 -0400 From: "George, Wes" To: "idr@ietf.org List" Date: Thu, 12 Apr 2012 08:31:44 -0400 Thread-Topic: [sidr] [Idr] No BGPSEC intradomain ? Thread-Index: Ac0X9vKgDybfDBfvSGCdfgxGGidh+AAQtH5AABuNe1A= Message-ID: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Apr 2012 08:10:08 -0700 Cc: "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:31:59 -0000 Trying again without the signature block. Sorry about that, hit send too so= on. *blush* > > > -----Original Message----- > > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > > Christopher Morrow > > Sent: Wednesday, April 11, 2012 11:23 AM > > To: Paul Jakma > > Cc: idr@ietf.org List; sidr@ietf.org > > Subject: Re: [sidr] [Idr] No BGPSEC intradomain ? > > > > On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma wrote: > > > On Tue, 10 Apr 2012, Jakob Heitz wrote: > > > > > >> I agree with Robert. Today, there are many tools that interact with = BGP > > >> messages. If the AS_PATH disappears, they will all break. > > > > > > > > > Indeed. If mandatory, well-known attributes are removed, then the BGP > > > protocol version number needs to be bumped. > > > > > > There's near-0-cost in doing that for those interested in implementin= g the > > > new functionality, and it avoids a world of hurt for all the various = tools > > > (sometimes in-house/home-grown) out there that believe they know what > > > they're getting when the version says 4. > > > > "if you don't ask for the 'bgpsec capability' then ... you get what > > you get today." > > > > also > > > > "if you ask for the 'bgpsec capabiltiy' then ... you get (and can > > presumably handle) the changes" > > > > so, everything you do today, ought to just keep right on working, or > > that's the plan. > > [WEG] Why *are* we so resistant to incrementing the BGP version? I think = that > there's some merit to the idea that this suite of things represents a > significant enough change to BGP that a change in version number might be= a > cleaner way to do the capability negotiation, perhaps even incorporating = other > secondary capabilities so that there isn't so much individual capability > negotiation for all of the things that we've tacked onto BGP4 over the ye= ars. > In other words, if you support BGPv5, you support the a list of capabilit= ies > (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to be > negotiated separately. Even if we move directly from version 4 to 6 as it > seems we are wont to do, I think this bears some consideration (by IDR, o= f > course) ;-) > > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for > the use of the individual or entity to which it is addressed. If you are = not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may= be > unlawful. If you have received this E-mail in error, please notify the se= nder > immediately and permanently delete the original and any copy of this E-ma= il > and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Thu Apr 12 08:28:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30021F867E; Thu, 12 Apr 2012 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.088 X-Spam-Level: X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5RStd6tcy9l; Thu, 12 Apr 2012 08:28:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9721F8671; Thu, 12 Apr 2012 08:28:44 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3329695obb.31 for ; Thu, 12 Apr 2012 08:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hr5zUVX4GZKT/9tTMUi5wSC8Q912tWbZRggxPRExLYM=; b=fwgjKJDIFkq2i8qTX48CHat6aBnGq8yUbahL5WKjORhx19PJz5dHZ9IOmOuTyJEePT vbrW15D2t1XnOq2ic6io6n8UdP0O2xR5FoZpsunc6oWdvTpZlcx7skS+dWHCUMIRYNId oC2LoaG2Ycm2VV0VHfovafitFiA9iCh6RH+7IWshQZbjgO4LtBlmmKgOYn3oZWKCJG/1 KOcIUFbje92HEvL0GNaB3GZa/0Qq+rn9baHDx6H9u3Qsm1XkJYKvAQNKmh/ZbGA7yBj1 gSgL4BsOdgVodLPPfHz3lGK9PyPRalGaQpKfhuCaYu3Jz7ph0rZeGC+xegVtmdrsbiz7 0Htw== MIME-Version: 1.0 Received: by 10.182.52.104 with SMTP id s8mr3534355obo.59.1334244524079; Thu, 12 Apr 2012 08:28:44 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.153.34 with HTTP; Thu, 12 Apr 2012 08:28:44 -0700 (PDT) In-Reply-To: <20120412145258.GB9700@slice> References: <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <20120411194809.GE1283@slice> <20120412145258.GB9700@slice> Date: Thu, 12 Apr 2012 11:28:44 -0400 X-Google-Sender-Auth: Sjm6YHY2tdr7taJbOTJ54y5oOc4 Message-ID: From: Christopher Morrow To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:28:45 -0000 On Thu, Apr 12, 2012 at 10:52 AM, Jeffrey Haas wrote: > On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote: >> > Functionally, confed segments are stripped prior to the global AS bein= g >> > added to the path. ?The box performing this function is the one that n= eeds >> > to amend the BGPSEC signature, not some box in the middle of the >> > confederation. >> >> I suppose you could re-sign... the case I was thinking of was >> attempting to validate inside your domain a prefix supposedly >> originated by an iBGP speaker inside your domain. > > If you don't trust your own boxes to originate, I think you have a =A0big= ger > problem. :-) yes... where's that box in $HOSTILE_COUNTRY ? are we SURE that no one has tampered with it during the recent 'unscheduled power outage' ? :( darned crapblarghistan and it's ongoing power grid problems! > That said, there's little stopping you from using RPKI (perhaps with a lo= cal > view) data to provide prefix sanity checking. =A0Internally the signature > piece is probably excessive. this is all from another frequent-poster to this list (the requirement I mean)... I'm just parroting it back for the record. (though I do see a valid case to sign on origination as well, and check internally) you don't seem to disagree that the functionality could be there, so ... 'violent agreement'! -chris From jhaas@slice.pfrc.org Thu Apr 12 08:39:21 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4721F864D; Thu, 12 Apr 2012 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.422 X-Spam-Level: X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcrBQ6fsmV26; Thu, 12 Apr 2012 08:39:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 282AD21F8666; Thu, 12 Apr 2012 08:39:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2B6E1170413; Thu, 12 Apr 2012 11:39:16 -0400 (EDT) Date: Thu, 12 Apr 2012 11:39:16 -0400 From: Jeffrey Haas To: Christopher Morrow Message-ID: <20120412153916.GC9700@slice> References: <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <20120411194809.GE1283@slice> <20120412145258.GB9700@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sidr@ietf.org" , "idr@ietf.org List" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 15:39:21 -0000 On Thu, Apr 12, 2012 at 11:28:44AM -0400, Christopher Morrow wrote: > you don't seem to disagree that the functionality could be there, so > ... 'violent agreement'! I think what I'd be saying is "if you want this to be done at point of origination", there's significant work to be done. - Jeff From wesley.george@twcable.com Thu Apr 12 10:07:40 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B309021F86A4; Thu, 12 Apr 2012 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAuf3tV2rPL8; Thu, 12 Apr 2012 10:07:40 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0600D21F865C; Thu, 12 Apr 2012 10:07:39 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,411,1330923600"; d="scan'208";a="366874950" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 13:07:05 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 12 Apr 2012 13:07:38 -0400 From: "George, Wes" To: Jeffrey Haas , Robert Raszuk Date: Thu, 12 Apr 2012 13:07:38 -0400 Thread-Topic: [Idr] [sidr] No BGPSEC intradomain ? Thread-Index: Ac0Yu52Sb0fgrDVUQ3i/YwnZDhisQwAEHdgA Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <4F86DE1D.4020505@raszuk.net> <20120412145033.GA9700@slice> In-Reply-To: <20120412145033.GA9700@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , Paul Jakma , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:07:40 -0000 > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Thursday, April 12, 2012 10:51 AM > To: Robert Raszuk > Cc: George, Wes; Paul Jakma; idr@ietf.org List; sidr@ietf.org > Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? > > On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote: > > I very much agree with both Paul and Wes that new BGP version number > > or at least new set of AFIs would be the best way to smoothly > > migrate unsecure BGP to secure one. > > If it's not backward compatible, sure. [WEG] that's sort of the point -- there are a lot of factors to consider wh= en determining what "backward compatible" truly means as far as BGPSec is c= oncerned, especially when it comes to monitoring tools and other things tha= t need to know the data but not necessarily make routing decisions on it. > > > I have not seem anyone resisting that idea yet with real technical > > arguments against it ;) > > See my migration comments earlier. If you think you can get a given SP t= hat > might be willing to install BGPSEC at the edges also willing to upgrade > every other BGP speaker inside their AS... you're more optimistic than I. [WEG] I'm not totally sure which message you're referring to, but I think t= hat may be a red herring. I'm not seeing how incrementing the BGP version a= utomatically means that all routers in an ASN must upgrade to it. This isn'= t exactly the same flag day sort of driver as the move between v3 and v4. B= GP speakers that support BGPv5 also SHOULD support BGPv4, and would determi= ne which they should use on initial capability negotiation. Same way as the= y would do if BGPSec (and any other option) is a standalone capability to n= egotiate. Even if you look at this from a scaling perspective (the BGPv5 sp= eaker would have to craft and send out two different versions of update) we= 've already sort of said that this is acceptable collateral damage because = of the fact that it can't send the same updates to neighbors of multiple di= fferent ASNs because it has to sign them all differently. What am I missing? Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jhaas@slice.pfrc.org Thu Apr 12 11:21:34 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAAB21F8610; Thu, 12 Apr 2012 11:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.87 X-Spam-Level: X-Spam-Status: No, score=-101.87 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEF9GY0Rkr0U; Thu, 12 Apr 2012 11:21:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CBB9F21F8625; Thu, 12 Apr 2012 11:21:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 776501703EA; Thu, 12 Apr 2012 14:21:23 -0400 (EDT) Date: Thu, 12 Apr 2012 14:21:23 -0400 From: Jeffrey Haas To: "George, Wes" Message-ID: <20120412182123.GE9700@slice> References: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <4F86DE1D.4020505@raszuk.net> <20120412145033.GA9700@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "idr@ietf.org List" , Paul Jakma , Robert Raszuk , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:21:35 -0000 On Thu, Apr 12, 2012 at 01:07:38PM -0400, George, Wes wrote: > [WEG] I'm not totally sure which message you're referring to, but I think that may be a red herring. I'm not seeing how incrementing the BGP version automatically means that all routers in an ASN must upgrade to it. Fish aside, given prior statements that once you leave a BGPSEC domain that you stop doing BGPSEC, then it seems reasonable that you can't have bgp-4 inside of bgpsec. I suspect that's not what some people are meaning by BGPSEC domains or versions or what have you. But this is all fall-out of what does it mean to do BGPSEC in an AS that won't have some number of routers that can do it. The original model discussed was BGPSEC signature operations at eBGP borders. In that model, iBGP considerations are largely irrelevant to the signatures. Where they become important is the edge cases where iBGP may alter AS_PATH data. If iBGP speakers are expected to participate in signature operations, we need to figure out what that means. Chris M. suggests signing at origination - signing to what exactly? When there's confederations, is there signing? What do those certs look like in the RPKI especially when AS numbers are re-used (private ASes)? How do you handle confederation AS stripping signature-wise? If you don't believe each router in an AS needs an upgrade, you obviously have protocol behavior in mind. Write it down, please. Keep in mind the answer will change based on whether BGPSEC operations are done in iBGP or not. > This isn't exactly the same flag day sort of driver as the move between v3 and v4. BGP speakers that support BGPv5 also SHOULD support BGPv4, and would determine which they should use on initial capability negotiation. If you can do the work via capability negotiation, I'd argue you don't really need a new version number. -- Jeff From paul@jakma.org Thu Apr 12 12:01:45 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505DE21F86B0 for ; Thu, 12 Apr 2012 12:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt3p-gYKpYSO for ; Thu, 12 Apr 2012 12:01:43 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0EE21F86A7 for ; Thu, 12 Apr 2012 12:01:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1568531wgb.13 for ; Thu, 12 Apr 2012 12:01:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:x-gm-message-state; bh=FshmqROHKowpPK1oxX4Z5nGKnu6iGvElPHr2NRblDJQ=; b=BQqV5/kTWa5li2znyzOPmCQBwGsI9/t7RIfzxmMbh2o5NKVEkD5noPF/YSORNTRCzs H4tfgMy5lL3maf5cxJkLQdMiufQwsqYMXqZTlGC1ZIc7pyIt599OCZkt+pgsa8n6Ento Wa82YkiWmhb7iSrTbkP54m6eLqL3LMpJv62zr+mPHqfUWueI9Ep5Avm5KXMLlqmNoPYy A1lBsnMa1w611h9pQSJ2e2latob/ZJvTKSkY1PWHj4DSoUUGB7IRYHHhUOjfSKWgGkka ww7eqbQkFJPFvu0T+tGb2R6bRg7hNU1JdEhV5Y09ddQartxpDr5QGedQZ57x3EmJ9Iox tQ+A== Received: by 10.180.86.132 with SMTP id p4mr8426541wiz.15.1334257302550; Thu, 12 Apr 2012 12:01:42 -0700 (PDT) Received: from stoner.gla.jakma.org (stoner.jakma.org. [81.168.24.42]) by mx.google.com with ESMTPS id ff9sm54179234wib.2.2012.04.12.12.01.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 12:01:40 -0700 (PDT) Date: Thu, 12 Apr 2012 20:01:37 +0100 (BST) From: Paul Jakma To: Christopher Morrow In-Reply-To: Message-ID: References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQkbE5hAIUefBy9umVNrs8Kf6pk+0auQRMgWt2NvLWZI8Qr+vLIzJq8mWzRcwegK8bxdOMRq Cc: "idr@ietf.org List" , "robert@raszuk.net" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] No BGPSEC intradomain ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:01:45 -0000 On Wed, 11 Apr 2012, Christopher Morrow wrote: > "if you don't ask for the 'bgpsec capability' then ... you get what > you get today." > so, everything you do today, ought to just keep right on working, or > that's the plan. Capability negotiation does not mean everything keeps on working. It means the session between the BGP speakers keeps working, sure. However, that's _not_ everything. The BGP UPDATE message is no longer context-complete (wrt to the well-known attributes at least). If a 3rd-party wishes to be able to validate the message as cortrect (in the case of missing attributes) or even decode it correctly (in the case where well-known attributes are incompatibly redefined in syntax, like AS_PATH has been), it has to have seen the opening negotiation - which may have happened days or weeks or more before - or it has to be manually configured or make intelligent guesses. It should be quite possible to keep BGP as completely parse-able at the message granularity - it just needs a modicum of care. It's a shame that ever more proposals are coming along that are overloading message formats, dependent on context that may only be exchanged very infrequently... regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: static from plastic slide rules From jakob.heitz@ericsson.com Thu Apr 12 20:59:35 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE95621F871E; Thu, 12 Apr 2012 20:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn6wLPicctaA; Thu, 12 Apr 2012 20:59:35 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 382A221F86F4; Thu, 12 Apr 2012 20:59:34 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3D3xXeR000623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Apr 2012 22:59:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 12 Apr 2012 23:59:33 -0400 From: Jakob Heitz To: Jeffrey Haas , Warren Kumari Date: Thu, 12 Apr 2012 23:59:30 -0400 Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) Thread-Index: Ac0X7mp45WFSp501Qb+tTgo50fNyTwBOdhVg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> In-Reply-To: <20120411142053.GA1283@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:59:35 -0000 On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote: > In the case where the paths are not congruent (which shouldn't happen > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across > other BGP), we probably have some sort of hard error case. One > reasonable assumption is=20 > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP > speaker doing path manipulations for policy. IMO, the proper > behavior here is to *not* propagate the route at a BGPSEC ASBR > boundary; any BGP speaker that manipulates the AS_PATH in such a way > as to break the congruency of ASes between AS_PATH and signature MUST > be a BGPSEC speaker.=20 >=20 > The above still doesn't deal with common deployment considerations > such as as-override, replace-as and remove-private. This just highlights the semantic difference between the BGPSEC path and the AS_PATH. They may be different legitimately. This is why we need both. A receiver can make its own decision whether the difference between the paths should cause path invalidation or not. If a sender is legitimately manipulating an AS_PATH, then the receiver should know about it and use this knowledge to help in the decision. --=20 Jakob Heitz.= From brian.peter.dickson@gmail.com Fri Apr 13 15:05:47 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF311E8132; Fri, 13 Apr 2012 15:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFHDaEJAbDVT; Fri, 13 Apr 2012 15:05:46 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6168B11E8130; Fri, 13 Apr 2012 15:05:45 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so5946771wib.13 for ; Fri, 13 Apr 2012 15:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dfeaOQ2ILu+gazCrOKxXaLJNognTO5oRcfIyNK86Q/U=; b=ajYof+ZQo1A19O3N3Ad081KYFat1YHzVhN5UI4XyU5OLgUYHg1i7G9/FgnjhS9mX9f TrEx5d75tih+ecQVpPp2ry4Akdi7jhT/ZCkxvPdW6OKGnMWJCv+awMhuwUTaDdOIwaBJ WuBWo872tkqO60a4g0rXeFuNIxfbAQ81JM2iGN6QZJ48s6v5bK4aY8xAlpog92yYIM7h JnVCTXvs+so3Kg1IcqzqQZ4ZtwZJeLV6GguOVo9/XsuXaE0ZFmylvZQNbgx0Opji6Krj QsKAgoTnCcUWBNcJp1uIzi0okDzxLEbVvXBqrkEaUftMrmT4ONI1pPFCdjwbdahmCrnR phiA== MIME-Version: 1.0 Received: by 10.180.95.129 with SMTP id dk1mr8528114wib.3.1334354744598; Fri, 13 Apr 2012 15:05:44 -0700 (PDT) Received: by 10.223.88.212 with HTTP; Fri, 13 Apr 2012 15:05:44 -0700 (PDT) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se> References: <4F828D6D.10907@raszuk.net> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se> Date: Fri, 13 Apr 2012 18:05:44 -0400 Message-ID: From: Brian Dickson To: Jakob Heitz Content-Type: multipart/alternative; boundary=f46d0444ee2d8e634304bd96ac1a Cc: "idr@ietf.org List" , "sidr@ietf.org" Subject: Re: [Idr] [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:05:47 -0000 --f46d0444ee2d8e634304bd96ac1a Content-Type: text/plain; charset=ISO-8859-1 At the risk of opening a can of worms (or at least seeing a cylindrical hollow metal labeled "Caution: contains worms")... I believe the larger issue is, that Authentication is orthogonal to Authorization. As it currently stands, only Authentication has been given any consideration, per se. The two things being Authenticated are: o Origination (prefix + ASN, and maybe other identifying elements such as IP addresses of routers), and o ASNs in the AS_PATH. What is not explicitly being discussed, is, the question of "What is $foo Authorized to do?". E.g. The implicit assumption is, Only ASN==X is allowed to originate prefixes whose AS_PATH "starts" (ends) with X. And, the other implicit assumption is, the only thing any ASN is permitted to do, is to prepend its own ASN to the AS_PATH, (zero or) one or more times. However, it may be worth considering all the other things that are done by ASNs currently: o Private ASNs being stripped (private leaf ASNs) o Confederations o Route Servers o ECMP and friends o other vendor-specific or multi-vendor stuff being done to the AS-Path (replace-as, as-sets, etc.) Rather than dogmatically ignoring these issues, or declare them "out of scope!!!", I would prefer to see a rational discussion on whether there is a suitable place in the system, to facilitate some way of handling these cases, in a way that does not weaken the security model. Basically, rather than just say, "Okay, if you want to do this, turn off BGPSEC", I think there is value in saying, "To do this, you need to add $X to $Y to authorize this activity", so that RPs are able to reconcile what they receive, with what the RPKI-encoded data says they should expect. For example: Say that ASs A, B, and C, exchange routes via a route-server AS S. Each of A, B, and C encode something that says, roughly: "I am okay with NLRIs I send to S, have S omitted from the AS_PATH", and, "I am okay with S sending me NLRIs that have S omitted, so long as the immediate AS after S, also allows S to omit itself". So, a signature block "R B S C Q" can be reconciled with an AS_PATH of "R B C Q", by seeing the S sig, and the rules for C->S and S->B allow this, established respectively by all of C, S, and B. The difference between this, and the whole "pCount==0" thing, is that the above is an explicit policy encoded in the RPKI, which can be validated more than one hop away from S. The "pCount==0" logic is only truly verifiable by the immediate recipient, and then only by the operator's personal implementation for enforcing local policy (which itself be weak or faulty). A recipient of an BGPSEC_Signatures_Block which has any pCount==0 in the middle, currently has no way of ascertaining the legitimacy of that occurrence. The Signature Block (AS/N) of "R/1 B/1 S/0 C/1 Q/1" is consistent with an AS_PATH of "R B C Q", but there is no way to know if this is in fact sensible. For other examples: Private ASNs are, by definition, not unique. However, it would still be nice to be able to identify their owners, e.g. by IP address, and validate ASN substitutions by RPKI, based on Origination/Signature data. Proxy Origination would also be nice to have Authorization of Delegation (to sign), possibly chained. E.g. A delegates signature_origination to B, who delegates signature_origination to C. Prefixes assigned to A, could be signed by C, but would validate only if the signed AS_PATH was "C B A". I'm sure there are plenty of other use cases, which match up with actual operator practices today. If the mechanics of this can be done in a scalable and secure manner, this will greatly enhance deployment likelihood, and ease deployment itself. (This is where the IETF in general, can redeem itself for its past sins. Don't ignore real needs, regardless of how tempting it is to keep designs "pure".) IMHO. Brian P.S. This kind of complex stuff really begs face-to-face meeting time. It is hard to convey intent via messages. Oh, the irony... On Thu, Apr 12, 2012 at 11:59 PM, Jakob Heitz wrote: > On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote: > > > In the case where the paths are not congruent (which shouldn't happen > > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across > > other BGP), we probably have some sort of hard error case. One > > reasonable assumption is > > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP > > speaker doing path manipulations for policy. IMO, the proper > > behavior here is to *not* propagate the route at a BGPSEC ASBR > > boundary; any BGP speaker that manipulates the AS_PATH in such a way > > as to break the congruency of ASes between AS_PATH and signature MUST > > be a BGPSEC speaker. > > > > The above still doesn't deal with common deployment considerations > > such as as-override, replace-as and remove-private. > > This just highlights the semantic difference between the BGPSEC > path and the AS_PATH. > > They may be different legitimately. This is why we need both. > > A receiver can make its own decision whether the difference > between the paths should cause path invalidation or not. > If a sender is legitimately manipulating an AS_PATH, then the > receiver should know about it and use this knowledge to help > in the decision. > > -- > Jakob Heitz. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --f46d0444ee2d8e634304bd96ac1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At the risk of opening a can of worms (or at least seeing a cylindrical hol= low metal labeled "Caution: contains worms")...

I believe = the larger issue is, that Authentication is orthogonal to Authorization.
As it currently stands, only Authentication has been given any consider= ation, per se.

The two things being Authenticated are:
o=A0 Origi= nation (prefix + ASN, and maybe other identifying elements such as IP addre= sses of routers), and
o=A0=A0 ASNs in the AS_PATH.

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

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

However, it may be worth considering all the other things that ar= e done by ASNs currently:
o =A0 Private ASNs being stripped (private leaf ASNs)
o =A0 Confederatio= ns
o =A0 Route Servers
o =A0 ECMP and friends
o =A0 other vendor-s= pecific or multi-vendor stuff being done to the AS-Path (replace-as, as-set= s, etc.)

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

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

For example:
Say that ASs A, B, and= C, exchange routes via a route-server AS S.
Each of A, B, and C encode = something that says, roughly:
"I am okay with NLRIs I send to S, have S omitted from the AS_PATH&quo= t;, and,
"I am okay with S sending me NLRIs that have S omitted, so= long as the immediate AS after S, also allows S to omit itself".
So, a signature block "R B S C Q" can be reconciled with an AS_PA= TH of "R B C Q", by seeing the S sig,
and the rules for C->= S and S->B allow this, established respectively by all of C, S, and B.
The difference between this, and the whole "pCount=3D=3D0" th= ing, is that the above is an explicit policy encoded in the RPKI,
which = can be validated more than one hop away from S.

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

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

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

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

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

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

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

IMHO.

Brian

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

On Thu, Apr 12, 2012 at 11:59 PM, Jakob Heit= z <jakob.h= eitz@ericsson.com> wrote:
On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <&g= t; wrote:

> In the case where the paths are not congruent = (which shouldn't happen
> unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec acro= ss
> other BGP), we probably have some sort of hard error case. =A0One
> reasonable assumption is
> that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP > speaker doing path manipulations for policy. =A0IMO, the proper
> behavior here is to *not* propagate the route at a BGPSEC ASBR
> boundary; any BGP speaker that manipulates the AS_PATH in such a way > as to break the congruency of ASes between AS_PATH and signature MUST<= br> > be a BGPSEC speaker.
>
> The above still doesn't deal with common deployment considerations=
> such as as-override, replace-as and remove-private.

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

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

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

--
Jakob Heitz.
_____________________= __________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--f46d0444ee2d8e634304bd96ac1a-- From internet-drafts@ietf.org Fri Apr 13 15:25:27 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A427811E8101; Fri, 13 Apr 2012 15:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwHYmQLfOQF9; Fri, 13 Apr 2012 15:25:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3597F21F873A; Fri, 13 Apr 2012 15:25:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413222527.30747.19974.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 15:25:27 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:25:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Support for Four-octet AS Number Space Author(s) : Quaizar Vohra Enke Chen Filename : draft-ietf-idr-rfc4893bis-05.txt Pages : 11 Date : 2012-04-13 The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-05.txt From internet-drafts@ietf.org Tue Apr 24 07:31:50 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43721F882B; Tue, 24 Apr 2012 07:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP60tcht+UB8; Tue, 24 Apr 2012 07:31:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DA021F87E8; Tue, 24 Apr 2012 07:31:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120424143150.29792.44318.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 07:31:50 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-rfc4893bis-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:31:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : BGP Support for Four-octet AS Number Space Author(s) : Quaizar Vohra Enke Chen Filename : draft-ietf-idr-rfc4893bis-06.txt Pages : 12 Date : 2012-04-24 The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/ From DanielC@orckit.com Wed Apr 25 05:42:36 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772DB21F86C5 for ; Wed, 25 Apr 2012 05:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p80iwZIoot1 for ; Wed, 25 Apr 2012 05:42:33 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [109.226.33.14]) by ietfa.amsl.com (Postfix) with ESMTP id 545B821F8712 for ; Wed, 25 Apr 2012 05:42:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD22E1.2D024931" Date: Wed, 25 Apr 2012 15:44:37 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130777C66C@tlvmail1> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BGP MIBv2 implementation Thread-Index: Ac0iKRxaraXNQ2I/RaKH/x1XRNleCgAs50DQ References: <44F4E579A764584EA9BDFD07D0CA0813076E31CA@tlvmail1> <6246F062-090F-4092-B931-B10F3A84AEB0@juniper.net> <44F4E579A764584EA9BDFD07D0CA0813076E323A@tlvmail1> <283B4946-C3D5-42A0-87D6-02C8FD5CA132@juniper.net> <44F4E579A764584EA9BDFD07D0CA08130777BECD@tlvmail1> From: "Daniel Cohn" To: "Jeffrey Haas" , Subject: Re: [Idr] BGP MIBv2 implementation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 12:42:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD22E1.2D024931 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeff and all, =20 Sorry for the delayed response. I think it would be a shame to go through the hassle of updating the BGP MIB without fully supporting BGP L3VPN/VPLS (in both RFC 4761 and 6074 flavors). Therefore I support using a generic NLRI prefix TC that explicitly supports these NLRIs and can be extended to support future BGP applications. It doesn't seem consistent to add AFI/SAFI to the MIB while leaving the NLRI as an IP address. =20 A couple more suggestions for this draft: =20 - Change the bgp4V2AdjRibsOutTable index to make it the same as in bgp4V2NlriTable. In its current form (a pointer to the bgp4V2NlriTable), it doesn't support BGP routes originated by this speaker (e.g. redistributed from IGP) so it's woefully inadequate. - Add support for BGP communities (as in your communities draft) in the NLRI in/out tables. - Restore local address (and maybe ports) to bgp4V2PeerTable index to support multiple BGP sessions between two speakers as in draft-ietf-grow-diverse-bgp-path-dist =20 Feedback is welcome, regards, =20 Daniel =20 From: Jeffrey Haas [mailto:jhaas@pfrc.orgnet]=20 Sent: Thu, 15 Mar 2012 14:19:17=20 Subject: Re: [Idr] IETF 83 - BGP MIBv2 Update - prefix Textual Conventions =20 Working Group, =20 As per prior plenary discussion on making more effect use of working group session time, please find my BGP MIBv2 update slides on the proceedings page: =20 http://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf =20 The bulk of the presentation is self explanatory. I'd like to thank=20 Bert Wijnen for additional MIB feedback. I suspect we'll get a bit more feedback from him since he discovered bugs as part of doing derivative work for the SIDR MIB. Draft -13 [1] reflects his comments as of the IETF 83 posting cutoff. =20 One item I would like to draw the working group's further attention to is covered on slides 5-7. As part of analyzing the requirements for the multicast next-gen VPN [2] MIBs that Jeffrey Zhang (zzhang at juniper.net) is working on, we briefly considered exposing MVPN routing state in BGP via the BGP MIBv2. Per prior presentations and discussions on design goals for the BGP MIBv2, we wanted one MIB that was capable of being re-used for various types of reachability that was being carried in BGP. However, the primary goal was to be able to carry IPv6 reachability. =20 RFC 6514 can be briefly examined to see the different types of reachability that are being passed around in BGP. The reachability is distinguished within the same AFI/SAFI by a "Route Type" field within the prefix with type specific encodings following. =20 =20 The BGP MIBv2 presents prefixes using the following two objects: bgp4V2NlriPrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of the IP address prefix in the Network Layer Reachability Information field. The value of this object is derived from the appropriate value from the bgp4V2NlriAfi field. Where an appropriate InetAddressType is not available, the value of the object must be unknown(0)." ::=3D { bgp4V2NlriEntry 4 } =20 bgp4V2NlriPrefix OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "An IP address prefix in the Network Layer Reachability Information field. This object is an IP address containing the prefix with length specified by bgp4V2NlriPrefixLen. Any bits beyond the length specified by bgp4V2NlriPrefixLen are zeroed. =20 An implementation is required to support IPv4 prefixes. In this case, the object length is (0..4). =20 An implementation MAY support IPv6 prefixes. In this case, the object length is (0..16)" REFERENCE "RFC 4271, Section 4.3." ::=3D { bgp4V2NlriEntry 5 } =20 The general goal of the "InetAddressType/InetAddress" textual conventions [3] is to provide a level of generality for MIB objects that are "addresses". Our initial design guidance for the BGP MIBv2 was to make use of these TCs to help represent both IPv4 and IPv6 addresses - and it does this well. =20 As part of investigating encoding MVPN prefixes in the BGP MIBv2, I sent mail to the ietfmibs mailing list to discuss this possibility. After a few exchanges, it was suggested that since the information is BGP specific that this was not the best fit for the INET-ADDRESS-MIB and that we should consider a BGP TC specifically for this purpose. =20 If we were to consider such a TC, we would make it "IANA maintained". This would permit us to issue the initial MIB but permit IANA to maintain the code points as new protocol elements are added. I.e. we don't have to have a MIB document stuck as an I-D forever. The current INET-ADDRESS-MIB is an example of such a MIB. =20 After further discussion with Jeffrey Zhang, we determined that there wasn't a strong incentive to continue the MVPN MIB work as a BGP MIBv2 extension, We may see future requirements from other BGP-based address families. =20 =20 My recommendation would be that we proceed with the work to create a BGP Prefix TC MIB with an explicit goal of being backward compatible with the INET-ADDRESS-MIB. However, the WG may also come to the decision to not pursue making this MIB completely general purpose and just worry about IPv4/IPv6. =20 With regard to standards advancement, the new BGP Prefix MIB shouldn't unnecessarily hinder the BGP MIBv2. =20 I would like the WG to come to some consensus as to whether we (very likely, I) take on the work to make such a prefix TC MIB. =20 If the discussion becomes interesting enough, Sue and John have agreed to grant us discussion time at the upcoming IDR session in Paris. =20 -- Jeff =20 ------_=_NextPart_001_01CD22E1.2D024931 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeff and all,

 

Sorry for the delayed response. I think it would be a shame to go = through the hassle of updating the BGP MIB without fully supporting BGP = L3VPN/VPLS (in both RFC 4761 and 6074 flavors). Therefore I support = using a generic NLRI prefix TC that explicitly supports these NLRIs and = can be extended to support future BGP applications. It doesn’t = seem consistent to add AFI/SAFI to the MIB while leaving the NLRI as an = IP address.

 

A couple more suggestions for this draft:

 

-          = Change the bgp4V2AdjRibsOutTable index to make it the same as in = bgp4V2NlriTable. In its current form (a pointer to the bgp4V2NlriTable), = it doesn’t support BGP routes originated by this speaker (e.g. = redistributed from IGP) so it’s woefully = inadequate.

-          = Add support for BGP communities (as in your communities draft) in the = NLRI in/out tables.

-          = Restore local address (and maybe ports) to bgp4V2PeerTable index to = support multiple BGP sessions between two speakers as in = draft-ietf-grow-diverse-bgp-path-dist

 

Feedback is welcome, regards,

 

Daniel

 

From:= = Jeffrey Haas [mailto:jhaas@pfrc.orgnet]
Sent: Thu, 15 Mar = 2012 14:19:17
Subject: Re: [Idr] IETF 83 - BGP MIBv2 Update - = prefix Textual Conventions

 

Working = Group,

 

As per = prior plenary discussion on making more effect use of working = group

session = time, please find my BGP MIBv2 update slides on the = proceedings

page:

 

ht= tp://www.ietf.org/proceedings/83/slides/slides-83-idr-0.pdf

 

The = bulk of the presentation is self explanatory.  I'd like to thank =

Bert = Wijnen for additional MIB feedback.   I suspect we'll get a = bit more

feedback from him since he discovered bugs as part of = doing derivative work

for the = SIDR MIB.  Draft -13 [1] reflects his comments as of the IETF = 83

posting = cutoff.

 

One = item I would like to draw the working group's further attention to = is

covered = on slides 5-7.  As part of analyzing the requirements for = the

multicast next-gen VPN [2] MIBs that Jeffrey Zhang = (zzhang at juniper.net) is

working on, we briefly considered exposing MVPN = routing state in BGP via the

BGP MIBv2.  Per prior presentations and = discussions on design goals for the

BGP MIBv2, we wanted one MIB that was capable of being = re-used for various

types = of reachability that was being carried in BGP.  However, the = primary

goal = was to be able to carry IPv6 reachability.

 

RFC = 6514 can be briefly examined to see the different types of = reachability

that = are being passed around in BGP.  The reachability is = distinguished

within = the same AFI/SAFI by a "Route Type" field within the prefix = with type

specific encodings following.  =

 

The BGP = MIBv2 presents prefixes using the following two = objects:

    bgp4V2NlriPrefixType = OBJECT-TYPE

        = SYNTAX     InetAddressType

        MAX-ACCESS = not-accessible

        = STATUS     current

        = DESCRIPTION

         &= nbsp;  "The type of the IP address prefix in = the

         &= nbsp;   Network Layer Reachability Information = field.

         &= nbsp;   The value of this object is derived from = the

         &= nbsp;   appropriate value from the bgp4V2NlriAfi = field.

         &= nbsp;   Where an appropriate InetAddressType is = not

         &= nbsp;   available, the value of the object must = be

         &= nbsp;   unknown(0)."

        ::=3D { = bgp4V2NlriEntry 4 }

 

    bgp4V2NlriPrefix = OBJECT-TYPE

        = SYNTAX     InetAddress

        MAX-ACCESS = not-accessible

        = STATUS     current

        = DESCRIPTION

         &= nbsp;  "An IP address prefix in the Network = Layer

         &= nbsp;   Reachability Information field. This = object

         &= nbsp;   is an IP address containing the prefix = with

         &= nbsp;   length specified by = bgp4V2NlriPrefixLen.

         &= nbsp;   Any bits beyond the length specified = by

         &= nbsp;   bgp4V2NlriPrefixLen are = zeroed.

 

         &= nbsp;   An implementation is required to support = IPv4

         &= nbsp;   prefixes.  In this case, the object = length

         &= nbsp;   is (0..4).

 

         &= nbsp;   An implementation MAY support IPv6 = prefixes.

         &= nbsp;   In this case, the object length is = (0..16)"

        = REFERENCE

         &= nbsp;  "RFC 4271, Section 4.3."

        ::=3D { = bgp4V2NlriEntry 5 }

 

The = general goal of the "InetAddressType/InetAddress" textual = conventions [3]

is to = provide a level of generality for MIB objects that are = "addresses".

Our = initial design guidance for the BGP MIBv2 was to make use of these = TCs

to help = represent both IPv4 and IPv6 addresses - and it does this = well.

 

As part = of investigating encoding MVPN prefixes in the BGP MIBv2, I = sent

mail to = the ietfmibs mailing list to discuss this possibility.  After a = few

exchanges, it was suggested that since the information = is BGP specific that

this = was not the best fit for the INET-ADDRESS-MIB and that we = should

consider a BGP TC specifically for this = purpose.

 

If we = were to consider such a TC, we would make it "IANA = maintained".  This

would permit us to issue the initial MIB but permit = IANA to maintain the

code = points as new protocol elements are added.  I.e. we don't have to = have

a MIB = document stuck as an I-D forever.  The current INET-ADDRESS-MIB = is

an = example of such a MIB.

 

After = further discussion with Jeffrey Zhang, we determined that there = wasn't

a = strong incentive to continue the MVPN MIB work as a BGP MIBv2 = extension,

We may = see future requirements from other BGP-based address families.  =

 

My = recommendation would be that we proceed with the work to create a = BGP

Prefix = TC MIB with an explicit goal of being backward compatible with = the

INET-ADDRESS-MIB.  However, the WG may also come = to the decision to not

pursue = making this MIB completely general purpose and just worry = about

IPv4/IPv6.

 

With = regard to standards advancement, the new BGP Prefix MIB = shouldn't

unnecessarily hinder the BGP = MIBv2.

 

I would = like the WG to come to some consensus as to whether we (very = likely,

I) take = on the work to make such a prefix TC MIB.

 

If the = discussion becomes interesting enough, Sue and John have agreed = to

grant = us discussion time at the upcoming IDR session in = Paris.

 

-- = Jeff

 

------_=_NextPart_001_01CD22E1.2D024931-- From internet-drafts@ietf.org Sun Apr 29 01:20:24 2012 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8383021F853D; Sun, 29 Apr 2012 01:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KiIVPmGyDlr; Sun, 29 Apr 2012 01:20:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0DF21F8526; Sun, 29 Apr 2012 01:20:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120429082024.13419.16988.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 01:20:24 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 08:20:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Dissemination of Flow Specification Rules for IPv6 Author(s) : Robert Raszuk Burjiz Pithawala Danny McPherson Filename : draft-ietf-idr-flow-spec-v6-03.txt Pages : 8 Date : 2012-04-29 Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/