From nobody Tue Apr  1 01:48:57 2014
Return-Path: <robert.sleigh@ee.co.uk>
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 04E361A6FFB for <opsec@ietfa.amsl.com>; Tue,  1 Apr 2014 01:48:56 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 r0j2wTGgB0Pu for <opsec@ietfa.amsl.com>; Tue,  1 Apr 2014 01:48:53 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.177]) by ietfa.amsl.com (Postfix) with ESMTP id 29F361A0812 for <opsec@ietf.org>; Tue,  1 Apr 2014 01:48:53 -0700 (PDT)
Received: from [85.158.137.67:34733] by server-17.bemta-3.messagelabs.com id CF/9E-22741-17D7A335; Tue, 01 Apr 2014 08:48:49 +0000
X-Env-Sender: robert.sleigh@ee.co.uk
X-Msg-Ref: server-5.tower-139.messagelabs.com!1396342128!28677251!1
X-Originating-IP: [193.36.79.210]
X-StarScan-Received: 
X-StarScan-Version: 6.11.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25602 invoked from network); 1 Apr 2014 08:48:48 -0000
Received: from unknown (HELO aphex) (193.36.79.210) by server-5.tower-139.messagelabs.com with SMTP; 1 Apr 2014 08:48:48 -0000
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by aphex with MailMarshal (v6, 8, 2, 9371) id <B533a7e130001>; Tue, 01 Apr 2014 09:51:31 +0100
Received: from UK31S005EXS06.EEAD.EEINT.CO.UK ([fe80::d851:f0e3:bba5:c1a0]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.02.0318.004; Tue, 1 Apr 2014 09:48:47 +0100
From: "Sleigh, Robert" <robert.sleigh@ee.co.uk>
To: Marco Ermini <Marco.Ermini@ResMed.com>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] comments for firewall draft
Thread-Index: AQHPTIlSGEUkBVtZGkyikdOJaeSur5r7WW0AgAAMAQCAAQ9cMA==
Date: Tue, 1 Apr 2014 08:48:47 +0000
Message-ID: <679694A32AB94046931C676BEF4BA8B80C8F9093@UK31S005EXS06.EEAD.EEINT.CO.UK>
References: <CAH3bfAC2g7NjZ+CuNtNG2BSpP31uptnim+p7ogZG5i4DpZihfA@mail.gmail.com> <53399D5A.8050802@viagenie.ca> <38465846B6383D4A8688C0A13971900C46A146D7@GE2EML2K1003.corp.resmed.org>
In-Reply-To: <38465846B6383D4A8688C0A13971900C46A146D7@GE2EML2K1003.corp.resmed.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/yq6DbPmJjA9b4g5WV8ol98dl42E
Subject: Re: [OPSEC] comments for firewall draft
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2014 08:48:56 -0000

Hi Marco

-1 for me, no place for NAT in an IPv6 FW doc

Regards
=A0
Bob
07958 318592
=A0
Life's for sharing... and what I like to share the most is a smile

-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Marco Ermini
Sent: 31 March 2014 18:36
To: opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Monday, March 31, 2014 6:53 PM
To: opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

> Do you have specific things in mind that the draft should say on this t=
opic?
>
> IMHO, the fact that NAT is common in firewall equipment is irrelevant.
> Many other functions are common: IPSEC gateway, SSL VPN, IDS, etc. etc.=

> etc. A draft covering everything would be a huge effort with low chance=
=20of success.
>
> I would prefer this draft to remain focused on the core firewall functi=
on.

Well, then the argument is: is NAT a central function in a firewall, espe=
cially in an IPv6 one?

I do believe NAT is a bit different than the others you mentioned, becaus=
e in the great majority of circumstances you would really use a firewall =
to perform NAT.

In all of the other cases you mentioned (VPN, NIDS, etc.) they may be ena=
bled with a license in environments where no better solution is desired, =
required or could be afforded; but they are really not central to a firew=
all, and are better performed with a dedicated system.

Mileage may vary with different firewall brands; e.g. with Juniper, SSL V=
PN is better provided by a dedicated security gateway appliance, while in=
=20Cisco or Palo Alto there is more convergence and this function is enab=
led by license. Anyway, all of them (thinking especially about NIDS/NIPS)=
=20are better provided by dedicated appliances and are not really so cent=
ral for a firewall.

Worth to be noted, in the original RFP document I redacted, there were al=
so all of these functions, but they were removed as it would have been to=
o many things to discuss at once. However, I do think that NAT may have s=
ome special merit. Therefore it would be good to collect votes on that. S=
o far I got 3+ and 1- if I am not wrong.


Marco Ermini=20

Senior IT Security and Compliance Analyst ResMed Germany Inc Fraunhofer S=
tr. 16 - 82152 - Martinsried - Germany ResMed.com=20

=20----------------------------------------------------------------------=

Warning:  Copyright ResMed.  Where the contents of this email and/or atta=
chment includes materials prepared by ResMed, the use of those materials =
is subject exclusively to the conditions of engagement between ResMed and=
=20the intended recipient.  This communication is confidential and may co=
ntain legally privileged information.  By the use of email over the Inter=
net or other communication systems, ResMed is not waiving either confiden=
tiality of, or legal privilege in, the content of the email and of any at=
tachments.  If the recipient of this message is not the intended addresse=
e, please call ResMed immediately on  1 (800) 424-0737 USA.
=20----------------------------------------------------------------------=


_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named p=
erson(s).  If you are not the intended recipient, notify the sender immed=
iately, delete this email from your system and do not disclose or use for=
=20any purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legi=
slation. We have taken steps to ensure that this email and attachments ar=
e free from any virus, but it remains your responsibility to ensure that =
viruses do not adversely affect you.=20

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor=
dshire, AL10 9BW


From nobody Tue Apr  1 02:20:53 2014
Return-Path: <robert.sleigh@ee.co.uk>
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 7566A1A7016 for <opsec@ietfa.amsl.com>; Tue,  1 Apr 2014 02:20:51 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 6CGzdKvdf8wk for <opsec@ietfa.amsl.com>; Tue,  1 Apr 2014 02:20:49 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 698431A098C for <opsec@ietf.org>; Tue,  1 Apr 2014 02:20:48 -0700 (PDT)
Received: from [85.158.137.35:56830] by server-16.bemta-3.messagelabs.com id C9/52-13481-CE48A335; Tue, 01 Apr 2014 09:20:44 +0000
X-Env-Sender: robert.sleigh@ee.co.uk
X-Msg-Ref: server-5.tower-134.messagelabs.com!1396344032!26304504!1
X-Originating-IP: [193.36.79.210]
X-StarScan-Received: 
X-StarScan-Version: 6.11.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3663 invoked from network); 1 Apr 2014 09:20:34 -0000
Received: from unknown (HELO aphex) (193.36.79.210) by server-5.tower-134.messagelabs.com with SMTP; 1 Apr 2014 09:20:34 -0000
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id <B533a85830002>; Tue, 01 Apr 2014 10:23:15 +0100
Received: from UK31S005EXS06.EEAD.EEINT.CO.UK ([fe80::d851:f0e3:bba5:c1a0]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([fe80::5093:62a6:6ee3:7198%11]) with mapi id 14.02.0318.004; Tue, 1 Apr 2014 10:20:31 +0100
From: "Sleigh, Robert" <robert.sleigh@ee.co.uk>
To: "Sleigh, Robert" <robert.sleigh@ee.co.uk>, Marco Ermini <Marco.Ermini@ResMed.com>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] comments for firewall draft
Thread-Index: AQHPTIlSGEUkBVtZGkyikdOJaeSur5r7WW0AgAAMAQCAAQ9cMIAAAlmQ
Date: Tue, 1 Apr 2014 09:20:32 +0000
Message-ID: <679694A32AB94046931C676BEF4BA8B80C8F913E@UK31S005EXS06.EEAD.EEINT.CO.UK>
References: <CAH3bfAC2g7NjZ+CuNtNG2BSpP31uptnim+p7ogZG5i4DpZihfA@mail.gmail.com> <53399D5A.8050802@viagenie.ca> <38465846B6383D4A8688C0A13971900C46A146D7@GE2EML2K1003.corp.resmed.org> <679694A32AB94046931C676BEF4BA8B80C8F9093@UK31S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <679694A32AB94046931C676BEF4BA8B80C8F9093@UK31S005EXS06.EEAD.EEINT.CO.UK>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/5Y7UJXmtj_UBeysXGKqhh2fnbVg
Subject: Re: [OPSEC] comments for firewall draft
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2014 09:20:51 -0000

Hi Marco

A little more clarity  after a little more reflection...

-1 no place for NAT66 or NAT46

+1 for optional/transitional NAT64

in an IPv6 FW doc, on the assumption that the intent to create an "IPv6 F=
W doc" sets it apart from just a "FW doc" where I might expect to see the=
=20full range of IPv4 & IPv6 techniques included...

Regards
=A0
Bob
07958 318592
=A0
Life's for sharing... and what I like to share the most is a smile


-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert
Sent: 01 April 2014 09:49
To: Marco Ermini; opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

Hi Marco

-1 for me, no place for NAT in an IPv6 FW doc

Regards
=A0
Bob
07958 318592
=A0
Life's for sharing... and what I like to share the most is a smile

-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Marco Ermini
Sent: 31 March 2014 18:36
To: opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Monday, March 31, 2014 6:53 PM
To: opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

> Do you have specific things in mind that the draft should say on this t=
opic?
>
> IMHO, the fact that NAT is common in firewall equipment is irrelevant.
> Many other functions are common: IPSEC gateway, SSL VPN, IDS, etc. etc.=

> etc. A draft covering everything would be a huge effort with low chance=
=20of success.
>
> I would prefer this draft to remain focused on the core firewall functi=
on.

Well, then the argument is: is NAT a central function in a firewall, espe=
cially in an IPv6 one?

I do believe NAT is a bit different than the others you mentioned, becaus=
e in the great majority of circumstances you would really use a firewall =
to perform NAT.

In all of the other cases you mentioned (VPN, NIDS, etc.) they may be ena=
bled with a license in environments where no better solution is desired, =
required or could be afforded; but they are really not central to a firew=
all, and are better performed with a dedicated system.

Mileage may vary with different firewall brands; e.g. with Juniper, SSL V=
PN is better provided by a dedicated security gateway appliance, while in=
=20Cisco or Palo Alto there is more convergence and this function is enab=
led by license. Anyway, all of them (thinking especially about NIDS/NIPS)=
=20are better provided by dedicated appliances and are not really so cent=
ral for a firewall.

Worth to be noted, in the original RFP document I redacted, there were al=
so all of these functions, but they were removed as it would have been to=
o many things to discuss at once. However, I do think that NAT may have s=
ome special merit. Therefore it would be good to collect votes on that. S=
o far I got 3+ and 1- if I am not wrong.


Marco Ermini=20

Senior IT Security and Compliance Analyst ResMed Germany Inc Fraunhofer S=
tr. 16 - 82152 - Martinsried - Germany ResMed.com=20

=20----------------------------------------------------------------------=

Warning:  Copyright ResMed.  Where the contents of this email and/or atta=
chment includes materials prepared by ResMed, the use of those materials =
is subject exclusively to the conditions of engagement between ResMed and=
=20the intended recipient.  This communication is confidential and may co=
ntain legally privileged information.  By the use of email over the Inter=
net or other communication systems, ResMed is not waiving either confiden=
tiality of, or legal privilege in, the content of the email and of any at=
tachments.  If the recipient of this message is not the intended addresse=
e, please call ResMed immediately on  1 (800) 424-0737 USA.
=20----------------------------------------------------------------------=


_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named p=
erson(s).  If you are not the intended recipient, notify the sender immed=
iately, delete this email from your system and do not disclose or use for=
=20any purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legi=
slation. We have taken steps to ensure that this email and attachments ar=
e free from any virus, but it remains your responsibility to ensure that =
viruses do not adversely affect you.=20

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor=
dshire, AL10 9BW

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named p=
erson(s).  If you are not the intended recipient, notify the sender immed=
iately, delete this email from your system and do not disclose or use for=
=20any purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legi=
slation. We have taken steps to ensure that this email and attachments ar=
e free from any virus, but it remains your responsibility to ensure that =
viruses do not adversely affect you.=20

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfor=
dshire, AL10 9BW


From nobody Tue Apr  1 02:23:52 2014
Return-Path: <Marco.Ermini@ResMed.com>
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 A13211A802C for <opsec@ietfa.amsl.com>; Tue,  1 Apr 2014 02:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=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 vYIO9_2nkE_S for <opsec@ietfa.amsl.com>; Tue,  1 Apr 2014 02:23:41 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.201]) by ietfa.amsl.com (Postfix) with ESMTP id 533121A8032 for <opsec@ietf.org>; Tue,  1 Apr 2014 02:23:41 -0700 (PDT)
Received: from [216.82.242.131:38977] by server-9.bemta-8.messagelabs.com id 87/87-11188-9958A335; Tue, 01 Apr 2014 09:23:37 +0000
X-Env-Sender: Marco.Ermini@ResMed.com
X-Msg-Ref: server-7.tower-76.messagelabs.com!1396344216!34732075!1
X-Originating-IP: [195.234.33.10]
X-StarScan-Received: 
X-StarScan-Version: 6.11.1; banners=resmed.com,-,-
X-VirusChecked: Checked
Received: (qmail 22218 invoked from network); 1 Apr 2014 09:23:37 -0000
Received: from unknown (HELO mail.resmed.de) (195.234.33.10) by server-7.tower-76.messagelabs.com with SMTP; 1 Apr 2014 09:23:37 -0000
Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mail.resmed.de with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 1 Apr 2014 11:23:36 +0200
Received: from GE2EML2K1003.corp.resmed.org ([fe80::8547:a85:1c2d:a4bd]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%17]) with mapi id 14.01.0355.002; Tue, 1 Apr 2014 11:23:35 +0200
From: Marco Ermini <Marco.Ermini@ResMed.com>
To: "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] comments for firewall draft
Thread-Index: AQHPTIlWpyXEukspEkWNz7BwNWd4kZr7SKkAgAAqYWCAAODAgIAACN4AgAAhuSA=
Date: Tue, 1 Apr 2014 09:23:35 +0000
Message-ID: <38465846B6383D4A8688C0A13971900C46A17E3F@GE2EML2K1003.corp.resmed.org>
References: <CAH3bfAC2g7NjZ+CuNtNG2BSpP31uptnim+p7ogZG5i4DpZihfA@mail.gmail.com> <53399D5A.8050802@viagenie.ca> <38465846B6383D4A8688C0A13971900C46A146D7@GE2EML2K1003.corp.resmed.org> <679694A32AB94046931C676BEF4BA8B80C8F9093@UK31S005EXS06.EEAD.EEINT.CO.UK> <679694A32AB94046931C676BEF4BA8B80C8F913E@UK31S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <679694A32AB94046931C676BEF4BA8B80C8F913E@UK31S005EXS06.EEAD.EEINT.CO.UK>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.17.48.87]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Apr 2014 09:23:36.0654 (UTC) FILETIME=[0F6C26E0:01CF4D8C]
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/9iDtySa7pos2ukMw2ky4r-zmF_Q
Subject: Re: [OPSEC] comments for firewall draft
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2014 09:23:44 -0000

Fine for me.

Fernando already commented on this, and he said he is engaged in adding so=
me words in the draft describing why NAT (or other functions for what that=
 matters) are not included.

Does anyone else think we should add "optional/transitional NAT64" to the =
draft?


Marco Ermini

Senior IT Security and Compliance Analyst
=20
ResMed Germany Inc=A0Fraunhofer Str. 16 - 82152 - Martinsried - Germany

ResMed.com


-----Original Message-----
From: Sleigh, Robert [mailto:robert.sleigh@ee.co.uk]=20
Sent: Tuesday, April 01, 2014 11:21 AM
To: Sleigh, Robert; Marco Ermini; opsec@ietf.org
Subject: RE: [OPSEC] comments for firewall draft

Hi Marco

A little more clarity  after a little more reflection...

-1 no place for NAT66 or NAT46

+1 for optional/transitional NAT64

in an IPv6 FW doc, on the assumption that the intent to create an "IPv6 FW=
 doc" sets it apart from just a "FW doc" where I might expect to see the f=
ull range of IPv4 & IPv6 techniques included...

Regards
=A0
Bob
07958 318592
=A0
Life's for sharing... and=20what I like to share the most is a smile


-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Sleigh, Robert
Sent: 01 April 2014 09:49
To: Marco Ermini; opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

Hi Marco

-1 for me, no place for NAT in an IPv6 FW doc

Regards
=A0
Bob
07958 318592
=A0
Life's for sharing... and what I like to share the most is a smile

-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Marco Ermini
Sent: 31 March 2014 18:36
To: opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Monday, March 31, 2014 6:53 PM
To: opsec@ietf.org
Subject: Re: [OPSEC] comments for firewall draft

> Do you have specific things in mind that the draft should say on this to=
pic?
>
> IMHO, the fact that NAT is common in firewall equipment is irrelevant.
> Many other functions are common: IPSEC gateway, SSL VPN, IDS, etc. etc.
> etc. A draft covering everything would be a huge effort with low chance =
of success.
>
> I would prefer this draft to remain focused on the core firewall functio=
n.

Well, then the argument is: is NAT a central function in a firewall, espec=
ially in an IPv6 one?

I do believe NAT is a bit different than the others you mentioned, because=
 in the great majority of circumstances you would really use a firewall to=
 perform NAT.

In all of the other cases you mentioned (VPN, NIDS, etc.) they may be enab=
led with a license in environments where no better solution is desired, re=
quired or could be afforded; but they are really not central to a firewall=
, and are better performed with a dedicated system.

Mileage may vary with different firewall brands; e.g. with Juniper, SSL VP=
N is better provided by a dedicated security gateway appliance, while in C=
isco or Palo Alto there is more convergence and this function is enabled b=
y license. Anyway, all of them (thinking especially about NIDS/NIPS) are b=
etter provided by=20dedicated appliances and are not really so central for=
 a firewall.

Worth to be noted, in the original RFP document I redacted, there were als=
o all of these functions, but they were removed as it would have been too =
many things to discuss at once. However, I do think that NAT may have some=
 special merit. Therefore it would be good to collect votes on that. So fa=
r I got 3+ and 1- if I am not wrong.


Marco Ermini=20

Senior IT Security and Compliance Analyst ResMed Germany Inc Fraunhofer St=
r. 16 - 82152 - Martinsried - Germany ResMed.com=20

 ----------------------------------------------------------------------
Warning:  Copyright ResMed.  Where the contents of this email and/or attac=
hment includes materials prepared by ResMed, the use of those materials is=
 subject exclusively to the conditions of engagement between ResMed and th=
e intended recipient.  This communication is confidential and may contain =
legally privileged information.  By the use of email over the Internet or =
other communication systems, ResMed is not waiving either confidentiality =
of, or legal privilege in, the content of the email and of any attachments=
.  If the recipient of this message is not the intended addressee, please =
call ResMed immediately on  1 (800) 424-0737 USA.
 ----------------------------------------------------------------------

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named pe=
rson(s).  If you are not the intended recipient, notify the sender immedia=
tely, delete this email from your system and do not disclose or use for an=
y purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legis=
lation. We have taken steps to ensure that this email and attachments are =
free from any virus, but it remains your responsibility to ensure that vir=
uses do not adversely affect you.=20

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertford=
shire, AL10 9BW

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named pe=
rson(s).  If you are not the intended recipient, notify the sender immedia=
tely, delete this email from your system and do not disclose or use for an=
y purpose. =20
=20
We may monitor all incoming and outgoing emails in line with current legis=
lation. We have taken steps to ensure that this email and attachments are =
free from any virus, but it remains your responsibility to ensure that vir=
uses do not adversely affect you.=20

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertford=
shire, AL10 9BW

 ----------------------------------------------------------------------
Warning:  Copyright ResMed.  Where the contents of this email and/or attac=
hment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between R=
esMed and the intended recipient.  This communication is confidential and =
may contain legally privileged information.  By the use of email over the =
Internet or other communication systems, ResMed is not waiving either conf=
identiality of, or legal privilege in, the content of the email and of any=
 attachments.  If the recipient of this message is not the intended addres=
see, please call ResMed immediately on  1 (800) 424-0737 USA.
 ----------------------------------------------------------------------


From nobody Tue Apr  8 02:18:27 2014
Return-Path: <gvandeve@cisco.com>
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 344001A01CE for <opsec@ietfa.amsl.com>; Tue,  8 Apr 2014 02:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.51
X-Spam-Level: 
X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 pHCwbsOoFBCA for <opsec@ietfa.amsl.com>; Tue,  8 Apr 2014 02:18:19 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 853471A01BB for <opsec@ietf.org>; Tue,  8 Apr 2014 02:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6996; q=dns/txt; s=iport; t=1396948694; x=1398158294; h=from:to:cc:subject:date:message-id:mime-version; bh=aFjNKZrg8YLlYcX9hDnNZu7dzzJJMu1VWmHC1h8OT6Y=; b=U5Bl5M4CPpj7l5Vhv/AYqQPDhn9zuzcQ5J+Tb9glF4sQUviIytPGZ9Af WzXB3zadQIoK3cyJeOJbG20OwWnM6dTqHwB4a+zjyVKHn66CXiGP1l7IY OAd1g1LMUvpxPpY8Dtto4GBjFsJqYMrv3ucJpK/fZ+HwnhArGPm7JRc1f s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiYFAGC+Q1OtJV2a/2dsb2JhbABZgkJEO1fEI4EeFnSCJwEEHRBMEgEqViYBBA4Nh3ENyiMTBI45LQSDK4EUBKscgzCCKw
X-IronPort-AV: E=Sophos; i="4.97,816,1389744000"; d="scan'208,217"; a="33905333"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 08 Apr 2014 09:18:13 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s389IDHV012201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 09:18:13 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 8 Apr 2014 04:18:13 -0500
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: opsec wg mailing list <opsec@ietf.org>
Thread-Topic: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQ==
Date: Tue, 8 Apr 2014 09:18:13 +0000
Message-ID: <67832B1175062E48926BF3CB27C49B241138EAF1@xmb-aln-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.84.61]
Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B241138EAF1xmbalnx12ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/DPNDRJ8wfCh5npz41xF1JNVsdEA
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>
Subject: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Apr 2014 09:18:24 -0000

--_000_67832B1175062E48926BF3CB27C49B241138EAF1xmbalnx12ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear OpSec WG,



This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security=
.

Due to the time taken to integrate all comments from the first WGLC this 2n=
d WGLC is initiated.



All three authors have replied, stating that they do not know of any IPR as=
sociated with this draft.


The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op=
sec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-onl=
y/>


Please review this draft to see if you think it is ready for publication an=
d comments to the list, clearly stating your view.



This WGLC ends 22-April-2014.



Thanks,

G/


--_000_67832B1175062E48926BF3CB27C49B241138EAF1xmbalnx12ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Dear O=
pSec WG,</span><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot=
;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><br>
<br>
<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">This s=
tarts a 2<sup>nd</sup> Working Group Last Call for draft-ietf-opsec-bgp-sec=
urity.<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Due to=
 the time taken to integrate all comments from the first WGLC this 2<sup>nd=
</sup> WGLC is initiated.<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black"><o:p>&=
nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">All th=
ree authors have replied, stating that they do not know of any IPR associat=
ed with this draft.</span><span style=3D"font-size:13.5pt;font-family:&quot=
;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">The dr=
aft is available here:</span><span style=3D"font-size:13.5pt;font-family:&q=
uot;Times&quot;,&quot;serif&quot;;color:black"><a href=3D"https://datatrack=
er.ietf.org/doc/draft-ietf-opsec-lla-only/"><span style=3D"font-family:&quo=
t;Arial&quot;,&quot;sans-serif&quot;;color:black">
 https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/</span></a>=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Please=
 review this draft to see if you think it is ready for publication and comm=
ents to the list, clearly stating your view.</span><span style=3D"font-size=
:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><br>
<br>
<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">This W=
GLC ends 22-April-2014.</span><span style=3D"font-size:13.5pt;font-family:&=
quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><br>
<br>
<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Thanks=
,</span><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot=
;serif&quot;;color:black"><o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">G/</sp=
an><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;seri=
f&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_67832B1175062E48926BF3CB27C49B241138EAF1xmbalnx12ciscoc_--


