From ietf@meetecho.com Thu Aug 1 02:06:41 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4159A21F8FB4 for ; Thu, 1 Aug 2013 02:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.547 X-Spam-Level: * X-Spam-Status: No, score=1.547 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkbsTcflAQf5 for ; Thu, 1 Aug 2013 02:06:34 -0700 (PDT) Received: from smtpdg6.aruba.it (smtpdg224.aruba.it [62.149.158.224]) by ietfa.amsl.com (Postfix) with ESMTP id 0793121F8438 for ; Thu, 1 Aug 2013 02:06:24 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6H1m0250EaGCq01M6JVe; Thu, 01 Aug 2013 11:06:19 +0200 Date: Thu, 1 Aug 2013 11:06:15 +0200 (CEST) From: Meetecho Team To: opsec@ietf.org Message-ID: <623601087.1.1375347975906.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_624254713.1375347975874" Subject: [OPSEC] OPSEC session recording available X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:06:41 -0000 ------=_Part_0_624254713.1375347975874 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the OPSEC WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#OPSEC For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_624254713.1375347975874-- From liushucheng@huawei.com Sat Aug 10 19:58:29 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602921F9E31 for ; Sat, 10 Aug 2013 19:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzo9FvHIMVni for ; Sat, 10 Aug 2013 19:58:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75E4711E8107 for ; Sat, 10 Aug 2013 19:52:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVX31758; Sun, 11 Aug 2013 02:51:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 11 Aug 2013 03:51:53 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 11 Aug 2013 03:51:53 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.24]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Sun, 11 Aug 2013 10:51:50 +0800 From: "Will Liu (Shucheng)" To: "opsec@ietf.org" Thread-Topic: ask for feedback on dhcpv6 shield doc// [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-00.txt Thread-Index: Ac6WPc23U2G2dx34TTaU0wgL9Yh4vw== Date: Sun, 11 Aug 2013 02:51:48 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.109.142] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB54CA1817szxeml546mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-opsec-dhcpv6-shield@tools.ietf.org" Subject: [OPSEC] ask for feedback on dhcpv6 shield doc// I-D Action: draft-ietf-opsec-dhcpv6-shield-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 02:58:29 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB54CA1817szxeml546mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, We plan to publish a revision of draft-ietf-opsec-dhcpv6-shield soon. If you have any feedback, please post it here or send it privately to the a= uthors. Thanks. Cheers, Will -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-b= ounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, December 12, 2012 6:11 PM To: i-d-announce@ietf.org Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP N= etwork Infrastructure Working Group of the IETF. Title : DHCPv6-Shield: Protecting Against Rogue DHCPv6 S= ervers Author(s) : Fernando Gont Will Liu Gunter Van de Velde Filename : draft-ietf-opsec-dhcpv6-shield-00.txt Pages : 13 Date : 2012-12-12 Abstract: This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-00 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 --_000_C9B5F12337F6F841B35C404CF0554ACB54CA1817szxeml546mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,<= /p>

 

We plan to publish a revisio= n of draft-ietf-opsec-dhcpv6-shield soon.

If you have any feedback, pl= ease post it here or send it privately to the authors. Thanks.

 

Cheers,

Will

 

