From nobody Fri May 8 12:41:21 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABE81B2ECE; Fri, 8 May 2015 12:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXIsax2aGVYe; Fri, 8 May 2015 12:41:19 -0700 (PDT) Received: from st13p11im-asmtp002.me.com (st13p11im-asmtp002.me.com [17.164.40.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376731B2ED7; Fri, 8 May 2015 12:41:19 -0700 (PDT) Received: from [192.168.1.14] (48.41-242-81.adsl-dyn.isp.belgacom.be [81.242.41.48]) by st13p11im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NO100AIYQN3NH00@st13p11im-asmtp002.me.com>; Fri, 08 May 2015 19:41:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-08_07:2015-05-08,2015-05-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=50 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1505080233 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Gunter Van De Velde In-reply-to: <9242D615-D355-4521-B60B-56F30AD6F368@icloud.com> Date: Fri, 08 May 2015 21:41:12 +0200 Content-transfer-encoding: quoted-printable Message-id: <3A6FC445-5BC6-4554-B3E1-397E59C337FC@icloud.com> References: <9242D615-D355-4521-B60B-56F30AD6F368@icloud.com> To: opsec@ietf.org X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-opsec-v6.all@ietf.org Subject: [OPSEC] New start of WGLC for draft-ietf-opsec-v6 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 19:41:20 -0000 Dear All, The response to this original WGLC has not been very impressive. Maybe some confusion was caused due to an URL mistake in the original = WGLC request.=20 Hence and new fresh final WGLC is started for the next two weeks. Without solid support, it is unclear what the future of this document = will be as OPSEC WG document. The draft is available at: = https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ The new WGLC will end on 22 May 2015. Brgds, G/ (as OpSec WG co-chair) > On 09 Apr 2015, at 20:08, Gunter Van De Velde = wrote: >=20 > Dear OpSec WG, >=20 > This starts a Working Group Last Call for=20 > draft-ietf-opsec-v6-06 >=20 > (Wes George=E2=80=99s comments on 2th April will be included in the = final WGLC comments) >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ >=20 >=20 > Please review this draft to see if you think it is ready for = publication. >=20 > Send comments to the list, clearly stating your view. >=20 > This WGLC ends Friday 23-Apr-2014. >=20 > Thanks, > G/ > (as OpSec WG co-chair) >=20 >=20 From nobody Tue May 12 10:19:46 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2961ACD7A for ; Tue, 12 May 2015 10:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-z_RPkv2swH for ; Tue, 12 May 2015 10:19:41 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4391ACD5D for ; Tue, 12 May 2015 10:19:40 -0700 (PDT) Received: by widdi4 with SMTP id di4so24720344wid.0 for ; Tue, 12 May 2015 10:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=bdwfl7bIgeoqJgZekF25nL96S+Fpqr6mG7NgvcwmWig=; b=KYKCXi+oEUxVK4LRx7z4IyMVjlCWZxhzfAtVqw7fnPXLKMZlXZa5xB3qCMshCH8Afo kJ3RLRNWKYfPiwD2qrcxQnejhoafFD9P/EBJojsaOH4EP2bXG6fTMAf0Hvk+DjynmCSF ikxNSn4Vndnf9oqI3XzhHFeApWX34YUOtZlQMshk6mflLtM3+2Iluw4dNDWZz9k3zL45 3LOiIINL4ZS6xwGsQSekMRFIOYPMGO4cg4nuul0XD9x5KRfAwEwXhRr5zyy7OmJF8Hd5 8WiN313smoePbKag+wIL7XQ7TyTLpVTPvsZkuR6zHI+q6lKNk6rSIqhNj6mERXvVlCNj OJ3g== MIME-Version: 1.0 X-Received: by 10.194.203.138 with SMTP id kq10mr31451731wjc.124.1431451179754; Tue, 12 May 2015 10:19:39 -0700 (PDT) Received: by 10.194.42.33 with HTTP; Tue, 12 May 2015 10:19:39 -0700 (PDT) Date: Tue, 12 May 2015 19:19:39 +0200 Message-ID: From: Jean-Michel Combes To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86deb21528210515e5b31b Archived-At: Cc: ip@ipspace.net Subject: [OPSEC] [Opsec] RFC7454: clarification about AS-Path Filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:19:43 -0000 --047d7b86deb21528210515e5b31b Content-Type: text/plain; charset=UTF-8 Hi, I am reading this RFC and I have a question about this paragraph (p19, Section 9): "Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless they intend to provide transit for these prefixes." What about prefixes being originated by a network? IMHO, if the announcements for such prefixes are compliant with this requirement (i.e., AS path is empty as the prefixes are not transited but originated), there should be an issue with the previous requirement: "Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path is not the one of the peer's unless the peering is done toward a BGP route server [17 ] (for example, on an IXP) with transparent AS path handling. In that case, this verification needs to be deactivated, as the first AS number will be the one of an IXP member, whereas the peer AS number will be the one of the BGP route server." Am I wrong? Did I miss something? Thanks in advance for your reply. Best regards, JMC. --047d7b86deb21528210515e5b31b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I= am reading this RFC and I have a question about this paragraph (p19, Secti= on 9):
"Network administrators SHOULD NOT advertise prefixes with a= nonempty AS path unless they intend to provide transit for these prefixes.= "

What about prefixes being originated by a network?
<= /div>
IMHO, if the announcements for such prefixes are compliant w= ith this requirement (i.e., AS path is empty as the prefixes are not transi= ted but originated), there should be an issue with the previous requirement= :
"Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path is not the one of the peer's unless the peering is done toward a BGP route server [17] (for example, on an IXP) with transparent AS path handling. In that case, this verification needs to be deactivated, as the first AS number will be the one of an IXP member, whereas the peer AS number will be the one of the BGP route server."

Am I wrong? Did I= miss something?

Thanks in advance for your reply.

Best regards,

JMC.
--047d7b86deb21528210515e5b31b-- From nobody Tue May 12 10:47:23 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AD11ACDB9 for ; Tue, 12 May 2015 10:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_DKOxFOXJOd for ; Tue, 12 May 2015 10:47:20 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89DD41ACDAB for ; Tue, 12 May 2015 10:47:19 -0700 (PDT) Received: by wgin8 with SMTP id n8so18458308wgi.0 for ; Tue, 12 May 2015 10:47:18 -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=IfbJXB845HlsXt+X/twg6n5qPF0WSrpnf2I9TyhqxB0=; b=PjQncy3Z+nqSbf2lynjf9dakVklQXkaBbszl+JnlHYvWXQOd2o1QQUUhblq5SBoPp5 IR06ACLxZYRUCvW7IHx0brZ+eSBySxLWzZdPQiVVb/fowkmBHEbbFVG44xyLqmKnrIyX JZ6PVVUV2WhP26eUhYzVXObe82vBoOxVPdaNHstVZhUVTUzAOd3GhWlYoXYVfxkSft9P QbR0YsU6DoI431pGNO9VQU4GtXVBLTZcxay5fGXG2/2BFqj2EKCfXMxo9CEntJwKWXxI O9fxD53MnD24wZF81dHlhl8rn/6fb4ls8vGL8zyeXeUhup3Po4ZYYxIvwRFpwtWlDzis tHFw== MIME-Version: 1.0 X-Received: by 10.194.133.133 with SMTP id pc5mr638855wjb.31.1431452838328; Tue, 12 May 2015 10:47:18 -0700 (PDT) Received: by 10.194.42.33 with HTTP; Tue, 12 May 2015 10:47:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2015 19:47:18 +0200 Message-ID: From: Jean-Michel Combes To: Ivan Pepelnjak Content-Type: multipart/alternative; boundary=089e01228622f11a2c0515e61588 Archived-At: Cc: "opsec@ietf.org" Subject: Re: [OPSEC] [Opsec] RFC7454: clarification about AS-Path Filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:47:22 -0000 --089e01228622f11a2c0515e61588 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ivan, Thanks for this (very) quick reply :) But what happens regarding the inbound filters on the peer? I mean, this peer knows that the local AS is not a transit provider for these prefixes and so, it should wait for an empty AS path, no? The sentence "Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless either they intend to provide transit for these prefixes or they are originated these prefixes." would not be simply more correct? Thanks again! Best regards, JMC. 2015-05-12 19:31 GMT+02:00 Ivan Pepelnjak : > Local AS (the AS of the BGP speaker) is inserted in the BGP AS path > attribute after the path has been filtered by the outgoing filters. The > local filters will thus NOT see device=E2=80=99s own AS in the AS path, t= he > neighbor receiving the update will. > > Hope this helps, > > Ivan Pepelnjak > www.ipSpace.net / blog.ipSpace.net > > Need a quick expert advice? Try ExpertExpress ( > www.ipspace.net/ExpertExpress) > > On 12 May 2015 at 19:19:44 , Jean-Michel Combes ( > jeanmichel.combes@gmail.com) wrote: > > Hi, > > I am reading this RFC and I have a question about this paragraph (p19, > Section 9): > "Network administrators SHOULD NOT advertise prefixes with a nonempty AS > path unless they intend to provide transit for these prefixes." > > What about prefixes being originated by a network? > > IMHO, if the announcements for such prefixes are compliant with this > requirement (i.e., AS path is empty as the prefixes are not transited but > originated), there should be an issue with the previous requirement: > "Network administrators SHOULD NOT accept prefixes when the first AS > number in the AS path is not the one of the peer's unless the peering is > done toward a BGP route server [17 > ] (for example, on an IXP) > with transparent AS path handling. In that case, this verification needs = to > be deactivated, as the first AS number will be the one of an IXP member, > whereas the peer AS number will be the one of the BGP route server." > > Am I wrong? Did I miss something? > > Thanks in advance for your reply. > > Best regards, > > JMC. > > --089e01228622f11a2c0515e61588 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ivan,

Thanks= for this (very) quick reply :)