From nobody Tue Apr  8 03:08:55 2014
Return-Path: <fgont@si6networks.com>
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 20F061A01FF for <opsec@ietfa.amsl.com>; Tue,  8 Apr 2014 03:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 0jsYVIOGuMWV for <opsec@ietfa.amsl.com>; Tue,  8 Apr 2014 03:08:48 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC01A02A5 for <opsec@ietf.org>; Tue,  8 Apr 2014 03:08:17 -0700 (PDT)
Received: from [186.137.77.143] (helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1WXSwo-0007Aw-Kb; Tue, 08 Apr 2014 12:08:06 +0200
Message-ID: <5343CA7C.6030109@si6networks.com>
Date: Tue, 08 Apr 2014 07:07:56 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Smith, Donald" <Donald.Smith@CenturyLink.com>,  Marco Ermini <Marco.Ermini@ResMed.com>, "opsec@ietf.org" <opsec@ietf.org>
References: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org> <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet>
In-Reply-To: <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Rg32xIgZzzyLRtiDQvaaXJM0KYY
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Apr 2014 10:08:54 -0000

On 02/18/2014 08:39 PM, Smith, Donald wrote:
> Just a nit initially.
> "This document
>    specifies a set of requirements for IPv6 firewalls, marked as
>    "mandatory", "recommended", or "optional"."
> 
> 
> That isn't the language we use.

FWIW, the plan is to change the requirements language to:

---- cut here ----
   In this document, the words that are used to define the significance
   of each particular requirement are capitalized.  These words are:

   o  "MUST" This word, or the words "REQUIRED" and "SHALL" mean that
      the item is an absolute requirement of the specification.

   o  "SHOULD" This word or the adjective "RECOMMENDED" means that there
      may exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before choosing a different course.

   o  "MAY" This word or the adjective "OPTIONAL" means that this item
      is truly optional.  One vendor may choose to include the item
      because a particular marketplace requires it or because it
      enhances the product, for example; another vendor may omit the
      same item.

   A firewall implementation is a module that supports at least one of
   the feature types defined in this document.  Firewall implementations
   may support multiple feature types, but conformance is considered
   individually for each type.

   A firewall implementation is not compliant with a specific feature
   type if it fails to satisfy one or more of the MUST requirements of
   such specific feature type.  An implementation that satisfies all the
   MUST and all the SHOULD requirements of a specific feature is said to
   be "unconditionally compliant" with such feature type; one that
   satisfies all the MUST requirements but not all the SHOULD
   requirements is said to be "conditionally compliant" with such
   feature type.
---- cut here ----

So you may decide to implement one set of feature, but not another. e.g.
"This device is fully-compliant wit the general security requirements in
[fw-reqs], conditionally-compliant to the reporting requirements in
[fw-reqs]", etc.

(FWIW, this was partly borrowed from the firewalls performance
benchmarking rfc, and part from some other rfc)

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Apr  9 14:05:49 2014
Return-Path: <wesley.george@twcable.com>
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 40D581A024D for <opsec@ietfa.amsl.com>; Wed,  9 Apr 2014 14:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.664
X-Spam-Level: **
X-Spam-Status: No, score=2.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, 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 h_R8NHVRF7mD for <opsec@ietfa.amsl.com>; Wed,  9 Apr 2014 14:05:30 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 90DA11A0232 for <opsec@ietf.org>; Wed,  9 Apr 2014 14:05:30 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.97,828,1389762000";  d="scan'208,217";a="255326567"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Apr 2014 17:03:22 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 9 Apr 2014 17:05:29 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>, opsec wg mailing list <opsec@ietf.org>
Date: Wed, 9 Apr 2014 17:05:27 -0400
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9UN2+/T1QHbw+ATLC7yGU3XgLHJQ==
Message-ID: <CF6B0FC1.179B5%wesley.george@twcable.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CF6B0FC1179B5wesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/EHAHFniBgk2lodUlLGq6keOQFUc
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2014 21:05:38 -0000

--_000_CF6B0FC1179B5wesleygeorgetwcablecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmXZlIHJldmlld2VkIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoaXMgZHJhZnQsIGJ1dCBtYWRl
IGEgbmV3IHBhc3MgdGhyb3VnaCBpdC4NCkkgdGhpbmsgaXTigJlzIG1vc3RseSByZWFkeSB0byBw
dWJsaXNoLCB0aG91Z2ggc29saWNpdGluZyByZXZpZXdzIGZyb20gbm9uLUlFVEYgb3BlcmF0b3Ig
bGlzdHMgbWlnaHQgYmUgYSBnb29kIHRoaW5nIHRvIGRvIGJlZm9yZSB3ZSBnbyB0byBJRVRGIExD
Lg0KDQpUaGUgYWJzdHJhY3QgbmVlZHMgdG8gcmVtb3ZlIHRoZSByZWZlcmVuY2UgdG8gTUQ1IHNp
bmNlIGl0IGlzIGRlcHJlY2F0ZWQuIFNpbWlsYXJseSwgc2VjdGlvbiA0LjEgbmVlZHMgdG8gZXhw
bGljaXRseSBub3RlIHRoYXQgTUQ1IGhhcyBiZWVuIGRlcHJlY2F0ZWQgYnkgQU8sIG5vdCBzaW1w
bHkgcmVjb21tZW5kIHRoYXQgQU8gYmUgdXNlZCB3aGVuIGF2YWlsYWJsZS4gSeKAmWxsIGNvbmNl
ZGUgdGhhdCBNRDUgaXMgYmV0dGVyIHRoYW4gbm90aGluZywgYnV0IGl04oCZcyBub3Qgc29tZXRo
aW5nIHdlIHdhbnQgdG8gcmVjb21tZW5kIGluIGEgbmV3IEJDUCB3aXRob3V0IGJlaW5nIGNsZWFy
IHdoeSBpdCBzaG91bGRu4oCZdCBiZSB1c2VkIGFueW1vcmUuDQoNClRoZXJlIGFyZSBwbGFjZXMg
d2hlcmUgd29yZHMgbGlrZSDigJxyZWNvbW1lbmRlZCIgYXJlIHVzZWQgaW4gd2F5cyB0aGF0IGxv
b2sgdG8gYmUgMjExOSB1c2FnZSwgYnV0IGFyZSBub3QgY2FwaXRhbGl6ZWQuIFRoaXMgbmVlZHMg
dG8gYmUgY29uc2lzdGVudCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCwgc28gdGhhdCB0aGV5IGFy
ZSB1c2VkIHdoZW5ldmVyIGEgcmVjb21tZW5kYXRpb24gaXMgYmVpbmcgbWFkZSBhcyBzb21ldGhp
bmcgdGhhdCB5b3UgU0hPVUxEL01VU1QgZG8gaW4gb3JkZXIgdG8gYmUgaW4gY29tcGxpYW5jZSB3
aXRoIHRoaXMgQmVzdCBDb21tb24gUHJhY3RpY2UuDQoNClNlY3Rpb24gMy0gbWF5IHdhbnQgdG8g
bWVudGlvbiByYXRlLWxpbWl0aW5nIGFjY2VwdGVkIHRyYWZmaWMgaW4gYWRkaXRpb24gdG8gc3Ry
aWN0IGZpbHRlcmluZyBvZiB1bmFjY2VwdGFibGUgdHJhZmZpYw0KDQo0LjEg4oCTIHJlZmVyZW5j
ZSB0byBCQ1AzOCBpbiB0aGUg4oCcYmxvY2sgc3Bvb2ZlZCBwYWNrZXRz4oCdIHNlY3Rpb24gYXQg
dGhlIGVuZD8NCg0KNS4xLjIuMyDigJMgcmVmZXJlbmNlIHRvIElSUnRvb2xzZXQ/DQoNCjUuMi4x
IChvciBwb3NzaWJseSBzZWN0aW9uIDgpIC0gRmlsdGVyaW5nIHBlZXIgQVNlcyBpbmJvdW5kIGZy
b20gY3VzdG9tZXJzPyAoaW4gdGhpcyBjYXNlIOKAnHBlZXLigJ0gbWVhbmluZyBhIG5vbi10cmFu
c2l0IGludGVyY29ubmVjdCwgbm90IGp1c3Qgc29tZW9uZSB5b3UgYXJlIGNvbm5lY3RlZCB0byB2
aWEgQkdQKSBJLmUuIElmIEkga25vdyB0aGF0IEkgc2hvdWxkIG9ubHkgcmVjZWl2ZSByb3V0ZXMg
d2l0aCA3MDEgaW4gdGhlIHBhdGggZnJvbSA3MDEgYmVjYXVzZSBJIGRvIG5vdCB1c2UgYW55IG90
aGVyIEFTTiBhcyB0cmFuc2l0IHRvIHJlYWNoIDcwMSwgSSBzaG91bGQgZmlsdGVyIHJvdXRlcyBp
bmJvdW5kIGZyb20gb3RoZXIgc291cmNlcyB0byBlbnN1cmUgdGhhdCB0aGV5IGRvbuKAmXQgYW5u
b3VuY2Ugcm91dGVzIHdpdGggdGhhdCBwYXRoLiBUaGlzIGlzIHNvbWV3aGVyZSBiZXR3ZWVuIHRo
ZSBzdHJpY3QgSVJSIGJhc2VkIGZpbHRlcnMgYW5kIHRoZSBsb29zZSBmaWx0ZXJzLCBhbmQgZGVw
ZW5kcyBvbiB0aGUgdG9wb2xvZ3kgb2YgdGhlIG5ldHdvcmsgYW5kIG15IGJ1c2luZXNzIHJlbGF0
aW9uc2hpcHMsIGJ1dCBJIHRoaW5rIGl04oCZcyBhIHVzZWZ1bCBwb2ludCB0byBtYWtlIHRvIGFk
ZCBzb21lIGFkZGl0aW9uYWwgc2FmZXR5IGZpbHRlcmluZyB0byBwcmV2ZW50IOKAnG15IGlkaW90
IGN1c3RvbWVyIGlzIHRyeWluZyB0byByZS1hbm5vdW5jZSB0aGUgaW50ZXJuZXQgdG8gbWXigJ0g
YWxvbmcgd2l0aCBtYXgtcHJlZml4LCB3aGljaCB5b3UgYWxyZWFkeSBjb3Zlci4NCg0KU2VjdGlv
biAxMeKAmXMgZnV0dXJlIHdvcmsgZWl0aGVyIG5lZWRzIHRvIGJlIGNvbXBsZXRlZCBpbiB0aGlz
IGRvY3VtZW50IG9yIGV4cGxpY2l0bHkgaWRlbnRpZmllZCBhcyB3b3JrIGZvciBhIGZ1dHVyZSBk
b2N1bWVudC4gVGhlIFdHIG5lZWRzIHRvIGRpc2N1c3Mgd2hhdCBpcyBhcHByb3ByaWF0ZSB0byBh
ZGQgdG8gdGhpcyBkb2MgdnMgbGVhdmUgZm9yIGZ1dHVyZSB3b3JrIGJlZm9yZSB0aGlzIHByb2Nl
ZWRzLg0KDQpTZWN0aW9uIDEyIG5lZWRzIGV4cGxpY2l0IG5vdGVzIHRvIHRoZSBSRkMgZWRpdG9y
IHRvIHJlbW92ZSB0aGUgc2VjdGlvbiBwcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KVGhpcyBtYXkg
YmUgc29tZXRoaW5nIHRoYXQgdGhlIFJGQyBlZGl0b3Igd2lsbCBmaXgsIGJ1dCBpdCB3b3VsZCBi
ZSBwcmVmZXJhYmxlIHRvIHVzZSB0aGUgYWN0dWFsIGRyYWZ0IG5hbWUgb3IgUkZDIG51bWJlciBh
cyB0aGUgcmVmZXJlbmNlIHRhZyBpbnN0ZWFkIG9mIG51bWVyaWMgdGFncywgc28gdGhhdCB0aGUg
cmVhZGVyIGtub3dzIHdoYXQgeW91IGFyZSByZWZlcmVuY2luZyB3aXRob3V0IGhhdmluZyB0byBq
dW1wIHRvIGZvb3Rub3RlcyBlYWNoIHRpbWUuDQoNCg0KVGhhbmtzLA0KDQpXZXMgR2VvcmdlDQoN
Cg0KRnJvbTogIkd1bnRlciBWYW4gZGUgVmVsZGUgKGd2YW5kZXZlKSIgPGd2YW5kZXZlQGNpc2Nv
LmNvbTxtYWlsdG86Z3ZhbmRldmVAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDgs
IDIwMTQgYXQgNToxOCBBTQ0KVG86IG9wc2VjIHdnIG1haWxpbmcgbGlzdCA8b3BzZWNAaWV0Zi5v
cmc8bWFpbHRvOm9wc2VjQGlldGYub3JnPj4NCkNjOiAiZHJhZnQtaWV0Zi1vcHNlYy1iZ3Atc2Vj
dXJpdHlAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3BzZWMtYmdwLXNlY3VyaXR5
QHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtb3BzZWMtYmdwLXNlY3VyaXR5QHRvb2xzLmll
dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLWJncC1zZWN1cml0eUB0b29scy5pZXRmLm9y
Zz4+DQpTdWJqZWN0OiBbT1BTRUNdIFN0YXJ0IG9mIDJuZCBXR0xDIGZvciBkcmFmdC1pZXRmLW9w
c2VjLWJncC1zZWN1cml0eQ0KDQoNCkRlYXIgT3BTZWMgV0csDQoNCg0KDQpUaGlzIHN0YXJ0cyBh
IDJuZCBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1vcHNlYy1iZ3Atc2Vj
dXJpdHkuDQoNCkR1ZSB0byB0aGUgdGltZSB0YWtlbiB0byBpbnRlZ3JhdGUgYWxsIGNvbW1lbnRz
IGZyb20gdGhlIGZpcnN0IFdHTEMgdGhpcyAybmQgV0dMQyBpcyBpbml0aWF0ZWQuDQoNCg0KDQpB
bGwgdGhyZWUgYXV0aG9ycyBoYXZlIHJlcGxpZWQsIHN0YXRpbmcgdGhhdCB0aGV5IGRvIG5vdCBr
bm93IG9mIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRoIHRoaXMgZHJhZnQuDQoNCg0KVGhlIGRyYWZ0
IGlzIGF2YWlsYWJsZSBoZXJlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLW9wc2VjLWJncC1zZWN1cml0eS88aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtaWV0Zi1vcHNlYy1sbGEtb25seS8+DQoNCg0KUGxlYXNlIHJldmlldyB0aGlzIGRy
YWZ0IHRvIHNlZSBpZiB5b3UgdGhpbmsgaXQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFuZCBj
b21tZW50cyB0byB0aGUgbGlzdCwgY2xlYXJseSBzdGF0aW5nIHlvdXIgdmlldy4NCg0KDQoNClRo
aXMgV0dMQyBlbmRzIDIyLUFwcmlsLTIwMTQuDQoNCg0KDQpUaGFua3MsDQoNCkcvDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz
IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGlu
Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3Qg
dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwg
aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0
eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55
IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGlu
IHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1h
aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg
Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K

--_000_CF6B0FC1179B5wesleygeorgetwcablecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PknigJl2ZSByZXZpZXdlZCBwcmV2aW91cyB2ZXJzaW9ucyBvZiB0aGlzIGRyYWZ0LCBidXQg
bWFkZSBhIG5ldyBwYXNzIHRocm91Z2ggaXQuPC9kaXY+DQo8ZGl2PkkgdGhpbmsgaXTigJlzIG1v
c3RseSByZWFkeSB0byBwdWJsaXNoLCB0aG91Z2ggc29saWNpdGluZyByZXZpZXdzIGZyb20gbm9u
LUlFVEYgb3BlcmF0b3IgbGlzdHMgbWlnaHQgYmUgYSBnb29kIHRoaW5nIHRvIGRvIGJlZm9yZSB3
ZSBnbyB0byBJRVRGIExDLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGFic3Ry
YWN0IG5lZWRzIHRvIHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRvIE1ENSBzaW5jZSBpdCBpcyBkZXBy
ZWNhdGVkLiBTaW1pbGFybHksIHNlY3Rpb24gNC4xIG5lZWRzIHRvIGV4cGxpY2l0bHkgbm90ZSB0
aGF0IE1ENSBoYXMgYmVlbiBkZXByZWNhdGVkIGJ5IEFPLCBub3Qgc2ltcGx5IHJlY29tbWVuZCB0
aGF0IEFPIGJlIHVzZWQgd2hlbiBhdmFpbGFibGUuIEnigJlsbCBjb25jZWRlIHRoYXQgTUQ1IGlz
IGJldHRlciB0aGFuIG5vdGhpbmcsDQogYnV0IGl04oCZcyBub3Qgc29tZXRoaW5nIHdlIHdhbnQg
dG8gcmVjb21tZW5kIGluIGEgbmV3IEJDUCB3aXRob3V0IGJlaW5nIGNsZWFyIHdoeSBpdCBzaG91
bGRu4oCZdCBiZSB1c2VkIGFueW1vcmUuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj5UaGVyZSBhcmUgcGxhY2VzIHdoZXJlIHdvcmRzIGxpa2Ug4oCccmVjb21tZW5kZWQmcXVv
dDsgYXJlIHVzZWQgaW4gd2F5cyB0aGF0IGxvb2sgdG8gYmUgMjExOSB1c2FnZSwgYnV0IGFyZSBu
b3QgY2FwaXRhbGl6ZWQuIFRoaXMgbmVlZHMgdG8gYmUgY29uc2lzdGVudCB0aHJvdWdob3V0IHRo
ZSBkb2N1bWVudCwgc28gdGhhdCB0aGV5IGFyZSB1c2VkIHdoZW5ldmVyIGEgcmVjb21tZW5kYXRp
b24gaXMgYmVpbmcgbWFkZSBhcyBzb21ldGhpbmcgdGhhdCB5b3UNCiBTSE9VTEQvTVVTVCBkbyBp
biBvcmRlciB0byBiZSBpbiBjb21wbGlhbmNlIHdpdGggdGhpcyBCZXN0IENvbW1vbiBQcmFjdGlj
ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlY3Rpb24gMy0gbWF5IHdhbnQgdG8g
bWVudGlvbiByYXRlLWxpbWl0aW5nIGFjY2VwdGVkIHRyYWZmaWMgaW4gYWRkaXRpb24gdG8gc3Ry
aWN0IGZpbHRlcmluZyBvZiB1bmFjY2VwdGFibGUgdHJhZmZpYzwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+NC4xIOKAkyByZWZlcmVuY2UgdG8gQkNQMzggaW4gdGhlIOKAnGJsb2NrIHNw
b29mZWQgcGFja2V0c+KAnSBzZWN0aW9uIGF0IHRoZSBlbmQ/PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj41LjEuMi4zIOKAkyByZWZlcmVuY2UgdG8gSVJSdG9vbHNldD88L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjUuMi4xIChvciBwb3NzaWJseSBzZWN0aW9uIDgpIC0gRmls
dGVyaW5nIHBlZXIgQVNlcyBpbmJvdW5kIGZyb20gY3VzdG9tZXJzPyAoaW4gdGhpcyBjYXNlIOKA
nHBlZXLigJ0gbWVhbmluZyBhIG5vbi10cmFuc2l0IGludGVyY29ubmVjdCwgbm90IGp1c3Qgc29t
ZW9uZSB5b3UgYXJlIGNvbm5lY3RlZCB0byB2aWEgQkdQKSBJLmUuIElmIEkga25vdyB0aGF0IEkg
c2hvdWxkIG9ubHkgcmVjZWl2ZSByb3V0ZXMgd2l0aCA3MDEgaW4gdGhlIHBhdGggZnJvbQ0KIDcw
MSBiZWNhdXNlIEkgZG8gbm90IHVzZSBhbnkgb3RoZXIgQVNOIGFzIHRyYW5zaXQgdG8gcmVhY2gg
NzAxLCBJIHNob3VsZCBmaWx0ZXIgcm91dGVzIGluYm91bmQgZnJvbSBvdGhlciBzb3VyY2VzIHRv
IGVuc3VyZSB0aGF0IHRoZXkgZG9u4oCZdCBhbm5vdW5jZSByb3V0ZXMgd2l0aCB0aGF0IHBhdGgu
IFRoaXMgaXMgc29tZXdoZXJlIGJldHdlZW4gdGhlIHN0cmljdCBJUlIgYmFzZWQgZmlsdGVycyBh
bmQgdGhlIGxvb3NlIGZpbHRlcnMsIGFuZCBkZXBlbmRzDQogb24gdGhlIHRvcG9sb2d5IG9mIHRo
ZSBuZXR3b3JrIGFuZCBteSBidXNpbmVzcyByZWxhdGlvbnNoaXBzLCBidXQgSSB0aGluayBpdOKA
mXMgYSB1c2VmdWwgcG9pbnQgdG8gbWFrZSB0byBhZGQgc29tZSBhZGRpdGlvbmFsIHNhZmV0eSBm
aWx0ZXJpbmcgdG8gcHJldmVudCDigJxteSBpZGlvdCBjdXN0b21lciBpcyB0cnlpbmcgdG8gcmUt
YW5ub3VuY2UgdGhlIGludGVybmV0IHRvIG1l4oCdIGFsb25nIHdpdGggbWF4LXByZWZpeCwgd2hp
Y2ggeW91IGFscmVhZHkNCiBjb3Zlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNl
Y3Rpb24gMTHigJlzIGZ1dHVyZSB3b3JrIGVpdGhlciBuZWVkcyB0byBiZSBjb21wbGV0ZWQgaW4g
dGhpcyBkb2N1bWVudCBvciBleHBsaWNpdGx5IGlkZW50aWZpZWQgYXMgd29yayBmb3IgYSBmdXR1
cmUgZG9jdW1lbnQuIFRoZSBXRyBuZWVkcyB0byBkaXNjdXNzIHdoYXQgaXMgYXBwcm9wcmlhdGUg
dG8gYWRkIHRvIHRoaXMgZG9jIHZzIGxlYXZlIGZvciBmdXR1cmUgd29yayBiZWZvcmUgdGhpcyBw
cm9jZWVkcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlY3Rpb24gMTIgbmVlZHMg
ZXhwbGljaXQgbm90ZXMgdG8gdGhlIFJGQyBlZGl0b3IgdG8gcmVtb3ZlIHRoZSBzZWN0aW9uIHBy
aW9yIHRvIHB1YmxpY2F0aW9uLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
VGhpcyBtYXkgYmUgc29tZXRoaW5nIHRoYXQgdGhlIFJGQyBlZGl0b3Igd2lsbCBmaXgsIGJ1dCBp
dCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvIHVzZSB0aGUgYWN0dWFsIGRyYWZ0IG5hbWUgb3IgUkZD
IG51bWJlciBhcyB0aGUgcmVmZXJlbmNlIHRhZyBpbnN0ZWFkIG9mIG51bWVyaWMgdGFncywgc28g
dGhhdCB0aGUgcmVhZGVyIGtub3dzIHdoYXQgeW91IGFyZSByZWZlcmVuY2luZyB3aXRob3V0IGhh
dmluZyB0byBqdW1wIHRvIGZvb3Rub3Rlcw0KIGVhY2ggdGltZS4mbmJzcDs8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVm
dDogMGluOyI+DQpUaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp
bjsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsiPg0K
V2VzIEdlb3JnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47Ij4NCjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10
b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47Ij4NCjxicj4NCjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP
TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4
dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP
UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU
OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7
IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtHdW50ZXIgVmFuIGRlIFZl
bGRlIChndmFuZGV2ZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpndmFuZGV2ZUBjaXNjby5j
b20iPmd2YW5kZXZlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCA4LCAyMDE0IGF0IDU6MTggQU08
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5vcHNlYyB3ZyBt
YWlsaW5nIGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpvcHNlY0BpZXRmLm9yZyI+b3BzZWNAaWV0
Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z
cGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2VjLWJncC1zZWN1cml0eUB0
b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1vcHNlYy1iZ3Atc2VjdXJpdHlAdG9vbHMuaWV0Zi5v
cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vcHNlYy1iZ3Atc2Vj
dXJpdHlAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3BzZWMtYmdwLXNlY3VyaXR5QHRvb2xz
LmlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3Vi
amVjdDogPC9zcGFuPltPUFNFQ10gU3RhcnQgb2YgMm5kIFdHTEMgZm9yIGRyYWZ0LWlldGYtb3Bz
ZWMtYmdwLXNlY3VyaXR5PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxu
czp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMt
bWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3Nv
ZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t
L29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRt
bDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy
IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzOw0KCXBhbm9zZS0x
OjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywg
c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs
aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5
bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3
Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPGRpdiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTou
MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBBcmlh
bCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+RGVhciBPcFNlYyBXRyw8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogVGltZXMsIHNlcmlmOyBjb2xv
cjogYmxhY2s7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBUaW1lcywgc2VyaWY7
IGNvbG9yOiBibGFjazsiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0
eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFj
azsiPlRoaXMgc3RhcnRzIGEgMjxzdXA+bmQ8L3N1cD4gV29ya2luZyBHcm91cCBMYXN0IENhbGwg
Zm9yIGRyYWZ0LWlldGYtb3BzZWMtYmdwLXNlY3VyaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9y
OiBibGFjazsiPkR1ZSB0byB0aGUgdGltZSB0YWtlbiB0byBpbnRlZ3JhdGUgYWxsIGNvbW1lbnRz
IGZyb20gdGhlIGZpcnN0IFdHTEMgdGhpcyAyPHN1cD5uZDwvc3VwPiBXR0xDIGlzIGluaXRpYXRl
ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90
dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6
IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm
OyBjb2xvcjogYmxhY2s7Ij5BbGwgdGhyZWUgYXV0aG9ycyBoYXZlIHJlcGxpZWQsIHN0YXRpbmcg
dGhhdCB0aGV5IGRvIG5vdCBrbm93IG9mIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRoIHRoaXMgZHJh
ZnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IFRp
bWVzLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyBmb250LWZhbWls
eTogVGltZXMsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBj
b2xvcjogYmxhY2s7Ij5UaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IFRpbWVzLCBzZXJpZjsgY29sb3I6
IGJsYWNrOyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
aWV0Zi1vcHNlYy1sbGEtb25seS8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh
bnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPg0KIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LWlldGYtb3BzZWMtYmdwLXNlY3VyaXR5Lzwvc3Bhbj48L2E+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
MTMuNXB0OyBmb250LWZhbWlseTogVGltZXMsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t
Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEFy
aWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5QbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQg
dG8gc2VlIGlmIHlvdSB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYW5kIGNvbW1l
bnRzIHRvIHRoZSBsaXN0LCBjbGVhcmx5IHN0YXRpbmcgeW91ciB2aWV3Ljwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBUaW1lcywgc2VyaWY7IGNvbG9y
OiBibGFjazsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IFRpbWVzLCBzZXJpZjsg
Y29sb3I6IGJsYWNrOyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5
bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNr
OyI+VGhpcyBXR0xDIGVuZHMgMjItQXByaWwtMjAxNC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogVGltZXMsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBUaW1lcywgc2VyaWY7IGNvbG9yOiBibGFj
azsiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46
MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0
OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPlRoYW5rcyw8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogVGltZXMs
IHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i
bWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
IDEzLjVwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5H
Lzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBUaW1l
cywgc2VyaWY7IGNvbG9yOiBibGFjazsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9zcGFuPjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iR3JheSIgc2l6
ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g
VGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp
bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRv
IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkNCiBmb3Ig
dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz
c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls
LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmli
dXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu
dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvDQogdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGli
aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp
bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJt
YW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBh
bmQgYW55IHByaW50b3V0Ljxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CF6B0FC1179B5wesleygeorgetwcablecom_--


From nobody Thu Apr 10 00:21:02 2014
Return-Path: <jerduran@cisco.com>
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 BCB441A0145 for <opsec@ietfa.amsl.com>; Thu, 10 Apr 2014 00:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.073
X-Spam-Level: 
X-Spam-Status: No, score=-12.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JhNxzg8VqbUm for <opsec@ietfa.amsl.com>; Thu, 10 Apr 2014 00:20:54 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C1C901A015D for <opsec@ietf.org>; Thu, 10 Apr 2014 00:20:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6892; q=dns/txt; s=iport; t=1397114449; x=1398324049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T8Nzf4PF+M+ZUovlUcwA56q2BgBW65E/jbbsw52ZYXs=; b=dp7+wknOTKhR4rbB91B9Oqq7dSwKntAkx7KupRzuy4hhoPISiFNI4YPp Z1a40qhGKeMqLCiOINiMMX3Osa4Ar2/B2qMs6XTi46E+ASHZNMHczu/kF a1mV2i1g05jFRI5ifTxfpn8idCQoOoBYobks0/u8h4MOuE9zQrebCHRWx k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkIFAHVFRlOtJV2c/2dsb2JhbABZgwY7V7xyhzWBHhZ0giUBAQEDAQEBARpRBAIFBQsCAQgRAwECLycLHQgBAQQOBYd0CA3MKxeJRYRFEQEdLgUHgySBFASUcYNtgTWRDYMwgXI5
X-IronPort-AV: E=Sophos;i="4.97,832,1389744000"; d="scan'208";a="316602613"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 10 Apr 2014 07:20:48 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3A7KmE0018041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Apr 2014 07:20:48 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 02:20:48 -0500
From: "Jerome Durand (jerduran)" <jerduran@cisco.com>
To: "George, Wes" <wesley.george@twcable.com>
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9UN2+/T1QHbw+ATLC7yGU3XgLHJQAf9z4A
Date: Thu, 10 Apr 2014 07:20:47 +0000
Message-ID: <FC8AB300-C5C4-4AE3-8E82-A2CE17E7C7EA@cisco.com>
References: <CF6B0FC1.179B5%wesley.george@twcable.com>
In-Reply-To: <CF6B0FC1.179B5%wesley.george@twcable.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.102.227]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <CB834D71063DF34697EEC47B2791F8A9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Eby43lDSZsUlgTIHc9W6maSTOCg
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 07:20:59 -0000

Hi George,

> I=92ve reviewed previous versions of this draft, but made a new pass thro=
ugh it.

First thanks a lot for your help on this doc!

> I think it=92s mostly ready to publish, though soliciting reviews from no=
n-IETF operator lists might be a good thing to do before we go to IETF LC.

Doc has already been presented RIPE and NANOG meeting as you know. Should w=
e simply send an email recalling this is last call?

> The abstract needs to remove the reference to MD5 since it is deprecated.=
 Similarly, section 4.1 needs to explicitly note that MD5 has been deprecat=
ed by AO, not simply recommend that AO be used when available. I=92ll conce=
de that MD5 is better than nothing, but it=92s not something we want to rec=
ommend in a new BCP without being clear why it shouldn=92t be used anymore.=
=20

I'll remove MD5 from the abstract.
For section 4.1 I propose the following text for 2nd paragraph you're refer=
ring to:

   TCP sessions used by BGP can be secured with a variety of mechanisms.
   MD5 protection of TCP session header [14] was the first existing mechani=
sm.
   It is now deprececated by TCP Authentication Option (TCP-AO, [10]) which
   offers stronger protection. IPsec can also be used for this purpose.
   While MD5 is still the most used mechanism due to its availability in
   vendor's equipment, TCP-AO and MD5 SHOULD be preferred when implemented.

Feel free to change the text.

> There are places where words like =93recommended" are used in ways that l=
ook to be 2119 usage, but are not capitalized. This needs to be consistent =
throughout the document, so that they are used whenever a recommendation is=
 being made as something that you SHOULD/MUST do in order to be in complian=
ce with this Best Common Practice.