-----Original Message----- From: opsec-bounces@ietf.org = [mailto:opsec-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, December 12, 2012 6:11 PM
To: i-d-announce@ietf.org
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-00.txt

 

 

A New Internet-Draft is avai= lable from the on-line Internet-Drafts directories.

This draft is a work item of= the Operational Security Capabilities for IP Network Infrastructure Workin= g Group of the IETF.

 

    &nbs= p;    Title        &= nbsp;  : DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers

    &nbs= p;    Author(s)       : Fernan= do Gont

    &nbs= p;            &= nbsp;        Will Liu<= /p>

    &nbs= p;            &= nbsp;        Gunter Van de Velde

    &nbs= p;    Filename        : d= raft-ietf-opsec-dhcpv6-shield-00.txt

    &nbs= p;    Pages        &= nbsp;  : 13

    &nbs= p;    Date         &= nbsp;  : 2012-12-12

 

Abstract:<= /p>

   This document s= pecifies a mechanism for protecting hosts connected to

   a broadcast net= work against rogue DHCPv6 servers.  The aforementioned

   mechanism is ba= sed on DHCPv6 packet-filtering at the layer-2 device

   on which the pa= ckets are received.  The aforementioned mechanism has

   been widely dep= loyed in IPv4 networks ('DHCP snooping'), and hence it

   is desirable th= at similar functionality be provided for IPv6

   networks.<= /o:p>

 

 

The IETF datatracker status = page for this draft is:

https://datatracker.ietf.or= g/doc/draft-ietf-opsec-dhcpv6-shield

 

There's also a htmlized vers= ion available at:

http://tools.ietf.org/html/dra= ft-ietf-opsec-dhcpv6-shield-00

 

 

Internet-Drafts are also ava= ilable by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

 

____________________________= ___________________

OPSEC mailing list

OPSEC@ietf.org

https://www.ietf.org/mailman/listinfo/opsec=

&n= bsp;

 

--_000_C9B5F12337F6F841B35C404CF0554ACB54CA1817szxeml546mbxchi_-- From warren@kumari.net Thu Aug 15 13:01:26 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3067C11E8177 for ; Thu, 15 Aug 2013 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmfa3CkZk2L9 for ; Thu, 15 Aug 2013 13:01:21 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1941611E80EE for ; Thu, 15 Aug 2013 13:01:18 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.80]) by vimes.kumari.net (Postfix) with ESMTPSA id 7AA9A1B407FE; Thu, 15 Aug 2013 16:01:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: Date: Thu, 15 Aug 2013 16:01:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <573A4AA8-625E-48E2-AC3C-9ADF4C23AC76@kumari.net> References: To: OpSec@ietf.org, draft-ietf-opsec-vpn-leakages@tools.ietf.org X-Mailer: Apple Mail (2.1508) Cc: Warren Kumari Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 20:01:26 -0000 On Jul 3, 2013, at 4:58 PM, Warren Kumari wrote: > Dear OpSec WG, >=20 > This starts a Working Group Last Call for = draft-ietf-opsec-vpn-leakages. And the WGLC is now completed (and the chairs finally had a chase to = chat after Berlin :-)). We see consensus for publication. Author, please incorporate the = comments received, and then we can toss it over the wall=85 Thanks to all those who reviewed, and for shame to those who didn't. W >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >=20 > The authors of draft-ietf-opsec-vpn-leakages have indicated that they = have incorporated feedback and believe that the document is ready for = WGLC.=20 > It is the authors responsibility to drum up additional feedback and = review. >=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 > This WGLC ends Wed 17-Jul-2013. >=20 >=20 >=20 > Helpful Notes:=20 > draft-ietf-opsec-vpn-leakages was originally = draft-gont-opsec-vpn-leakages. >=20 > There was some discussion in the thread: IPv6 implications on IPv4 = nets: IPv6 RAs, IPv4's VPN "leakage" > and "New IETF I-D about VPN traffic leakages (Fwd: New Version = Notification for draft-gont-opsec-vpn-leakages-00.txt)" >=20 >=20 > Thanks, > Warren Kumari > (as OpSec WG co-chair) >=20 >=20 > --=20 > Outside of a dog, a book is your best friend, and inside of a dog, = it's too dark to read=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --=20 Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 -- J.R.R. Tolkien From Donald.Smith@CenturyLink.com Thu Aug 15 13:05:17 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835821F99BF for ; Thu, 15 Aug 2013 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHLX2SVnQAIi for ; Thu, 15 Aug 2013 13:05:12 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5789421F9A6D for ; Thu, 15 Aug 2013 13:05:12 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r7FK5ANk018692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2013 15:05:11 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 6C1851E003F; Thu, 15 Aug 2013 15:05:05 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 371A91E004F; Thu, 15 Aug 2013 15:05:05 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r7FK541p023282; Thu, 15 Aug 2013 14:05:04 -0600 (MDT) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r7FK53nc023254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 14:05:03 -0600 (MDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Thu, 15 Aug 2013 14:05:02 -0600 From: "Smith, Donald" To: "'Warren Kumari'" , "'OpSec@ietf.org'" , "'draft-ietf-opsec-vpn-leakages@tools.ietf.org'" Thread-Topic: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages Thread-Index: AQHOmfJC4y+ujlVqxUGGwzUJhkGa05mWsRMA Date: Thu, 15 Aug 2013 20:05:02 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A3D75F2@PDDCWMBXEX503.ctl.intranet> References: <573A4AA8-625E-48E2-AC3C-9ADF4C23AC76@kumari.net> In-Reply-To: <573A4AA8-625E-48E2-AC3C-9ADF4C23AC76@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 20:05:18 -0000 Can we change the name? The reason I ask is the v6 traffic never gets into the tunnel so it can't r= eally leak out. It is a potential data leak or exposure but not really a vpn leak;) "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf >Of Warren Kumari >Sent: Thursday, August 15, 2013 2:01 PM >To: OpSec@ietf.org; draft-ietf-opsec-vpn-leakages@tools.ietf.org >Cc: Warren Kumari >Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages > > >On Jul 3, 2013, at 4:58 PM, Warren Kumari wrote: > >> Dear OpSec WG, >> >> This starts a Working Group Last Call for draft-ietf-opsec-vpn- >leakages. > >And the WGLC is now completed (and the chairs finally had a chase to >chat after Berlin :-)). > >We see consensus for publication. Author, please incorporate the >comments received, and then we can toss it over the wall... > >Thanks to all those who reviewed, and for shame to those who didn't. > >W > >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >> >> The authors of draft-ietf-opsec-vpn-leakages have indicated that they >have incorporated feedback and believe that the document is ready for >WGLC. >> It is the authors responsibility to drum up additional feedback and >review. >> >> Please review this draft to see if you think it is ready for >> publication and comments to the list, clearly stating your view. >> >> This WGLC ends Wed 17-Jul-2013. >> >> >> >> Helpful Notes: >> draft-ietf-opsec-vpn-leakages was originally draft-gont-opsec-vpn- >leakages. >> >> There was some discussion in the thread: IPv6 implications on IPv4 >nets: IPv6 RAs, IPv4's VPN "leakage" >> and "New IETF I-D about VPN traffic leakages (Fwd: New Version >Notification for draft-gont-opsec-vpn-leakages-00.txt)" >> >> >> Thanks, >> Warren Kumari >> (as OpSec WG co-chair) >> >> >> -- >> Outside of a dog, a book is your best friend, and inside of a dog, >> it's too dark to read >> >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > >-- >Do not meddle in the affairs of wizards, for they are subtle and quick >to anger. > -- J.R.R. Tolkien > > >_______________________________________________ >OPSEC mailing list >OPSEC@ietf.org >https://www.ietf.org/mailman/listinfo/opsec From sriram.ietf@gmail.com Thu Aug 22 01:56:25 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28111E8190 for ; Thu, 22 Aug 2013 01:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n2N24Aqv585 for ; Thu, 22 Aug 2013 01:56:19 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0D11E80E9 for ; Thu, 22 Aug 2013 01:56:19 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id db10so1300187veb.0 for ; Thu, 22 Aug 2013 01:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5fTV2MhiglKD1Qoc5YiawT/0a6D3AzO/y/VFo5n0SAk=; b=zZocK0iVykrJJO9UdOSdayg+DgU+4TGCea9MIDDGpDColfYpLY+dd5+GkLH5bUPZOQ BI0ni+AjADcQtXbTg4SMzUhyJfOGKLXtSNkPlY56sjlQdUBmMZJ5OdcJ6EkpmgqNRP3s ATu3G9l50E2WoPqDGuX/yAvsRGhyH4GPOWFymHts3HaK85KMS8Z50f3ENlWA9/7CllOd k300WvnaJVNF+kaqB2MQ9Hs1x+BtifBn3QsehOE9TeTPykhpQmkClG8Xk6PWjUiw+FWK gf5VeMBKZ6BOCYnpdpnL/oc0FsINTspi+Vpi7/W/5aZMYbTQnzJ46WvAaCzmBS9jaCrM AeVA== MIME-Version: 1.0 X-Received: by 10.52.165.111 with SMTP id yx15mr416990vdb.33.1377161777697; Thu, 22 Aug 2013 01:56:17 -0700 (PDT) Received: by 10.220.251.129 with HTTP; Thu, 22 Aug 2013 01:56:17 -0700 (PDT) Date: Thu, 22 Aug 2013 14:26:17 +0530 Message-ID: From: Kotikalapudi Sriram To: opsec@ietf.org Content-Type: multipart/alternative; boundary=001a11c2c5368f05cb04e4857695 X-Mailman-Approved-At: Thu, 22 Aug 2013 01:59:43 -0700 Cc: draft-ietf-opsec-bgp-security@tools.ietf.org Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 08:56:25 -0000 --001a11c2c5368f05cb04e4857695 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have read the document (draft-ietf-opsec-bgp-security-01) and I=92m in support of publication this document as a BCP. Some comments/suggestions below. I have not had chance to go through all the comments you have received so far on this list. Hence, sorry if some of mine seem like a repeat of comments from others. At NIST, we had put together BGP security recommendations document several years ago. You may consider referencing it: R. Kuhn, K. Sriram, and D. Mongomery, =93Border Gateway Protocol Security,= =94 NIST Special Publication 800-54. http://csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf Some nits/comments follow: Consider defining inbound/outbound upfront. p.3, sec 1, para 1: ACL is access control list p.3, sec 1, para 1: this quoted phrase needs further clarity and can be rephrased / explained: =93=85. to avoid filtering transit traffic if not needed=94 section 5.1.1.1 title change: IPv4 special purpose prefixes section 5.1.1.2 title change: IPv6 special purpose prefixes section 5.1.2: replace =93=85described in this section if it is not capable of=85=94 with =93=85described in this section if they are not capable of=85= =94 sec 5.1.2.1, para 1: replace =93=85keep checking prefixes in the IANA alloc= ated address space =85=94 with =93=85keep checking prefixes in the IANA allocate= d IPv4 address space =85=94 sec 5.1.2.1, para 1: replace =93=85IPv4 prefixes they receive have been allocated=85=94 with =93=85IPv4 prefixes they receive in BGP updates have= been allocated=85=85=94 sec 5.1.2.2, para 1: replace =93=85To overcome this risk=85=94 with =93= =85To partially mitigate this risk=85=85=94 sec 5.1.2.3, para 3: replace =93=85a script can build for=85=94 with =93= =85a script can be built for=85=85=94 sec 5.1.2.3, para 4: comment about =93=85only use information from sources representing the five current RIRs=85=94 Question: Why not include the mirrored IRR data of major ISPs as well? I understand such data are readily available in the RADB. sec 5.1.2.3, para 5: replace =93=85may quickly vary over time=85=94 with = =93=85may frequently vary over time =85=85=94 sec 5.1.2.3, para 5: replace =93=85could even been considered=85=94 with = =93=85could even be considered =85=85=94 sec 5.1.2.4, last para: The validation procedure described is inaccurate and incomplete. So (per Randy=92s suggestion as well) you may simply refer = to RFC 6811 here. It may also be worth including RFC 6907 (the SIDR RPKI use cases document) as a reference here. Sec 5.1.4: It would be helpful if a definition of =93local AS=94 is provide= d here. Sec 5.1.5.2: Acronyms pMTUd and uRPF should be spelt out. Sec 5.2.3.1, para 1: replace =93is the same than the one for=94 with =93is = the same as the one for=94 Section 8, last bullet: Is there a practical example when an exception (accepting your own AS number in AS-path) is required? Thanks much. Sriram --001a11c2c5368f05cb04e4857695 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I have read the document (draft-ietf-opse= c-bgp-security-01) and I=92m in support of publication this document as a BCP. Some comments/s= uggestions below.=A0 I have not had chance to go through all the comments you have received so far on this list. Hence, sorr= y if some of mine seem like a repeat of comments from others. =A0