But what happens regarding the= inbound filters on the peer?
I mean, this peer knows that the loc= al AS is not a transit provider for these prefixes and so, it should wait f= or an empty AS path, no?

The sentence "Network admin= istrators SHOULD NOT advertise prefixes with a nonempty AS=20 path unless either they intend to provide transit for these prefixes or the= y are originated these prefixes." would not be simply more correct?

Thanks again!

Best regards,

JMC.

20= 15-05-12 19:31 GMT+02:00 Ivan Pepelnjak <ip@ipspace.net>:
Local AS (the AS of the BGP speaker) is inserted in th= e BGP AS path attribute after the path has been filtered by the outgoing fi= lters. The local filters will thus NOT see device=E2=80=99s own AS in the A= S path, the neighbor receiving the update will.

Hope this helps,
=20 =20 =20

Ivan Pepelnjak
www.i= pSpace.net=C2=A0/=C2=A0blog.ipSpace.net
Need a quick expert advice? Try ExpertExpres= s (www.i= pspace.net/ExpertExpress)

=20

On 12 May 2015 at= 19:19:44 , Jean-Michel Combes (jeanmichel.combes@gmail.com) wrote:

Hi,

I am reading this RFC and I have a question about this paragraph (p19, Section 9):
"Network administrators SHOULD NOT advertise prefixes with a nonempty AS path unless they intend to provide transit for these prefixes."