OK.

> Section 3- may want to mention rate-limiting accepted traffic in addition=
 to strict filtering of unacceptable traffic

Maybe a note on that. We probably don't want to start discussing the right =
thresholds here.

> 4.1 =96 reference to BCP38 in the =93block spoofed packets=94 section at =
the end?

Good point. I remember there was BCP38 at some stage but we removed it and =
forgot to add it again when we added this small paragraph in 4.1

> 5.1.2.3 =96 reference to IRRtoolset?

OK for a reference.

> 5.2.1 (or possibly section 8) - Filtering peer ASes inbound from customer=
s? (in this case =93peer=94 meaning a non-transit interconnect, not just so=
meone you are connected to via BGP) I.e. If I know that I should only recei=
ve routes with 701 in the path from 701 because I do not use any other ASN =
as transit to reach 701, I should filter routes inbound from other sources =
to ensure that they don=92t announce routes with that path. This is somewhe=
re between the strict IRR based filters and the loose filters, and depends =
on the topology of the network and my business relationships, but I think i=
t=92s a useful point to make to add some additional safety filtering to pre=
vent =93my idiot customer is trying to re-announce the internet to me=94 al=
ong with max-prefix, which you already cover.

I think that first bullet of section 8 is saying this. We are saying we nee=
d to make sure we receive only identified ASes from customer, we probably d=
on't need to add we have to filter the ones we don't want. Tell me if I did=
n't understand your point. Feel free to propose some modified text.

> Section 11=92s future work either needs to be completed in this document =
or explicitly identified as work for a future document. The WG needs to dis=
cuss what is appropriate to add to this doc vs leave for future work before=
 this proceeds.

Indeed. Idea is indeed to remove this section: I forgot it was here.
Comments were integrated except the one about IRRTOOLSET. Adding a referenc=
e is enough I think, probably don't need to give examples in appendix.

> Section 12 needs explicit notes to the RFC editor to remove the section p=
rior to publication.=20

Sure, I think I'll even remove this section in next version.

> This may be something that the RFC editor will fix, but it would be prefe=
rable to use the actual draft name or RFC number as the reference tag inste=
ad of numeric tags, so that the reader knows what you are referencing witho=
ut having to jump to footnotes each time.

If RFC editor can fix it I buy the idea. Otherwise you need to explain to m=
e how to do it easily :)

Thanks again for your comments. They will be integrated really soon. Please=
 let me know about the text I proposed in 4.1.

Jerome


>=20
>=20
> Thanks,
> =20
> Wes George
> =20
>=20
> From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
> Date: Tuesday, April 8, 2014 at 5:18 AM
> To: opsec wg mailing list <opsec@ietf.org>
> Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-=
security@tools.ietf.org>
> Subject: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
>=20
> Dear OpSec WG,
>=20
>=20
> This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-securi=
ty.
> Due to the time taken to integrate all comments from the first WGLC this =
2nd WGLC is initiated.
> =20
> All three authors have replied, stating that they do not know of any IPR =
associated with this draft.
> =20
> The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-=
opsec-bgp-security/
> =20
> Please review this draft to see if you think it is ready for publication =
and comments to the list, clearly stating your view.
>=20
>=20
> This WGLC ends 22-April-2014.
>=20
>=20
> Thanks,
> G/
> =20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable prop=
rietary information, which is privileged, confidential, or subject to copyr=
ight 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 t=
he intended recipient of this E-mail, you are hereby notified that any diss=
emination, distribution, copying, or action taken in relation to the conten=
ts of and attachments to this E-mail is strictly prohibited and may be unla=
wful. If you have received this E-mail in error, please notify the sender i=
mmediately and permanently delete the original and any copy of this E-mail =
and any printout.
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
jerduran@cisco.com  -  +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE








From nobody Thu Apr 10 10:30:03 2014
Return-Path: <wesley.george@twcable.com>
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 82AD41A01F4 for <opsec@ietfa.amsl.com>; Thu, 10 Apr 2014 10:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.737
X-Spam-Level: 
X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 yjf1nYPgaGF6 for <opsec@ietfa.amsl.com>; Thu, 10 Apr 2014 10:29:59 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB281A01FF for <opsec@ietf.org>; Thu, 10 Apr 2014 10:29:59 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.97,835,1389762000"; d="scan'208";a="263506019"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Apr 2014 13:27:56 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 10 Apr 2014 13:29:58 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Jerome Durand (jerduran)" <jerduran@cisco.com>
Date: Thu, 10 Apr 2014 13:30:00 -0400
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9U4n418boyE8d1QUu1yN8Z6I3g6g==
Message-ID: <CF6C45BA.17C3E%wesley.george@twcable.com>
References: <CF6B0FC1.179B5%wesley.george@twcable.com> <FC8AB300-C5C4-4AE3-8E82-A2CE17E7C7EA@cisco.com>
In-Reply-To: <FC8AB300-C5C4-4AE3-8E82-A2CE17E7C7EA@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/0YKBfWc7i8FlMDClKVHsRq7GFB0
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2014 17:30:02 -0000

T24gNC8xMC8xNCwgMzoyMCBBTSwgIkplcm9tZSBEdXJhbmQgKGplcmR1cmFuKSIgPGplcmR1cmFu
QGNpc2NvLmNvbT4gd3JvdGU6DQoNCg0KPkRvYyBoYXMgYWxyZWFkeSBiZWVuIHByZXNlbnRlZCBS
SVBFIGFuZCBOQU5PRyBtZWV0aW5nIGFzIHlvdSBrbm93LiBTaG91bGQNCj53ZSBzaW1wbHkgc2Vu
ZCBhbiBlbWFpbCByZWNhbGxpbmcgdGhpcyBpcyBsYXN0IGNhbGw/DQoNCkNvdWxkbuKAmXQgaHVy
dC4NCg0KPkZvciBzZWN0aW9uIDQuMSBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciAy
bmQgcGFyYWdyYXBoIHlvdSdyZQ0KPnJlZmVycmluZyB0bzoNCj4NCj4gICBUQ1Agc2Vzc2lvbnMg
dXNlZCBieSBCR1AgY2FuIGJlIHNlY3VyZWQgd2l0aCBhIHZhcmlldHkgb2YgbWVjaGFuaXNtcy4N
Cj4gICBNRDUgcHJvdGVjdGlvbiBvZiBUQ1Agc2Vzc2lvbiBoZWFkZXIgWzE0XSB3YXMgdGhlIGZp
cnN0IGV4aXN0aW5nDQo+bWVjaGFuaXNtLg0KPiAgIEl0IGlzIG5vdyBkZXByZWNlY2F0ZWQgYnkg
VENQIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiAoVENQLUFPLCBbMTBdKQ0KPndoaWNoDQo+ICAgb2Zm
ZXJzIHN0cm9uZ2VyIHByb3RlY3Rpb24uIElQc2VjIGNhbiBhbHNvIGJlIHVzZWQgZm9yIHRoaXMg
cHVycG9zZS4NCj4gICBXaGlsZSBNRDUgaXMgc3RpbGwgdGhlIG1vc3QgdXNlZCBtZWNoYW5pc20g
ZHVlIHRvIGl0cyBhdmFpbGFiaWxpdHkgaW4NCj4gICB2ZW5kb3IncyBlcXVpcG1lbnQsIFRDUC1B
TyBhbmQgTUQ1IFNIT1VMRCBiZSBwcmVmZXJyZWQgd2hlbg0KPmltcGxlbWVudGVkLg0KDQpMb29r
cyBmaW5lLCBhbHRob3VnaCBJIHRoaW5rIHlvdSBtZWFudCB0byBzYXkg4oCcVENQLUFPIFNIT1VM
RCBiZSBwcmVmZXJyZWTigJ0NCm5vdCDigJxUQ1AtQU8gYW5kIE1ENSBTSE9VTETigJ0gaW4gdGhl
IGxhc3Qgc2VudGVuY2UuDQoNCj4NCj4+U2VjdGlvbiAzLSBtYXkgd2FudCB0byBtZW50aW9uIHJh
dGUtbGltaXRpbmcgYWNjZXB0ZWQgdHJhZmZpYyBpbg0KPj5hZGRpdGlvbiB0byBzdHJpY3QgZmls
dGVyaW5nIG9mIHVuYWNjZXB0YWJsZSB0cmFmZmljDQo+DQo+TWF5YmUgYSBub3RlIG9uIHRoYXQu
IFdlIHByb2JhYmx5IGRvbid0IHdhbnQgdG8gc3RhcnQgZGlzY3Vzc2luZyB0aGUNCj5yaWdodCB0
aHJlc2hvbGRzIGhlcmUuDQoNCkFncmVlDQoNCj4+IDUuMi4xIChvciBwb3NzaWJseSBzZWN0aW9u
IDgpIC0gRmlsdGVyaW5nIHBlZXIgQVNlcyBpbmJvdW5kIGZyb20NCj4+Y3VzdG9tZXJzPyAoaW4g
dGhpcyBjYXNlIOKAnHBlZXLigJ0gbWVhbmluZyBhIG5vbi10cmFuc2l0IGludGVyY29ubmVjdCwg
bm90DQo+Pmp1c3Qgc29tZW9uZSB5b3UgYXJlIGNvbm5lY3RlZCB0byB2aWEgQkdQKSBJLmUuIElm
IEkga25vdyB0aGF0IEkgc2hvdWxkDQo+Pm9ubHkgcmVjZWl2ZSByb3V0ZXMgd2l0aCA3MDEgaW4g
dGhlIHBhdGggZnJvbSA3MDEgYmVjYXVzZSBJIGRvIG5vdCB1c2UNCj4+YW55IG90aGVyIEFTTiBh
cyB0cmFuc2l0IHRvIHJlYWNoIDcwMSwgSSBzaG91bGQgZmlsdGVyIHJvdXRlcyBpbmJvdW5kDQo+
PmZyb20gb3RoZXIgc291cmNlcyB0byBlbnN1cmUgdGhhdCB0aGV5IGRvbuKAmXQgYW5ub3VuY2Ug
cm91dGVzIHdpdGggdGhhdA0KPj5wYXRoLiBUaGlzIGlzIHNvbWV3aGVyZSBiZXR3ZWVuIHRoZSBz
dHJpY3QgSVJSIGJhc2VkIGZpbHRlcnMgYW5kIHRoZQ0KPj5sb29zZSBmaWx0ZXJzLCBhbmQgZGVw
ZW5kcyBvbiB0aGUgdG9wb2xvZ3kgb2YgdGhlIG5ldHdvcmsgYW5kIG15DQo+PmJ1c2luZXNzIHJl
bGF0aW9uc2hpcHMsIGJ1dCBJIHRoaW5rIGl04oCZcyBhIHVzZWZ1bCBwb2ludCB0byBtYWtlIHRv
IGFkZA0KPj5zb21lIGFkZGl0aW9uYWwgc2FmZXR5IGZpbHRlcmluZyB0byBwcmV2ZW50IOKAnG15
IGlkaW90IGN1c3RvbWVyIGlzIHRyeWluZw0KPj50byByZS1hbm5vdW5jZSB0aGUgaW50ZXJuZXQg
dG8gbWXigJ0gYWxvbmcgd2l0aCBtYXgtcHJlZml4LCB3aGljaCB5b3UNCj4+YWxyZWFkeSBjb3Zl
ci4NCj4NCj5JIHRoaW5rIHRoYXQgZmlyc3QgYnVsbGV0IG9mIHNlY3Rpb24gOCBpcyBzYXlpbmcg
dGhpcy4gV2UgYXJlIHNheWluZyB3ZQ0KPm5lZWQgdG8gbWFrZSBzdXJlIHdlIHJlY2VpdmUgb25s
eSBpZGVudGlmaWVkIEFTZXMgZnJvbSBjdXN0b21lciwgd2UNCj5wcm9iYWJseSBkb24ndCBuZWVk
IHRvIGFkZCB3ZSBoYXZlIHRvIGZpbHRlciB0aGUgb25lcyB3ZSBkb24ndCB3YW50LiBUZWxsDQo+
bWUgaWYgSSBkaWRuJ3QgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBGZWVsIGZyZWUgdG8gcHJvcG9z
ZSBzb21lIG1vZGlmaWVkDQo+dGV4dC4NCg0KWW914oCZcmUgcmlnaHQsIGl04oCZcyBtb3N0bHkg
c2F5aW5nIHRoYXQuIEkgdGhpbmsgdGhlIG1vZGVsIHlvdeKAmXJlIGFkdm9jYXRpbmcNCmlzIGEg
ZmlsdGVyIHRoYXQgZXhwbGljaXRseSBwZXJtaXRzIGNlcnRhaW4gQVNOcywgZ2VuZXJhdGVkIHVu
aXF1ZWx5IGZvcg0KZWFjaCBjdXN0b21lciwgbWVhbmluZyBlYWNoIGhhcyBhbiBpbXBsaWNpdCBk
ZW55IG9mIGFueXRoaW5nIHRoYXQgaXNu4oCZdA0KZXhwbGljaXRseSBwZXJtaXR0ZWQuIFRoYXTi
gJlzIGNlcnRhaW5seSB0aGUgYmV0dGVyIG1vZGVsLiBNeSBzdWdnZXN0aW9uIHdhcw0KbW9yZSBm
b3IgdGhlIHNlY29uZCBjYXNlIOKAnGlmIHlvdSBjYW5ub3QgYnVpbGQgZmlsdGVyc+KApuKAnSwg
d2hlcmUgYnVpbGRpbmcgYQ0Kc2hvcnQgbGlzdCBvZiBleHBsaWNpdGx5IGRlbmllZCBBU05zIHRo
YXQgeW91IHNob3VsZCBuZXZlciBzZWUgZnJvbSAqYW55Kg0KZG93bnN0cmVhbSBjdXN0b21lciAo
aS5lLiBUaGUgQVNOcyBvZiB5b3VyIHBlZXJzIGFuZC9vciB1cHN0cmVhbSB0cmFuc2l0DQpwcm92
aWRlcnMpIHRvIGEgbm9uLWN1c3RvbWVyLXNwZWNpZmljIGZpbHRlciB0aGF0IGNhbiBiZSBnbG9i
YWxseSBhcHBsaWVkDQpvbiBhbGwgY3VzdG9tZXIgQkdQIHNlc3Npb25zIHByb3ZpZGVzIGEgdXNl
ZnVsIHNhZmV0eSBtZWNoYW5pc20gYmV5b25kDQpBUy1wYXRoLWxlbmd0aCBsaW1pdHMsIGFuZCBw
cm90ZWN0cyBpZiB0aGUgY3VzdG9tZXItc3BlY2lmaWMgZmlsdGVyIGlzDQppbmFkdmVydGVudGx5
IG5vdCBhcHBsaWVkIChzaW5jZSB0aGF0IG5ldmVyIGhhcHBlbnMgOi0pICkuDQpIb3BlIHRoYXTi
gJlzIGNsZWFyZXIuDQoNCj4NCj4+IFRoaXMgbWF5IGJlIHNvbWV0aGluZyB0aGF0IHRoZSBSRkMg
ZWRpdG9yIHdpbGwgZml4LCBidXQgaXQgd291bGQgYmUNCj4+cHJlZmVyYWJsZSB0byB1c2UgdGhl
IGFjdHVhbCBkcmFmdCBuYW1lIG9yIFJGQyBudW1iZXIgYXMgdGhlIHJlZmVyZW5jZQ0KPj50YWcg
aW5zdGVhZCBvZiBudW1lcmljIHRhZ3MsIHNvIHRoYXQgdGhlIHJlYWRlciBrbm93cyB3aGF0IHlv
dSBhcmUNCj4+cmVmZXJlbmNpbmcgd2l0aG91dCBoYXZpbmcgdG8ganVtcCB0byBmb290bm90ZXMg
ZWFjaCB0aW1lLg0KPg0KPklmIFJGQyBlZGl0b3IgY2FuIGZpeCBpdCBJIGJ1eSB0aGUgaWRlYS4g
T3RoZXJ3aXNlIHlvdSBuZWVkIHRvIGV4cGxhaW4gdG8NCj5tZSBob3cgdG8gZG8gaXQgZWFzaWx5
IDopDQoNCkkganVzdCBsb29rZWQgYnJpZWZseSBhdCB5b3VyIFhNTCBjb21wYXJlZCB3aXRoIG9u
ZSBvZiBteSBkcmFmdHMsIGFuZCBJDQpjYW7igJl0IHNlZSBob3cgaXTigJlzIGRpZmZlcmVudCwg
c28gSeKAmW0gYWN0dWFsbHkgbm90IHN1cmUgaG93IHRvIGZpeCwgc28gSQ0KZ3Vlc3MgbGV04oCZ
cyBkb27igJl0IHdvcnJ5IGFib3V0IGl0Lg0KDQpXZXMgR2VvcmdlDQoNCg0KVGhpcyBFLW1haWwg
YW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUg
cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh
bCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl
LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2
aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg
dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90
aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBh
Y3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50
cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm
dWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90
aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp
Z2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo=


From nobody Fri Apr 11 08:38:24 2014
Return-Path: <carsten.schmoll@fokus.fraunhofer.de>
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 282D41A01CF for <opsec@ietfa.amsl.com>; Fri, 11 Apr 2014 08:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-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 N1e6nsqHDDXV for <opsec@ietfa.amsl.com>; Fri, 11 Apr 2014 08:38:17 -0700 (PDT)
Received: from mx-relay36-dus.antispameurope.com (mx-relay36-dus.antispameurope.com [94.100.134.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD061A0145 for <opsec@ietf.org>; Fri, 11 Apr 2014 08:38:13 -0700 (PDT)
Received: from smtpsrv1.fokus.fraunhofer.de ([195.37.77.166]) by mx-gate36-dus.antispameurope.com; Fri, 11 Apr 2014 17:38:08 +0200
Received: from CURIE.fokus.fraunhofer.de (curie.fokus.fraunhofer.de [IPv6:2001:638:806:9::203] (may be forged)) by smtpsrv1.fokus.fraunhofer.de (8.14.4/8.14.4) with ESMTP id s3BFc2kK008437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for <opsec@ietf.org>; Fri, 11 Apr 2014 17:38:04 +0200
Received: from DIRAC.fokus.fraunhofer.de ([fe80::95a6:a35d:2023:242c]) by CURIE.fokus.fraunhofer.de ([fe80::4405:336c:6211:c99f%16]) with mapi id 14.03.0181.006; Fri, 11 Apr 2014 17:37:54 +0200
From: "Schmoll, Carsten" <carsten.schmoll@fokus.fraunhofer.de>
To: "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] IPv6 firewalls reqs: Rationale
Thread-Index: Ac9Vm9yDZJRfWPgvSSa3PJ64SVFZrg==
Date: Fri, 11 Apr 2014 15:37:56 +0000
Message-ID: <45F6EC28CBA2DE418529BD6EBC89A8226BC843AA@DIRAC.fokus.fraunhofer.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.147.69.161]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-cloud-security-sender: carsten.schmoll@fokus.fraunhofer.de
X-cloud-security-recipient: opsec@ietf.org
X-cloud-security-Virusscan: CLEAN
X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate36-dus with 3971C211802A
X-cloud-security-connect: smtpsrv1.fokus.fraunhofer.de[195.37.77.166], TLS=, IP=195.37.77.166
X-cloud-security: scantime:.2275
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/vz-hsWwFtyLhaQCfUPOtTBDdb60
Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Apr 2014 15:38:22 -0000

Dear Fernando, authors of this I-D,

thanks for pushing this (IMO) worthwhile topic forward.

The more we see IPv6 availability, the more important is it that the router=
/gateway/firewalls, will provide an (at least) on-par-security for IPv6, co=
mpared to IPv4. With such a document, firewall makers can have a valuable c=
hecklist in their hands - and go at least for the "conditionally-compliant"=
 feature set.

My gut feeling is that such document should aim a little higher than just p=
roviding parity with IPv4 firewall features. IMO this is especially true fo=
r the DoS section (chapter 7), since more attack vectors exist with IPv6 (o=
r so it feels to me).

Two small ideas:
* If deemed as useful, the document should clearly state the importance of =
(the NAT-less yet) stateful PF with IPv6, and maybe some details of it.
* If suitable for this I-D, some words could be added on privacy issues wit=
h IPv6 and how an IPv6-FW could help (or not) with that.

Best regards
Carsten


-----Original Message-----
From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont
Sent: Wednesday, February 19, 2014 12:09 AM
To: 'opsec@ietf.org'
Subject: [OPSEC] IPv6 firewalls reqs: Rationale

Folks,

As noted in my previous email, this is a request to discuss the first item =
listed in my previous email:

1) Agree on a rationale to write this spec.

For example, one possible rationale is "aim at providing parity of features=
 with IPv4". Another one could be that "should should aim a little higher".=
 For example, in the light of draft-farrell-perpass-attack we may aim at re=
quiring some privacy features that might not be that common in IPv4 firewal=
ls.


Thoughts?

Yours,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809=
 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec


From nobody Sun Apr 13 08:45:45 2014
Return-Path: <joelja@bogus.com>
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 4BA511A01CB for <opsec@ietfa.amsl.com>; Sun, 13 Apr 2014 08:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level: 
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272] 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 cWnzBrPhh8XK for <opsec@ietfa.amsl.com>; Sun, 13 Apr 2014 08:45:41 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C12861A01C6 for <OpSec@ietf.org>; Sun, 13 Apr 2014 08:45:38 -0700 (PDT)
Received: from mb-aye.local (c-67-171-230-191.hsd1.wa.comcast.net [67.171.230.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s3DFjYUP052810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 15:45:36 GMT (envelope-from joelja@bogus.com)
Message-ID: <534AB11A.90800@bogus.com>
Date: Sun, 13 Apr 2014 08:45:30 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0
MIME-Version: 1.0
To: draft-ietf-opsec-lla-only@tools.ietf.org, opsec chairs <opsec-chairs@tools.ietf.org>, "opsec@ietf.org" <OpSec@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1dAMnxG2dDFisXkvFWB1xGpw90t91jdmh"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 13 Apr 2014 15:45:36 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/T2aHexPjtvmWX_CQbpXTEBj1Qoo
Subject: [OPSEC] draft-ietf-opsec-lla-only IETF last-call
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Apr 2014 15:45:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1dAMnxG2dDFisXkvFWB1xGpw90t91jdmh
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Folks,

What I took away from the IETF LC is not that this document is
unsuitable for publication, but that a suitably dire warning with
respect to the limitations needs to be attached (probably in the
introduction). It is my feeling from my colleagues on the IESG that they
are relatively opposed to the idea of an IESG statement being applied to
say this if the authors can do so in conjunction with the community.

Thanks
joel


--1dAMnxG2dDFisXkvFWB1xGpw90t91jdmh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNKsRoACgkQ8AA1q7Z/VrI57ACghjmHJCS+2wT5i5igWUxMJ4tM
ZgIAoIQQZf9tWarpar2h+VkRDNJfljB9
=xcH5
-----END PGP SIGNATURE-----

--1dAMnxG2dDFisXkvFWB1xGpw90t91jdmh--


From nobody Sun Apr 13 08:48:11 2014
Return-Path: <evyncke@cisco.com>
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 2E9D51A01D2 for <opsec@ietfa.amsl.com>; Sun, 13 Apr 2014 08:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.773
X-Spam-Level: 
X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 weJSDlyuDfxC for <opsec@ietfa.amsl.com>; Sun, 13 Apr 2014 08:48:09 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 21FC71A01C6 for <OpSec@ietf.org>; Sun, 13 Apr 2014 08:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=876; q=dns/txt; s=iport; t=1397404087; x=1398613687; h=from:to:subject:date:message-id:in-reply-to: content-transfer-encoding:mime-version; bh=FSE0MH3AbQInCAkdIe2CJIWhLwVimQQKxa5ptSp7lEE=; b=F4u7tXyevqRbiqt4R0slXMATHfwile8nK6PYV/gK0tfpDmOecTjzy2rw KxHwgk0FUSC8wKAqfd3ogsChFZm9R5vK7XPImqdKQew1rKgIGRs71dzj0 /2JOyV9aHedkrrMorLnBEyjCkgZ7I7r7PirAGUJFSgpV/65BeawAE4Mn/ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANGwSlOtJA2G/2dsb2JhbABYgwaBEsMtgRoWdIInAQSBCwEIIh05FBECBAESCAyHaMowF447AgYygySBFAEDiSSiAIMxgis
X-IronPort-AV: E=Sophos;i="4.97,851,1389744000"; d="scan'208";a="317369268"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 13 Apr 2014 15:48:07 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s3DFm612008591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Apr 2014 15:48:06 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Sun, 13 Apr 2014 10:48:06 -0500
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: "'joelja@bogus.com'" <joelja@bogus.com>, "'draft-ietf-opsec-lla-only@tools.ietf.org'" <draft-ietf-opsec-lla-only@tools.ietf.org>, "'opsec-chairs@tools.ietf.org'" <opsec-chairs@tools.ietf.org>, "'OpSec@ietf.org'" <OpSec@ietf.org>
Thread-Topic: draft-ietf-opsec-lla-only IETF last-call
Thread-Index: AQHPVy9xysbEiccWh0mT7TBciDSFrpsPsSUm
Date: Sun, 13 Apr 2014 15:48:06 +0000
Message-ID: <97EB7536A2B2C549846804BBF3FD47E123D07FC5@xmb-aln-x02.cisco.com>
In-Reply-To: <534AB11A.90800@bogus.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.37.181.97]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/zhABe4-OC53QYKb0IWacSJ2FS-8
Subject: Re: [OPSEC] draft-ietf-opsec-lla-only IETF last-call
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Apr 2014 15:48:10 -0000

Joel

Thanks for your message=20

Michael and I will come back to you

Eric

----- Message d'origine -----
De : joel jaeggli [mailto:joelja@bogus.com]
Envoy=E9 : Sunday, April 13, 2014 05:45 PM=0A=
=C0 : draft-ietf-opsec-lla-only@tools.ietf.org <draft-ietf-opsec-lla-only@t=
ools.ietf.org>; opsec chairs <opsec-chairs@tools.ietf.org>; opsec@ietf.org =
<OpSec@ietf.org>
Objet : draft-ietf-opsec-lla-only IETF last-call

Folks,

What I took away from the IETF LC is not that this document is
unsuitable for publication, but that a suitably dire warning with
respect to the limitations needs to be attached (probably in the
introduction). It is my feeling from my colleagues on the IESG that they
are relatively opposed to the idea of an IESG statement being applied to
say this if the authors can do so in conjunction with the community.

Thanks
joel


From nobody Sun Apr 13 08:55:38 2014
Return-Path: <joelja@bogus.com>
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 B60201A02C6 for <opsec@ietfa.amsl.com>; Sun, 13 Apr 2014 08:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 p4vZ6tWKwusU for <opsec@ietfa.amsl.com>; Sun, 13 Apr 2014 08:55:36 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC651A01DE for <OpSec@ietf.org>; Sun, 13 Apr 2014 08:55:36 -0700 (PDT)
Received: from mb-aye.local (c-67-171-230-191.hsd1.wa.comcast.net [67.171.230.191]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s3DFtVUT052851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 13 Apr 2014 15:55:31 GMT (envelope-from joelja@bogus.com)
Message-ID: <534AB36E.7050601@bogus.com>
Date: Sun, 13 Apr 2014 08:55:26 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "'draft-ietf-opsec-lla-only@tools.ietf.org'" <draft-ietf-opsec-lla-only@tools.ietf.org>,  "'opsec-chairs@tools.ietf.org'" <opsec-chairs@tools.ietf.org>, "'OpSec@ietf.org'" <OpSec@ietf.org>
References: <97EB7536A2B2C549846804BBF3FD47E123D07FC5@xmb-aln-x02.cisco.com>
In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E123D07FC5@xmb-aln-x02.cisco.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TR94apeMDnm5l3fhQPj4rv7COQ6AJ0bh2"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 13 Apr 2014 15:55:31 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KRS96Ixmjbj7968vYhJAyPSM2xc
Subject: Re: [OPSEC] draft-ietf-opsec-lla-only IETF last-call
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Apr 2014 15:55:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TR94apeMDnm5l3fhQPj4rv7COQ6AJ0bh2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks guys.

joel

On 4/13/14, 8:48 AM, Eric Vyncke (evyncke) wrote:
> Joel
>=20
> Thanks for your message=20
>=20
> Michael and I will come back to you
>=20
> Eric
>=20
> ----- Message d'origine -----
> De : joel jaeggli [mailto:joelja@bogus.com]
> Envoy=E9 : Sunday, April 13, 2014 05:45 PM
> =C0 : draft-ietf-opsec-lla-only@tools.ietf.org <draft-ietf-opsec-lla-on=
ly@tools.ietf.org>; opsec chairs <opsec-chairs@tools.ietf.org>; opsec@iet=
f.org <OpSec@ietf.org>
> Objet : draft-ietf-opsec-lla-only IETF last-call
>=20
> Folks,
>=20
> What I took away from the IETF LC is not that this document is
> unsuitable for publication, but that a suitably dire warning with
> respect to the limitations needs to be attached (probably in the
> introduction). It is my feeling from my colleagues on the IESG that the=
y
> are relatively opposed to the idea of an IESG statement being applied t=
o
> say this if the authors can do so in conjunction with the community.
>=20
> Thanks
> joel
>=20
>=20



--TR94apeMDnm5l3fhQPj4rv7COQ6AJ0bh2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNKs28ACgkQ8AA1q7Z/VrLwtACfcCpfRe4BdqKtGKpKtOOntO74
xgsAnjA9IESZXZAtrayxS9lTFqoXtVsL
=1r9/
-----END PGP SIGNATURE-----

--TR94apeMDnm5l3fhQPj4rv7COQ6AJ0bh2--


From nobody Mon Apr 14 01:21:25 2014
Return-Path: <ietf@rozanak.com>
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 9B6B11A0293 for <opsec@ietfa.amsl.com>; Mon, 14 Apr 2014 01:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 t0_qSB0PZYJl for <opsec@ietfa.amsl.com>; Mon, 14 Apr 2014 01:21:22 -0700 (PDT)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) by ietfa.amsl.com (Postfix) with ESMTP id 345611A0290 for <opsec@ietf.org>; Mon, 14 Apr 2014 01:21:22 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 77A7523E2B25; Mon, 14 Apr 2014 08:21:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id betjC74L7aC6; Mon, 14 Apr 2014 10:21:17 +0200 (CEST)
Received: from kopoli (g226184084.adsl.alicedsl.de [92.226.184.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id F30E423E24BF; Mon, 14 Apr 2014 10:21:16 +0200 (CEST)
From: "Hosnieh Rafiee" <ietf@rozanak.com>
To: "'KK'" <kk@google.com>
Date: Mon, 14 Apr 2014 10:21:14 +0200
Message-ID: <000001cf57ba$80a5d940$81f18bc0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac9Xun6pLhhrOvVJQUmozH5hjV21uA==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/zFv_m5M05oSBq3gtUPnJ7ADF44w
Cc: opsec@ietf.org
Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-dhcpv6-shield
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Apr 2014 08:21:23 -0000

I read this draft and I support the publication of this draft. I think =
it is important to perform any step toward securing clients and DHCP =
servers.=20
I guess it will be also useful that the authors include a section =
related to comparison of this work with SAVI-DHCP as I asked authors =
offlist.

Thanks,
Best,
Hosnieh

From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of KK
Sent: Friday, March 28, 2014 4:44 PM
To: opsec@ietf.org
Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-dhcpv6-shield

Dear OpSec WG,

This starts a Working Group Last Call for draft-ietf-opsec-dhcpv6-shield

The draft is available here: =
https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

Please review this draft to see if you think it is ready for =
publication.

Send comments to the list, clearly stating your view.

This WGLC ends Friday 11-Apr-2014.

Thanks,
KK
(as OpSec WG co-chair)


From nobody Tue Apr 15 11:25:15 2014
Return-Path: <wwwrun@rfc-editor.org>
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 D78A91A01FE; Tue, 15 Apr 2014 11:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-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 6exoZvdScuMf; Tue, 15 Apr 2014 11:25:07 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 375531A011A; Tue, 15 Apr 2014 11:25:07 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 2075918000C; Tue, 15 Apr 2014 11:24:39 -0700 (PDT)
To: nick@foobar.org, dave@juniper.net, cpignata@cisco.com, rodunn@cisco.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140415182439.2075918000C@rfc-editor.org>
Date: Tue, 15 Apr 2014 11:24:39 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZnJDT8kLOpIZT4qR2KynpB1LBMc
Cc: opsec@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org
Subject: [OPSEC] [Errata Verified] RFC6192 (3906)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 18:25:13 -0000

The following errata report has been verified for RFC6192,
"Protecting the Router Control Plane". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6192&eid=3906

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Nick Hilliard <nick@foobar.org>
Date Reported: 2014-03-02
Verified by: Benoit Claise (IESG)

Section: A.1

Original Text
-------------
[...]
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.252 eq domain any
   ipv6 access-list DNSv6
    permit udp 2001:DB8:100:1::/64 eq domain any
    permit tcp 2001:DB8:100:1::/64 eq domain any
   ip access-list extended NTP
    permit udp 198.51.100.4 255.255.255.252 any eq ntp
   ipv6 access-list NTPv6
    permit udp 2001:DB8:100:2::/64 any eq ntp
   ip access-list extended SSH
    permit tcp 198.51.100.128 0.0.0.128 any eq 22
   ipv6 access-list SSHv6
    permit tcp 2001:DB8:100:3::/64 any eq 22
   ip access-list extended SNMP
    permit udp 198.51.100.128 0.0.0.128 any eq snmp
[...]


Corrected Text
--------------
[...]
   ip access-list extended DNS
    permit udp 198.51.100.0 0.0.0.3 eq domain any
   ipv6 access-list DNSv6
    permit udp 2001:DB8:100:1::/64 eq domain any
    permit tcp 2001:DB8:100:1::/64 eq domain any
   ip access-list extended NTP
    permit udp 198.51.100.4 0.0.0.3 any eq ntp
   ipv6 access-list NTPv6
    permit udp 2001:DB8:100:2::/64 any eq ntp
   ip access-list extended SSH
    permit tcp 198.51.100.128 0.0.0.127 any eq 22
   ipv6 access-list SSHv6
    permit tcp 2001:DB8:100:3::/64 any eq 22
   ip access-list extended SNMP
    permit udp 198.51.100.128 0.0.0.127 any eq snmp
[...]

Notes
-----
The bitfield masks in the Cisco Configuration example  in section A.1 look incorrect.  The authors may have intended the following meanings:

ip access-list extended DNS
  all hosts between 198.51.100.0 and 198.51.100.3 instead of all addresses in the range 198.51.100.0/24 which are evenly divisible by 4

ip access-list extended NTP
  all hosts between 198.51.100.4 and 198.51.100.7 instead of all addresses in the range 0.0.0.0/0 which are evenly divisible by 4

ip access-list extended SSH
  all hosts between 198.51.100.128 and 198.51.100.255 instead of 198.51.100.128/32

ip access-list extended SNMP
  all hosts between 198.51.100.128 and 198.51.100.255 instead of 198.51.100.128/32

--------------------------------------
RFC6192 (draft-ietf-opsec-protect-control-plane-06)
--------------------------------------
Title               : Protecting the Router Control Plane
Publication Date    : March 2011
Author(s)           : D. Dugal, C. Pignataro, R. Dunn
Category            : INFORMATIONAL
Source              : Operational Security Capabilities for IP Network Infrastructure
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Wed Apr 16 04:55:43 2014
Return-Path: <gvandeve@cisco.com>
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 5C52D1A014D for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 04:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.772
X-Spam-Level: 
X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ios1E10Hdw-F for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 04:55:37 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 19FB31A0142 for <opsec@ietf.org>; Wed, 16 Apr 2014 04:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8732; q=dns/txt; s=iport; t=1397649334; x=1398858934; h=from:to:cc:subject:date:message-id:mime-version; bh=X67QciRn7UfvFL4uD+AcwUcr3/pcFV/c8PrU+t0VF1w=; b=FPKpVZ36JIjE79LZOZhLPUkk1Ht+IHhdEp6oZQGyMJ+dgrfvDKVW7Op+ U2/p9wVBN20mJs8icSAiIQXndlEw5EZAOEVs0O0X+bcumXvjrLgoe64LA fjoUdlkDuA0eqdnmr/3xZ/6aTo1/QQaACHluYlgp4ULKO1OmiNs8f7R3m E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FABtvTlOtJV2Y/2dsb2JhbABZgkJEO1fDM4EhFnSCJQEBAQQdEEELEgEIEQQBAQtWHQkBBA4FCId0DcdTEwSOMS0EgyuBFASrL4Mxgis
X-IronPort-AV: E=Sophos;i="4.97,872,1389744000";  d="scan'208,217";a="318169087"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 16 Apr 2014 11:55:33 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3GBtXeQ017938 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 11:55:33 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 06:55:33 -0500
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: opsec wg mailing list <opsec@ietf.org>
Thread-Topic: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQGX/bdQ
Date: Wed, 16 Apr 2014 11:55:32 +0000
Message-ID: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.196.139]
Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B24113958CBxmbalnx12ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/f2b2THEBwdrdLSFbMw-L4x4uits
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, "kk@dropbox.com" <kk@dropbox.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 11:55:42 -0000

--_000_67832B1175062E48926BF3CB27C49B24113958CBxmbalnx12ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please find this reminder to query for your feedback.

Brgds,
G/

From: Gunter Van de Velde (gvandeve)
Sent: 08 April 2014 11:18
To: opsec wg mailing list
Cc: KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org
Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security


Dear OpSec WG,


This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security=
.

Due to the time taken to integrate all comments from the first WGLC this 2n=
d WGLC is initiated.



All three authors have replied, stating that they do not know of any IPR as=
sociated with this draft.


The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op=
sec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-onl=
y/>


Please review this draft to see if you think it is ready for publication an=
d comments to the list, clearly stating your view.


This WGLC ends 22-April-2014.


Thanks,

G/


--_000_67832B1175062E48926BF3CB27C49B24113958CBxmbalnx12ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Please find this remin=
der to query for your feedback.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Brgds,<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">G/<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-language:EN=
-GB">From:</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-fa=
mily:&quot;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-language:EN-GB">=
 Gunter
 Van de Velde (gvandeve) <br>
<b>Sent:</b> 08 April 2014 11:18<br>
<b>To:</b> opsec wg mailing list<br>
<b>Cc:</b> KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org=
<br>
<b>Subject:</b> Start of 2nd WGLC for draft-ietf-opsec-bgp-security<o:p></o=
:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Dear O=
pSec WG,</span><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot=
;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span style=3D"font-s=
ize:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:=
p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">This s=
tarts a 2<sup>nd</sup> Working Group Last Call for draft-ietf-opsec-bgp-sec=
urity.<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Due to=
 the time taken to integrate all comments from the first WGLC this 2<sup>nd=
</sup> WGLC is initiated.<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black"><o:p>&=
nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">All th=
ree authors have replied, stating that they do not know of any IPR associat=
ed with this draft.</span><span style=3D"font-size:13.5pt;font-family:&quot=
;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">The dr=
aft is available here:</span><span style=3D"font-size:13.5pt;font-family:&q=
uot;Times&quot;,&quot;serif&quot;;color:black"><a href=3D"https://datatrack=
er.ietf.org/doc/draft-ietf-opsec-lla-only/"><span style=3D"font-family:&quo=
t;Arial&quot;,&quot;sans-serif&quot;;color:black">
 https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/</span></a>=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Please=
 review this draft to see if you think it is ready for publication and comm=
ents to the list, clearly stating your view.</span><span style=3D"font-size=
:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p><=
/o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span style=3D"font-s=
ize:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:=
p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">This W=
GLC ends 22-April-2014.</span><span style=3D"font-size:13.5pt;font-family:&=
quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span style=3D"font-s=
ize:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:=
p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Thanks=
,</span><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot=
;serif&quot;;color:black"><o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">G/</sp=
an><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;seri=
f&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_67832B1175062E48926BF3CB27C49B24113958CBxmbalnx12ciscoc_--


From nobody Wed Apr 16 06:34:37 2014
Return-Path: <rbonica@juniper.net>
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 0083A1A0194 for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 06:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 z-jtn2BnvMGp for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 06:34:32 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB1C1A0193 for <opsec@ietf.org>; Wed, 16 Apr 2014 06:34:31 -0700 (PDT)
Received: from mail27-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Apr 2014 13:33:47 +0000
Received: from mail27-ch1 (localhost [127.0.0.1])	by mail27-ch1-R.bigfish.com (Postfix) with ESMTP id 2B617180743; Wed, 16 Apr 2014 13:33:47 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: VPS-20(zz9371Ic85fh4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h)
Received-SPF: pass (mail27-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(164054003)(377454003)(189002)(199002)(86362001)(92566001)(16236675002)(50986999)(15202345003)(76482001)(81542001)(46102001)(76176999)(54356999)(2656002)(80022001)(81342001)(87936001)(79102001)(4396001)(74502001)(15975445006)(99286001)(99396002)(74662001)(19609705001)(77982001)(76576001)(83072002)(66066001)(31966008)(20776003)(19300405004)(19580395003)(74316001)(85852003)(83322001)(19580405001)(33646001)(80976001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:FC8EC43E.9EE295A3.BDD77F7F.4EA1910.20220; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail27-ch1 (localhost.localdomain [127.0.0.1]) by mail27-ch1 (MessageSwitch) id 139765522511622_19949; Wed, 16 Apr 2014 13:33:45 +0000 (UTC)
Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242])	by mail27-ch1.bigfish.com (Postfix) with ESMTP id EFFB8160206;	Wed, 16 Apr 2014 13:33:44 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Apr 2014 13:33:44 +0000
Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 16 Apr 2014 13:34:23 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 16 Apr 2014 13:34:21 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.244]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.244]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 13:34:20 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>, opsec wg mailing list <opsec@ietf.org>
Thread-Topic: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQGX/bdQAAN0kZA=
Date: Wed, 16 Apr 2014 13:34:19 +0000
Message-ID: <c8822f998646410f8404b9e59c02a13f@CO1PR05MB442.namprd05.prod.outlook.com>
References: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com>
In-Reply-To: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.12]
x-forefront-prvs: 01834E39B7
Content-Type: multipart/alternative; boundary="_000_c8822f998646410f8404b9e59c02a13fCO1PR05MB442namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/urn7g8PXtqWE2NBxzjb-HdC5PSQ
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, "kk@dropbox.com" <kk@dropbox.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 13:34:36 -0000

--_000_c8822f998646410f8404b9e59c02a13fCO1PR05MB442namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,

This document is very comprehensive and well-written. Kudos to the authors.

However, please take a look at the Forward.

                                                Ron


From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Veld=
e (gvandeve)
Sent: Wednesday, April 16, 2014 7:56 AM
To: opsec wg mailing list
Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security

Please find this reminder to query for your feedback.

Brgds,
G/

From: Gunter Van de Velde (gvandeve)
Sent: 08 April 2014 11:18
To: opsec wg mailing list
Cc: KK (kk@google.com<mailto:kk@google.com>); draft-ietf-opsec-bgp-security=
@tools.ietf.org<mailto:draft-ietf-opsec-bgp-security@tools.ietf.org>
Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security


Dear OpSec WG,


This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security=
.

Due to the time taken to integrate all comments from the first WGLC this 2n=
d WGLC is initiated.



All three authors have replied, stating that they do not know of any IPR as=
sociated with this draft.


The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op=
sec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-onl=
y/>


Please review this draft to see if you think it is ready for publication an=
d comments to the list, clearly stating your view.


This WGLC ends 22-April-2014.


Thanks,

G/


--_000_c8822f998646410f8404b9e59c02a13fCO1PR05MB442namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Folks,<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">This document is very =
comprehensive and well-written. Kudos to the authors.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">However, please take a=
 look at the Forward.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ron<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b>From:</b> OPSEC [mailto:opsec-bounces@ietf.org] <=
b>On Behalf Of
</b>Gunter Van de Velde (gvandeve)<br>
<b>Sent:</b> Wednesday, April 16, 2014 7:56 AM<br>
<b>To:</b> opsec wg mailing list<br>
<b>Cc:</b> draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com<br>
<b>Subject:</b> Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-secu=
rity<o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">Please =
find this reminder to query for your feedback.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">Brgds,<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">G/<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-language:EN-GB">From:</spa=
n></b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=
sans-serif&quot;;mso-fareast-language:EN-GB"> Gunter Van de Velde (gvandeve=
)
<br>
<b>Sent:</b> 08 April 2014 11:18<br>
<b>To:</b> opsec wg mailing list<br>
<b>Cc:</b> KK (<a href=3D"mailto:kk@google.com">kk@google.com</a>); <a href=
=3D"mailto:draft-ietf-opsec-bgp-security@tools.ietf.org">
draft-ietf-opsec-bgp-security@tools.ietf.org</a><br>
<b>Subject:</b> Start of 2nd WGLC for draft-ietf-opsec-bgp-security<o:p></o=
:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Dear OpSec WG,</span><span lang=3D"EN-GB" style=3D"font-size:13.5p=
t;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p><=
/span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span lang=3D"EN-GB" =
style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;c=
olor:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">This starts a 2<sup>nd</sup> Working Group Last Call for draft-iet=
f-opsec-bgp-security.<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Due to the time taken to integrate all comments from the first WGL=
C this 2<sup>nd</sup> WGLC is initiated.<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">All three authors have replied, stating that they do not know of a=
ny IPR associated with this draft.</span><span lang=3D"EN-GB" style=3D"font=
-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-=
family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></=
span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">The draft is available here:</span><span lang=3D"EN-GB" style=3D"f=
ont-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black=
"><a href=3D"https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/"><=
span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:bl=
ack">
 https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/</span></a>=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-=
family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></=
span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Please review this draft to see if you think it is ready for publi=
cation and comments to the list, clearly stating your view.</span><span lan=
g=3D"EN-GB" style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;s=
erif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span lang=3D"EN-GB" =
style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;c=
olor:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">This WGLC ends 22-April-2014.</span><span lang=3D"EN-GB" style=3D"=
font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:blac=
k"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span lang=3D"EN-GB" =
style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;c=
olor:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Thanks,</span><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-=
family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span><=
/p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">G/</span><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-famil=
y:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_c8822f998646410f8404b9e59c02a13fCO1PR05MB442namprd05pro_--


From nobody Wed Apr 16 07:51:28 2014
Return-Path: <rbonica@juniper.net>
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 7593F1A01D6 for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 07:51:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.2
X-Spam-Level: 
X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 UMovVWdzRpEv for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 07:51:19 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 99B9A1A01C0 for <opsec@ietf.org>; Wed, 16 Apr 2014 07:51:19 -0700 (PDT)
Received: from mail169-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Apr 2014 14:50:35 +0000
Received: from mail169-co9 (localhost [127.0.0.1])	by mail169-co9-R.bigfish.com (Postfix) with ESMTP id D9C852405DC;	Wed, 16 Apr 2014 14:50:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: VPS-20(zz9371Ic85fh4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h)
Received-SPF: pass (mail169-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(377454003)(164054003)(74316001)(31966008)(20776003)(19300405004)(83072002)(66066001)(19580395003)(33646001)(80976001)(83322001)(85852003)(19580405001)(80022001)(2656002)(79102001)(4396001)(74502001)(81342001)(87936001)(86362001)(92566001)(16236675002)(46102001)(81542001)(54356999)(76482001)(76176999)(50986999)(15202345003)(74662001)(99396002)(99286001)(76576001)(19609705001)(77982001)(15975445006)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:FCBEF03E.BCE295A3.BDC7BF7F.AEA4930.202FC; MLV:sfv; PTR:InfoNoRecords; A:1;  MX:1; LANG:en; 
Received: from mail169-co9 (localhost.localdomain [127.0.0.1]) by mail169-co9 (MessageSwitch) id 1397659833667814_3364; Wed, 16 Apr 2014 14:50:33 +0000 (UTC)
Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.233])	by mail169-co9.bigfish.com (Postfix) with ESMTP id 98CDCD80063; Wed, 16 Apr 2014 14:50:33 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Apr 2014 14:50:32 +0000
Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 16 Apr 2014 14:50:59 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.918.8; Wed, 16 Apr 2014 14:50:57 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.244]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.244]) with mapi id 15.00.0918.000; Wed, 16 Apr 2014 14:50:56 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>, opsec wg mailing list <opsec@ietf.org>
Thread-Topic: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQGX/bdQAAN0kZAAAonwsA==
Date: Wed, 16 Apr 2014 14:50:56 +0000
Message-ID: <cda8642294584887a88ba505424a2c19@CO1PR05MB442.namprd05.prod.outlook.com>
References: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.17]
x-forefront-prvs: 01834E39B7
Content-Type: multipart/alternative; boundary="_000_cda8642294584887a88ba505424a2c19CO1PR05MB442namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/EaU9bFz0I6EzGAOm67faDbp806U
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, "kk@dropbox.com" <kk@dropbox.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 14:51:23 -0000

--_000_cda8642294584887a88ba505424a2c19CO1PR05MB442namprd05pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,


In Sections 5.1.1.1 and 5.1.1.2, you say, "Only prefixes with value "False"=
 in column "Global" MUST be discarded on Internet BGP peerings."



This statement is mostly true, but I can think of a corner case. Assume tha=
t two autonomous systems are cooperating to provide a DS-lite or some simil=
ar service. They might agree to co-ordinate assignment of non-global routes=
 and exchange non-global routes with one another.



                                                                           =
       Ron


From: Ronald Bonica
Sent: Wednesday, April 16, 2014 9:34 AM
To: 'Gunter Van de Velde (gvandeve)'; opsec wg mailing list
Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com
Subject: RE: Start of 2nd WGLC for draft-ietf-opsec-bgp-security

Folks,

This document is very comprehensive and well-written. Kudos to the authors.

However, please take a look at the Forward.

                                                Ron


From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Veld=
e (gvandeve)
Sent: Wednesday, April 16, 2014 7:56 AM
To: opsec wg mailing list
Cc: draft-ietf-opsec-bgp-security@tools.ietf.org<mailto:draft-ietf-opsec-bg=
p-security@tools.ietf.org>; kk@dropbox.com<mailto:kk@dropbox.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security

Please find this reminder to query for your feedback.

Brgds,
G/

From: Gunter Van de Velde (gvandeve)
Sent: 08 April 2014 11:18
To: opsec wg mailing list
Cc: KK (kk@google.com<mailto:kk@google.com>); draft-ietf-opsec-bgp-security=
@tools.ietf.org<mailto:draft-ietf-opsec-bgp-security@tools.ietf.org>
Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security


Dear OpSec WG,


This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security=
.

Due to the time taken to integrate all comments from the first WGLC this 2n=
d WGLC is initiated.



All three authors have replied, stating that they do not know of any IPR as=
sociated with this draft.


The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op=
sec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-onl=
y/>


Please review this draft to see if you think it is ready for publication an=
d comments to the list, clearly stating your view.


This WGLC ends 22-April-2014.


Thanks,

G/


--_000_cda8642294584887a88ba505424a2c19CO1PR05MB442namprd05pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:"Calibri Light";
	panose-1:2 15 3 2 2 2 4 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Folks,<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<pre style=3D"page-break-before:always"><span style=3D"font-size:12.0pt;fon=
t-family:&quot;Calibri Light&quot;,&quot;sans-serif&quot;">In Sections 5.1.=
1.1 and 5.1.1.2, you say, &#8220;</span><span style=3D"font-size:12.0pt;fon=
t-family:&quot;Calibri Light&quot;,&quot;sans-serif&quot;">Only prefixes wi=
th value &quot;False&quot; in column &quot;Global&quot; MUST be discarded o=
n Internet BGP peerings.&#8221;<o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:12.0pt;fon=
t-family:&quot;Calibri Light&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p=
></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:12.0pt;fon=
t-family:&quot;Calibri Light&quot;,&quot;sans-serif&quot;">This statement i=
s mostly true, but I can think of a corner case. Assume that two autonomous=
 systems are cooperating to provide a DS-lite or some similar service. They=
 might agree to co-ordinate assignment of non-global routes and exchange no=
n-global routes with one another.<o:p></o:p></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:12.0pt;fon=
t-family:&quot;Calibri Light&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p=
></span></pre>
<pre style=3D"page-break-before:always"><span style=3D"font-size:12.0pt;fon=
t-family:&quot;Calibri Light&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; Ron<o:p></o:p></span></pre>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b>From:</b> Ronald Bonica <br>
<b>Sent:</b> Wednesday, April 16, 2014 9:34 AM<br>
<b>To:</b> 'Gunter Van de Velde (gvandeve)'; opsec wg mailing list<br>
<b>Cc:</b> draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com<br>
<b>Subject:</b> RE: Start of 2nd WGLC for draft-ietf-opsec-bgp-security<o:p=
></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Folks,<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">This document is very =
comprehensive and well-written. Kudos to the authors.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">However, please take a=
 look at the Forward.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ron<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b>From:</b> OPSEC [<a href=3D"mailto:opsec-bounces@=
ietf.org">mailto:opsec-bounces@ietf.org</a>]
<b>On Behalf Of </b>Gunter Van de Velde (gvandeve)<br>
<b>Sent:</b> Wednesday, April 16, 2014 7:56 AM<br>
<b>To:</b> opsec wg mailing list<br>
<b>Cc:</b> <a href=3D"mailto:draft-ietf-opsec-bgp-security@tools.ietf.org">=
draft-ietf-opsec-bgp-security@tools.ietf.org</a>;
<a href=3D"mailto:kk@dropbox.com">kk@dropbox.com</a><br>
<b>Subject:</b> Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-secu=
rity<o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">Please =
find this reminder to query for your feedback.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">Brgds,<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D">G/<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-language:EN-GB">From:</spa=
n></b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;=
sans-serif&quot;;mso-fareast-language:EN-GB"> Gunter Van de Velde (gvandeve=
)
<br>
<b>Sent:</b> 08 April 2014 11:18<br>
<b>To:</b> opsec wg mailing list<br>
<b>Cc:</b> KK (<a href=3D"mailto:kk@google.com">kk@google.com</a>); <a href=
=3D"mailto:draft-ietf-opsec-bgp-security@tools.ietf.org">
draft-ietf-opsec-bgp-security@tools.ietf.org</a><br>
<b>Subject:</b> Start of 2nd WGLC for draft-ietf-opsec-bgp-security<o:p></o=
:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Dear OpSec WG,</span><span lang=3D"EN-GB" style=3D"font-size:13.5p=
t;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p><=
/span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span lang=3D"EN-GB" =
style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;c=
olor:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">This starts a 2<sup>nd</sup> Working Group Last Call for draft-iet=
f-opsec-bgp-security.<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Due to the time taken to integrate all comments from the first WGL=
C this 2<sup>nd</sup> WGLC is initiated.<o:p></o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">All three authors have replied, stating that they do not know of a=
ny IPR associated with this draft.</span><span lang=3D"EN-GB" style=3D"font=
-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-=
family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></=
span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">The draft is available here:</span><span lang=3D"EN-GB" style=3D"f=
ont-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black=
"><a href=3D"https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/"><=
span style=3D"font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:bl=
ack">
 https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/</span></a>=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-=
family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></=
span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Please review this draft to see if you think it is ready for publi=
cation and comments to the list, clearly stating your view.</span><span lan=
g=3D"EN-GB" style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;s=
erif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span lang=3D"EN-GB" =
style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;c=
olor:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">This WGLC ends 22-April-2014.</span><span lang=3D"EN-GB" style=3D"=
font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:blac=
k"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span lang=3D"EN-GB" =
style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;c=
olor:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">Thanks,</span><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-=
family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span><=
/p>
<p style=3D"margin:0in;margin-bottom:.0001pt"><span lang=3D"EN-GB" style=3D=
"font-size:13.5pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;colo=
r:black">G/</span><span lang=3D"EN-GB" style=3D"font-size:13.5pt;font-famil=
y:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_cda8642294584887a88ba505424a2c19CO1PR05MB442namprd05pro_--


From nobody Wed Apr 16 15:51:44 2014
Return-Path: <jerduran@cisco.com>
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 4F86E1A0359 for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 15:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level: 
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 1HVaYmLpDM6C for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 15:51:39 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id DA3791A0299 for <opsec@ietf.org>; Wed, 16 Apr 2014 15:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3506; q=dns/txt; s=iport; t=1397688695; x=1398898295; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pII9/rTbR2DY6Eh90VfTX81VIsjJyZ3NSo2H0b3vkoA=; b=Whh6zDXF8aom4ntELsGXHxk5ACflSsR36jMv3dIEGVp02Cqm6lFklNR2 Q9+ZkythpqnfTA9TkuQGsTwkzkwvr06m4ommXVqdNjOIjMdyUh0OAOT0L C1P6eX0VjL2U6Dv8mvurEh2Szk48aj5ZrtwJe46mUpaIOxMprkiTgGRIB I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAHMIT1OtJV2a/2dsb2JhbABZgwY7V7t/hziBIRZ0giUBAQEDAQEBARpRCwULAgEIDgMEAQEoBycLFAkIAQEEDgWHdAgNqzCeTxeOLzMHgySBFASYZoE3kRKDMYIr
X-IronPort-AV: E=Sophos;i="4.97,875,1389744000"; d="scan'208";a="36453681"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 16 Apr 2014 22:51:33 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3GMpXUS012784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 22:51:33 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 17:51:33 -0500
From: "Jerome Durand (jerduran)" <jerduran@cisco.com>
To: Ronald Bonica <rbonica@juniper.net>
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQGX/bdQAAN0kZAAAonwsAAbc/eA
Date: Wed, 16 Apr 2014 22:51:32 +0000
Message-ID: <11F1FD94-5C9A-4653-BC34-214BA9A8A009@cisco.com>
References: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com> <cda8642294584887a88ba505424a2c19@CO1PR05MB442.namprd05.prod.outlook.com>
In-Reply-To: <cda8642294584887a88ba505424a2c19@CO1PR05MB442.namprd05.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.100.140]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <10E5BD0BC042294C9F660C527979FA77@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/_Tzi1tWnApsxAmUeSShG2d1eBkk
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>, "kk@dropbox.com" <kk@dropbox.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 22:51:43 -0000

Thank you Ron for your comment and support,

Actually I believe exceptions can more or less happen for every guideline l=
isted in the document. My view is that it is better to stay on the generic =
case and maybe better highlight in introduction that exceptions happen when=
 both peers agree to do so. Idea would be that normative language only refe=
r to classic peerings (not the exception scenario) so we don't have to chan=
ge MUST for SHOULD everywhere in the doc and lower the value of the doc.

What do you think?

Thanks

Jerome






Le 16 avr. 2014 =E0 16:50, Ronald Bonica <rbonica@juniper.net>
 a =E9crit :

> Folks,
> =20
> In Sections 5.1.1.1 and 5.1.1.2, you say, =93Only prefixes with value "Fa=
lse" in column "Global" MUST be discarded on Internet BGP peerings.=94
> =20
> This statement is mostly true, but I can think of a corner case. Assume t=
hat two autonomous systems are cooperating to provide a DS-lite or some sim=
ilar service. They might agree to co-ordinate assignment of non-global rout=
es and exchange non-global routes with one another.
> =20
>                                                                          =
         Ron
> =20
> =20
> From: Ronald Bonica=20
> Sent: Wednesday, April 16, 2014 9:34 AM
> To: 'Gunter Van de Velde (gvandeve)'; opsec wg mailing list
> Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com
> Subject: RE: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
> =20
> Folks,
> =20
> This document is very comprehensive and well-written. Kudos to the author=
s.
> =20
> However, please take a look at the Forward.
> =20
>                                                 Ron
> =20
> =20
> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Ve=
lde (gvandeve)
> Sent: Wednesday, April 16, 2014 7:56 AM
> To: opsec wg mailing list
> Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com
> Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
> =20
> Please find this reminder to query for your feedback.
> =20
> Brgds,
> G/
> =20
> From: Gunter Van de Velde (gvandeve)=20
> Sent: 08 April 2014 11:18
> To: opsec wg mailing list
> Cc: KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org
> Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
> =20
> Dear OpSec WG,
> =20
>=20
> This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-securi=
ty.
> Due to the time taken to integrate all comments from the first WGLC this =
2nd WGLC is initiated.
> =20
> All three authors have replied, stating that they do not know of any IPR =
associated with this draft.
> =20
> The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-=
opsec-bgp-security/
> =20
> Please review this draft to see if you think it is ready for publication =
and comments to the list, clearly stating your view.
> =20
>=20
> This WGLC ends 22-April-2014.
> =20
>=20
> Thanks,
> G/
> =20
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
jerduran@cisco.com  -  +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE








From nobody Wed Apr 16 16:14:43 2014
Return-Path: <jerduran@cisco.com>
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 9A1A71A03CA for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 16:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level: 
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 pw1D4WF3dErp for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 16:14:35 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id DF1E21A03AC for <opsec@ietf.org>; Wed, 16 Apr 2014 16:14:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5489; q=dns/txt; s=iport; t=1397690053; x=1398899653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ad0XisW1d8+Rn3IEluuLxGFHkUXi00wiMxtucj47CNU=; b=bNOkMkRRwwdJ+3/MZ2wosUfmyXaFDg1KKdMllmVSY6Dj6Y042d0nL+He OPH37BlBc7danEmUpAgVHmU1YUVwVtbaY4LewMjl2puKA7W9F79240J23 qOpCvbHZY1AxTpWMaRJLn04/KKiJcVnJmOW7LDwyJ8c/8CM0EccOgbUi4 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FANUNT1OtJA2H/2dsb2JhbABZgwY7V8M3gSEWdIIlAQEBAwFyBxACAQhGMiUBAQQOBYd0CA3JdxeOLy4FB4MkgRQEmGaBN5ESgzGCKw
X-IronPort-AV: E=Sophos;i="4.97,875,1389744000"; d="scan'208";a="36449051"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 16 Apr 2014 23:14:13 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3GNEDX7010194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 23:14:13 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 18:14:13 -0500
From: "Jerome Durand (jerduran)" <jerduran@cisco.com>
To: "George, Wes" <wesley.george@twcable.com>
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9UN2+/T1QHbw+ATLC7yGU3XgLHJQAf9z4AABVG+QABOcUBAA==
Date: Wed, 16 Apr 2014 23:14:12 +0000
Message-ID: <950E64EC-8DD6-47CD-9C21-2530577F9A6B@cisco.com>
References: <CF6B0FC1.179B5%wesley.george@twcable.com> <FC8AB300-C5C4-4AE3-8E82-A2CE17E7C7EA@cisco.com> <CF6C45BA.17C3E%wesley.george@twcable.com>
In-Reply-To: <CF6C45BA.17C3E%wesley.george@twcable.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.100.140]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B5BE0B025F1D1B488EBD98DCA7DCFDB1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/RHP0H9io3q6T1omN0eD106uyv4c
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2014 23:14:40 -0000

>>  TCP sessions used by BGP can be secured with a variety of mechanisms.
>>  MD5 protection of TCP session header [14] was the first existing
>> mechanism.
>>  It is now deprececated by TCP Authentication Option (TCP-AO, [10])
>> which
>>  offers stronger protection. IPsec can also be used for this purpose.
>>  While MD5 is still the most used mechanism due to its availability in
>>  vendor's equipment, TCP-AO and MD5 SHOULD be preferred when
>> implemented.
>=20
> Looks fine, although I think you meant to say =93TCP-AO SHOULD be preferr=
ed=94
> not =93TCP-AO and MD5 SHOULD=94 in the last sentence.

Indeed!

>>> Section 3- may want to mention rate-limiting accepted traffic in
>>> addition to strict filtering of unacceptable traffic
>>=20
>> Maybe a note on that. We probably don't want to start discussing the
>> right thresholds here.
>=20
> Agree
>=20
>>> 5.2.1 (or possibly section 8) - Filtering peer ASes inbound from
>>> customers? (in this case =93peer=94 meaning a non-transit interconnect,=
 not
>>> just someone you are connected to via BGP) I.e. If I know that I should
>>> only receive routes with 701 in the path from 701 because I do not use
>>> any other ASN as transit to reach 701, I should filter routes inbound
>>> from other sources to ensure that they don=92t announce routes with tha=
t
>>> path. This is somewhere between the strict IRR based filters and the
>>> loose filters, and depends on the topology of the network and my
>>> business relationships, but I think it=92s a useful point to make to ad=
d
>>> some additional safety filtering to prevent =93my idiot customer is try=
ing
>>> to re-announce the internet to me=94 along with max-prefix, which you
>>> already cover.
>>=20
>> I think that first bullet of section 8 is saying this. We are saying we
>> need to make sure we receive only identified ASes from customer, we
>> probably don't need to add we have to filter the ones we don't want. Tel=
l
>> me if I didn't understand your point. Feel free to propose some modified
>> text.
>=20
> You=92re right, it=92s mostly saying that. I think the model you=92re adv=
ocating
> is a filter that explicitly permits certain ASNs, generated uniquely for
> each customer, meaning each has an implicit deny of anything that isn=92t
> explicitly permitted. That=92s certainly the better model. My suggestion =
was
> more for the second case =93if you cannot build filters=85=94, where buil=
ding a
> short list of explicitly denied ASNs that you should never see from *any*
> downstream customer (i.e. The ASNs of your peers and/or upstream transit
> providers) to a non-customer-specific filter that can be globally applied
> on all customer BGP sessions provides a useful safety mechanism beyond
> AS-path-length limits, and protects if the customer-specific filter is
> inadvertently not applied (since that never happens :-) ).
> Hope that=92s clearer.

It is, thanks. I propose to slightly change the end of the first bullet the=
n:

   o  You SHOULD accept from customers only AS(4)-Paths containing ASNs
      belonging to (or authorized to transit through) the customer.  If
      you can not build and generate filtering expressions to implement
      this, consider accepting only path lengths relevant to the type of
      customer you have (as in, if they are a leaf or have customers of
      their own), try to discourage excessive prepending in such paths.
      *This loose policy could be combined with filters for specific
      AS(4)-Paths that must not be accepted if advertised by the
      customer.*

Please tell me if that does the job. Feel free to propose an laternative te=
xt if not.


>>> This may be something that the RFC editor will fix, but it would be
>>> preferable to use the actual draft name or RFC number as the reference
>>> tag instead of numeric tags, so that the reader knows what you are
>>> referencing without having to jump to footnotes each time.
>>=20
>> If RFC editor can fix it I buy the idea. Otherwise you need to explain t=
o
>> me how to do it easily :)
>=20
> I just looked briefly at your XML compared with one of my drafts, and I
> can=92t see how it=92s different, so I=92m actually not sure how to fix, =
so I
> guess let=92s don=92t worry about it.

Good!

Thanks agin for your suport!

Jerome

>=20
> Wes George
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable prop=
rietary information, which is privileged, confidential, or subject to copyr=
ight 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 t=
he intended recipient of this E-mail, you are hereby notified that any diss=
emination, distribution, copying, or action taken in relation to the conten=
ts of and attachments to this E-mail is strictly prohibited and may be unla=
wful. If you have received this E-mail in error, please notify the sender i=
mmediately and permanently delete the original and any copy of this E-mail =
and any printout.

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
jerduran@cisco.com  -  +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE








From nobody Wed Apr 16 22:55:45 2014
Return-Path: <fgont@si6networks.com>
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 1479E1A0439 for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 22:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level: 
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, SPF_HELO_PASS=-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 bDJfYRRhTuda for <opsec@ietfa.amsl.com>; Wed, 16 Apr 2014 22:55:38 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF61A0458 for <opsec@ietf.org>; Wed, 16 Apr 2014 22:55:37 -0700 (PDT)
Received: from [2001:5c0:1000:a::c59] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1WafII-0002uJ-J7; Thu, 17 Apr 2014 07:55:30 +0200
Message-ID: <534F6CCF.9020506@si6networks.com>
Date: Thu, 17 Apr 2014 02:55:27 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>
References: <20140416024729.24745.47144.idtracker@ietfa.amsl.com>
In-Reply-To: <20140416024729.24745.47144.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/4-Mej62viW_2jJJDzhOxueQCz6c
Subject: [OPSEC] Revision of the IPv6 Firewalls document (Fwd: New Version Notification for draft-gont-opsec-ipv6-firewall-reqs-01.txt)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 05:55:42 -0000

Folks,

We have published a revision of the IPv6 firewalls I-D. Please find it
at:
<http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-01.txt>.

We have incorporated virtually all the comments received so far... which
have been a lot (both on- and off-list).

Among the changes are:

* We have clarified the requirements language.

* We have clarified some of the existing requirements, and addded new ones.

* We have incorporated many references that were missing in the -00 version.

* We incorporated some words in the area of performance -- which tends
to be pretty critical, as has been shown during the Berlin ipv6hackers
meeting last year.


If you provided feedback on the -00 version of the I-D, please do let us
know if we have addressed your comments. If you haven't provided
feedback on the -00 version, please do it for this one (-01).

Thanks!
Best regards,
Fernando




-------- Original Message --------
Subject: New Version Notification for
draft-gont-opsec-ipv6-firewall-reqs-01.txt
Date: Tue, 15 Apr 2014 19:47:29 -0700
From: internet-drafts@ietf.org
To: Will Liu <liushucheng@huawei.com>, "Shucheng LIU (Will)"
<liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>,
"Fernando Gont" <fgont@si6networks.com>, Marco Ermini
<marco.ermini@resmed.com>, "Marco Ermini" <marco.ermini@resmed.com>


A new version of I-D, draft-gont-opsec-ipv6-firewall-reqs-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-opsec-ipv6-firewall-reqs
Revision:	01
Title:		Requirements for IPv6 Enterprise Firewalls
Document date:	2014-04-16
Group:		Individual Submission
Pages:		18
URL:
http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/
Htmlized:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-firewall-reqs-01

Abstract:
   While there has been some work in the area of firewalls, concrete
   requirements for IPv6 firewalls have never been specified in the RFC
   series.  The more limited experience with the IPv6 protocols and the
   more reduced number of firewalls that support IPv6 has made it rather
   difficult to infer what are reasonable features to expect in an IPv6
   firewall.  This has typically been a problem for network operators,
   who typically have to produce a "Request for Proposal" from scratch
   that describes such features.  This document specifies a set of
   requirements for IPv6 firewalls, in order to establish some common-
   ground in terms of what features can be expected in them.





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.

The IETF Secretariat





From nobody Thu Apr 17 07:45:51 2014
Return-Path: <wesley.george@twcable.com>
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 6B5D41A01CB for <opsec@ietfa.amsl.com>; Thu, 17 Apr 2014 07:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.737
X-Spam-Level: 
X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 D_WevQm8VMiZ for <opsec@ietfa.amsl.com>; Thu, 17 Apr 2014 07:45:49 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 384411A0166 for <opsec@ietf.org>; Thu, 17 Apr 2014 07:45:49 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.97,879,1389762000"; d="scan'208";a="273396792"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Apr 2014 10:45:17 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 17 Apr 2014 10:45:41 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "Jerome Durand (jerduran)" <jerduran@cisco.com>
Date: Thu, 17 Apr 2014 10:45:41 -0400
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9aS7S8oZ3MFxLCRwCLDTeb/CIbvw==
Message-ID: <CF7560E7.187F2%wesley.george@twcable.com>
References: <CF6B0FC1.179B5%wesley.george@twcable.com> <FC8AB300-C5C4-4AE3-8E82-A2CE17E7C7EA@cisco.com> <CF6C45BA.17C3E%wesley.george@twcable.com> <950E64EC-8DD6-47CD-9C21-2530577F9A6B@cisco.com>
In-Reply-To: <950E64EC-8DD6-47CD-9C21-2530577F9A6B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/jyFF_egUcA5ws0SbtzSnoNULveM
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 14:45:50 -0000

T24gNC8xNi8xNCwgNzoxNCBQTSwgIkplcm9tZSBEdXJhbmQgKGplcmR1cmFuKSIgPGplcmR1cmFu
QGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5JdCBpcywgdGhhbmtzLiBJIHByb3Bvc2UgdG8gc2xpZ2h0
bHkgY2hhbmdlIHRoZSBlbmQgb2YgdGhlIGZpcnN0IGJ1bGxldA0KPnRoZW46DQo+DQo+ICAgbyAg
WW91IFNIT1VMRCBhY2NlcHQgZnJvbSBjdXN0b21lcnMgb25seSBBUyg0KS1QYXRocyBjb250YWlu
aW5nIEFTTnMNCj4gICAgICBiZWxvbmdpbmcgdG8gKG9yIGF1dGhvcml6ZWQgdG8gdHJhbnNpdCB0
aHJvdWdoKSB0aGUgY3VzdG9tZXIuICBJZg0KPiAgICAgIHlvdSBjYW4gbm90IGJ1aWxkIGFuZCBn
ZW5lcmF0ZSBmaWx0ZXJpbmcgZXhwcmVzc2lvbnMgdG8gaW1wbGVtZW50DQo+ICAgICAgdGhpcywg
Y29uc2lkZXIgYWNjZXB0aW5nIG9ubHkgcGF0aCBsZW5ndGhzIHJlbGV2YW50IHRvIHRoZSB0eXBl
IG9mDQo+ICAgICAgY3VzdG9tZXIgeW91IGhhdmUgKGFzIGluLCBpZiB0aGV5IGFyZSBhIGxlYWYg
b3IgaGF2ZSBjdXN0b21lcnMgb2YNCj4gICAgICB0aGVpciBvd24pLCB0cnkgdG8gZGlzY291cmFn
ZSBleGNlc3NpdmUgcHJlcGVuZGluZyBpbiBzdWNoIHBhdGhzLg0KPiAgICAgICpUaGlzIGxvb3Nl
IHBvbGljeSBjb3VsZCBiZSBjb21iaW5lZCB3aXRoIGZpbHRlcnMgZm9yIHNwZWNpZmljDQo+ICAg
ICAgQVMoNCktUGF0aHMgdGhhdCBtdXN0IG5vdCBiZSBhY2NlcHRlZCBpZiBhZHZlcnRpc2VkIGJ5
IHRoZQ0KPiAgICAgIGN1c3RvbWVyLioNCg0KSSBzdWdnZXN0IGEgc2xpZ2h0IGFkZGl0aW9uLSDi
gJxUaGlzIGxvb3NlIHBvbGljeSBjb3VsZCBiZSBjb21iaW5lZCB3aXRoDQpmaWx0ZXJzIGZvciBz
cGVjaWZpYyBBUyg0KS1QYXRocyB0aGF0IG11c3Qgbm90IGJlIGFjY2VwdGVkIGlmIGFkdmVydGlz
ZWQNCmJ5IHRoZSBjdXN0b21lciwgc3VjaCBhcyB1cHN0cmVhbSB0cmFuc2l0IHByb3ZpZGVyIG9y
IHBlZXIgQVNOcy7igJ0NCg0KSSB0aGluayB0aGUgZXhhbXBsZXMgbWFrZSBpdCBjbGVhcmVyIHdo
YXQgd2UgbWVhbi4NCg0KV2VzDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNo
bWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRp
b24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5
cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRl
bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo
aWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu
dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2Vt
aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRp
b24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz
dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2Vp
dmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp
YXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m
IHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo=


From nobody Thu Apr 17 11:45:12 2014
Return-Path: <rbonica@juniper.net>
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 E5E241A019C for <opsec@ietfa.amsl.com>; Thu, 17 Apr 2014 11:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Level: 
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Oh8fOqr24H_7 for <opsec@ietfa.amsl.com>; Thu, 17 Apr 2014 11:45:04 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2821A017A for <opsec@ietf.org>; Thu, 17 Apr 2014 11:45:04 -0700 (PDT)
Received: from mail198-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE042.bigfish.com (10.236.130.105) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Apr 2014 18:44:16 +0000
Received: from mail198-co9 (localhost [127.0.0.1])	by mail198-co9-R.bigfish.com (Postfix) with ESMTP id 749D23C02D4;	Thu, 17 Apr 2014 18:44:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(zz9371Ic89bh542I1dbaI1432I4015Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068h1954cbhz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h)
Received-SPF: pass (mail198-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rbonica@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(13464003)(164054003)(189002)(199002)(51704005)(2656002)(4396001)(19580405001)(50986999)(76576001)(76176999)(87936001)(54356999)(86362001)(74502001)(46102001)(81342001)(16601075003)(66066001)(80022001)(76482001)(15975445006)(81542001)(99396002)(74662001)(80976001)(15202345003)(19580395003)(83322001)(74316001)(79102001)(20776003)(83072002)(85852003)(33646001)(77982001)(99286001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:FF9FF13E.9CF29590.BDC77F6F.8EEAF113.2047F; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail198-co9 (localhost.localdomain [127.0.0.1]) by mail198-co9 (MessageSwitch) id 139776025426545_24408; Thu, 17 Apr 2014 18:44:14 +0000 (UTC)
Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.232])	by mail198-co9.bigfish.com (Postfix) with ESMTP id EC0BE98006E; Thu, 17 Apr 2014 18:44:13 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Apr 2014 18:44:14 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 17 Apr 2014 18:44:57 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 17 Apr 2014 18:44:55 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.244]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.244]) with mapi id 15.00.0918.000; Thu, 17 Apr 2014 18:44:55 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: "Jerome Durand (jerduran)" <jerduran@cisco.com>
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQGX/bdQAAN0kZAAAonwsAAbc/eAAB8yBgA=
Date: Thu, 17 Apr 2014 18:44:54 +0000
Message-ID: <4e776d1376d44c3c8e71f2a4a7d07d86@CO1PR05MB442.namprd05.prod.outlook.com>
References: <67832B1175062E48926BF3CB27C49B24113958CB@xmb-aln-x12.cisco.com> <cda8642294584887a88ba505424a2c19@CO1PR05MB442.namprd05.prod.outlook.com> <11F1FD94-5C9A-4653-BC34-214BA9A8A009@cisco.com>
In-Reply-To: <11F1FD94-5C9A-4653-BC34-214BA9A8A009@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.12]
x-forefront-prvs: 01842C458A
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/twuT7P3Q32OiNBYAxgWXeYIKV5M
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>, "kk@dropbox.com" <kk@dropbox.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 18:45:10 -0000

Jerome,

Your approach may work. Since you can't soften the 2119 definition of the w=
ord "MUST", you will have to do something clever in the Introduction to res=
trict the scope if the document's recommendations.=20

How will you do this?

                                                                           =
Ron


-----Original Message-----
From: Jerome Durand (jerduran) [mailto:jerduran@cisco.com]=20
Sent: Wednesday, April 16, 2014 6:52 PM
To: Ronald Bonica
Cc: Gunter Van de Velde (gvandeve); opsec wg mailing list; draft-ietf-opsec=
-bgp-security@tools.ietf.org; kk@dropbox.com
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security

Thank you Ron for your comment and support,

Actually I believe exceptions can more or less happen for every guideline l=
isted in the document. My view is that it is better to stay on the generic =
case and maybe better highlight in introduction that exceptions happen when=
 both peers agree to do so. Idea would be that normative language only refe=
r to classic peerings (not the exception scenario) so we don't have to chan=
ge MUST for SHOULD everywhere in the doc and lower the value of the doc.

What do you think?

Thanks

Jerome






Le 16 avr. 2014 =E0 16:50, Ronald Bonica <rbonica@juniper.net>  a =E9crit :

> Folks,
> =20
> In Sections 5.1.1.1 and 5.1.1.2, you say, "Only prefixes with value "Fals=
e" in column "Global" MUST be discarded on Internet BGP peerings."
> =20
> This statement is mostly true, but I can think of a corner case. Assume t=
hat two autonomous systems are cooperating to provide a DS-lite or some sim=
ilar service. They might agree to co-ordinate assignment of non-global rout=
es and exchange non-global routes with one another.
> =20
>                                                                          =
        =20
> Ron
> =20
> =20
> From: Ronald Bonica
> Sent: Wednesday, April 16, 2014 9:34 AM
> To: 'Gunter Van de Velde (gvandeve)'; opsec wg mailing list
> Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com
> Subject: RE: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
> =20
> Folks,
> =20
> This document is very comprehensive and well-written. Kudos to the author=
s.
> =20
> However, please take a look at the Forward.
> =20
>                                                 Ron
> =20
> =20
> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de=20
> Velde (gvandeve)
> Sent: Wednesday, April 16, 2014 7:56 AM
> To: opsec wg mailing list
> Cc: draft-ietf-opsec-bgp-security@tools.ietf.org; kk@dropbox.com
> Subject: Re: [OPSEC] Start of 2nd WGLC for=20
> draft-ietf-opsec-bgp-security
> =20
> Please find this reminder to query for your feedback.
> =20
> Brgds,
> G/
> =20
> From: Gunter Van de Velde (gvandeve)
> Sent: 08 April 2014 11:18
> To: opsec wg mailing list
> Cc: KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org
> Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
> =20
> Dear OpSec WG,
> =20
>=20
> This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-securi=
ty.
> Due to the time taken to integrate all comments from the first WGLC this =
2nd WGLC is initiated.
> =20
> All three authors have replied, stating that they do not know of any IPR =
associated with this draft.
> =20
> The draft is available here:=20
> https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/
> =20
> Please review this draft to see if you think it is ready for publication =
and comments to the list, clearly stating your view.
> =20
>=20
> This WGLC ends 22-April-2014.
> =20
>=20
> Thanks,
> G/
> =20
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching jerduran@cisco.com  -  +3=
3 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE











From nobody Thu Apr 17 13:03:19 2014
Return-Path: <jerduran@cisco.com>
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 91F0F1A007B for <opsec@ietfa.amsl.com>; Thu, 17 Apr 2014 13:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.773
X-Spam-Level: 
X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 VxJ81EBVVliG for <opsec@ietfa.amsl.com>; Thu, 17 Apr 2014 13:03:11 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 97F641A005E for <opsec@ietf.org>; Thu, 17 Apr 2014 13:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1397764988; x=1398974588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=o7Fs5deBw5lRAKvj9cw2Y5ZLZ9qg6qyRt/zN46IOLOA=; b=HYm0sf9kHzvKc52nA+SiW/kvL4n06hN1SH6sN+U3GGwkTMHBryMC5epO 3qree926DrxS6cEqNk+Zk4+9dBn0lA38HGEAph8s91sSZNEKp/gN5c0Vh lJwfxg/4oNBQEcDBXIHDSGfDeHMFK56kXpffs3ph6RKD+Qpk0Wlp81GuF 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAA0zUFOtJV2c/2dsb2JhbABZgwY7V8NmgScWdIIlAQEBAwFyBwULAgEIRjIlAQEEDgWHdAgNzA4Xji8uBQeDJIEUBJhugTeRFoMxgis
X-IronPort-AV: E=Sophos;i="4.97,881,1389744000"; d="scan'208";a="318571692"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 17 Apr 2014 20:03:07 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3HK36Gk005541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 20:03:06 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 15:03:05 -0500
From: "Jerome Durand (jerduran)" <jerduran@cisco.com>
To: "George, Wes" <wesley.george@twcable.com>
Thread-Topic: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9UN2+/T1QHbw+ATLC7yGU3XgLHJQAf9z4AABVG+QABOcUBAAAgiB2AAAsUIwA=
Date: Thu, 17 Apr 2014 20:03:06 +0000
Message-ID: <5C9402DC-FBCB-4A4D-B204-60CD98739CBA@cisco.com>
References: <CF6B0FC1.179B5%wesley.george@twcable.com> <FC8AB300-C5C4-4AE3-8E82-A2CE17E7C7EA@cisco.com> <CF6C45BA.17C3E%wesley.george@twcable.com> <950E64EC-8DD6-47CD-9C21-2530577F9A6B@cisco.com> <CF7560E7.187F2%wesley.george@twcable.com>
In-Reply-To: <CF7560E7.187F2%wesley.george@twcable.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.103.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <E7A71DDF16E86E4BACEE9FEF0A7E1535@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/mSPCnyGkB9-1-YO44-_G4-hTAGA
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 20:03:16 -0000