At NIST, we had put together BGP security recommendations = document several years ago. You may consider referencing it:

R. Kuhn, K. Sriram, and D. Mongomery, =93Border Gateway Protocol Security,=94 NIST=A0 Special Publication 800-54. http://csrc.nist.gov/publications/nistpubs/800-5= 4/SP800-54.pdf

Some nits/comments follow:

Consider defining inbound/outbound upfront.=

p.3, sec 1, para 1: ACL is access control list

p.3, sec 1, para 1: this quoted phrase needs further clarity and can be rephrased / explained:=A0= =A0=93=85. to avoid filtering transit traffic if not needed=94

section 5.1.1.1 title change: IPv4 special purpose prefixes

section 5.1.1.2 title change: IPv6 special purpose prefixes

section 5.1.2: replace =93=85described in this section if it is not capable of=85=94 with =93=85described in this sec= tion if they are not capable of=85=94=A0

sec 5.1.2.1, para 1: replace =93=85keep checking prefixes in the IANA allocated address space =85=94 with =93=85kee= p checking prefixes in the IANA allocated IPv4 address space =85=94

sec 5.1.2.1, para 1: replace =93=85IPv4 prefixes they receive have been allocated=85=94=A0= =A0with=A0=A0=93=85IPv4 prefixes they receive in BGP updates have been allocated=85=85=94

sec 5.1.2.2, para 1: replace =93=85To overcome this risk=85=94=A0=A0with= =A0=A0=93=85To partially mitigate this risk=85=85=94

sec 5.1.2.3, para 3: replace =93=85a script can build for=85=94=A0=A0with=A0=A0=93=85a script can be built for=85=85=94