What about prefixes being originated by a network?

IMHO, if the announcements for such prefixes are compliant with this requirement (i.e., AS path is empty as the prefixes are not transited but originated), there should be an issue with the previous requirement:
"Network administrators SHOULD NOT accept prefixes when the first AS number in the AS path is not the one of the peer's unless the peering is done toward a BGP route server [17] (for example, on an IXP) with transparent AS path handling. In that case, this verification needs to be deactivated, as the first AS number will be the one of an IXP member, whereas the peer AS number will be the one of the BGP route server."

Am I wrong? Did I miss something?

Thanks in advance for your reply.

Best regards,

JMC.

--089e01228622f11a2c0515e61588-- From nobody Tue May 12 13:44:06 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7B71AD0BF for ; Tue, 12 May 2015 13:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzSeRnm8EP8k for ; Tue, 12 May 2015 13:44:02 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1492F1AD0B8 for ; Tue, 12 May 2015 13:43:55 -0700 (PDT) X-Original-To: opsec@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2D43F60A99 for ; Tue, 12 May 2015 22:43:53 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C795960798 for ; Tue, 12 May 2015 22:43:52 +0200 (CEST) Received: (qmail 97754 invoked by uid 1007); 12 May 2015 22:43:52 +0200 Date: Tue, 12 May 2015 22:43:52 +0200 From: Gert Doering To: Jean-Michel Combes Message-ID: <20150512204352.GP54385@Space.Net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DzL9ZNgrYYMXm7Ms" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "opsec@ietf.org" , Ivan Pepelnjak Subject: Re: [OPSEC] [Opsec] RFC7454: clarification about AS-Path Filtering X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:44:04 -0000 --DzL9ZNgrYYMXm7Ms Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, May 12, 2015 at 07:47:18PM +0200, Jean-Michel Combes wrote: > The sentence "Network administrators SHOULD NOT advertise prefixes with a > nonempty AS path unless either they intend to provide transit for these > prefixes or they are originated these prefixes." would not be simply more > correct? Advertising your own prefixes is actually matched by filtering on the path ^$ in Cisco regex speak - read: "the empty path". So, it is a slightly complicated way to formulate the thing, but it is correct - a nonempty path means "transit for other ASes", and the empty path is "yourself". On outbound. Your peer, on inbound, won't see an empty path of course. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --DzL9ZNgrYYMXm7Ms Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVVJmCN9WwGXkzn/FAQL1khAAmCxLeyoDj+GPoBmisZDkWWQ9/Wl0L0D3 DGx2qaMmYsox8/GgZ80YFsMpEnvD6j7JAJTh+wsz27LV7kquwUpr6rwygvLJyWVk 11itZI58LkWgULn7ms2l5FbY/UzFR1LjUMQqwD/8HQhEoU1ZlLUxgBqqvzs8dufv VEZLdteWjSAX/TeQO3JAwupX2rNSE+dT8BvNpOWdx4FoNIgBv/yNJ7SlNWkmTC0V vW4jl03QlZpvJ130d/9eiyl8Em+QN1a6WkdPbcPlL+6LNf0F3tRaW0Dzr+RZmPnW TDcAD9w4sve32RKbMnkCZ1jAkWfSJQxGdddOXRB5oiDYaK1IBlZMTZhPrtd4CiX/ PsDIPiyGlmlJTi9trlGijFngRW+aJ7DS9rylnQ0KFi6VKVgNSmBbB55r4O3TSLGV 6BuL2MZdDqPC3bM3M4DnzYgjXsRikS89Mcy3SPKhaV1bm8lg+CBLveVaMPf8cx99 nPhWl/TaCFyJ3XPDjqRmTgEJGBLKEp0z/8MTcpkVSdIXmqyJs8RzdPIQBWx8Ik7T 1rveOmczw1K3ljOfHKqyVFIYnmRvRbqGCXLSLzmM3uutlVmgUBnn7lNVOV/C+Kzm RfcuDGpui0lqlFcEkdvSOfSOp/XUgTlA7k1rrzqPyJX37zGi8qsIqwIYZ3TKVjIR wcorwI+asXo= =1iLm -----END PGP SIGNATURE----- --DzL9ZNgrYYMXm7Ms-- From nobody Fri May 15 09:32:01 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FF71A3BA7; Fri, 15 May 2015 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gILvtcziAPOr; Fri, 15 May 2015 09:31:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 532E91A6F05; Fri, 15 May 2015 09:31:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150515163152.27063.80335.idtracker@ietfa.amsl.com> Date: Fri, 15 May 2015 09:31:52 -0700 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-07.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:31:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Authors : Fernando Gont Will Liu Gunter Van de Velde Filename : draft-ietf-opsec-dhcpv6-shield-07.txt Pages : 11 Date : 2015-05-15 Abstract: This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6 Shield. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 16 06:55:08 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EC21A0264 for ; Sat, 16 May 2015 06:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.981 X-Spam-Level: **** X-Spam-Status: No, score=4.981 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTjuhmOf6VgI for ; Sat, 16 May 2015 06:55:06 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id D441A1A0143 for ; Sat, 16 May 2015 06:55:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4CC0C40175 for ; Sat, 16 May 2015 15:55:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAf2zpFbsg3D for ; Sat, 16 May 2015 15:55:00 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 63A204009C for ; Sat, 16 May 2015 15:55:00 +0200 (CEST) Message-ID: <55574C32.2060404@globis.net> Date: Sat, 16 May 2015 15:54:58 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: opsec@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010000080207080409070407" Archived-At: Subject: Re: [OPSEC] OPSEC Digest, Vol 89, Issue 4 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 13:55:07 -0000 This is a multi-part message in MIME format. --------------010000080207080409070407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Date:Tue, 12 May 2015 22:43:52 +0200 > From: Gert Doering > To: Jean-Michel Combes > Cc:"opsec@ietf.org" , Ivan Pepelnjak > Subject: Re: [OPSEC] [Opsec] RFC7454: clarification about AS-Path > Filtering > Message-ID:<20150512204352.GP54385@Space.Net> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > On Tue, May 12, 2015 at 07:47:18PM +0200, Jean-Michel Combes wrote: >> > The sentence "Network administrators SHOULD NOT advertise prefixes with a >> > nonempty AS path unless either they intend to provide transit for these >> > prefixes or they are originated these prefixes." would not be simply more >> > correct? > > Advertising your own prefixes is actually matched by filtering on the > path ^$ in Cisco regex speak - read: "the empty path". > > So, it is a slightly complicated way to formulate the thing, but it is > correct - a nonempty path means "transit for other ASes", and the empty > path is "yourself". On outbound. > > Your peer, on inbound, won't see an empty path of course. > > Gert Doering > -- NetMaster > -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: > Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 > (0)89/32356-444 USt-IdNr.: DE813185279 Unless you're intentionally performing AS prepending on prefixes you are originating. But I guess that exception should be obvious for most people who configure up BGP. --------------010000080207080409070407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 