> I suggest a slight addition- =93This loose policy could be combined with
> filters for specific AS(4)-Paths that must not be accepted if advertised
> by the customer, such as upstream transit provider or peer ASNs.=94
>=20
> I think the examples make it clearer what we mean.

Perfect!

Jerome

>=20
> Wes
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable prop=
rietary information, which is privileged, confidential, or subject to copyr=
ight 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 t=
he intended recipient of this E-mail, you are hereby notified that any diss=
emination, distribution, copying, or action taken in relation to the conten=
ts of and attachments to this E-mail is strictly prohibited and may be unla=
wful. If you have received this E-mail in error, please notify the sender i=
mmediately and permanently delete the original and any copy of this E-mail =
and any printout.

--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
jerduran@cisco.com  -  +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand

CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE








From nobody Fri Apr 18 16:39:01 2014
Return-Path: <fred@cisco.com>
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 388331A0527 for <opsec@ietfa.amsl.com>; Fri, 18 Apr 2014 16:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.773
X-Spam-Level: 
X-Spam-Status: No, score=-114.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 V1HaIp7aEMgO for <opsec@ietfa.amsl.com>; Fri, 18 Apr 2014 16:38:51 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B58841A0503 for <opsec@ietf.org>; Fri, 18 Apr 2014 16:38:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33333; q=dns/txt; s=iport; t=1397864327; x=1399073927; h=from:to:cc:subject:date:message-id:mime-version; bh=6a2CM0k2heDKdJ9S4xFIAaX1hLZu1vbIKMBykwuEBo4=; b=F9s+Aw4q45vGsWLjfhi6jBxUzCeOpNxXfy3g1CLjENpsBv3SHm3wIhWM DaHrGztSojeQ//C8DBpmsCaB3d48ixRqybPBCMQJyPtK7jkWGBHu73tPv y9aIwOHsckT29ZTgNe1facx2V5Ejrx0E9sFkK+36EtMJMNuKYoLre42F/ M=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0FADy2UVOtJV2Y/2dsb2JhbABQCoMGT1e3EIwZUYEaFnSCJQEBAQMBGgNICgEJBQ0BNgFJJwQOEw0EiBoIDY4BvwUXiT2EOgkBBQQBBgEHJyICFwGDEYEUBJBsgTeCXYNukk+DMYFpAQEHFwYc
X-IronPort-AV: E=Sophos;i="4.97,886,1389744000";  d="asc'?scan'208";a="318629593"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 18 Apr 2014 23:38:45 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3INcjPI011073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 23:38:45 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 18:38:45 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: Thoughts on draft-gont-opsec-ipv6-firewall-reqs
Thread-Index: AQHPW19WUDen5ceWtk6r3ElyI+Whqw==
Date: Fri, 18 Apr 2014 23:38:44 +0000
Message-ID: <6B19BDB7-4DE2-4187-B5BA-07E4D48C03E1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.116]
Content-Type: multipart/signed; boundary="Apple-Mail=_D1DC2972-1227-4F1B-BA7E-F1949FF5D193"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ChcrugoCFG5t2mTDTYRqwQPoTTk
Cc: "draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org" <draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org>
Subject: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Apr 2014 23:38:57 -0000

--Apple-Mail=_D1DC2972-1227-4F1B-BA7E-F1949FF5D193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I thought I might take a crack at a few comments on this draft.

First comment: I=92d appreciate it if we had a framework for the =
discussion of this, RFC 6092, =
draft-hutton-rtcweb-nat-firewall-considerations, =
draft-jab-host-firewalls, draft-ietf-v6ops-balanced-ipv6-security, =
draft-vyncke-advanced-ipv6-security, and a long list of other drafts =
with the name =93firewall=94 in them.

Second comment: I think this draft is not about an IPv6 firewall, and as =
currently structured is likely to take approximately forever to discuss, =
and will then be wrong. Let me throw out a thought experiment: consider =
REQ SPC-70. This is listed as an =93IPv6=94 firewall feature, but it =
requires =93stateful=94 association of ICMPv6 replies to TCP, UDP, and =
ICMPv6 sessions - it doesn=92t mention IPv6, and apart from the ICMPv6 =
part, would be substantively the same if we were to suddenly decide to =
deploy CATNIP or TUBA. Why are these not a separate document that such a =
deployment could refer to? I can build that product on an enterprise =
scale if you can afford it, but you=92re talking about some serious =
state in the network, far beyond what firewalls do today. You want to =
specify the user interface for a firewall? Care to say exactly which =
firewall you can buy today incorporates both the firewall features and =
the user interface, and what market that is targeted at?

I=92m join to suggest that this be broken up into a number of =
separately-discussable documents, each of which defines a test target. =
If I build a product and claim that it firewalls IPv6, what are the =
requirements of that product? If I build a product (perhaps the same =
product) that claims to firewall TCP sessions, what are the requirements =
for that product? There are a variety of ways that user interfaces can =
be built, and they generally target different markets. What the IETF =
does NOT want to do is get in the way of vendor innovation in design of =
user interfaces. However, whatever UI a vendor provides, what are the =
requirements that it must address?

>    While there has been some work in the area of firewalls, concrete
>    requirements for IPv6 firewalls have never been specified in the =
RFC
>    series.

Except in RFC 6092.

> The more limited experience with the IPv6 protocols and the
>    more reduced number of firewalls that support IPv6 has made it =
rather
>    difficult to infer what are reasonable features to expect in an =
IPv6
>    firewall.  This has typically been a problem for network operators,
>    who typically have to produce a "Request for Proposal" from scratch
>    that describes such features.  This document specifies a set of
>    requirements for IPv6 firewalls, in order to establish some common-
>    ground in terms of what features can be expected in them.

> 2.  Introduction
>=20
>    While the IETF has published a large number of documents discussing
>    IP and IPv6 packet filtering (see e.g. [RFC7126] and some documents
>    on the topic of IP firewalls (see e.g. [RFC2979] and [RFC3511]),
>    concrete requirements for IP firewalls have never been specified in
>    the RFC series.

Except in RFC 6092.

> When it comes to IPv4, a number of features have
>    become common over the years, and firewall requirements have =
somehow
>    become operational wisdom.  When it comes to IPv6 [RFC2460], the =
more
>    limited experience with the protocols, and the reduced variety of
>    IPv6 firewalls has made it rather difficult to specify what are
>    reasonable features to be expected of an IPv6 firewall.  This has
>    proven to be a problem for network operators (who have typically =
had
>    to produce a "Request for Proposal" from scratch), but also for
>    vendors (who lack a well defined set of requirements that can serve
>    as a roadmap for implementation).

I=92m not sure that is actually true. IPv4 firewalls are far from =
standardized; they all supply some basic functions, such as being able =
to block traffic, but the mechanisms on which they operate differ a =
great deal. My company has at least two broad classes of firewall =
products, based on topological zones and the roles of actors, and =
somewhere in my head I think we have a third. Juniper, Checkpoint, =
Barracuda, and others have other technologies that are based on =
anomaly-based and signature-based intrusion detection, and other =
technologies. You can consider a proxy to be a firewall, in that it can =
observe sessions and prevent them. The features available in various =
firewalls differ quite a bit, and that is the basis on which those =
vendors compete.

And at first blush, I=92ll bet the requirements for an IPv6 firewall are =
almost identical to those of an IPv4 firewall. Reason? The attacks are =
the same, and the security policies are the same. If a smurf can run on =
IPv4, it can run on IPv6. Amplification attacks, spoofed source address =
issues, and so on and so forth, are likely to be identical, because in a =
certain sense IPv6 is IPv4 with bigger addresses, and the transports and =
applications use the two interchangeably.

The one place that the IETF would *like* security policy to differ is =
that a to of security practitioners bought, hook line and sinker, the =
circa-1995 marketing that a NAT was a security technology; it=92s not, =
it=92s an address multiplexing technology, and produces a certain kind =
of firewall-like capability as an accidental side-effect, but a lot of =
corporate security policies star with =93you put your NAT here=94, and =
then stop.

That=92s not to say that we shouldn=92t document a set of requirements =
for a firewall. But let=92s not be silly about it.

> 4.  General Security Features
>=20
>    REQ GEN-5:
>       The firewall MUST include performance benchmarking =
documentation.
>       Such documentation MUST include information that reflects =
firewall
>       performance with respect to IPv6 packet, but also regarding how
>       IPv6 traffic may affect the performance of IPv4 traffic.  The
>       aforementioned documentation MUST be, at the very least,
>       conditionally-compliant with both [RFC3511] and [RFC5180] (that
>       is, it MUST support all "MUST" requirements in such documents, =
and
>       may also support the "SHOULD" requirements in such documents).
>=20
>          NOTE: This is for operators to spot be able to identify cases
>          where a devices may under-perform in the presence of IPv6
>          traffic (see e.g. [FW-Benchmark]).  XXX: This note may be
>          removed before publication if deemed appropriate.

I=92m OK with basic benchmark information, but, well, there=92s lies, =
damn lies, and benchmarks.=20

>    REQ GEN-10:
>       All features of the firewall MUST be able to be individually
>       configured (at least ON or OFF, with other configurable =
parameters
>       as applicable).  A well-documented default initial setting must =
be
>       provided for each feature.

>    REQ GEN-20:
>       MUST support basic Access Control Lists (ACLs).

Define a =93basic=94 access list?=20

>    REQ GEN-30:
>       MUST support stateless packet inspection and filtering at
>       transport layer.

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-40:
>       MUST support stateful packet inspection and filtering at =
transport
>       layer.

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-50:
>       SHOULD support full-proxy for the TCP [RFC0793] connections (the
>       handshake is validated on the firewall before reaching the =
target
>       system).
>=20
>          Some products identify this feature with terms such as "TCP
>          Intercept and Limiting Embryonic Connections".

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-60:
>       MUST be able to enforce timeouts on protocol sessions based on =
the
>       upper-layer protocol (e.g. enforce a timeout on the FIN-WAIT =
state
>       for TCP connections, a timeout for DNS query/respose pair, =
etc.).
>       In general, it MUST have different timeout parameters and
>       thresholds to be used to prevent idle sessions from exhausting
>       resources on the device and/or the service that is defended.  =
For
>       sessions composed of multiple packets (such as TCP connections),
>       the exchange of valid packets MUST refresh the timers employed =
for
>       enforcing the aforementioned timeouts.
>=20
>          NOTE: This is to avoid the known and buggy behavior where
>          firewalls enforce a maximum lifetime for the protocol session
>          (e.g. TCP connection) regardless of whether there is ongoing
>          exchange of legitimate packets for such session.

This also forces certain behaviors, such as TCP keep-alives, to be used, =
which means that host applications that don=92t currently use them to be =
changed before they can be used in the context of this firewall.

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ GEN-70:
>       MUST be able to provide anti-spoofing features (e.g. uRPF ).

I=92d actually suggest that this is general to routers. You might take a =
look at RFC 3704. An important behavior in uRPF is that it actually =
depend on the RIB rather than the FIB, and should have the ability to =
have external information added to it such as =93I know this address is =
<there>, but it is not being advertised to me in routing (it is a static =
route or aggregated into some other route), so I can=92t automagically =
know that.=94

>    REQ GEN-80:
>       MUST be able to redirect specific traffic to a proxy server e.g.
>       for HTTP/S protocols.
>=20
>          NOTE: "Redirection means that the firewall should be able to
>          divert the traffic to a proxy - i.e., take the traffic, send =
it
>          to an inspection engine, receive it back and forward it (all
>          this completely transparent to the users).

This can be complicated. if I am redirecting DNS to a local server, for =
example, I need the server to be able to accept a packet as =93to it=94 =
regardless of its destination address, and respond as if it were that =
system. If it is http/https, I=92d actually rather have this built into =
routing somehow - instead of all of the traffic going through the =
firewall to the proxy, and routing deliver it to the proxy in the first =
place.

>    REQ GEN-90:
>       MUST be able to detect and reject invalid source or destination
>       addresses (e.g. local-link addresses that try to traverse the
>       firewall) with a single policy.

Again, a general router requirement. Any router needs to be able to =
generate an ICMP Destination Unreachable for any of the seven valid =
codes if appropriate. That includes validating source address scope.

> 5.  IPv6-Specific Features
>=20
>    REQ SPC-10:
>       MUST be able to filter ICMPv6 [RFC4443] traffic at a message =
type/
>       code granularity.  [RFC4890] MUST be employed for the default
>       filtering configuration.

ICMPv6 is not IPv6. This belongs in an ICMPv6-specific firewall =
specification. It=92s OK to make a requirement of the IPv6 firewall =
specification that it also implement the ICMPv6 specification.

>    REQ SPC-20:
>       MUST be able to block packets containing any specified extension
>       header type (based on its Next Header value), on a specified
>       number of instances of a specified extension header type, and on =
a
>       specified overall number of IPv6 extension headers.
>=20
>    REQ SPC-30:
>       MUST be able to block IPv6 packets that employ a Routing Header
>       both at the granularity of Extension Header Type (as required in
>       SPC-20) and Routing Header Type.

I=92d actually generalize that. Any of the extension headers that can =
handle a sub-option (of which the Routing Header and Destination Header =
are examples) should be able to filter on the presence, absence, or =
content of the various sub-options.

>    REQ SPC-40:
>       SHOULD be able to drop packets based on IPv6 option types.

Is that the same as SPC-30?

>    REQ SPC-50:
>       MUST be able to detect IPv6 tunnels such as SIIT [RFC6145], 6to4
>       [RFC3056], 6in4 [RFC4213], ISATAP [RFC5214] and Teredo [RFC4380]
>       (please see [RFC7123], and MUST be able to selectively block or
>       allow them for specific sources, destinations, routes or
>       interfaces.

Why is this not =93must implement an ACL that can permit or deny traffic =
based on any combination of source and destination prefixes or port =
numbers, or next header (e.g. protocol) values=94?

>    REQ SPC-60:
>       MUST be able to validate IPv6 Neighbor Discovery [RFC4861] =
packets
>       (RS, RA, NS, NA, Redirect) according to
>       [I-D.ietf-opsec-ipv6-nd-security].

Why is this not a requirement of any IPv6 node? What makes it specific =
to a firewall?

>    REQ SPC-70:
>       MUST be able to statefully match ICMPv6 errors to TCP [RFC0793],
>       UDP [RFC0768], and ICMPv6 [RFC4443] communication instances (see
>       [RFC5927]).

So, it not only keeps source/destination pair state, as a NA(P)T might, =
but tracks send and acknowledge sequence numbers, last message sent (SYN =
vs data vs ack vs FIN/RST), and where the conversation is in its state =
machine. This precludes loa-sharing among firewalls, as the most recent =
message will by definition have passed one and not both.

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ SPC-80:
>       MUST be able to parse all defined extension headers according to
>       [RFC7045], and SHOULD filter packets containing IPv6 Extension
>       Headers as recommended in [draft-gont-opsec-ipv6-eh-filtering].

How does this differ from SPC-20?

>    REQ SPC-90:
>       MUST be able to find the upper-layer protocol in an IPv6 header
>       chain (see [RFC7112].

How does this differ from SPC-80?

>    REQ SPC-100:
>       SHOULD be able to normalize (rewrite) the following IPv6 header
>       fields on a per-interface basis:
>=20
>       *  Hop Limit

DANGER! DANGER WILL ROBINSON! Do you *really* want to do that?

> 6.  VPN Security Requirements
>=20
>    REQ VPN-10:
>       MUST implement IPsec-based [RFC4301] VPN technology.

What, precisely, does that mean? Does it mean =93must implement ESP=94? =
"must implement IPsec/UDP=94? What types of crypto algorithms? =
Algorithms like DMVPN go quite a way beyond that; are you also looking =
at PKI solutions, VPN Routing, and the like?

>    REQ VPN-20:
>       MUST implement "hub-and-spoke" Dynamic Multipoint VPN-like
>       technology, allowing creation of dynamic-meshed VPN without =
having
>       to pre-configure all of possible tunnels.

=93Must reverse-engineer Cisco proprietary technology=94=20
=
http://www.cisco.com/c/en/us/products/security/dynamic-multipoint-vpn-dmvp=
n/index.html

>    REQ VPN-30:
>       MUST implement SSL/TLS-based [SSL-VPNs] VPN technology.

Must fix Heartbleed?

>    REQ VPN-40:
>       MUST be able to use digital certificates, including CRL and OCSP
>       revocation checking methods, to mutually authenticate VPN peers.

Is that part of VPN-30?

>    REQ VPN-50:
>       MUST be able to disable or enable split-tunnelling feature on =
VPN
>       as required.

Not sure what you mean. Does that become =93must support ACLs=94 for who =
it may or may not connect to, and diverting traffic among various peers?

>    REQ VPN-60:
>       MUST support the enrollment of the system in a PKI =
infrastructure
>       for the regular renewal of certificates.

Should we specify the technology this implies? I think there are several =
options.

>    REQ VPN-70:
>       MUST be able to transit IPv4 and IPv6 packets providing full
>       parity for services, and also offer both protocols in dual-stack
>       in the same VPN connection.

IPv4 is not IPv6. I certainly don=92t object to calling for feature =
parity given that one implements IPv4, but I don=92t think you want to =
make an IPv6-only product non-compliant.
=20
>    REQ VPN-80:
>       MUST be able to apply to the tunnelled content that is =
terminated
>       on the device, the same inspection policies that are possible in
>       the non tunnelled traffic.

earlier, I started to write "To my way of thinking, any tunnel, =
including a VPN tunnel, can be an external interface just like a =
physical interface - it just has to connect to someone deemed =
=93untrusted=94. Do you want to say something about filtering traffic =
passed to/through VPN tunnels?=94. I=92m glad you put this here.

DMVPN, which you referred to, has the ability to emulate a n NBMA =
network similar to ATM or Frame Relay - the header is the same, but it =
is used as an encapsulation rather than as a static tunnel. Thinking =
about this requirement in that context makes my head hurt; do I want to =
have different policies for the various neighbors on an NBMA interface, =
or is it OK to have one policy for all of the neighbors on the =
=93interface=94?

>    REQ VPN-90:
>       MUST perform a full validation of the certificates' chains when
>       verifying the validity of the OCSP/CLR responses.  Caching of
>       responses SHOULD be configurable by end users, and the default
>       response SHOULD be not to accept a non-valid certificate.  The
>       default response MAY be overridden by the administrators, but it
>       MUST be configurable on a per-domain basis (e.g. accept =
incomplete
>       certificate chains for "intranet_of_internal_corp.example.org",
>       but refuse it for all of the other domains).
>=20
> 7.  Denial of Service (DoS) Protection
>=20
>    REQ DoS-10:
>       MUST be able to protect against implementation-specific attacks,
>       including:
>=20
>       *  Winnuke [Myst1997]
>=20
>       *  ping-of-death [Kenney1996]
>=20
>       *  Smurf [CERT1998a]
>=20
>       *  LAND Attack [Meltman1997]
>=20
>       *  Teardrop Attack [CERT1997] [Junos-Teardrop]

So, just checking on the implications here. Nobody has thought of a new =
DDOS attack since 1998?

>    REQ DoS-20:
>       MUST be able to protect against IPv6 resource exhaustion =
attacks,
>       including:
>=20
>       *  fragment flooding attacks

Protect what against such attacks? Itself, hosts behind it? If hosts =
behind it, are you asking for the stateful firewall to also include =
reassembly and re-transmission of incoming traffic to prevent the host =
from needing to do so?

>       *  Neighbor Cache Exhaustion attacks, whether launched from a
>          local network (see [I-D.ietf-opsec-ipv6-nd-security] or from
>          remote networks (see [RFC6583]

It certainly needs to protect itself. It can=92t protect hosts behind =
it, especially if they are on a different LAN. why is this not a general =
host requirement?

>    REQ DoS-30:
>       MUST be able to protect against TCP flooding attacks: =
connection-
>       flooding, FIN-WAIT-1 flooding, etc. (see e.g. [CPNI-TCP])

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ DoS-40:
>       MUST be able to protect against TCP resource exhaustion attacks:
>       zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP])

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

SYN-flood is generally best solved using good table design in a TCP =
implementation. TCP Cookies, LRU lists of TCBs that enable you to re-use =
a TCB that received a SYN and nothing since, and so on.

>    REQ DoS-50:
>       MUST be able to detect and drop malformed IPv6 packets =
(incorrect
>       header/option lengths, etc.).

Hey! This is great! This IPv6 firewall actually does something with =
IPv6!

Is a side-effect of this that we can=92t deploy a new feature like we =
had with ECN?

>    REQ DoS-60:
>       MUST be able to detect and drop malformed TCP packets (incorrect
>       segment/options lengths, etc.).

The transport layer is not IPv6. This belongs in a =
transport-layer-specific firewall specification, as it will be portable =
to IPv4, IPv7, and IPv9 firewalls that use the same transport.

>    REQ DoS-70:
>       MUST be able to provide bandwidth management (QoS or anti-
>       flooding) policies customizable for specific source and
>       destination networks, or by VLAN or MPLS ID.

Hmm. That kind of thing is usually found in higher-end equipment. Are =
you saying that a residential firewall that one purchases for peanuts =
needs to do this? Do you have a market requirement?

>    REQ DoS-80:
>       MUST be able to participate to a blackhole/synkhole routing
>       infrastructure as per [RFC5635].

This is a general router requirement.

>    REQ DoS-85:
>       MUST be able to fetch and use third party "reputational" IP =
white-
>       and black-lists (e.g. download them via RSS feeds or query via
>       them DNS record) and use them in policy constructs/ACLs.  In
>       general, it MUST be able to provide some form of reputational
>       service for IP addresses which must include IPv6 networks.

In an IPv6 specification, you have to say that this also applies to =
IPv6?

When it comes to things like this, addresses fall broadly into two sets =
- the addresses we forward from, and the rest. The firewall won=92t take =
a 20%-trustworthy address and forward 20% of its packets. I think you=92re=
 going to have to specify further what is meant here. Operators will =
usually download white lists or black lists and use a default for the =
other, and if there is a numeric value in the record, we=92ll need to be =
able to specify a threshold of some sort.

>    REQ DoS-90:
>       MUST be able to set up a maximum session setup rate, and detect
>       hosts or networks exceeding it.

Easier said than done. If I access a site that has hundreds of thumbnail =
images, and the images all are on different hosts or what appear to be =
different hosts, I can set up sessions at a very high rate for a short =
amount of time. If that exceeds a firewall configuration, am I =
blacklisted forever? Or until my privacy address changes?

This sounds like one of those =93in theory...=94 things...

>    REQ DoS-100:
>       MUST be able to set up a maximum IPv6 source and/or destination
>       session limit, and detect when they are exceeded.

Is this to protect the firewall (table abuse), the host, or the =
organization maintaining it? TCP sessions now commonly don=92t close - =
they just fade away. In my zillion-thumbnail example, it would be pretty =
easy to imagine the TCBs being re-used without going through =
FIN/FIN-ACK, just grabbing it and opening a new session using it, =
knowing that IF the peer ever sends a packet he=92ll get an RST. How =
does this interact with this requirement?

>    REQ DoS-110:
>       For each of the previous detection controls, different
>       configurable reactions SHOULD be possible by IPv6 address and
>       network sources and/or destinations.  The minimum actions =
required
>       are the following:
>=20
>       1.   allow the traffic ("ignore" or "whitelist")
>=20
>       2.   allow the traffic but log ("bypass" or "detection only" =
mode)
>=20
>       3.   drop the packet (only the offending packet but do not reset
>            the connection)
>=20
>       4.   drop session (drop the entire connection, but do not send a
>            reset back)
>=20
>       5.   "greylist" - put it in a list of blocked addresses, but
>            remove it from the list after a configurable amount of time
>=20
>       6.   send an email/SMS/pager text to the firewall administrator
>=20
>       7.   send TCP reset to source only
>=20
>       8.   send TCP reset to destination only
>=20
>=20
>=20
>=20
> Gont, et al.            Expires October 18, 2014               [Page =
10]
> Internet-Draft               IPv6 Firewalls                   April =
2014
>=20
>=20
>       9.   send TCP reset to both source and destination
>=20
>       10.  perform a specific, preconfigured change on the firewall
>            policy
>=20
>       11.  feed a third party source such as a switch/NAC/NAP or =
RADIUS
>            system, to isolate/quarantine the offending port/MAC =
address/
>            user
>=20
>       12.  quarantine the specific traffic or source (block them for a
>            configurable amount of time, e.g. 5 minutes, and then allow
>            them again; eventually, the quarantine time may get longer =
if
>            the offense is repeated)

Sure there isn=92t a 13th option? If a vendor added a 13th option, would =
s/he be in violation of the specification?

> 8.  Application Layer Firewall
>=20
>    REQ APP-10:
>       MUST be able to provide web filtering features, such as =
enforcing
>       access to allowed web content and filtering high risk URLs such =
as
>       anonymizers and known hostile addresses.

What, specifically, does this have to do with IPv6? The rules would =
presumably be the same whether it runs on TCP/IPv4, TCP/IPv6, QUIC/IPv4, =
QUIC/IPv6, SCTP/IPv4, SCTP/IPv6, COAP/IPv6, or anything else. This =
belongs in an application-specific document.

>    REQ APP-20:
>       MUST be able to provide email filtering features, such as
>       mitigating spam, phishing and email harvesting, and enforce =
email
>       policies.

What, specifically, does this have to do with IPv6? The rules would =
presumably be the same whether it runs on TCP/IPv4, TCP/IPv6, QUIC/IPv4, =
QUIC/IPv6, SCTP/IPv4, SCTP/IPv6, COAP/IPv6, or anything else. This =
belongs in an application-specific document.

> 9.  Logging, Auditing and Security Operation Centre (SOC) requirements
>=20
>    REQ SOC-10:
>       MUST generate log for all the changes performed to the system,
>       including change of group membership for a device, new or =
removed
>       devices in a group, new or removed administrators.
>=20
>    REQ SOC-20:
>       MUST provide the following features:
>=20
>       1.  Connection logs
>=20
>       2.  Local log storage
>=20
>       3.  Network logging
>=20
>       4.  Real time log viewer
>=20
>       5.  Attack detected
>=20
>       6.  Per rule logging
>=20
>       7.  Automatic log file compression
>=20
>       8.  Log file rotation

No port logging? Your government is pretty interested in port logging. =
So is mine.

>    REQ SOC-30:
>       MUST be able to generate a log for:
>=20
>       1.  all the logins, logouts and failed login attempts from
>           firewall administrators
>=20
>       2.  any modifications or disabling of the firewall rules
>=20
>    REQ SOC-40:
>       Any security event detected - malicious traffic, hit of a =
policy,
>       policy violation, termination of a session and so on - MUST be
>       able to generate a log, and be configurable to do that or not by
>       administrators.

>    REQ SOC-50:
>       There MUST be a mechanism to prevent log flooding from the =
device
>       against the management system, such as aggregation of like =
events.
>=20
>    REQ SOC-60:
>       The amount of information in the alerts MUST be configurable; it
>       SHOULD possible to have the date/time and type of event and the
>       full payload of the traffic that has triggered the signature/
>       event.

How about the protocol? For example, syslog is common, but IPFIX can =
also be useful on high-rate systems.

>    REQ SOC-70:
>       The firewall MUST minimize the number of log entries generated =
for
>       a single event - e.g. when repeated similar events for a short
>       period of time are detected, they are aggregated and the
>       cumulative number of events is reported.
>=20
>    REQ SOC-80:
>       The firewall MUST be able to send logs in multiple ways and
>       formats, for instance UDP syslog, TCP syslog, SMTP, SNMP and so
>       on.  It must be possible to configure different ways and formats
>       for different policies and configure some ways and formats as a
>       "backup" in the case that the main way fails.  Please describe =
the
>       different possibilities.
>=20
>    REQ SOC-90:
>       The firewall SHOULD alert the firewall administrator when the
>       policy to be enforced does not follow the advice in [RFC4890] --
>       particularly if the filtering policy would block/drop ICMPv6
>       Packet Too Big error messages.

> 10.  Console and Events Visualization requirements

Why is this a *firewall* requirement?

>    REQ CON-10:
>       MUST provide a dashboard view, which must be customizable by =
end-
>       user and end-users' group (e.g. their Microsoft Active Directory
>       or LDAP group).

So, vendors like Cisco need not apply, because we don=92t ship terminals =
with our equipment.

>    REQ CON-20:
>       The dashboard must be able to include system health monitoring
>       information, such as the following:
>=20
>       1.  CPU idle
>=20
>       2.  Real and Swap memory usage
>=20
>       3.  Disk usage
>=20
>       4.  Number of accepted and dropped packets
>=20
>       5.  Operating status for all supported facilities (HA, QoS, VPN)
>=20
>       6.  VPN tunnels status
>=20
>       7.  NIC link state

But you can get that information from a Cisco product. It=92s just not =
in a fancy GUI on a built-in screen display. Why not say what =
information you want to access without specifying how it is accessed?

>    REQ CON-30:
>       MUST have the possibility to select a particular piece of data =
or
>       individual alert, and visualize the policy that has triggered =
the
>       event.

Define =93visualize=94? Is that anything like =93display=94?

>    REQ CON-40:
>       MUST be able to create exception filters that will suppress
>       visualization of a specific alert (e.g. from specific sources, =
or
>       specific events), without actually affecting the detection and =
log
>       retention.
>=20
>    REQ CON-50:
>       MUST provide a remote access method to obtain all current
>       operational data on demand, in a documented format, covering =
items
>       such as those listed in REQ CON-20.
>=20
>          Note: This is to be able to integrate firewall operations in =
an
>          existing NMS.

It is common to make suggestions. SSH, NetConf, SNMP, and other =
solutions come to mind.

> 11.  Reporting requirements
>=20
>    REQ REP-10:
>       Built in reports MUST be provided by default, such as protocol
>       distribution, policy and rule matched, top attacks, top sources/
>       destinations, top targets, top geographical sources, device =
status
>       including utilizations, and so on.

Reports to whom, with what authorization requirements?=20

>    REQ REP-20:
>       SHOULD allow to run reporting over historical and archived logs,
>       automatically restoring and re-archiving them.

So - is the firewall required to support rotating media? Is there any =
chance that the medium might be in network-attached storage, and access =
to the media from a different system?

--Apple-Mail=_D1DC2972-1227-4F1B-BA7E-F1949FF5D193
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFTUbeCbjEdbHIsm0MRAt6gAKDzkjB8YfpnreoF8kZHJwTBFkphIgCggsFm
i9L6nDI8lLRefi+n/o50+y4=
=B3m5
-----END PGP SIGNATURE-----

--Apple-Mail=_D1DC2972-1227-4F1B-BA7E-F1949FF5D193--


From nobody Fri Apr 18 21:32:35 2014
Return-Path: <rdobbins@arbor.net>
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 70C3F1A00C0 for <opsec@ietfa.amsl.com>; Fri, 18 Apr 2014 21:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wlSyVPtO-kJc for <opsec@ietfa.amsl.com>; Fri, 18 Apr 2014 21:32:29 -0700 (PDT)
Received: from gwo4.mbox.net (gwo4.mbox.net [165.212.64.24]) by ietfa.amsl.com (Postfix) with ESMTP id 161371A00C2 for <opsec@ietf.org>; Fri, 18 Apr 2014 21:32:29 -0700 (PDT)
Received: from gwo4.mbox.net (localhost [127.0.0.1]) by gwo4.mbox.net (Postfix) with ESMTP id 3g9h944dkVzrlKsH; Sat, 19 Apr 2014 04:32:24 +0000 (UTC)
X-USANET-Received: from gwo4.mbox.net [127.0.0.1] by gwo4.mbox.net via mtad (C8.MAIN.3.82G)  with ESMTP id 547sDseGV8384Mo4; Sat, 19 Apr 2014 04:32:21 -0000
X-USANET-GWS2-Tagid: UNKN
Received: from S1P5HUB6.EXCHPROD.USA.NET [165.212.120.254] by gwo4.mbox.net via smtad (C8.MAIN.3.95E)  with ESMTPS id XID339sDseGw1603Xo4; Sat, 19 Apr 2014 04:32:22 -0000
X-USANET-Source: 165.212.120.254 OUT rdobbins@arbor.net S1P5HUB6.EXCHPROD.USA.NET TLS
X-USANET-MsgId: XID339sDseGw1603Xo4
Received: from S1P5DAG6A.EXCHPROD.USA.NET ([169.254.1.225]) by S1P5HUB6.EXCHPROD.USA.NET ([10.120.223.36]) with mapi id 14.03.0181.006; Sat, 19 Apr 2014 04:30:59 +0000
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs
Thread-Index: AQHPW19WUDen5ceWtk6r3ElyI+Whq5sYWaWA
Date: Sat, 19 Apr 2014 04:30:58 +0000
Message-ID: <C04F38A8-47BA-4867-B842-E7CC989B9E1A@arbor.net>
References: <6B19BDB7-4DE2-4187-B5BA-07E4D48C03E1@cisco.com>
In-Reply-To: <6B19BDB7-4DE2-4187-B5BA-07E4D48C03E1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [207.204.241.96]
Content-Type: multipart/signed; boundary="Apple-Mail=_EDC36BC4-85C2-4F9C-B98B-A366E8660826"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/luRpyeFkzjUQngUQdcvkKKYD8-U
Cc: "draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org" <draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org>
Subject: Re: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Apr 2014 04:32:33 -0000

--Apple-Mail=_EDC36BC4-85C2-4F9C-B98B-A366E8660826
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Apr 19, 2014, at 6:38 AM, Fred Baker (fred) <fred@cisco.com> wrote:

> I=92m join to suggest that this be broken up into a number of =
separately-discussable documents, each of which defines a test target.=20=


Concur 100% - and with everything else Fred noted, along with my =
previous comments.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton


--Apple-Mail=_EDC36BC4-85C2-4F9C-B98B-A366E8660826
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlNR/BEACgkQqFo5ORybTB3E1gCfXQLvi+tGHZUZqws3ekbh7u2b
HZwAoNOAwT26ITo5TUCVnNLxRGPIBb8y
=V0k2
-----END PGP SIGNATURE-----

--Apple-Mail=_EDC36BC4-85C2-4F9C-B98B-A366E8660826--


From nobody Sat Apr 19 07:25:23 2014
Return-Path: <lbromirs@cisco.com>
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 EF9651A0252 for <opsec@ietfa.amsl.com>; Sat, 19 Apr 2014 07:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Level: 
X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 1UkKTjVuY4qm for <opsec@ietfa.amsl.com>; Sat, 19 Apr 2014 07:25:18 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id E54451A024B for <opsec@ietf.org>; Sat, 19 Apr 2014 07:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=749; q=dns/txt; s=iport; t=1397917514; x=1399127114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Z867yRhAWsQyPghJvN+TyvQX2eZsUQ71U7lz4WIc47w=; b=hJnXEqN/0NvPyt9Iw4rU/WMbFtnQuUkCYGbDPFNviOUa3LlgVQwpnzUb RejdyPbIlPRbFYrvFjVbE08DKsScW4mGP/MK2RNZkgYQ7tgivdIVGgyxQ dzGiZlEhSHMZTaMz4QjLuL7x5YIfwfhBaE4BpvNoDbjDqx/oIYaNQK9nX g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFAI+GUlOtJA2L/2dsb2JhbABZgwaENcB2gRwWdIIlAQEBAwEEHARVBQsCAQgYAygDMiUCBAENBYg5CKoMDKNBF4EqjEs6MweCcDSBFAEDmG6ST4Mx
X-IronPort-AV: E=Sophos;i="4.97,888,1389744000"; d="scan'208";a="37148241"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 19 Apr 2014 14:25:13 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3JEPDYw006404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Apr 2014 14:25:13 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Sat, 19 Apr 2014 09:25:12 -0500
From: "Lukasz Bromirski (lbromirs)" <lbromirs@cisco.com>
To: "opsec@ietf.org" <opsec@ietf.org>, "draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org" <draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org>
Thread-Topic: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs
Thread-Index: AQHPW19WUDen5ceWtk6r3ElyI+Whq5sYWaWAgACl9ro=
Date: Sat, 19 Apr 2014 14:25:12 +0000
Message-ID: <E42542A1-3A1F-4D82-AF56-C5BEEE81C1BA@cisco.com>
References: <6B19BDB7-4DE2-4187-B5BA-07E4D48C03E1@cisco.com>, <C04F38A8-47BA-4867-B842-E7CC989B9E1A@arbor.net>
In-Reply-To: <C04F38A8-47BA-4867-B842-E7CC989B9E1A@arbor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZeN5HoU1eBGQMmZNpP99zF0NiUY
Subject: Re: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Apr 2014 14:25:22 -0000

> On 19 kwi 2014, at 06:32, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
>> On Apr 19, 2014, at 6:38 AM, Fred Baker (fred) <fred@cisco.com> wrote:
>> I=92m join to suggest that this be broken up into a number of separately=
-discussable documents, each of which defines a test target.
> Concur 100% - and with everything else Fred noted, along with my previous=
 comments.

Yes, the doc is pretty lenghty and deals with all bells and whistles you ca=
n imagine. But only small percentage is IPv6 related, some points ask for u=
nnecessary bloating of firewall code (BGP blackholing, MPLS, e-mail/url fil=
tering), and some seems to be inspired by some specific products.

--=20
=A3ukasz Bromirski
CCIE R&S/SP #15929, CCDE 2012::17


From nobody Mon Apr 21 02:37:36 2014
Return-Path: <fgont@si6networks.com>
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 2AAAD1A01E5 for <opsec@ietfa.amsl.com>; Mon, 21 Apr 2014 02:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 zoccO8pxuXZ0 for <opsec@ietfa.amsl.com>; Mon, 21 Apr 2014 02:37:27 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1919E1A01CE for <opsec@ietf.org>; Mon, 21 Apr 2014 02:37:25 -0700 (PDT)
Received: from 114-174-17-190.fibertel.com.ar ([190.17.174.114] helo=[192.168.3.104]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1WcAew-0006oW-FS; Mon, 21 Apr 2014 11:37:06 +0200
Message-ID: <5354E694.5050209@si6networks.com>
Date: Mon, 21 Apr 2014 06:36:20 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>,  "opsec@ietf.org" <opsec@ietf.org>
References: <6B19BDB7-4DE2-4187-B5BA-07E4D48C03E1@cisco.com>
In-Reply-To: <6B19BDB7-4DE2-4187-B5BA-07E4D48C03E1@cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/fDsMr9C74WmrS-j-v3X9ZNkJNUg
Cc: "draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org" <draft-gont-opsec-ipv6-firewall-reqs@tools.ietf.org>
Subject: Re: [OPSEC] Thoughts on draft-gont-opsec-ipv6-firewall-reqs
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 09:37:32 -0000

Hi, Fred,

Thanks so much for your feedback! (and thanks for taking the time to
write down such a detailed review!) -- Please find (some of) my
comments in-line...


On 04/18/2014 08:38 PM, Fred Baker (fred) wrote:
> 
> First comment: I’d appreciate it if we had a framework for the 
> discussion of this, RFC 6092, 
> draft-hutton-rtcweb-nat-firewall-considerations, 
> draft-jab-host-firewalls, draft-ietf-v6ops-balanced-ipv6-security, 
> draft-vyncke-advanced-ipv6-security, and a long list of other
> drafts with the name “firewall” in them.

Could you elaborate what (specifically) you have in mind?



> Second comment: I think this draft is not about an IPv6 firewall,
> and as currently structured is likely to take approximately forever
> to discuss, and will then be wrong. Let me throw out a thought 
> experiment: consider REQ SPC-70. This is listed as an “IPv6”
> firewall feature, but it requires “stateful” association of ICMPv6
> replies to TCP, UDP, and ICMPv6 sessions - it doesn’t mention IPv6,
> and apart from the ICMPv6 part, would be substantively the same if
> we were to suddenly decide to deploy CATNIP or TUBA.

Not sure what you mean. Clearly, an IPv6 firewall does not deal only
with IPv6, but with whatever is on top of it 8at least the transport
layer). In this particular case, the intent is that, if you allow,
say, outgoing tcp segments destined to port 80, you should also allow
the corresponding (ICMPv6) control messages.


> Why are these not a separate document that such a deployment could
> refer to?

You mean e.g., a document that just focuses on the IPv6 packet
filtering details? -- If so, I can agree with you.


> I can build that product on an enterprise scale if you can afford
> it, but you’re talking about some serious state in the network, far
> beyond what firewalls do today.

FWIW, here we're assuming that you're doing stateful filtering -- so
the state is already there.



> I’m join to suggest that this be broken up into a number of 
> separately-discussable documents, each of which defines a test 
> target. If I build a product and claim that it firewalls IPv6,
> what are the requirements of that product? If I build a product
> (perhaps the same product) that claims to firewall TCP sessions,
> what are the requirements for that product?

I'd have no issues with that. I'd say that it makes perfect sense to
move "how to filter X protocol" into a different document.. although
I'm not sure if I'd do "one protocol per document" (me, I wouldn't
mind, but then there are folks that claim about multiple small
documents..)


>> 2.  Introduction
>> 
>> While the IETF has published a large number of documents 
>> discussing IP and IPv6 packet filtering (see e.g. [RFC7126] and 
>> some documents on the topic of IP firewalls (see e.g. [RFC2979]
>> and [RFC3511]), concrete requirements for IP firewalls have never
>> been specified in the RFC series.
> 
> Except in RFC 6092.

[fwiw, point noted]



[....]
> And at first blush, I’ll bet the requirements for an IPv6 firewall 
> are almost identical to those of an IPv4 firewall. Reason? The 
> attacks are the same, and the security policies are the same. If a 
> smurf can run on IPv4, it can run on IPv6. Amplification attacks, 
> spoofed source address issues, and so on and so forth, are likely
> to be identical, because in a certain sense IPv6 is IPv4 with
> bigger addresses, and the transports and applications use the two 
> interchangeably.

I agree that the functional requirements will be very similar to those
of IPv4. But the problem is that it is not unusual to find that there
is no such parity of features between the two protocols (given the
same device).


> The one place that the IETF would *like* security policy to differ
> is that a to of security practitioners bought, hook line and
> sinker, the circa-1995 marketing that a NAT was a security
> technology; it’s not, it’s an address multiplexing technology, and
> produces a certain kind of firewall-like capability as an
> accidental side-effect, but a lot of corporate security policies
> star with “you put your NAT here”, and then stop.

Agreed.



>> REQ GEN-10: All features of the firewall MUST be able to be 
>> individually configured (at least ON or OFF, with other 
>> configurable parameters as applicable).  A well-documented
>> default initial setting must be provided for each feature.
> 
>> REQ GEN-20: MUST support basic Access Control Lists (ACLs).
> 
> Define a “basic” access list?

Will do.



>> REQ GEN-30: MUST support stateless packet inspection and
>> filtering at transport layer.
> 
> The transport layer is not IPv6. This belongs in a 
> transport-layer-specific firewall specification, as it will be 
> portable to IPv4, IPv7, and IPv9 firewalls that use the same 
> transport.

Sort of. There's interaction between e.g. ICMPv6 and the transport
layer. -- for instance, if you require the fw to perform e.g. TCP
checksum validation, it won't be "IP-agnostic".

I'd also say that basic packet filtering capabilities imply the
ability to do this sort of stateful filtering.



>> REQ GEN-60: MUST be able to enforce timeouts on protocol
>> sessions based on the upper-layer protocol (e.g. enforce a
>> timeout on the FIN-WAIT state for TCP connections, a timeout for
>> DNS query/respose pair, etc.). In general, it MUST have different
>> timeout parameters and thresholds to be used to prevent idle
>> sessions from exhausting resources on the device and/or the
>> service that is defended.  For sessions composed of multiple
>> packets (such as TCP connections), the exchange of valid packets
>> MUST refresh the timers employed for enforcing the aforementioned
>> timeouts.
>> 
>> NOTE: This is to avoid the known and buggy behavior where
>> firewalls enforce a maximum lifetime for the protocol session
>> (e.g. TCP connection) regardless of whether there is ongoing
>> exchange of legitimate packets for such session.
> 
> This also forces certain behaviors, such as TCP keep-alives, to be 
> used, which means that host applications that don’t currently use 
> them to be changed before they can be used in the context of this 
> firewall.

Agreed.




>> REQ GEN-80: MUST be able to redirect specific traffic to a proxy 
>> server e.g. for HTTP/S protocols.
>> 
>> NOTE: "Redirection means that the firewall should be able to
>> divert the traffic to a proxy - i.e., take the traffic, send it
>> to an inspection engine, receive it back and forward it (all
>> this completely transparent to the users).
> 
> This can be complicated. if I am redirecting DNS to a local
> server, for example, I need the server to be able to accept a
> packet as “to it” regardless of its destination address, and
> respond as if it were that system. If it is http/https, I’d
> actually rather have this built into routing somehow - instead of
> all of the traffic going through the firewall to the proxy, and
> routing deliver it to the proxy in the first place.

FWIW, this req is based on a commonly supported firewall feature.




>> REQ GEN-90: MUST be able to detect and reject invalid source or 
>> destination addresses (e.g. local-link addresses that try to 
>> traverse the firewall) with a single policy.
> 
> Again, a general router requirement. Any router needs to be able
> to generate an ICMP Destination Unreachable for any of the seven
> valid codes if appropriate. That includes validating source address
> scope.

Agreed. Question: are you implying that we should remove this
requirement? Something else?



>> 5.  IPv6-Specific Features
>> 
>> REQ SPC-10: MUST be able to filter ICMPv6 [RFC4443] traffic at a 
>> message type/ code granularity.  [RFC4890] MUST be employed for
>> the default filtering configuration.
> 
> ICMPv6 is not IPv6. This belongs in an ICMPv6-specific firewall 
> specification. It’s OK to make a requirement of the IPv6 firewall 
> specification that it also implement the ICMPv6 specification.

I'm fine with, say, putting the filtering details in separate
documents. But I'd disagree that ICMPv6 is not IPv6. Or, well.. that
depends on what what means by "IPv6". If one means "IPv6 protocol
suite", then ICMPv6 is definitely a part of it (that's what we mean here).



>> REQ SPC-20: MUST be able to block packets containing any
>> specified extension header type (based on its Next Header value),
>> on a specified number of instances of a specified extension
>> header type, and on a specified overall number of IPv6 extension
>> headers.
>> 
>> REQ SPC-30: MUST be able to block IPv6 packets that employ a 
>> Routing Header both at the granularity of Extension Header Type
>> (as required in SPC-20) and Routing Header Type.
> 
> I’d actually generalize that. Any of the extension headers that
> can handle a sub-option (of which the Routing Header and
> Destination Header are examples) should be able to filter on the
> presence, absence, or content of the various sub-options.

Good point. Will do.



>> REQ SPC-40: SHOULD be able to drop packets based on IPv6 option 
>> types.
> 
> Is that the same as SPC-30?

No. Here we mean that you should be able to filter based on the
*options* (i.e., this is finer-grained than SPC-30).



>> REQ SPC-50: MUST be able to detect IPv6 tunnels such as SIIT 
>> [RFC6145], 6to4 [RFC3056], 6in4 [RFC4213], ISATAP [RFC5214] and 
>> Teredo [RFC4380] (please see [RFC7123], and MUST be able to 
>> selectively block or allow them for specific sources,
>> destinations, routes or interfaces.
> 
> Why is this not “must implement an ACL that can permit or deny 
> traffic based on any combination of source and destination
> prefixes or port numbers, or next header (e.g. protocol) values”?

Would do. Maybe it would be valuable to avoid requiring the admin to
craft the aforementioned rules from cratch?



>> REQ SPC-60: MUST be able to validate IPv6 Neighbor Discovery 
>> [RFC4861] packets (RS, RA, NS, NA, Redirect) according to 
>> [I-D.ietf-opsec-ipv6-nd-security].
> 
> Why is this not a requirement of any IPv6 node? What makes it 
> specific to a firewall?

It's certainly not... But some validation checks are not (yet)
required for all nodes, and [I-D.ietf-opsec-ipv6-nd-security] will not
formally achieve this, since it's on the Informational track....



>> REQ SPC-70: MUST be able to statefully match ICMPv6 errors to
>> TCP [RFC0793], UDP [RFC0768], and ICMPv6 [RFC4443] communication 
>> instances (see [RFC5927]).
> 
> So, it not only keeps source/destination pair state, as a NA(P)T 
> might, but tracks send and acknowledge sequence numbers, last
> message sent (SYN vs data vs ack vs FIN/RST), and where the
> conversation is in its state machine. This precludes loa-sharing
> among firewalls, as the most recent message will by definition have
> passed one and not both.

Note: here we're requiring the ability of doing so... not the
enforcement of the policy.



>> REQ SPC-80: MUST be able to parse all defined extension headers 
>> according to [RFC7045], and SHOULD filter packets containing
>> IPv6 Extension Headers as recommended in 
>> [draft-gont-opsec-ipv6-eh-filtering].
> 
> How does this differ from SPC-20?

I agree this one wasn't clear. But here's the intent: SPC-20 requires
that the device has the capability to filter EHs on a per-type
granularity, etc. SPC-80 is meant to provide a default ruleset via
[draft-gont-opsec-ipv6-eh-filtering].

(yes, this is not clear... and the reference to RFC7045 is probably
superflous).



>> REQ SPC-90: MUST be able to find the upper-layer protocol in an 
>> IPv6 header chain (see [RFC7112].
> 
> How does this differ from SPC-80?

SPC-80 specifies default filtering rules based on EHs. SPC-90 requires
the fw to be able to process the entire IPv6 header chain (such that
e.g. the fw cannot be bypassed via inclusion of IPv6 EHs and the like).



>> REQ SPC-100: SHOULD be able to normalize (rewrite) the following 
>> IPv6 header fields on a per-interface basis:
>> 
>> *  Hop Limit
> 
> DANGER! DANGER WILL ROBINSON! Do you *really* want to do that?

As with many of the previous ones, here we're specifying feature,
rather than enforcement of a policy. (the device must be able to do
that... but that doesn't mean that e.g. the feature must be enabled by
default).

That said, normalizing the Hop Limit to something like, say, 64, will
prevent external nodes from discovering your network topology (yes,
you can also filter the corresponding ICMPv6 errors), and, most
importantly, will prevent an attacker from evading a NIDS by playing
with the Hop Limit field (such that the sensor sees the packet, but
the target doesn't).



>> 7.  Denial of Service (DoS) Protection
>> 
>> REQ DoS-10: MUST be able to protect against
>> implementation-specific attacks, including:
>> 
>> *  Winnuke [Myst1997]
>> 
>> *  ping-of-death [Kenney1996]
>> 
>> *  Smurf [CERT1998a]
>> 
>> *  LAND Attack [Meltman1997]
>> 
>> *  Teardrop Attack [CERT1997] [Junos-Teardrop]
> 
> So, just checking on the implications here. Nobody has thought of
> a new DDOS attack since 1998?

FWIW, these are not really DDOS, but rather common implementation
errors. The references are certainly about the IPv4 incarnation of
these vulnerabilities.. but some of them have reincarnated in IPv6
implementations. See e.g.:

*
<http://gcn.com/blogs/cybereye/2013/08/microsoft-patch-ping-of-death-ipv6.aspx>

* <http://tools.ietf.org/id/draft-gont-6man-ipv6-smurf-amplifier-01.txt>




>> REQ DoS-50: MUST be able to detect and drop malformed IPv6
>> packets (incorrect header/option lengths, etc.).
> 
> Hey! This is great! This IPv6 firewall actually does something
> with IPv6!
> 
> Is a side-effect of this that we can’t deploy a new feature like
> we had with ECN?

Why should it be? ECN had trouble being deployed because fw's were
dropping packets that had a *Reserved* bit set. Here we're talking
about *malformed* packet -- a packet with a reserved bit set does not
qualify as such.




>> REQ DoS-70: MUST be able to provide bandwidth management (QoS or 
>> anti- flooding) policies customizable for specific source and 
>> destination networks, or by VLAN or MPLS ID.
> 
> Hmm. That kind of thing is usually found in higher-end equipment.
> Are you saying that a residential firewall that one purchases for
> peanuts needs to do this? Do you have a market requirement?

We're certainly not talking about "residential firewalls" here. That
said, the idea is that if you have a residential firewall that somehow
wanted to "comply" with this document, you could simply state that it
e.g. "does not comply with the 'requirements for dos mitigation' in
this document", or e.g., that "it is conditionally compliant to the
'requirements for DoS mitigation' in this document".



>> REQ DoS-80: MUST be able to participate to a blackhole/synkhole 
>> routing infrastructure as per [RFC5635].
> 
> This is a general router requirement.

do you mean "a formal router requirement" (as say, per RFC1812)?

P.S.: More responses in the pipeline...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Apr 24 03:11:27 2014
Return-Path: <internet-drafts@ietf.org>
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 674371A0176; Thu, 24 Apr 2014 03:11:18 -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 EdPk3BaqyJCM; Thu, 24 Apr 2014 03:11:16 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E4D1A004E; Thu, 24 Apr 2014 03:11:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140424101116.24868.94568.idtracker@ietfa.amsl.com>
Date: Thu, 24 Apr 2014 03:11:16 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/iswxzmBlDO6IIqoAZEOdjaaQRa8
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 10:11:18 -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           : Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks
        Author          : Fernando Gont
	Filename        : draft-ietf-opsec-vpn-leakages-05.txt
	Pages           : 10
	Date            : 2014-04-24

Abstract:
   The subtle way in which the IPv6 and IPv4 protocols co-exist in
   typical networks, together with the lack of proper IPv6 support in
   popular Virtual Private Network (VPN) tunnel products, may
   inadvertently result in VPN tunnel traffic leaks.  That is, traffic
   meant to be transferred over an encrypted and integrity protected VPN
   tunnel may leak out of such tunnel and be sent in the clear on the
   local network towards the final destination.  This document discusses
   some scenarios in which such VPN tunnel traffic leakages may occur as
   a result of employing IPv6-unaware VPN software.  Additionally, this
   document offers possible mitigations for this issue.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-vpn-leakages-05


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 Thu Apr 24 08:07:38 2014
Return-Path: <gvandeve@cisco.com>
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 4F2101A0318 for <opsec@ietfa.amsl.com>; Thu, 24 Apr 2014 08:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.772
X-Spam-Level: 
X-Spam-Status: No, score=-14.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 MSxRBHzoDNoA for <opsec@ietfa.amsl.com>; Thu, 24 Apr 2014 08:07:32 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4A1A036F for <opsec@ietf.org>; Thu, 24 Apr 2014 08:07:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9202; q=dns/txt; s=iport; t=1398352043; x=1399561643; h=from:to:cc:subject:date:message-id:mime-version; bh=0SBdUBRrvp7tv21qC4HVQXNlZ4ArPR5eAvJW8S7TNE8=; b=JFFEN8Zo3YlCALd6cE84Qp+6tUS9fYfaw/8lc8qH4AQjcY6ZBkxDkcpA SGwctxRZqkDd2YfEkKq2UoPClf1Ok1ErWkyJUu3jEPRo0PLT3mfGibzdu mFRC9ycB1Ej94p7tS8sNgEBvS2qoy3Zquuwu2mnOeyjLbKRN5UHkw6JUk c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAOInWVOtJA2K/2dsb2JhbABZgkJET1fENoEaFnSCJQEBAQQdEEELEgEIEQQBAQtWHQkBBA4FCIg5DctHEwSOJy0EgyuBFQSrS4Mxgis
X-IronPort-AV: E=Sophos;i="4.97,919,1389744000";  d="scan'208,217";a="320150023"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 24 Apr 2014 15:07:22 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3OF7MIJ028291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 15:07:22 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 10:07:22 -0500
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: opsec wg mailing list <opsec@ietf.org>
Thread-Topic: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
Thread-Index: Ac9TCpCty6WW3UV9Rc+t1rBkEBAqQQMxA9Mw
Date: Thu, 24 Apr 2014 15:07:21 +0000
Message-ID: <67832B1175062E48926BF3CB27C49B24113A0049@xmb-aln-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.70.103]
Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B24113A0049xmbalnx12ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/P27ii7qg15azYZyRtuhvPBvJsjg
Cc: "draft-ietf-opsec-bgp-security@tools.ietf.org" <draft-ietf-opsec-bgp-security@tools.ietf.org>, "KK \(kk@google.com\)" <kk@google.com>
Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 15:07:34 -0000

--_000_67832B1175062E48926BF3CB27C49B24113A0049xmbalnx12ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

The WGLC is ended.
Authors, please adjust the Draft according to the outcome of WG discussions=
, so that the next step can be progressed towards.

All the best,
G/

From: Gunter Van de Velde (gvandeve)
Sent: 08 April 2014 11:18
To: opsec wg mailing list
Cc: KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org
Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security


Dear OpSec WG,


This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security=
.

Due to the time taken to integrate all comments from the first WGLC this 2n=
d WGLC is initiated.



All three authors have replied, stating that they do not know of any IPR as=
sociated with this draft.


The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op=
sec-bgp-security/<https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-onl=
y/>


Please review this draft to see if you think it is ready for publication an=
d comments to the list, clearly stating your view.


This WGLC ends 22-April-2014.


Thanks,

G/


--_000_67832B1175062E48926BF3CB27C49B24113A0049xmbalnx12ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Dear all,<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">The WGLC is ended.<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Authors, please adjust=
 the Draft according to the outcome of WG discussions, so that the next ste=
p can be progressed towards.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">All the best,<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">G/<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-language:EN=
-GB">From:</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-fa=
mily:&quot;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-language:EN-GB">=
 Gunter
 Van de Velde (gvandeve) <br>
<b>Sent:</b> 08 April 2014 11:18<br>
<b>To:</b> opsec wg mailing list<br>
<b>Cc:</b> KK (kk@google.com); draft-ietf-opsec-bgp-security@tools.ietf.org=
<br>
<b>Subject:</b> Start of 2nd WGLC for draft-ietf-opsec-bgp-security<o:p></o=
:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Dear O=
pSec WG,</span><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot=
;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span style=3D"font-s=
ize:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:=
p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">This s=
tarts a 2<sup>nd</sup> Working Group Last Call for draft-ietf-opsec-bgp-sec=
urity.<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Due to=
 the time taken to integrate all comments from the first WGLC this 2<sup>nd=
</sup> WGLC is initiated.<o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black"><o:p>&=
nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">All th=
ree authors have replied, stating that they do not know of any IPR associat=
ed with this draft.</span><span style=3D"font-size:13.5pt;font-family:&quot=
;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">The dr=
aft is available here:</span><span style=3D"font-size:13.5pt;font-family:&q=
uot;Times&quot;,&quot;serif&quot;;color:black"><a href=3D"https://datatrack=
er.ietf.org/doc/draft-ietf-opsec-lla-only/"><span style=3D"font-family:&quo=
t;Arial&quot;,&quot;sans-serif&quot;;color:black">
 https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/</span></a>=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:13.5pt;font-family:&quot;Ti=
mes&quot;,&quot;serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Please=
 review this draft to see if you think it is ready for publication and comm=
ents to the list, clearly stating your view.</span><span style=3D"font-size=
:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:p><=
/o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span style=3D"font-s=
ize:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:=
p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">This W=
GLC ends 22-April-2014.</span><span style=3D"font-size:13.5pt;font-family:&=
quot;Times&quot;,&quot;serif&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:13.5pt"><span style=3D"font-s=
ize:13.5pt;font-family:&quot;Times&quot;,&quot;serif&quot;;color:black"><o:=
p>&nbsp;</o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">Thanks=
,</span><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot=
;serif&quot;;color:black"><o:p></o:p></span></p>
<p style=3D"margin:0cm;margin-bottom:.0001pt"><span style=3D"font-size:13.5=
pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:black">G/</sp=
an><span style=3D"font-size:13.5pt;font-family:&quot;Times&quot;,&quot;seri=
f&quot;;color:black"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_67832B1175062E48926BF3CB27C49B24113A0049xmbalnx12ciscoc_--


From nobody Thu Apr 24 09:14:57 2014
Return-Path: <internet-drafts@ietf.org>
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 83D4B1A020F; Thu, 24 Apr 2014 09:14:52 -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 vVACFi3BvuZS; Thu, 24 Apr 2014 09:14:51 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 226171A035C; Thu, 24 Apr 2014 09:14:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140424161451.2555.74589.idtracker@ietfa.amsl.com>
Date: Thu, 24 Apr 2014 09:14:51 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/vb4umLZowxs8X-WGxVOfevQu7oU
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-06.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Apr 2014 16:14:52 -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           : Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- stack hosts/networks
        Author          : Fernando Gont
	Filename        : draft-ietf-opsec-vpn-leakages-06.txt
	Pages           : 10
	Date            : 2014-04-24

Abstract:
   The subtle way in which the IPv6 and IPv4 protocols co-exist in
   typical networks, together with the lack of proper IPv6 support in
   popular Virtual Private Network (VPN) tunnel products, may
   inadvertently result in VPN tunnel traffic leaks.  That is, traffic
   meant to be transferred over an encrypted and integrity protected VPN
   tunnel may leak out of such tunnel and be sent in the clear on the
   local network towards the final destination.  This document discusses
   some scenarios in which such VPN tunnel traffic leakages may occur as
   a result of employing IPv6-unaware VPN software.  Additionally, this
   document offers possible mitigations for this issue.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-vpn-leakages-06


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 Apr 26 09:44:47 2014
Return-Path: <cpignata@cisco.com>
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 730731A0503 for <opsec@ietfa.amsl.com>; Sat, 26 Apr 2014 09:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.773
X-Spam-Level: 
X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 KEnGkVJ2BqiB for <opsec@ietfa.amsl.com>; Sat, 26 Apr 2014 09:44:41 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B61A04F6 for <opsec@ietf.org>; Sat, 26 Apr 2014 09:44:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3324; q=dns/txt; s=iport; t=1398530675; x=1399740275; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PsemSNf+edl07GeOiJkwBE4WUmVeblOSA1Wp8WuWnGE=; b=izn6RzDBMNKqxQ9+29lBcR7DGguoJSl/2crDRRWkLcejY4zdThUzOd2c zaeN6So5wHU2My9WIgOi1JEsYCbkwkJIfg8Wo0jBE9YyuXsm9YXtrf7b4 Gwi9AuTlegBYYVd60d9+Nmy523y3p4SKD4PyqAjn94qdMV0PkNLDwiYd1 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqQHAB7iW1OtJA2L/2dsb2JhbABZgwZPUQa9Ioc5gQsWdIIlAQEBAwEBAQE3NBALAgEINhAnCyUCBAoJCYgwCAgFyWwXjiY6gySBFQSZDIE6kSSDMYIr
X-IronPort-AV: E=Sophos;i="4.97,934,1389744000"; d="scan'208";a="320620598"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 26 Apr 2014 16:44:34 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3QGiYbl003001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <opsec@ietf.org>; Sat, 26 Apr 2014 16:44:34 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 11:44:34 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "<opsec@ietf.org>" <opsec@ietf.org>
Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt
Thread-Index: AQHPX6WdkquvJDRI4kGUbD3bsO26+JskciEA
Date: Sat, 26 Apr 2014 16:44:33 +0000
Message-ID: <67CDA47B-7A57-42AE-A333-6A6FA51212B8@cisco.com>
References: <20140424101116.24868.94568.idtracker@ietfa.amsl.com>
In-Reply-To: <20140424101116.24868.94568.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.234.204]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FE4B8BE5863C754FA70D88E288F95E02@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/FY6bPQLAPTBhDLmS2-OmsVI-ec4
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Apr 2014 16:44:43 -0000

Hi,

I do not think that "L3 VPN" appropriately qualifies the type of "VPN Leaka=
ges" described in this document. It seems to me that "split tunnel AF bug" =
describes it better. One definition of "L3VPN" is at https://tools.ietf.org=
/html/rfc4031#section-3.1

It would also be interesting to ask the L3VPN WG about it.

Please find a couple more comments inline on the Abstract.

On Apr 24, 2014, at 6:11 AM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Operational Security Capabilities for IP=
 Network Infrastructure Working Group of the IETF.
>=20
>        Title           : Layer-3 Virtual Private Network (VPN) tunnel tra=
ffic leakages in dual- stack hosts/networks
>        Author          : Fernando Gont
> 	Filename        : draft-ietf-opsec-vpn-leakages-05.txt
> 	Pages           : 10
> 	Date            : 2014-04-24
>=20
> Abstract:
>   The subtle way in which the IPv6 and IPv4 protocols co-exist in
>   typical networks, together with the lack of proper IPv6 support in
>   popular Virtual Private Network (VPN) tunnel products, may

I believe that "lack of proper IPv6 support in popular VPN tunnel products"=
 needs to be either substantiated or dropped. Also, it's not clear to me wh=
at is "proper support" versus (perhaps) "improper support".

>   inadvertently result in VPN tunnel traffic leaks.  That is, traffic
>   meant to be transferred over an encrypted and integrity protected VPN
>   tunnel

The title says "L3VPN Tunnels", but in general L3VPN Tunnels do not imply e=
ncryption. IP-in-IP, GRE, and L2TPv3 can create L3VPN tunnels without encry=
ption or integrity protection.

> may leak out of such tunnel and be sent in the clear on the
>   local network towards the final destination.  This document discusses
>   some scenarios in which such VPN tunnel traffic leakages may occur as
>   a result of employing IPv6-unaware VPN software.

This paragraph seems closer to describing the actual problem: "IPv6 unaware=
 tunnel encapsulation" -- it seems to me that this is not a "VPN" problem.

Lastly, please note that there are instances where the demultiplexing of IP=
v6 from IPv4 before tunnel encapsulation is a deliberate action: http://www=
.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/l2tpv29s.html#wp1276833

Thanks,

Carlos.

>  Additionally, this
>   document offers possible mitigations for this issue.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-05
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-vpn-leakages-05
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec


From nobody Sat Apr 26 09:51:33 2014
Return-Path: <joelja@bogus.com>
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 C4E2D1A0639 for <opsec@ietfa.amsl.com>; Sat, 26 Apr 2014 09:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 MjrmQFA0pHJn for <opsec@ietfa.amsl.com>; Sat, 26 Apr 2014 09:51:30 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 03C6C1A04F6 for <opsec@ietf.org>; Sat, 26 Apr 2014 09:51:29 -0700 (PDT)
Received: from mb-aye.lan (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s3QGpF8B003116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 26 Apr 2014 16:51:16 GMT (envelope-from joelja@bogus.com)
Message-ID: <535BE403.2000506@bogus.com>
Date: Sat, 26 Apr 2014 09:51:15 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0
MIME-Version: 1.0
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "<opsec@ietf.org>" <opsec@ietf.org>
References: <20140424101116.24868.94568.idtracker@ietfa.amsl.com> <67CDA47B-7A57-42AE-A333-6A6FA51212B8@cisco.com>
In-Reply-To: <67CDA47B-7A57-42AE-A333-6A6FA51212B8@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RwIk4W0LAUKEps01RnGAiwq8aHq6x9phP"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sat, 26 Apr 2014 16:51:16 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/aI_qZgdBDuskLjyNjHkSrW7ZieE
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Apr 2014 16:51:32 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RwIk4W0LAUKEps01RnGAiwq8aHq6x9phP
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 4/26/14, 9:44 AM, Carlos Pignataro (cpignata) wrote:
> Hi,
>=20
> I do not think that "L3 VPN" appropriately qualifies the type of "VPN L=
eakages" described in this document. It seems to me that "split tunnel AF=
 bug" describes it better. One definition of "L3VPN" is at https://tools.=
ietf.org/html/rfc4031#section-3.1
>=20
> It would also be interesting to ask the L3VPN WG about it.
>=20
> Please find a couple more comments inline on the Abstract.
>=20
> On Apr 24, 2014, at 6:11 AM, internet-drafts@ietf.org wrote:
>=20
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
>> This draft is a work item of the Operational Security Capabilities for=
 IP Network Infrastructure Working Group of the IETF.
>>
>>        Title           : Layer-3 Virtual Private Network (VPN) tunnel =
traffic leakages in dual- stack hosts/networks
>>        Author          : Fernando Gont
>> 	Filename        : draft-ietf-opsec-vpn-leakages-05.txt
>> 	Pages           : 10
>> 	Date            : 2014-04-24
>>
>> Abstract:
>>   The subtle way in which the IPv6 and IPv4 protocols co-exist in
>>   typical networks, together with the lack of proper IPv6 support in
>>   popular Virtual Private Network (VPN) tunnel products, may
>=20
> I believe that "lack of proper IPv6 support in popular VPN tunnel produ=
cts" needs to be either substantiated or dropped. Also, it's not clear to=
 me what is "proper support" versus (perhaps) "improper support".

I disagree and i think the comments from present and past implementers
(myself included) corroborate this assertion. naming specific products
doesn't actually serve a useful purpose.

>>   inadvertently result in VPN tunnel traffic leaks.  That is, traffic
>>   meant to be transferred over an encrypted and integrity protected VP=
N
>>   tunnel
>=20
> The title says "L3VPN Tunnels", but in general L3VPN Tunnels do not imp=
ly encryption. IP-in-IP, GRE, and L2TPv3 can create L3VPN tunnels without=
 encryption or integrity protection.
>=20
>> may leak out of such tunnel and be sent in the clear on the
>>   local network towards the final destination.  This document discusse=
s
>>   some scenarios in which such VPN tunnel traffic leakages may occur a=
s
>>   a result of employing IPv6-unaware VPN software.
>=20
> This paragraph seems closer to describing the actual problem: "IPv6 una=
ware tunnel encapsulation" -- it seems to me that this is not a "VPN" pro=
blem.
>=20
> Lastly, please note that there are instances where the demultiplexing o=
f IPv6 from IPv4 before tunnel encapsulation is a deliberate action: http=
://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/l2tpv29s.html#wp=
1276833
>=20
> Thanks,
>=20
> Carlos.
>=20
>>  Additionally, this
>>   document offers possible mitigations for this issue.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-05
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-vpn-leakages-05
>>
>>
>> Please note that it may take a couple of minutes from the time of subm=
ission
>> 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/
>>
>> _______________________________________________
>> OPSEC mailing list
>> OPSEC@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsec
>=20
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>=20



--RwIk4W0LAUKEps01RnGAiwq8aHq6x9phP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNb5AMACgkQ8AA1q7Z/VrKwvgCeOa7rWPHPI8AC7Zr5tVNJijLe
qugAn2ddwKAq+Ype74daAg2Cc/l3mzfu
=nG6k
-----END PGP SIGNATURE-----

--RwIk4W0LAUKEps01RnGAiwq8aHq6x9phP--


From nobody Sat Apr 26 09:59:46 2014
Return-Path: <cpignata@cisco.com>
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 B2F2B1A0639 for <opsec@ietfa.amsl.com>; Sat, 26 Apr 2014 09:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.772
X-Spam-Level: 
X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 nDhKbgxJ8JfK for <opsec@ietfa.amsl.com>; Sat, 26 Apr 2014 09:59:41 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id F198B1A064C for <opsec@ietf.org>; Sat, 26 Apr 2014 09:59:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6444; q=dns/txt; s=iport; t=1398531574; x=1399741174; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r/UWFjJxgJ58jR8VyImkcadVzTmGObx6t1uvAa+Sxa8=; b=RCn0uxApmab6PqMUzdzUtuBPzzcLoZW8xcAbYJT4bw9o/k8NrpR9l9EI s4/DvsJ4jwiy4bO/KDjYtDoIUeELOKLe+g7U4DK57+COMPvv1w6ziKHwG Y7WSLsDl2jDjac8lMCOqHeE+ijevXueSNLZ4ekMDVq7S/37j5DzAggUXK I=;
X-Files: signature.asc : 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIFAFzlW1OtJA2J/2dsb2JhbABYgkJEgSbEW4ELFnSCJQEBAQMBeRACAQhGMiUCBA4FDogrCMlwF45ZB4MkgRUEkQGBOIZTkl6DMYIr
X-IronPort-AV: E=Sophos;i="4.97,934,1389744000";  d="asc'?scan'208,217";a="39018435"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 26 Apr 2014 16:59:33 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3QGxXXF005333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Apr 2014 16:59:33 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 11:59:32 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Joel Jaeggli <joelja@bogus.com>
Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt
Thread-Index: AQHPX6WdkquvJDRI4kGUbD3bsO26+JskciEAgAAB3oCAAAJRAA==
Date: Sat, 26 Apr 2014 16:59:32 +0000
Message-ID: <C567EA20-FF89-4B6A-99B6-F9EBD58135E1@cisco.com>
References: <20140424101116.24868.94568.idtracker@ietfa.amsl.com> <67CDA47B-7A57-42AE-A333-6A6FA51212B8@cisco.com> <535BE403.2000506@bogus.com>
In-Reply-To: <535BE403.2000506@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.234.204]
Content-Type: multipart/signed; boundary="Apple-Mail=_B39FB03E-4282-45AB-B05D-58C8250FF71D"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6KkMJn0Ru-YxhyMLSYbbYbk0J0g
Cc: "<opsec@ietf.org>" <opsec@ietf.org>
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-05.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Apr 2014 16:59:43 -0000

--Apple-Mail=_B39FB03E-4282-45AB-B05D-58C8250FF71D
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D098A960-4621-4AD0-BDD9-058FCB7FD512"


--Apple-Mail=_D098A960-4621-4AD0-BDD9-058FCB7FD512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Apr 26, 2014, at 12:51 PM, joel jaeggli <joelja@bogus.com> wrote:

>> I believe that "lack of proper IPv6 support in popular VPN tunnel =
products" needs to be either substantiated or dropped. Also, it's not =
clear to me what is "proper support" versus (perhaps) "improper =
support".
>=20
> I disagree and i think the comments from present and past implementers
> (myself included) corroborate this assertion. naming specific products
> doesn't actually serve a useful purpose.

My point is that the comments on broken implementations relate to a =
subset of the universe of "VPN Products". My understanding is that these =
relate to software-based "VPN client endpoints" (happy to be corrected =
otherwise) but *not* to the many other types of "VPN products".

I agree that naming specific products is not helpful at all. That was =
not my suggestion. But, implying that this problem exists generally in =
"VPN products" does not help either. Are you aware of this bug present =
in *any* RFC 4364 L3VPN?

I still think that the title and abstract are overly-scoped, and more =
precision in definition will help the document.

Thanks,

Carlos.

--Apple-Mail=_D098A960-4621-4AD0-BDD9-058FCB7FD512
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Apr 26, 2014, at 12:51 PM, joel =
jaeggli &lt;<a href=3D"mailto:joelja@bogus.com">joelja@bogus.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><blockquote type=3D"cite" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;">I believe that "lack of proper IPv6 support in popular VPN tunnel =
products" needs to be either substantiated or dropped. Also, it's not =
clear to me what is "proper support" versus (perhaps) "improper =
support".<br></blockquote><br style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: =
none; display: inline !important;">I disagree and i think the comments =
from present and past implementers</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><span style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;">(myself included) corroborate =
this assertion. naming specific products</span><br style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><span style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;">doesn't actually serve a =
useful purpose.</span></blockquote></div><br><div>My point is that the =
comments on broken implementations relate to a subset of the universe of =
"VPN Products". My understanding is that these relate to software-based =
"VPN client endpoints" (happy to be corrected otherwise) but *not* to =
the many other types of "VPN products".</div><div><br></div><div>I agree =
that naming specific products is not helpful at all. That was not my =
suggestion. But, implying that this problem exists generally in "VPN =
products" does not help either. Are you aware of this bug present in =
*any*&nbsp;RFC 4364 L3VPN?</div><div><br></div><div>I still think that =
the title and abstract are overly-scoped, and more precision in =
definition will help the =
document.</div><div><br></div><div>Thanks,</div><div><br></div><div>Carlos=
.</div></body></html>=

--Apple-Mail=_D098A960-4621-4AD0-BDD9-058FCB7FD512--

--Apple-Mail=_B39FB03E-4282-45AB-B05D-58C8250FF71D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlNb5fMACgkQtfDPGTp3USyv5gCgvsosZyl1T1LGC8oAB0b+CxLM
1VQAnj87OOBMqkqW7AEhnclSbnpeEVur
=kTuD
-----END PGP SIGNATURE-----

--Apple-Mail=_B39FB03E-4282-45AB-B05D-58C8250FF71D--


From nobody Sun Apr 27 13:30:46 2014
Return-Path: <internet-drafts@ietf.org>
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 B82C71A06AD; Sun, 27 Apr 2014 13:30:44 -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 B3lZQpxUCZVn; Sun, 27 Apr 2014 13:30:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DBE1A066A; Sun, 27 Apr 2014 13:30:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140427203042.20840.34608.idtracker@ietfa.amsl.com>
Date: Sun, 27 Apr 2014 13:30:42 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/d9vqiF-wVdwg9gzeLY7tRBM27xI
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-03.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Apr 2014 20:30:44 -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           : BGP operations and security
        Authors         : Jerome Durand
                          Ivan Pepelnjak
                          Gert Doering
	Filename        : draft-ietf-opsec-bgp-security-03.txt
	Pages           : 29
	Date            : 2014-04-27

Abstract:
   BGP (Border Gateway Protocol) is the protocol almost exclusively used
   in the Internet to exchange routing information between network
   domains.  Due to this central nature, it is important to understand
   the security measures that can and should be deployed to prevent
   accidental or intentional routing disturbances.

   This document describes measures to protect the BGP sessions itself
   (like TTL, TCP-AO, control plane filtering) and to better control the
   flow of routing information, using prefix filtering and
   automatization of prefix filters, max-prefix filtering, AS path
   filtering, route flap dampening and BGP community scrubbing.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-bgp-security-03


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 Mon Apr 28 08:43:43 2014
Return-Path: <wesley.george@twcable.com>
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 12E2C1A04C5 for <opsec@ietfa.amsl.com>; Mon, 28 Apr 2014 08:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.416
X-Spam-Level: 
X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, 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 wzQBQMnJGLbl for <opsec@ietfa.amsl.com>; Mon, 28 Apr 2014 08:43:38 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E13E1A048C for <opsec@ietf.org>; Mon, 28 Apr 2014 08:43:38 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.97,945,1389762000"; d="scan'208";a="281730897"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Apr 2014 11:43:22 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 28 Apr 2014 11:43:36 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "opsec@ietf.org" <opsec@ietf.org>
Date: Mon, 28 Apr 2014 11:43:35 -0400
Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-03.txt
Thread-Index: Ac9i+J289RFmlFR+TWORBv6MImdt8w==
Message-ID: <CF83EF3A.19C19%wesley.george@twcable.com>
References: <20140427203042.20840.34608.idtracker@ietfa.amsl.com>
In-Reply-To: <20140427203042.20840.34608.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/tR-CpZl4diSHQyPkfwNuj74_89s
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-03.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Apr 2014 15:43:40 -0000

VGhpcyBuZXcgdmVyc2lvbiBhZGRyZXNzZXMgbXkgY29tbWVudHMuIFRoYW5rcyB0byB0aGUgYXV0
aG9ycyBmb3IgdGhlaXINCndvcmsgb24gdGhpcyBkb2N1bWVudCwgaXQgd2lsbCBiZSB2ZXJ5IHVz
ZWZ1bC4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQoNCg0KT24gNC8yNy8xNCwgNDozMCBQTSwgImlu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3Rl
Og0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp
bmUgSW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3Jr
IGl0ZW0gb2YgdGhlIE9wZXJhdGlvbmFsIFNlY3VyaXR5IENhcGFiaWxpdGllcyBmb3INCj5JUCBO
ZXR3b3JrIEluZnJhc3RydWN0dXJlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAg
ICAgICBUaXRsZSAgICAgICAgICAgOiBCR1Agb3BlcmF0aW9ucyBhbmQgc2VjdXJpdHkNCj4gICAg
ICAgIEF1dGhvcnMgICAgICAgICA6IEplcm9tZSBEdXJhbmQNCj4gICAgICAgICAgICAgICAgICAg
ICAgICAgIEl2YW4gUGVwZWxuamFrDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBHZXJ0IERv
ZXJpbmcNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1vcHNlYy1iZ3Atc2Vj
dXJpdHktMDMudHh0DQo+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDI5DQo+ICAgICAgIERhdGUg
ICAgICAgICAgICA6IDIwMTQtMDQtMjcNCj4NCj5BYnN0cmFjdDoNCj4gICBCR1AgKEJvcmRlciBH
YXRld2F5IFByb3RvY29sKSBpcyB0aGUgcHJvdG9jb2wgYWxtb3N0IGV4Y2x1c2l2ZWx5IHVzZWQN
Cj4gICBpbiB0aGUgSW50ZXJuZXQgdG8gZXhjaGFuZ2Ugcm91dGluZyBpbmZvcm1hdGlvbiBiZXR3
ZWVuIG5ldHdvcmsNCj4gICBkb21haW5zLiAgRHVlIHRvIHRoaXMgY2VudHJhbCBuYXR1cmUsIGl0
IGlzIGltcG9ydGFudCB0byB1bmRlcnN0YW5kDQo+ICAgdGhlIHNlY3VyaXR5IG1lYXN1cmVzIHRo
YXQgY2FuIGFuZCBzaG91bGQgYmUgZGVwbG95ZWQgdG8gcHJldmVudA0KPiAgIGFjY2lkZW50YWwg
b3IgaW50ZW50aW9uYWwgcm91dGluZyBkaXN0dXJiYW5jZXMuDQo+DQo+ICAgVGhpcyBkb2N1bWVu
dCBkZXNjcmliZXMgbWVhc3VyZXMgdG8gcHJvdGVjdCB0aGUgQkdQIHNlc3Npb25zIGl0c2VsZg0K
PiAgIChsaWtlIFRUTCwgVENQLUFPLCBjb250cm9sIHBsYW5lIGZpbHRlcmluZykgYW5kIHRvIGJl
dHRlciBjb250cm9sIHRoZQ0KPiAgIGZsb3cgb2Ygcm91dGluZyBpbmZvcm1hdGlvbiwgdXNpbmcg
cHJlZml4IGZpbHRlcmluZyBhbmQNCj4gICBhdXRvbWF0aXphdGlvbiBvZiBwcmVmaXggZmlsdGVy
cywgbWF4LXByZWZpeCBmaWx0ZXJpbmcsIEFTIHBhdGgNCj4gICBmaWx0ZXJpbmcsIHJvdXRlIGZs
YXAgZGFtcGVuaW5nIGFuZCBCR1AgY29tbXVuaXR5IHNjcnViYmluZy4NCj4NCj4NCj4NCj5UaGUg
SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2VjLWJncC1zZWN1cml0eS8N
Cj4NCj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj5odHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2VjLWJncC1zZWN1cml0eS0wMw0K
Pg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5o
dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2VjLWJncC1zZWN1
cml0eS0wMw0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg
bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXpl
ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+
SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K
PmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5PUFNFQyBtYWlsaW5nIGxpc3QNCj5P
UFNFQ0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3Bz
ZWMNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp
biBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJp
dmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcg
dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3Ig
dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz
c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls
LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmli
dXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVu
dHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0
ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwg
aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFu
ZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5k
IGFueSBwcmludG91dC4NCg==