sec 5.1.2.3, para 4: comment about =93=85only use information from sources representing the five current RIRs= =85=94=A0=A0Question: Why not include the mirrored IRR data of major ISPs as well? I understand such data are readily available in the RADB.

sec 5.1.2.3, para 5: replace =93=85may quickly vary over time=85=94=A0=A0with=A0=A0=93=85may frequently vary over time =85=85=94

sec 5.1.2.3, para 5: replace =93=85could even been considered=85=94=A0=A0with=A0=A0=93=85could even be considered =85=85=94

sec 5.1.2.4, last para: The validation procedure described is inaccurate and incomplete. So (per Randy=92s suggest= ion as well) you may simply refer to RFC 6811 here. It may also be worth including= RFC 6907 (the SIDR RPKI use cases document) as a reference here.

Sec 5.1.4: It would be helpful if a definition of =93local AS=94 is provided here.

Sec=A05.1= .5.2:= Acronyms pMTUd and uRPF should be spelt out.

Sec 5.2.3.1, para 1: replace =93is the same than the one for=94 with =93is the same as the one for=94=A0=A0

Section 8, last bullet: Is there a practical example when an exception (accepting your own AS number in AS-pat= h) is required?=A0=A0=A0

Thanks muc= h.

Sriram

--001a11c2c5368f05cb04e4857695-- From jerduran@cisco.com Thu Aug 22 02:12:13 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEBD11E81A1 for ; Thu, 22 Aug 2013 02:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6UY652kWs2b for ; Thu, 22 Aug 2013 02:12:08 -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 AFD2D11E81AA for ; Thu, 22 Aug 2013 02:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4132; q=dns/txt; s=iport; t=1377162726; x=1378372326; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/0GthJxjrCUHUf+EEc1+6OggDF8d0qk7PglrFN3aPKQ=; b=g/8Jinu7fdHjJJgIvIvED0cWTtfwHq6HnP2JPDxaSeFX+Gnf8OClhuFg dFHxK7erNmbspxwvbluQddJRBtVhZ6oD5uRvvxWRgPwW9sRH9vtrpwPMR 0tznuokXK1/zW45WhZVVsKxcMEdwlsPB/b1ElJBKzy98U5wLiS0TiWBzU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAKvVFVKtJXHA/2dsb2JhbABagwU1UcAHgR0WdIIkAQEBAwF5BQsCAQgiJDIlAgQOBQiIAgYMrxqQMwIxB4MbewOZE5Atgx+CKw X-IronPort-AV: E=Sophos;i="4.89,933,1367971200"; d="scan'208";a="250165710" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 22 Aug 2013 09:12:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7M9C5bg001575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 09:12:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 04:12:05 -0500 From: "Jerome Durand (jerduran)" To: joel jaeggli Thread-Topic: some thoughts on draft-jdurand-bgp-security-02.txt Thread-Index: AQHOjB+vSEbxfgKlbUC1hU+VnxIhe5mha8aA Date: Thu, 22 Aug 2013 09:12:04 +0000 Message-ID: <0145702467942740A26A9633AA8B60FA47302C5A@xmb-rcd-x01.cisco.com> References: <51F602DA.7060502@bogus.com> In-Reply-To: <51F602DA.7060502@bogus.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.120] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" , "" Subject: Re: [OPSEC] some thoughts on draft-jdurand-bgp-security-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 09:12:13 -0000 Dear Joel, > since this is on the agenda I'd thought I'd add some comments And indeed thanks for that! First I see that you probably worked on a wrong version of the doc as we ar= e now on draft-ietf-opsec-bgp-security-01 > section-4 worth noting citing/rfc 6192 >=20 > Protecting the Router Control Plane We have section 3 for protection of the router itself where we are referenc= ing RFC6192. I find it clearer to leave reference in section 3. > section 5.1.2.3 >=20 > these sections are too deep. needs better organization, e.g. section 5 > is actually probably two or three sessions. >=20 > e.g. >=20 > 5.1.1. Prefixes that MUST not be routed by definition >=20 > Most of Regional > Internet Registries do also operate an IRR and can control that > registered routes conform to allocations made. >=20 > 3 of 5 Changed to "A majority of Regional Internet Registries [=85]" > should cite >=20 > http://tools.ietf.org/html/rfc4012 >=20 > rpsl It's cited I believe: "5.1.2.3. Prefix filters creation from Internet Routing Registries (IRR) An Internet Routing Registry (IRR) is a database containing internet routing information, described using Routing Policy Specification Language objects [16]" > would be helpful to cite irrtoolset provide an example in an appendix. That's interesting. I put that on a TODO list. I'll see what we can do. > the tier one example isn't that helpful would be more interesting to > cite the example for a customer vantge point e.g. managing objects so > that your upstreams will accept them. Yes I heard the point in the meetecho recordings. I believe you were the on= e who made that point? I may not agree with the fact the example is a tier one example. We have ma= ny small ISPs peering everywhere on the Internet. Some do not even connect = any customer (just servers) and they want there content to be accessible ov= er the Internet. These guys may be interested in making sure they accept ap= propriate routes coming from each of the peers. I wrote that section with t= hese guys into consideration. I was also thinking of other transit networks= (not tier 1) connecting directly customers that I used to operate. These g= uys are far from being tier 1 (2 steps away) but still they peer, sometimes= with the aforementionned CDNs. Still I understand that this section is maybe not clear on applicability (i= e who should do what?) and indeed we have not talked much about objects and= what people SHOULD do. Point taken, I'll see what we can do. > ---- >=20 > rpki section needs to be fleshed out e.g. what you do with it, how it's > used what it can't be used for needs examples. >=20 > The rest of this > section assumes the reader understands all technologies associated > with SIDR. >=20 > Whut??????? This was removed. I received several interesting comments on this section a= nd there is an existing operational doc so we will change few things yes. >=20 > 5.1.4 >=20 > mixes customer prefixes filtering policy with local prefixes=85 Good point. I'll try to improve this. > issues around loop-detection (e.g. disconnected islands) vs more > specific(s) e.g. hijacking. >=20 > outbound filtering (prefix advertisement) Not sure what you mean with this point? Still referering to 5.1.4? > 5.3 and later >=20 > prefer to think of these things as import/export policy rather than > describing everything as filter. OK. Will see how to deal easily with this. > 8. >=20 > o Do not accept overly long AS path prepending from the customer. >=20 > going to have to scope that. New text is "try to discourage excessive prepending in such paths". I'm afr= aid it's difficult to scope that is an IETF document (or we should think of= some standard). Thanks, Jerome -- Jerome Durand Consulting Systems Engineer - Routing & Switching jerduran@cisco.com - +33 6 35 11 60 50 http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr CISCO France 11, rue Camille Desmoulins 92782 Issy les Moulineaux CEDEX 9 FRANCE From jerduran@cisco.com Thu Aug 22 03:23:12 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA03821F9AA9 for ; Thu, 22 Aug 2013 03:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCvcSFAWuTeh for ; Thu, 22 Aug 2013 03:23:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E121F9D98 for ; Thu, 22 Aug 2013 03:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4516; q=dns/txt; s=iport; t=1377166988; x=1378376588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GdhyQfhBIhlMDsYKpT0VoaRiw5TXhXC2DHJ2D90D53U=; b=D6BOq57ibIYhzy+RcsKk07CoAF2iHnlhtxUKncudR4+v/SnUEgXsnGLl tgLfDQgLbjHptezoGT1mE/FmWRJmyBpgCQErsthEPUhTA4QZnJzYnl0gg ncXtpybeAT0N9ib8llSeKO0nHcfbgOsfd3ZPg5NJW+iKR1kJvU8vhBfpz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFDmFVKtJV2d/2dsb2JhbABagwU1UcAHgR0WdIIkAQEBAgEBeQULAgEIIiQyJQIEDg2IAgYMrwCQMwIxB4MbewOZE5Atgx+BayQc X-IronPort-AV: E=Sophos;i="4.89,933,1367971200"; d="scan'208";a="247382682" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 22 Aug 2013 10:23:07 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7MAN5Wx012510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 10:23:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.31]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 05:23:06 -0500 From: "Jerome Durand (jerduran)" To: Kotikalapudi Sriram Thread-Topic: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security Thread-Index: AQHOnxWH6VRecyY450OV6FzZBWppGZmhWbOA Date: Thu, 22 Aug 2013 10:23:06 +0000 Message-ID: <0145702467942740A26A9633AA8B60FA47302FE3@xmb-rcd-x01.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.120] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 10:23:13 -0000 Hi! > I have read the document (draft-ietf-opsec-bgp-security-01) and I=92m in = support of publication this document as a BCP. Some comments/suggestions be= low. I have not had chance to go through all the comments you have receive= d so far on this list. Hence, sorry if some of mine seem like a repeat of c= omments from others. =20 No problem! I haven't been able to answer to all the great coments we've re= ceived so far. Thanks for your support that's appreciated! > At NIST, we had put together BGP security recommendations document severa= l years ago. You may consider referencing it: >=20 > R. Kuhn, K. Sriram, and D. Mongomery, =93Border Gateway Protocol Security= ,=94 NIST Special Publication 800-54. http://csrc.nist.gov/publications/ni= stpubs/800-54/SP800-54.pdf I wasn't aware of it sorry. I believe this is highlighting that having an I= ETF BCP would be useful as no network operator can be aware of all the grea= t material avalaible everywhere. > Some nits/comments follow: >=20 > Consider defining inbound/outbound upfront. >=20 > p.3, sec 1, para 1: ACL is access control list OK > p.3, sec 1, para 1: this quoted phrase needs further clarity and can be r= ephrased / explained: =93=85. to avoid filtering transit traffic if not ne= eded=94 Clarified > section 5.1.1.1 title change: IPv4 special purpose prefixes OK > section 5.1.1.2 title change: IPv6 special purpose prefixes OK > section 5.1.2: replace =93=85described in this section if it is not capab= le of=85=94 with =93=85described in this section if they are not capable of= =85=94=20 OK > sec 5.1.2.1, para 1: replace =93=85keep checking prefixes in the IANA all= ocated address space =85=94 with =93=85keep checking prefixes in the IANA a= llocated IPv4 address space =85=94 OK > sec 5.1.2.1, para 1: replace =93=85IPv4 prefixes they receive have been a= llocated=85=94 with =93=85IPv4 prefixes they receive in BGP updates have = been allocated=85=85=94 OK > sec 5.1.2.2, para 1: replace =93=85To overcome this risk=85=94 with =93= =85To partially mitigate this risk=85=85=94 OK > sec 5.1.2.3, para 3: replace =93=85a script can build for=85=94 with = =93=85a script can be built for=85=85=94 I don't think so. Full sentence is below so we are talking about the fact t= hat the script builds something: "With these two mechanisms a script can build for a given peer the list of = allowed prefixes and the AS number from which they should be originated" > sec 5.1.2.3, para 4: comment about =93=85only use information from source= s representing the five current RIRs=85=94 Question: Why not include the m= irrored IRR data of major ISPs as well? I understand such data are readily = available in the RADB. OK, changed to: One could check a popular IRR containing many sources (such as RADB, the Ro= uting Assets Database) and only select as sources some desired RIRs and tru= sted major ISPs > sec 5.1.2.3, para 5: replace =93=85may quickly vary over time=85=94 with= =93=85may frequently vary over time =85=85=94 OK > sec 5.1.2.3, para 5: replace =93=85could even been considered=85=94 with= =93=85could even be considered =85=85=94 OK > sec 5.1.2.4, last para: The validation procedure described is inaccurate = and incomplete. So (per Randy=92s suggestion as well) you may simply refer = to RFC 6811 here. It may also be worth including RFC 6907 (the SIDR RPKI us= e cases document) as a reference here. Yes we'll work further on the section globally. > Sec 5.1.4: It would be helpful if a definition of =93local AS=94 is provi= ded here. OK. Same here we should clarify few things here. > Sec 5.1.5.2: Acronyms pMTUd and uRPF should be spelt out. OK, will appear in accronym&definition section of -02=20 > Sec 5.2.3.1, para 1: replace =93is the same than the one for=94 with =93i= s the same as the one for=94 =20 OK > Section 8, last bullet: Is there a practical example when an exception (a= ccepting your own AS number in AS-path) is required? =20 Well I've personnaly seen that when customers have a single AS for several = sites and are interconnected through various ISPs. We are usually using oth= er mecahnisms like as-override but I'd assume some would prefer to change d= efault BGP bahaviour and agree on the risks. I am not sure we wanted to put= an example in the document. Again, thanks a lot for your participation! Jerome From cpignata@cisco.com Thu Aug 22 05:56:40 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40621F89EB for ; Thu, 22 Aug 2013 05:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTRr1yEG36Xj for ; Thu, 22 Aug 2013 05:56:31 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6241321F9F08 for ; Thu, 22 Aug 2013 05:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16573; q=dns/txt; s=iport; t=1377176191; x=1378385791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f5pvBukTE8FvFqQ4eE1FLksE7XSFFUzZ6if4p7W0x+E=; b=BEAzNEFrTZxVHrgVWx+8/F6ZdtncK5JqayytYM2oRQcgTlA0kz3odA5G 0PTl1RbrZi7rhXi1/Jno7SX/F2TQeJVZ2LZHGbAJy0yDkNn0LlqNi9R7r iXB1pMlhoe9eqDOF8bUnUS6UUtmrbsS09LXcCu2r8VxiuxnCXqlVzWcc5 I=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAIAJFlKtJV2Z/2dsb2JhbABagwU1Swa3OohNgR0WdIIkAQEBAwEBAQFrCwULAgEIGAokIQYBCiUCBA4FCAEFC4dlAwkGBwWsdg2CAI1tgkgtBAeDG3sDkBaBLoNaX4MWiwSFKYMfgis X-IronPort-AV: E=Sophos;i="4.89,934,1367971200"; d="asc'?scan'208,217";a="250408722" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 22 Aug 2013 12:56:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7MCuUPu009818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 12:56:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.221]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 07:56:30 -0500 From: "Carlos Pignataro (cpignata)" To: KK Thread-Topic: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 Thread-Index: AQHOe+pau4UDPw83oEGNf2neu7CvGJlcvOiAgAAZWwCAB07TgIAW4g4AgABqlwCAJlhLgA== Date: Thu, 22 Aug 2013 12:56:29 +0000 Message-ID: <95067C434CE250468B77282634C96ED3240FD5DA@xmb-aln-x02.cisco.com> References: <60119.1373294971@sonic.net> <1565B7C7-E70B-4645-971E-421CE90B27E4@gmail.com> <95067C434CE250468B77282634C96ED322CD0A9C@xmb-aln-x02.cisco.com> <4DAFAE6C-C7A1-4BB2-B70A-F727DCE6F847@kumari.net> <95067C434CE250468B77282634C96ED322D5E9F0@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.20] Content-Type: multipart/signed; boundary="Apple-Mail=_0CA0FE47-DDB0-4E3C-A961-C5319F54BA28"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Warren Kumari , "" , RJ Atkinson Subject: Re: [OPSEC] Review of: draft-ietf-opsec-ip-options-filtering-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 12:56:40 -0000 --Apple-Mail=_0CA0FE47-DDB0-4E3C-A961-C5319F54BA28 Content-Type: multipart/alternative; boundary="Apple-Mail=_D4EE4A27-D4B3-4352-8DF5-ABE0FFC47692" --Apple-Mail=_D4EE4A27-D4B3-4352-8DF5-ABE0FFC47692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, KK, The most recent state in the tracker for this document is [1]: 2013-07-14 04 Warren Kumari IETF WG state changed to WG = Consensus: Waiting for Write-Up from In WG Last Call This is after a WGLC in Feb this year: 2013-02-18 02 Warren Kumari IETF state changed to In WG Last = Call from WG Document =20 Do you have an update? Thanks, -- Carlos. [1] = https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/his= tory/ On Jul 28, 2013, at 11:22 PM, KK wrote: > Hi Carlos, >=20 > I have the shepherd write-up almost ready to be shipped out. My plan = is to do it this week. >=20 > Thanks you for your patience. >=20 > Regards, > KK >=20 >=20 > On Sun, Jul 28, 2013 at 2:01 PM, Carlos Pignataro (cpignata) = wrote: > Warren, >=20 > On Jul 14, 2013, at 9:34 AM, Warren Kumari wrote: >=20 > > > > On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) = wrote: > > > >> WG, > >> > >> I just posted a new revision, intended to address all WGLC comments = on this document. > > > > > > > > Thank you. > > > > We have discussed this and judge there to be consensus to progress = this. >=20 > Thanks. All the WGLC comments were resolved with revision -04 posted = on July 11th. >=20 > Do you have a target for when the doc will be sent to the IESG? >=20 > -- Carlos. >=20 > > > > We would also like to apologize for how long it took to complete = this WGLC, and thank the authors (and WG) for their patience. We have / = will be making some changes to streamline things, and hopefully prevent = long delays in the future. > > > > > > W > > > > > >> > >> You can find it at = http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-03. > >> You can also find diffs from the previous version at = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-0= 3 > >> > >> This new revision incorporates resolution to all comments, = especially from Arturo and Merike, as well as the text below. It also = incorporates a number of editorial (typographical, grammar) fixes. = Hopefully we have not missed anything. > >> > >> Please review. > >> > >> Thanks! > >> > >> -- Carlos. > >> > >> On Jul 9, 2013, at 10:27 AM, RJ Atkinson = wrote: > >> > >>> All, > >>> > >>> Here is some candidate text to replace the indented text > >>> in Sections 4.12.2 & 4.13.2, leveraging Merike's suggested > >>> introduction, and restoring (with minor edits) the previous > >>> language: > >>> > >>> Some private IP networks consider IP router-based > >>> per-interface selective filtering of packets based > >>> on (a) the presence of an IPSO option (including BSO > >>> and ESO) and (b) based on the contents of that IPSO > >>> option to be important for operational security reasons. > >>> The recent IPv6 CALIPSO option specification discusses > >>> this in additional detail, albeit in an IPv6 context. > >>> [RFC5570] > >>> > >>> Such private IP networks commonly are built using both > >>> commercial and open-source products - for hosts, guards, > >>> firewalls, switches, routers, etc. Some commercial IP > >>> routers support this option, as do some IP routers which > >>> are built on top of Multi-Level Secure (MLS) operating > >>> systems (e.g. on top of Trusted Solaris [Solaris2008] or > >>> Security-Enhanced Linux [SELinux2008]). > >>> > >>> For example, many Cisco routers that run Cisco IOS include > >>> support for selectively filtering packets that contain the > >>> IP Security Options (IPSO) with per-interface granularity. > >>> This capability has been present in many Cisco routers > >>> since the early 1990s [Cisco-IPSO-Cmds]. Some government > >>> sector products reportedly also support the IP Security > >>> Options (IPSO), for example CANEWARE [RFC4949]. > >>> > >>> Support for the IPSO Basic Security Option also is > >>> included in the "IPsec Configuration Policy Information > >>> Model" [RFC3585] and in the "IPsec Security Policy > >>> Database Configuration MIB" [RFC4807]. Section 4.6.1 > >>> of the IP Security Domain of Interpretation [RFC2407] > >>> includes support for labeled IPsec security associations > >>> compatible with the IP Security Options. > >>> > >>> I'm greatly obliged to Merike for her suggested text, > >>> which is included in the proposed revised text above, > >>> and to Arturo for agreeing that an edited version of > >>> the original text could be retained in this document. > >>> > >>> > >>> Yours, > >>> > >>> Ran Atkinson > >>> > >>> > >>> _______________________________________________ > >>> OPSEC mailing list > >>> OPSEC@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsec > >> > >> _______________________________________________ > >> OPSEC mailing list > >> OPSEC@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec > >> > > > > -- > > "Build a man a fire, and he'll be warm for a day. Set a man on fire, = and he'll be warm for the rest of his life." -- Terry Pratchett > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_D4EE4A27-D4B3-4352-8DF5-ABE0FFC47692 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = KK,

The most recent state in the tracker for this = document is [1]:

2013-07-14 04 Warren Kumari IETF WG = state changed to WG Consensus: Waiting for Write-Up from In WG = Last Call

This is after a WGLC in Feb this = year:

2013-02-18 02 Warren Kumari IETF = state changed to In WG Last Call from WG Document   =   

Do you have an = update?

Thanks,

-- = Carlos.

On Jul 28, 2013, at = 11:22 PM, KK <kk@google.com> = wrote:

Hi Carlos,

I = have the shepherd write-up almost ready to be shipped out. My plan is to = do it this week.

Thanks you for your = patience.

Regards,
KK


On Sun, Jul 28, = 2013 at 2:01 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Warren,

On Jul 14, 2013, at 9:34 AM, Warren Kumari <warren@kumari.net> wrote:

>
> On Jul 9, 2013, at 11:58 AM, Carlos Pignataro (cpignata) = <cpignata@cisco.com> wrote:
>
>> WG,
>>
>> I just posted a new revision, intended to address all WGLC = comments on this document.
>
> <chair hat>
>
> Thank you.
>
> We have discussed this and judge there to be consensus to progress = this.

Thanks. All the WGLC comments were resolved with revision -04 = posted on July 11th.

Do you have a target for when the doc will be sent to the IESG?

-- Carlos.

>
> We would also like to apologize for how long it took to complete = this WGLC, and thank the authors (and WG) for their patience. We have / = will be making some changes to streamline things, and hopefully prevent = long delays in the future.
>
>
> W
> </chair hat>
>
>>
>> You can find it at http://tools.ietf.org/html/draft-ietf-opsec-ip-options-f= iltering-03.
>> You can also find diffs from the previous version at http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-o= ptions-filtering-03
>>
>> This new revision incorporates resolution to all comments, = especially from Arturo and Merike, as well as the text below. It also = incorporates a number of editorial (typographical, grammar) fixes. = Hopefully we have not missed anything.
>>
>> Please review.
>>
>> Thanks!
>>
>> -- Carlos.
>>
>> On Jul 9, 2013, at 10:27 AM, RJ Atkinson <rja.lists@gmail.com> wrote:
>>
>>> All,
>>>
>>> Here is some candidate text to replace the indented = text
>>> in Sections 4.12.2 & 4.13.2, leveraging Merike's = suggested
>>> introduction, and restoring (with minor edits) the = previous
>>> language:
>>>
>>>     Some private IP networks consider IP = router-based
>>>     per-interface selective filtering of packets = based
>>>     on (a) the presence of an IPSO option = (including BSO
>>>     and ESO) and (b) based on the contents of = that IPSO
>>>     option to be important for operational = security reasons.
>>>     The recent IPv6 CALIPSO option specification = discusses
>>>     this in additional detail, albeit in an IPv6 = context.
>>>     [RFC5570]
>>>
>>>     Such private IP networks commonly are built = using both
>>>     commercial and open-source products - for = hosts, guards,
>>>     firewalls, switches, routers, etc.  Some = commercial IP
>>>     routers support this option, as do some IP = routers which
>>>     are built on top of Multi-Level Secure (MLS) = operating
>>>     systems (e.g. on top of Trusted Solaris = [Solaris2008] or
>>>     Security-Enhanced Linux [SELinux2008]).
>>>
>>>     For example, many Cisco routers that run = Cisco IOS include
>>>     support for selectively filtering packets = that contain the
>>>     IP Security Options (IPSO) with per-interface = granularity.
>>>     This capability has been present in many = Cisco routers
>>>     since the early 1990s [Cisco-IPSO-Cmds]. =  Some government
>>>     sector products reportedly also support the = IP Security
>>>     Options (IPSO), for example CANEWARE = [RFC4949].
>>>
>>>     Support for the IPSO Basic Security Option = also is
>>>     included in the "IPsec Configuration Policy = Information
>>>     Model" [RFC3585] and in the "IPsec Security = Policy
>>>     Database Configuration MIB" [RFC4807]. =  Section 4.6.1
>>>     of the IP Security Domain of Interpretation = [RFC2407]
>>>     includes support for labeled IPsec security = associations
>>>     compatible with the IP Security Options.
>>>
>>> I'm greatly obliged to Merike for her suggested text,
>>> which is included in the proposed revised text above,
>>> and to Arturo for agreeing that an edited version of
>>> the original text could be retained in this document.
>>>
>>>
>>> Yours,
>>>
>>> Ran Atkinson
>>>
>>>
>>> _______________________________________________
>>> OPSEC mailing list
>>> OPSEC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsec
>>
>> _______________________________________________
>> OPSEC mailing list
>> OPSEC@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsec
>>
>
> --
> "Build a man a fire, and he'll be warm for a day. Set a man on = fire, and he'll be warm for the rest of his life." -- Terry = Pratchett
>
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec


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


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

= --Apple-Mail=_D4EE4A27-D4B3-4352-8DF5-ABE0FFC47692-- --Apple-Mail=_0CA0FE47-DDB0-4E3C-A961-C5319F54BA28 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 iEYEARECAAYFAlIWCn0ACgkQtfDPGTp3USxASgCeL5Oj1zzHYx9tCZtnyvh1bFJn TBwAn02oFO2Wtg6DtJ0Hg1YDWfVnjboO =1YKT -----END PGP SIGNATURE----- --Apple-Mail=_0CA0FE47-DDB0-4E3C-A961-C5319F54BA28-- From bgreene@senki.org Thu Aug 22 06:16:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C062211E81C1 for ; Thu, 22 Aug 2013 06:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn1rN9+5jd0n for ; Thu, 22 Aug 2013 06:16:11 -0700 (PDT) Received: from smtp73.ord1c.emailsrvr.com (smtp73.ord1c.emailsrvr.com [108.166.43.73]) by ietfa.amsl.com (Postfix) with ESMTP id EAAB111E81BD for ; Thu, 22 Aug 2013 06:16:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 81B821E824B; Thu, 22 Aug 2013 09:16:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id F0E4B1E829E; Thu, 22 Aug 2013 09:16:08 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Barry Greene In-Reply-To: <0145702467942740A26A9633AA8B60FA47302FE3@xmb-rcd-x01.cisco.com> Date: Thu, 22 Aug 2013 20:16:04 +0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8585B496-9079-4608-B9B4-A388EEF2F5A6@senki.org> References: <0145702467942740A26A9633AA8B60FA47302FE3@xmb-rcd-x01.cisco.com> To: "Jerome Durand (jerduran)" X-Mailer: Apple Mail (2.1508) Cc: Kotikalapudi Sriram , "" , "" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 13:16:17 -0000 On Aug 22, 2013, at 5:23 PM, "Jerome Durand (jerduran)" = wrote: >> R. Kuhn, K. Sriram, and D. Mongomery, =93Border Gateway Protocol = Security,=94 NIST Special Publication 800-54. = http://csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf >=20 > I wasn't aware of it sorry. I believe this is highlighting that having = an IETF BCP would be useful as no network operator can be aware of all = the great material avalaible everywhere. For completeness sake, include the workshop seminar references from = NANOG, RIPE, and APRICOT as well as the recommendations in a couple of = books.=20= From internet-drafts@ietf.org Thu Aug 22 17:26:56 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1FB11E829A; Thu, 22 Aug 2013 17:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5RJwLhzVYa7; Thu, 22 Aug 2013 17:26:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ECB11E8289; Thu, 22 Aug 2013 17:26:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130823002655.23309.76395.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2013 17:26:55 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 00:26:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Virtual Private Network (VPN) traffic leakages in dual-s= tack hosts/ networks Author(s) : Fernando Gont Filename : draft-ietf-opsec-vpn-leakages-02.txt Pages : 15 Date : 2013-08-22 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) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-vpn-leakages-02 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 fgont@si6networks.com Thu Aug 22 17:43:20 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5BC11E812E for ; Thu, 22 Aug 2013 17:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w+8JyBTXs4v for ; Thu, 22 Aug 2013 17:43:19 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B69A111E80EA for ; Thu, 22 Aug 2013 17:43:19 -0700 (PDT) Received: from [186.134.0.127] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VCfTA-0005Un-06; Fri, 23 Aug 2013 02:43:16 +0200 Message-ID: <5216B01F.70904@si6networks.com> Date: Thu, 22 Aug 2013 21:43:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: opsec chairs References: <20130823002655.23309.76395.idtracker@ietfa.amsl.com> In-Reply-To: <20130823002655.23309.76395.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 00:43:20 -0000 FYI, ready to ship. :-) Cheers, Fernando On 08/22/2013 09:26 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. > > Title : Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks > Author(s) : Fernando Gont > Filename : draft-ietf-opsec-vpn-leakages-02.txt > Pages : 15 > Date : 2013-08-22 > > 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) products, may inadvertently > result in VPN traffic leaks. That is, traffic meant to be > transferred over a VPN connection may leak out of such connection and > be transferred in the clear from the local network to the final > destination. This document discusses some scenarios in which such > VPN leakages may occur, either as a side effect of enabling IPv6 on a > local network, or as a result of a deliberate attack from a local > attacker. Additionally, it discusses possible mitigations for the > aforementioned 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-vpn-leakages-02 > > > 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/ > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492