Date: Tue, 12 May 2015 22:43:52 +0200
From: Gert Doering <gert@space.net>
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
Cc: "opsec@ietf.org" <opsec@ietf.org>, Ivan Pepelnjak <ip@ipspace.net>
Subject: Re: [OPSEC] [Opsec] RFC7454: clarification about AS-Path
	Filtering
Message-ID: <20150512204352.GP54385@Space.Net>
Content-Type: text/plain; charset="us-ascii"

Hi,

On Tue, May 12, 2015 at 07:47:18PM +0200, Jean-Michel Combes wrote:

> The sentence "Network administrators SHOULD NOT advertise prefixes with a
> nonempty AS path unless either they intend to provide transit for these
> prefixes or they are originated these prefixes." would not be simply more
> correct?


Advertising your own prefixes is actually matched by filtering on the
path ^$ in Cisco regex speak - read: "the empty path".

So, it is a slightly complicated way to formulate the thing, but it is
correct - a nonempty path means "transit for other ASes", and the empty
path is "yourself".  On outbound.

Your peer, on inbound, won't see an empty path of course.

Gert Doering
        -- NetMaster

-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
Unless you're intentionally performing AS prepending on prefixes you are originating.

But I guess that exception should be obvious for most people who configure up BGP.

--------------010000080207080409070407-- From nobody Sat May 30 20:35:03 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B311ACE92 for ; Sat, 30 May 2015 20:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy0IMWcIa_uw for ; Sat, 30 May 2015 20:35:00 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F1E1ACE8D for ; Sat, 30 May 2015 20:35:00 -0700 (PDT) Received: (qmail 19186 invoked from network); 30 May 2015 20:34:50 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 May 2015 20:34:50 -0700 Date: Sat, 30 May 2015 20:34:50 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSEC In-Reply-To: <20150515163152.27063.80335.idtracker@ietfa.amsl.com> Message-ID: References: <20150515163152.27063.80335.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-07.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 03:35:01 -0000 Greetings, The text in Section 3 seems to have dropped the step saying that if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client then a DHCPv6-Shield implementation MUST drop the packet. That omission defeats the entire purpose of the draft and renders it unsuitable for publication. As noted in http://www.ietf.org/mail-archive/web/opsec/current/msg01870.html, this problem was introduced in the -06 version of the draft. Could the authors PLEASE fix this, or else point out where in -07 this step is spelled out? //cmh On Fri, 15 May 2015, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. > > Title : DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers > Authors : Fernando Gont > Will Liu > Gunter Van de Velde > Filename : draft-ietf-opsec-dhcpv6-shield-07.txt > Pages : 11 > Date : 2015-05-15 > > Abstract: > This document specifies a mechanism for protecting hosts connected to > a switched network against rogue DHCPv6 servers. It is based on > DHCPv6 packet-filtering at the layer-2 device at which the packets > are received. A similar mechanism has been widely deployed in IPv4 > networks ('DHCP snooping'), and hence it is desirable that similar > functionality be provided for IPv6 networks. This document specifies > a Best Current Practice for the implementation of DHCPv6 Shield. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > >