From fgont@si6networks.com Fri Nov 2 20:29:56 2012 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 A4AF711E8103 for ; Fri, 2 Nov 2012 20:29: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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsIym5O7WI4z for ; Fri, 2 Nov 2012 20:29:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0C11E80DF for ; Fri, 2 Nov 2012 20:29:56 -0700 (PDT) Received: from [186.134.30.112] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TUUQg-0000xL-EQ; Sat, 03 Nov 2012 04:29:50 +0100 Message-ID: <50948FA5.7030106@si6networks.com> Date: Sat, 03 Nov 2012 00:29:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Cameron Byrne References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> <508C6E0E.9010100@si6networks.com> In-Reply-To: <508C6E0E.9010100@si6networks.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-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: Sat, 03 Nov 2012 03:29:56 -0000 Hi, Cameron, Please let me know your thoughts about my comments below, such that I can rev the I-D accordingly. Thanks! Best regards, Fernando On 10/27/2012 08:28 PM, Fernando Gont wrote: > Hi, Cameron, > > Thanks so much for your feedback! Please find my comments in-line.... > > > On 10/27/2012 06:10 PM, Cameron Byrne wrote: >> The attack that i am most concerned about is that many folks assume >> the VPN will "lock the stack". And, the VPN software may in fact lock >> the IPv4 stack (on the WAN, only traffic to and from the VPN endpoints >> is allowed). But, in the case of dual stack, the VPN locks the IPv4 >> stack and the IPv6 stack is left wide open to a public WLAN. So, the >> attacker at a coffee shop can own the VPN users system via IPv6 and >> therefore access the secure corporate network over IPv4. This is not >> a case of protocol translation or traffic leaking, but a case of using >> a "jump host" to illicitly move from a public WLAN to a secure >> corporate network. > > Agreed. > > It looks like I should probably change the title of the I-D to something > along the lines of > > "Security Implications of dual-stack hosts/networks on Virtual Private > Networks (VPN)" > > or > > "Security Issues of Virtual Private Networks (VPN) in dual-stack hosts/ > networks" > ? > > (please do let me know if you have any preference of title over the > other, or feel free to suggest an alternative title) > > Then the I-D could mention possible/common security implications such: > > * Lost of confidentiality in the resulting traffic (i.e., you thought > your traffic was protected from eavesdroppers, when in fact it wasn't) > > * The possibility of an attacker stealing credentials (e.g. if an > insecure protocol was sending user/pass in the clear) > > * And the attack scenario you describing (an attacker using the VPN as a > pivot to attack some system in the VPN). > > > >> I think there is also some additional ipv6 nuance that can be explored >> in this case of a dual-stack VPN. For example, how is LLA treated on >> the coffee shop WLAN? > > In what sense? > > >> Also, the name server issue can be explored, >> if RA or DHCPv6 provides a DNS server, the VPN client should be sure >> to not use those since a rogue DNS server can create a situation where >> VPN traffic is leaked.... http://intranet is spoofed by the local >> attacker DNS server and skims login creds > > Agreed. I will try to test common implementations (Windows, *BSD, > Solaris, and Linux) with respect to this issue, and provide a summary. > > Thanks so much for your feedback! > > Best regards, > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From cb.list6@gmail.com Fri Nov 2 21:10:23 2012 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 43B6221F9C0C for ; Fri, 2 Nov 2012 21:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUC-DwFOkWHV for ; Fri, 2 Nov 2012 21:10:22 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D81821F9B31 for ; Fri, 2 Nov 2012 21:10:22 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3249180lam.31 for ; Fri, 02 Nov 2012 21:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dn8+UO0tK8/S6NuKePA6xkVnv/uyqEzPMNpIwB0Tkmg=; b=a/SNx6xuPVlBslsYo9+1ID8vx6BKmJajXc+6S9Y+YszOOBHnUIBBATgcEnQLl1QBfz D8q3fug4+/2jJws4Nf8XvsxucfbeeglLpH8GNNV1uQleP3G1w+bwEIIzNBOvwFlGu7N0 akfRLyCn36DOom4nOoiZLlaGfIJ9xkEXz7WzyfefBhJkfWFoFLg4dUiAO2gQ7DgrB1kw eZvzHRkjXxJcii4bc40xT3D1M2iD/Js2Ff3R7nlHpVofXyXthdCiK1azjrCuax7YciN5 Fwu/K12mTUzGQCBKqQphnRxKQVhZ/RdRdg3ptUMZo+rJ3OxvLbOivsF5shogGVEJ1/q5 r49Q== MIME-Version: 1.0 Received: by 10.152.109.145 with SMTP id hs17mr3481455lab.5.1351915821222; Fri, 02 Nov 2012 21:10:21 -0700 (PDT) Received: by 10.112.81.167 with HTTP; Fri, 2 Nov 2012 21:10:21 -0700 (PDT) In-Reply-To: <508C6E0E.9010100@si6networks.com> References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> <508C6E0E.9010100@si6networks.com> Date: Fri, 2 Nov 2012 21:10:21 -0700 Message-ID: From: Cameron Byrne To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-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: Sat, 03 Nov 2012 04:10:23 -0000 Hi, On Sat, Oct 27, 2012 at 4:28 PM, Fernando Gont wrote: > Hi, Cameron, > > Thanks so much for your feedback! Please find my comments in-line.... > > > On 10/27/2012 06:10 PM, Cameron Byrne wrote: >> The attack that i am most concerned about is that many folks assume >> the VPN will "lock the stack". And, the VPN software may in fact lock >> the IPv4 stack (on the WAN, only traffic to and from the VPN endpoints >> is allowed). But, in the case of dual stack, the VPN locks the IPv4 >> stack and the IPv6 stack is left wide open to a public WLAN. So, the >> attacker at a coffee shop can own the VPN users system via IPv6 and >> therefore access the secure corporate network over IPv4. This is not >> a case of protocol translation or traffic leaking, but a case of using >> a "jump host" to illicitly move from a public WLAN to a secure >> corporate network. > > Agreed. > > It looks like I should probably change the title of the I-D to something > along the lines of > > "Security Implications of dual-stack hosts/networks on Virtual Private > Networks (VPN)" > > or > > "Security Issues of Virtual Private Networks (VPN) in dual-stack hosts/ > networks" > ? > Yes, i think that make sense. The major issue is that when VPN clients on hosts do not have feature parity between IPv4 and IPv6, there will be problems. Either way is fine with me. > (please do let me know if you have any preference of title over the > other, or feel free to suggest an alternative title) > > Then the I-D could mention possible/common security implications such: > > * Lost of confidentiality in the resulting traffic (i.e., you thought > your traffic was protected from eavesdroppers, when in fact it wasn't) > > * The possibility of an attacker stealing credentials (e.g. if an > insecure protocol was sending user/pass in the clear) > > * And the attack scenario you describing (an attacker using the VPN as a > pivot to attack some system in the VPN). > > > >> I think there is also some additional ipv6 nuance that can be explored >> in this case of a dual-stack VPN. For example, how is LLA treated on >> the coffee shop WLAN? > > In what sense? > Well, even feature parity between IPv4 and IPv6 is not enough. A dual-stack VPN should also account for LLA connectivity. IPv4 only had to account for 1 address scope. If the VPN is not supposed to be a "split tunnel", then is LLA on the WLAN interface is also supposed to be statefully firewalled on the host? Should the VPN host allow NDP from LLA and nothing else? If this is a guide to implementers, then pointing out the LLA area may be a good idea. > >> Also, the name server issue can be explored, >> if RA or DHCPv6 provides a DNS server, the VPN client should be sure >> to not use those since a rogue DNS server can create a situation where >> VPN traffic is leaked.... http://intranet is spoofed by the local >> attacker DNS server and skims login creds > > Agreed. I will try to test common implementations (Windows, *BSD, > Solaris, and Linux) with respect to this issue, and provide a summary. > > Thanks so much for your feedback! > Your welcome, i hope this draft can improve the area of VPN implementations. Thanks for taking the time to write it up. CB > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > From kkumar@google.com Sat Nov 3 16:54:13 2012 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 0A6F221F95DB for ; Sat, 3 Nov 2012 16:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJrIHur6sZJZ for ; Sat, 3 Nov 2012 16:54:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA31021F970E for ; Sat, 3 Nov 2012 16:54:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3629863lbo.31 for ; Sat, 03 Nov 2012 16:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=nAil1xB8SOZLF+ZnZjkVeuvbXDg3GHPIAF0S2E/WcvQ=; b=BH8nL6zgKVqQtsiYdkU5fh1yEcBtJckMZLoK5XWpyLJ2qdxir0oeP3IBVFB8BOoPdj a0imVW+n9XSKDwE6FCobujkGdmfDC711EDefAkZ22hTnU9+3NzeNQpVPDZCBCDDLmKv/ DClh8nOcws3O+5bEYWQSjF1iiuFx6JaF59ypnhjFO3fdETVXgzWyfyKK4BcWI6+skPyB dm8Jcx/jbLcEfxknYAfPDyxxDTOjT+FJFcnxKoBO/47LnI5mfqM1sF4YB55WXKRaMOMj f8zXv9Qns0VDoR6sGWFg5FfPPFOVOyjrA1om3UBNpGkTk1/YatbGIOnWRND0+ytNcMGQ zE3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=nAil1xB8SOZLF+ZnZjkVeuvbXDg3GHPIAF0S2E/WcvQ=; b=RdFm2CvukwYGR1mdx5cHVPfJH2TZNgMSqlcGjGFkPmIxhbLEGm0EAjusQnk0t/Qj69 nPZJQTcViWW9wiv439PAagBRSQRsuLbfp7sk0Y9ep/2zi76pz7ShBlI8qMDX1aVE8Pbv 9P9OmMC/nurpXCXiJ/yGsa/jwy80cQfE8I7fkql3c+XndvX+WV1pM5lrgOW+D+/tBLFM NJ0Sx63j38oF+iHPhaAqqIXXdu05l+Xv6JXODGebtT0k25ilGd7FgLjv/hi3ttK2enRT p6k6FQjP8zg7fN8yLLXj/HYYnHPCVeKbSLRBJ8hrxGMq81Apba/vTk++Z7tdboJ/1D8N X3aA== Received: by 10.112.25.161 with SMTP id d1mr2357059lbg.118.1351986850781; Sat, 03 Nov 2012 16:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.6.42 with HTTP; Sat, 3 Nov 2012 16:53:50 -0700 (PDT) From: KK Date: Sat, 3 Nov 2012 16:53:50 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=bcaec554d71cfb58ef04cd9ff7c8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl7rbVqeLX+4wQxbWfFzRJ9COs7+ClqPNZZjmhsNunLzu9M8uj7oKrLJGnL7eXq6Q1dGyZWjyambh4vpzskuDM/eWCT7PTMpp236b7Ulsjs7+au+Ql3CtpowknoItuVV/Mv+nd0wNUTs/hk0PkWZhHoo1fd/Ag5cCddMuaoTlNTIs+odpd4SWspH4HCGsv4FvPi+Gr8 Subject: [OPSEC] Presenters Slides Requested 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: Sat, 03 Nov 2012 23:54:13 -0000 --bcaec554d71cfb58ef04cd9ff7c8 Content-Type: text/plain; charset=ISO-8859-1 To folks on the agenda- It would be greatly appreciated if you could provide the chairs with your slides no later than Wednesday night. Thanks, KK, Gunter, Warren --bcaec554d71cfb58ef04cd9ff7c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To folks on = the agenda - It would be greatly appreciated if you could = provide the chairs with your slides no later than Wednesday night.

Thanks,
KK, Gunter, Warren
--bcaec554d71cfb58ef04cd9ff7c8-- From radarbha@cisco.com Wed Nov 7 05:43:37 2012 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 3778F21F85E2 for ; Wed, 7 Nov 2012 05:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.252 X-Spam-Level: X-Spam-Status: No, score=-10.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw0AFbzT+PYd for ; Wed, 7 Nov 2012 05:43:36 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 24FD221F85DA for ; Wed, 7 Nov 2012 05:43:36 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7DhV16017596; Wed, 7 Nov 2012 08:43:31 -0500 (EST) Received: from dhcp-10-150-53-244.cisco.com (dhcp-10-150-53-244.cisco.com [10.150.53.244]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7DhVl1011739; Wed, 7 Nov 2012 08:43:31 -0500 (EST) Message-ID: <509A6581.4030702@cisco.com> Date: Wed, 07 Nov 2012 08:43:29 -0500 From: Rama Darbha User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Fernando Gont Subject: [OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning 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: Wed, 07 Nov 2012 13:43:37 -0000 To Opsec Subscribers, I originally emailed the feedback below directly to Fernando Gont and he requested I provide the feedback directly to the alias. I have some feedback regarding this document. I feel documents like this are primarily used by industry professionals as guides to secure their networks. As a result, my feedback pertains specifically to helping network administrators better apply the knowledge outlined in your RFC: 3.1.3. Manually-configured addresses "This is typically the case for IPv6 addresses assigned to routers, since routers do not employ automatic address configuration." I would not state that routers do not universally employ automatic address configuration. In order to state that, I would at least suggest referencing an RFC where it is not recommended to use automatic address configuration. One of the functions of IPv6 is its "plug-and-play" nature. I feel a statement like this may be misinterpreted by the more general audience. "On the other hand, the search space for IPv6 wordy-addresses is probably larger and more complex, but still greatly reduced when compared to the original 64- bit search space." The terminology used in this sentence does not sound technically confident. Words like "probably" make the sentence sound unimportant. I understand what you're getting across, but the sentence itself doesn't feel technically strong. 3.2. IPv6 address scanning of remote area networks "While in IPv4 networks attackers have been able to get away with "brute force" scanning attacks (thanks to the reduced search space), successfully performing a brute-force scan of an entire /64 network would be infeasible. " When I first read this, I immediately agreed that performing a brute-force attach on a /64 network would be infeasible. But then I started to reflect on why it would be so infeasible? Computers are getting faster, and NICs have more capacity, so their ability to create faster mappings scales in relation. Do we have current research numbers to state how long it takes to do a brute force scan of a /64? I think referencing research would go a long way to convincing readers of this statement. "Unfortunately, a number of IPv6 implementations have been found to be unable to properly handle large number of entries in the Neighbor Cache, and hence these address-scan attacks may have the side effect of resulting in a Denial of Service (DoS) attack [CPNI-IPv6] [I-D.ietf-v6ops-v6nd-problems]." It might be worth mentioning that stateful devices in the network path, like firewalls, will track neighbour cache and connection information. Since these values are so much larger in IPv6, these intermediate devices are also subject to such DoS vulnerabilities. I am new to providing feedback on IETF documentation. So let me know if I've missed the mark on this email. I don't know the exact format or procedures for providing this feedback but I thought there would be no harm in emailing the authors directly with my thoughts. Regards, Rama -- Rama Darbha, CCIE#28006 919-574-5071 radarbha@cisco.com Cisco TAC - Security Solutions RTP, NC, USA Hours: 8h30 - 17h00 (EST) http://www.cisco.com/tac/ From radarbha@cisco.com Mon Nov 5 18:53:37 2012 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 6281D21F85A8 for ; Mon, 5 Nov 2012 18:53:37 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stbuI5l2seZ7 for ; Mon, 5 Nov 2012 18:53:36 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9302121F8457 for ; Mon, 5 Nov 2012 18:53:36 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA62rZwZ005106 for ; Mon, 5 Nov 2012 21:53:36 -0500 (EST) Received: from rtp-radarbha-8712.cisco.com (rtp-radarbha-8712.cisco.com [10.116.50.243]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA62rZvk018401 for ; Mon, 5 Nov 2012 21:53:35 -0500 (EST) Message-ID: <50987BAF.60909@cisco.com> Date: Mon, 05 Nov 2012 21:53:35 -0500 From: Rama Darbha User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Nov 2012 06:46:52 -0800 Subject: [OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning 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: Tue, 06 Nov 2012 23:59:06 -0000 To Opsec Subscribers, I originally emailed the feedback below directly to Fernando Gont and he requested I provide the feedback directly to the alias. I have some feedback regarding this document. I feel documents like this are primarily used by industry professionals as guides to secure their networks. As a result, my feedback pertains specifically to helping network administrators better apply the knowledge outlined in your RFC: 3.1.3. Manually-configured addresses "This is typically the case for IPv6 addresses assigned to routers, since routers do not employ automatic address configuration." I would not state that routers do not universally employ automatic address configuration. In order to state that, I would at least suggest referencing an RFC where it is not recommended to use automatic address configuration. One of the functions of IPv6 is its "plug-and-play" nature. I feel a statement like this may be misinterpreted by the more general audience. "On the other hand, the search space for IPv6 wordy-addresses is probably larger and more complex, but still greatly reduced when compared to the original 64- bit search space." The terminology used in this sentence does not sound technically confident. Words like "probably" make the sentence sound unimportant. I understand what you're getting across, but the sentence itself doesn't feel technically strong. 3.2. IPv6 address scanning of remote area networks "While in IPv4 networks attackers have been able to get away with "brute force" scanning attacks (thanks to the reduced search space), successfully performing a brute-force scan of an entire /64 network would be infeasible. " When I first read this, I immediately agreed that performing a brute-force attach on a /64 network would be infeasible. But then I started to reflect on why it would be so infeasible? Computers are getting faster, and NICs have more capacity, so their ability to create faster mappings scales in relation. Do we have current research numbers to state how long it takes to do a brute force scan of a /64? I think referencing research would go a long way to convincing readers of this statement. "Unfortunately, a number of IPv6 implementations have been found to be unable to properly handle large number of entries in the Neighbor Cache, and hence these address-scan attacks may have the side effect of resulting in a Denial of Service (DoS) attack [CPNI-IPv6] [I-D.ietf-v6ops-v6nd-problems]." It might be worth mentioning that stateful devices in the network path, like firewalls, will track neighbour cache and connection information. Since these values are so much larger in IPv6, these intermediate devices are also subject to such DoS vulnerabilities. I am new to providing feedback on IETF documentation. So let me know if I've missed the mark on this email. I don't know the exact format or procedures for providing this feedback but I thought there would be no harm in emailing the authors directly with my thoughts. Regards, Rama -- Rama Darbha, CCIE#28006 919-574-5071 radarbha@cisco.com Cisco TAC - Security Solutions RTP, NC, USA Hours: 8h30 - 17h00 (EST) http://www.cisco.com/tac/ From internet-drafts@ietf.org Thu Nov 8 07:53:45 2012 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 46DB121F850A; Thu, 8 Nov 2012 07:53:45 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fLmsoB0801b; Thu, 8 Nov 2012 07:53:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90C321F84EA; Thu, 8 Nov 2012 07:53:44 -0800 (PST) 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.36 Message-ID: <20121108155344.21609.69598.idtracker@ietfa.amsl.com> Date: Thu, 08 Nov 2012 07:53:44 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-01.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, 08 Nov 2012 15:53:45 -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 : Operational Security Considerations for IPv6 Networks Author(s) : Kiran Kumar Chittimaneni Merike Kaeo Eric Vyncke Filename : draft-ietf-opsec-v6-01.txt Pages : 40 Date : 2012-11-08 Abstract: Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded best common practices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-v6-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-v6-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gert@space.net Fri Nov 9 05:52:37 2012 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 5C99B21F85C0 for ; Fri, 9 Nov 2012 05:52:37 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7LFXDqAZs3b for ; Fri, 9 Nov 2012 05:52:36 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id B3A1421F84C6 for ; Fri, 9 Nov 2012 05:52:35 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4DAE26029E for ; Fri, 9 Nov 2012 14:52:34 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 2E5EC60150 for ; Fri, 9 Nov 2012 14:52:34 +0100 (CET) Received: (qmail 56812 invoked by uid 1007); 9 Nov 2012 14:52:34 +0100 Date: Fri, 9 Nov 2012 14:52:34 +0100 From: Gert Doering To: Rama Darbha Message-ID: <20121109135234.GH13776@Space.Net> References: <50987BAF.60909@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50987BAF.60909@cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsec@ietf.org Subject: Re: [OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning 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, 09 Nov 2012 13:52:37 -0000 Hi, On Mon, Nov 05, 2012 at 09:53:35PM -0500, Rama Darbha wrote: > When I first read this, I immediately agreed that performing a > brute-force attach on a /64 network would be infeasible. But then I > started to reflect on why it would be so infeasible? Computers are > getting faster, and NICs have more capacity, so their ability to create > faster mappings scales in relation. Do we have current research numbers > to state how long it takes to do a brute force scan of a /64? Basic math. If you can send 1000 packets/sec without being noticed, scanning 2^64 addresses will take about 584942417 *years*. If you can send a million packets/sec, it will only take 584942 years, though... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From ietf@meetecho.com Sat Nov 10 12:16:57 2012 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 BF0E221F8622 for ; Sat, 10 Nov 2012 12:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq7JmcHzoZoQ for ; Sat, 10 Nov 2012 12:16:57 -0800 (PST) Received: from smtpdg7.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3C27A21F85AA for ; Sat, 10 Nov 2012 12:16:57 -0800 (PST) Received: from [192.168.0.4] ([151.77.98.23]) by smtpcmd03.ad.aruba.it with bizsmtp id MwGr1k00Y0WGHKK01wGuFe; Sat, 10 Nov 2012 21:16:55 +0100 Message-ID: <509EB62F.8070004@meetecho.com> Date: Sat, 10 Nov 2012 21:16:47 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSEC] Meetecho session recording 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: Sat, 10 Nov 2012 20:16:57 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From radarbha@cisco.com Fri Nov 16 14:51:46 2012 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 E2A6921F8669 for ; Fri, 16 Nov 2012 14:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm-8DuNS4jkp for ; Fri, 16 Nov 2012 14:51:34 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFBA21F866F for ; Fri, 16 Nov 2012 14:51:33 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAGMpWpS012608; Fri, 16 Nov 2012 17:51:32 -0500 (EST) Received: from dhcp-10-150-53-202.cisco.com (dhcp-10-150-53-202.cisco.com [10.150.53.202]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAGMpVgH004765; Fri, 16 Nov 2012 17:51:31 -0500 (EST) Message-ID: <50A6C373.1020804@cisco.com> Date: Fri, 16 Nov 2012 17:51:31 -0500 From: Rama Darbha User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Gert Doering References: <50987BAF.60909@cisco.com> <20121109135234.GH13776@Space.Net> In-Reply-To: <20121109135234.GH13776@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning 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, 16 Nov 2012 22:51:46 -0000 Gert, Good point. Now that you explain it, my concerns below sound irrelevant. Thanks! - Rama On 11/9/12 8:52 AM, Gert Doering wrote: > Hi, > > On Mon, Nov 05, 2012 at 09:53:35PM -0500, Rama Darbha wrote: >> When I first read this, I immediately agreed that performing a >> brute-force attach on a /64 network would be infeasible. But then I >> started to reflect on why it would be so infeasible? Computers are >> getting faster, and NICs have more capacity, so their ability to create >> faster mappings scales in relation. Do we have current research numbers >> to state how long it takes to do a brute force scan of a /64? > Basic math. If you can send 1000 packets/sec without being noticed, > scanning 2^64 addresses will take about 584942417 *years*. > > If you can send a million packets/sec, it will only take 584942 years, > though... > > Gert Doering > -- NetMaster -- Rama Darbha, CCIE#28006 919-574-5071 radarbha@cisco.com Cisco TAC - Security Solutions RTP, NC, USA Hours: 8h30 - 17h00 (EST) http://www.cisco.com/tac/ From gvandeve@cisco.com Tue Nov 27 04:34:46 2012 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 AF70A21F84CA; Tue, 27 Nov 2012 04:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.597 X-Spam-Level: X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e0gqJ+5-IwM; Tue, 27 Nov 2012 04:34:46 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E1D2021F84C7; Tue, 27 Nov 2012 04:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3506; q=dns/txt; s=iport; t=1354019686; x=1355229286; h=from:to:cc:subject:date:message-id:mime-version; bh=jilI+d7J8hhH5BQ1OYKseTxSsgjdK4brZ32gpHpdPB8=; b=JlEH27V66sOS8q8dGB0dlcyrl/7j+rQDxILQuQJmlu2hCgYJLxSGrIxu B5uCCwLk7nmJfAGK6gETaISpFxE/GL0hm1GvtWoyxNG2bCmCcXwbz0jcE 3zz/vzgCmkexP+aLTArjtl986GGEowVGeaLRrV/e+K749cQQMpa8CKllf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngLADOytFCtJXG8/2dsb2JhbABEgkmDGbpFgQIHgiABBB0QTBIBDB5WJgEEDg2IBQywGJBMjD6DVWEDlx2PKIJvgWgXHg X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146607396" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 27 Nov 2012 12:34:45 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qARCYjPG023820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 12:34:45 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:34:44 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" Thread-Index: Ac3Mmyvmk7+I5HczQcyRUdYsnOR6pw== Date: Tue, 27 Nov 2012 12:34:43 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C8326B7@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.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "dhc@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" , "savi@ietf.org" Subject: [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" 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: Tue, 27 Nov 2012 12:34:46 -0000 --_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, During IETF85 meeting this draft was found useful as WG document by the OPS= EC WG. This is a call for WG adoption of this work. Please voice your comments in = OPSEC WG email alias. Latest document: http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-sh= ield/ Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

During IETF85 meeting this draft was found useful as= WG document by the OPSEC WG.

 

This is a call for WG adoption of this work. Please = voice your comments in OPSEC WG email alias.

 

Latest document: http://datatracker.ietf.org/doc/dra= ft-gont-opsec-dhcpv6-shield/

 

Kind Regards,

OPSEC chairs

--_000_67832B1175062E48926BF3CB27C49B240C8326B7xmbalnx12ciscoc_-- From gvandeve@cisco.com Tue Nov 27 04:40:01 2012 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 A374821F84C7 for ; Tue, 27 Nov 2012 04:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH9sOWcYtTjV for ; Tue, 27 Nov 2012 04:40:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E624921F8233 for ; Tue, 27 Nov 2012 04:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3334; q=dns/txt; s=iport; t=1354020001; x=1355229601; h=from:to:subject:date:message-id:mime-version; bh=ONKxkSU7APZmZZaM/9yN4JvdQxHpyvD8ON7dp39PrEI=; b=GQ71QJNIHPzkBJDl/WAxCcROuBGAKgo9mwd7KaE7HGJq+7vhJJ8JfjsB c4QFNu6KjNxQIo8irHhoKD4JTqN209HoLfnFq9jtsiHRSggKPConVvABv xhEAKz9mi9CIPsFZMr6eaZ2oXJdAr5utWgb+w7RbsAB0ZaVYMUZ9Syqyb Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncLAH2ztFCtJXG//2dsb2JhbABEgkmDGbpFgQIHgiABBB0QXgEMHlYmAQQbiAUMnwqRDZBKjD6DVWEDlx2PKIJvgWg1 X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146651103" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 27 Nov 2012 12:40:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qARCe0Uv032713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 27 Nov 2012 12:40:00 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:40:00 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: WG LC for addoption of as WG item: http://tools.ietf.org/html/draft-jdurand-bgp-security-02 Thread-Index: Ac3MnBjuwGCjHWQySiChJAfIFURpxQ== Date: Tue, 27 Nov 2012 12:39:59 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C8326E4@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.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C8326E4xmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [OPSEC] WG LC for addoption of as WG item: http://tools.ietf.org/html/draft-jdurand-bgp-security-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: Tue, 27 Nov 2012 12:40:02 -0000 --_000_67832B1175062E48926BF3CB27C49B240C8326E4xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, During IETF85 meeting this draft was found useful as WG document by the OPS= EC WG. This is a call for WG adoption of this work. Please voice your comments in = OPSEC WG email alias. If no major issues are suggested, then this document will be adopted as OPS= EC WG item. Latest document: http://tools.ietf.org/html/draft-jdurand-bgp-security-02 Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C8326E4xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

During IETF85 meeting this draft was found useful as= WG document by the OPSEC WG.

 

This is a call for WG adoption of this work. Please = voice your comments in OPSEC WG email alias.

If no major issues are suggested, then this document= will be adopted as OPSEC WG item.

 

Latest document: http://tools.ietf.org/html/draft-jd= urand-bgp-security-02

 

Kind Regards,

OPSEC chairs

 

--_000_67832B1175062E48926BF3CB27C49B240C8326E4xmbalnx12ciscoc_-- From gvandeve@cisco.com Tue Nov 27 04:44:55 2012 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 2BC0821F84F6; Tue, 27 Nov 2012 04:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3IQodLIZejn; Tue, 27 Nov 2012 04:44:54 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0921F8530; Tue, 27 Nov 2012 04:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4183; q=dns/txt; s=iport; t=1354020294; x=1355229894; h=from:to:cc:subject:date:message-id:mime-version; bh=oax3ZHETYu6ufC9I/umISwezdwXYOHgE/Kmmrdd/XXA=; b=IXvkFWcWyyIqifGwG1G/KKkk9Rf5+1Aq6HkfgU1nbqiHDpzFc+y3iXs+ 3bZEDMafL/FeFpxMFL1MeRVQRklvaNYtKujGZbUVlDLiBrIrONF42xKmK sIdTs4ORiaBokArD1kub2i3JLTwBRa776gWfGNPWHO3qBTxNSxNz8/oEs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsLAIG0tFCtJXG9/2dsb2JhbABEgkmDGbEwiRWBAgeCGgYBBB0QTBIBKlYmAQQODYVBB4IfHgywGZBKkBNhA5cdjyiCb4Id X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146612011" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 27 Nov 2012 12:44:53 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qARCirLI026089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 12:44:53 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:44:53 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Call for WG adoption - Network Reconnaissance in IPv6 Networks Thread-Index: Ac3MnIXJcUynRZMASfCNcCJaERG/Rg== Date: Tue, 27 Nov 2012 12:44:52 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C8326F5@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.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: [OPSEC] Call for WG adoption - Network Reconnaissance in IPv6 Networks 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: Tue, 27 Nov 2012 12:44:55 -0000 --_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear, Please find this request for WG adoption for "Network Reconnaissance in IPv= 6 Networks" This work is to update RFC5157. Please speak to voice your opinion. Latest draft can be found at: http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning-02 Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear,

 

Pleas= e find this request for WG adoption for “= Network Reconnaissance in IPv6 Networks”

This = work is to update RFC5157. Please speak to voice your opinion.

=  

Lates= t draft can be found at:

http://tools.ietf.org/html/draft-gont-opsec-ipv6-= host-scanning-02

 

Kind Regards,

OPSEC chairs

--_000_67832B1175062E48926BF3CB27C49B240C8326F5xmbalnx12ciscoc_-- From gvandeve@cisco.com Tue Nov 27 04:57:34 2012 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 5031B21F8466; Tue, 27 Nov 2012 04:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzUXmG3ENNBc; Tue, 27 Nov 2012 04:57:33 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF421F8464; Tue, 27 Nov 2012 04:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2993; q=dns/txt; s=iport; t=1354021053; x=1355230653; h=from:to:cc:subject:date:message-id:mime-version; bh=nw2fSZKySjIWdNobkVNo4pL1xE//gg5S1kjzc6S0xyM=; b=hOggX5QD1fVcOirpl1jquKw9szHq9eY03uEa1Uucet8PJNF3TgMkR7G8 6x6rXUBhP0N0flYjEi9erMLnvzwd5de1xM5b+kdZGOq5E2o/mO+yKB46k asJwwVDeJaG2aUw8nL6wgS8T5BbpDVN0tPN7u4owSqpi0WNQSfypYdw5d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkLAAS4tFCtJV2a/2dsb2JhbABEgkmDGbpFgQIHgiABBB0QTBIBDB4ZPSYBBA4NiAUMsB2QS5ATYQOXHY8ogm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146396834" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 27 Nov 2012 12:57:33 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qARCvXwM004704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 12:57:33 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.216]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 06:57:32 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks Thread-Index: Ac3Mnk8XCC7UKWxNT+OWDCCme2iK1A== Date: Tue, 27 Nov 2012 12:57:32 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C832724@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.86.72] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: [OPSEC] Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks 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: Tue, 27 Nov 2012 12:57:34 -0000 --_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find this call as result of IETF85 OPSEC meeting for WG adoption for document http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages/ Please speak out during the next 2 weeks on your opinion to adopt within OP= SEC or not adopt. Kind Regards, OPSEC chairs --_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Please find this call as result of IETF85 OPSEC meet= ing for WG adoption for

document http://datatracker.ietf.org/doc/draft-gont-= opsec-vpn-leakages/

 

Please speak out during the next 2 weeks on your opi= nion to adopt within OPSEC or not adopt.

 

Kind Regards,

OPSEC chairs

--_000_67832B1175062E48926BF3CB27C49B240C832724xmbalnx12ciscoc_-- From gert@space.net Tue Nov 27 05:03:56 2012 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 6219521F8472 for ; Tue, 27 Nov 2012 05:03:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM8rsVepQa8n for ; Tue, 27 Nov 2012 05:03:55 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id C361D21F84C4 for ; Tue, 27 Nov 2012 05:03:54 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7EB786038B for ; Tue, 27 Nov 2012 14:03:53 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5CC2160137 for ; Tue, 27 Nov 2012 14:03:53 +0100 (CET) Received: (qmail 21665 invoked by uid 1007); 27 Nov 2012 14:03:53 +0100 Date: Tue, 27 Nov 2012 14:03:53 +0100 From: Gert Doering To: "Gunter Van de Velde \(gvandeve\)" Message-ID: <20121127130353.GH19111@Space.Net> References: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsec@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] [v6ops] Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks 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: Tue, 27 Nov 2012 13:03:56 -0000 Hi, On Tue, Nov 27, 2012 at 12:57:32PM +0000, Gunter Van de Velde (gvandeve) wrote: > Please find this call as result of IETF85 OPSEC meeting for WG adoption for > document http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages/ > > Please speak out during the next 2 weeks on your opinion to adopt within OPSEC or not adopt. Adopt. Useful operational security considerations -> opsec. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From aservin@lacnic.net Tue Nov 27 06:26:15 2012 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 CD4B021F86D4 for ; Tue, 27 Nov 2012 06:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCPb0yQ0kEFz for ; Tue, 27 Nov 2012 06:26:15 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5423E21F84D7 for ; Tue, 27 Nov 2012 06:26:14 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:f904:aeae:640a:62b8]) by mail.lacnic.net.uy (Postfix) with ESMTP id B98F630841C for ; Tue, 27 Nov 2012 12:26:08 -0200 (UYST) Message-ID: <50B4CD7E.4080903@lacnic.net> Date: Tue, 27 Nov 2012 12:26:06 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: opsec@ietf.org References: <67832B1175062E48926BF3CB27C49B240C8326F5@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240C8326F5@xmb-aln-x12.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [OPSEC] Call for WG adoption - Network Reconnaissance in IPv6 Networks 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: Tue, 27 Nov 2012 14:26:16 -0000 I support WG adoption of draft-gont-opsec-ipv6-host-scanning-02. There are some comments that I have and I will send them later, however their are not in opposition to wg adoption. Regards, as On 27/11/2012 10:44, Gunter Van de Velde (gvandeve) wrote: > Dear, > > > > > Please find this request for WG adoption for “Network Reconnaissance > in IPv6 Networks” > > > This work is to update RFC5157. Please speak to voice your opinion. > > > > > > Latest draft can be found at: > > http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning-02 > > > > Kind Regards, > > OPSEC chairs > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From j.schoenwaelder@jacobs-university.de Wed Nov 28 00:58:01 2012 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 05E6321F8536 for ; Wed, 28 Nov 2012 00:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5XnbHQdLlqr for ; Wed, 28 Nov 2012 00:58:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4580721F8815 for ; Wed, 28 Nov 2012 00:58:00 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21B9B20A9B; Wed, 28 Nov 2012 09:57:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jZHWmSQwjgfe; Wed, 28 Nov 2012 09:57:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC70F20A6D; Wed, 28 Nov 2012 09:57:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 06A1F2310F1D; Wed, 28 Nov 2012 09:58:04 +0100 (CET) Date: Wed, 28 Nov 2012 09:58:04 +0100 From: Juergen Schoenwaelder To: opsec@ietf.org Message-ID: <20121128085804.GA99802@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 08:58:01 -0000 Hi, I took a look at draft-gont-opsec-dhcpv6-shield-01.txt and in general the subject seems reasonably well explained. I am wondering, however, why this is called "DHCPv6-Shield" while it seems the more established term for this type of functionality is "DHCP Snooping" on IPv4 networks. I am also not sure whether there is actually a document defining DHCP snooping for IPv4 networks, the I-D mentions IPv4 DHCP snooping but provides no reference. If there is no specification of DHCP snooping, I am wondering whether the scope of this document should not be DHCP snooping in general, that is covering both IPv4 and IPv6 DHCP snooping. Editorial nits: - item 4. talks about RA-Guard, probably a cut-n-paste error. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Wed Nov 28 05:19:28 2012 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 8F0E421F84BA for ; Wed, 28 Nov 2012 05:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oNlvhuEQxNu for ; Wed, 28 Nov 2012 05:19:27 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53EFF21F8521 for ; Wed, 28 Nov 2012 05:19:27 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so5020645eaa.31 for ; Wed, 28 Nov 2012 05:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ajU7YEZRMsfTuc61w+fPNDnyjBNFF5h3fVS21rg4Jlk=; b=YqVwEcfOE3Pz191ZF/b5KrVkVtc8U54LNTBRFpxRiQqZWQiaPovHudaLJjj3DyaZuo dHa8+y1B+7GVDXzcpwQoIdZNdA0dOw5j/g0t42TuZbM1xN6saZQNnP3l6JI2yxa+8SjF MvoUET/0B1QsK0JUrbYMOARM+TUiK96Mx/lep8ptIQR4659Br4PmhV4KoVONrjmlPTHO WQqtmoIA6SPn9BIoNmkas8vuYccoJhTCtUAsC2PP66JArqYD6/N1PZ2dzIUfgwoaffoR hiuMJEapTu7FFZNJepwr4xGUAoUot7DUotv8ho0JpFynDSEsCsGc0NKO/XAXMDXBMJ5P NUCQ== Received: by 10.14.209.193 with SMTP id s41mr32237501eeo.9.1354108766458; Wed, 28 Nov 2012 05:19:26 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-221.as13285.net. [2.102.217.221]) by mx.google.com with ESMTPS id d44sm47022239eeo.10.2012.11.28.05.19.23 (version=SSLv3 cipher=OTHER); Wed, 28 Nov 2012 05:19:24 -0800 (PST) Message-ID: <50B60F63.90800@gmail.com> Date: Wed, 28 Nov 2012 13:19:31 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-ietf-opsec-v6.all@tools.ietf.org References: <20121108155344.21609.69598.idtracker@ietfa.amsl.com> In-Reply-To: <20121108155344.21609.69598.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-01.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: Wed, 28 Nov 2012 13:19:28 -0000 Hi, Some comments (but this is not a full review). > 2.1.2. Use of ULAs > > ULAs are intended for scenarios where IP addresses will not have > global scope. The implicit expectation from the RFC is that all ULAs > will be randomly created as /48s. However, in practice some > environments have chosen to create ULAs as a /32. You should point out that this practice completely violates RFC 4193 and greatly reduces the probability of non-collision between ULA prefixes. I am frankly amazed that anyone would do it. BTW you need a reference to RFC 4193 in the text. > While ULAs can be > useful for infrastructure hiding You could refer to RFC 4864 here. Actually, there are many places in this draft where you could refer to RFC 4864. > (as they force the use of address > translation to reach the Internet), Absolutely wrong. The idea is that you would use ULAs for internal traffic and simultaneously use a global address for external traffic. > it may create an issue in the > future if the decision at some point is to make the machines using > ULAs globally reachable. This would require renumbering No, no, no. It would requiring giving such hosts (and only such hosts) a global (PI or PA) address. That is standard operating procedure for IPv6. > or perhaps > even stateful IPv6 Network Address and Port Translation (IPv6 NAPT -- > not an IETF work item). No, no, no. It would be possible (but is not recommended) to run stateless NPTv6 (RFC 6296) for outbound access, but there is never a reason to run translation for inbound access. > The latter would be problematic in trying to > track specific machines that may source malware although this is less > of an issue if appropriate logging is done which includes utilizing > accurate timestamps and logging a node's source ports [RFC6302]. > > The use of ULA does not isolate 'by magic' the part of the network > using ULA from other parts of the network (including the Internet). > Routers will happily forward packets whose source or destination > address is ULA as long as they have a route to the destination and > there is no ACL blocking those packets. Again, please read and refer to RFC 4193: The default behavior of exterior routing protocol sessions between administrative routing regions must be to ignore receipt of and not advertise prefixes in the FC00::/7 block. A network operator may specifically configure prefixes longer than FC00::/7 for inter-site communication. You are correct that there is no magic, but border routers MUST filter ULA prefixes. That filter, or an equivalent ACL, is mandatory. > 2.1.3. Point-to-Point Links > > [RFC3627] indicates that the use of a /64 is the best solution for > point-to-point links while a /112 can be used if that's not > possible. RFC 3627 is obsolete and historic - you should only mention it to say so (see RFC 6547). This whole paragraph should be rewritten to discuss RFC 6164 only. > 2.1.4. Privacy Extension Addresses I think it is better to use the correct terminology from RFC 4941: "Temporary Addresses". > Since MAC addresses for specific > vendor equipment can be know, it may be easy for a potential attacker > to perform a more directed intelligent scan to try and ascertain > specific vendor device reachability for exploitation. Privacy > extensions attempts to mitigate this threat. That is misleading. This mitigation is a side-effect of temporary addresses; the design motivation was to protect user privacy. > As privacy extensions could also be used to hide illegal and unsavory > activities, privacy extensions addresses can be assigned, audited, > and controlled in managed enterprise networks via DHCPv6. How? Where is that described? How is privacy ensured if an address is assigned by DHCP? > 2.3.3. Packet Exceptions ... > o processing of the hop-by-hop extension header. See > [I-D.krishnan-ipv6-hopbyhop] Expired draft. > On some routers, not everything can be done by the specialized data > plane hardware which requires some packets to be 'punted' to the > generic RP. This could include for example the processing of a long > extension header chain in order to apply an ACL based on layer 4 > information. You probably need to look at draft-ietf-6man-oversized-header-chain and expand this text. Also look at draft-carpenter-6man-ext-transmit which discusses another aspect of the problem, with discussion of what firewalls should do. > 2.6.2. Transition Mechanisms ... > To mitigate the bypassing of security policies, it could be helpful > to block all default configuration tunnels by denying all IPv4 > traffic matching: This is too simple and discourages baby steps towards IPv6. A better statement would be: - If offering IPv6 service to end-users, there is no need for 6-in-4 tunnels of any kind, so they can be blocked. - If not offering IPv6 service to end-users, a specific decision is needed about which tunneling mechanism will be available for early adopters; that can be allowed, others can be blocked. > 2.6.2.4. 6to4 ... > They suffer from several technical issues as well as security issues > [RFC3964]. Their use is no longer recommended (see > [I-D.ietf-v6ops-6to4-to-historic]). That draft was dropped after IETF Last Call and is officially dead, so the sentence is inaccurate. Replacement: Client usage of 6to4 by default is now discouraged, and significant precautions are needed to avoid operational problems [RFC6343]. >From a security PoV, that RFC notes: However, it should be noted that if an operator provides well-managed servers and relays for 6to4, non-encapsulated IPv6 packets will pass through well- defined points (the native IPv6 interfaces of those servers and relays) at which security mechanisms may be applied. In other words, operating 6to4 correctly reduces security risks, compared with ignoring it. > 3.2. Internal Security Considerations: ... > Automated IPv6-in-IPv4 tunnels (see Section 2.6.2) should also be > blocked to avoid bypassing the IPv4 security policy. Again, too simple, see my above comment under "Transition Mechanisms". Regards Brian Carpenter From jeanmichel.combes@gmail.com Wed Nov 28 08:06:54 2012 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 87F9C21F88C9; Wed, 28 Nov 2012 08:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU81GbwdBJNo; Wed, 28 Nov 2012 08:06:53 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8821F8821; Wed, 28 Nov 2012 08:06:52 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6544465vbb.31 for ; Wed, 28 Nov 2012 08:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fq561Uv544RjXy3tG6gepy0rWKCeDjcRzyghTNbcmA4=; b=ViJyvONAEX0TD3c+ejxWyxeI9+VUyXBdI/ICZ0B7bQkyq/6TA3cVlpJacaQtKAJPdc Q/SYXkaFU82JOSUeO2CK3rx5ACzVK0IxI7pkEJ0QinqTeZ6oyJ2Mjl6z9pbsVZGSWpPn MLYKwbffaG9l5VsHoZ/4ewFkEiCDRDa41GDC40poug1+h4jaVTd0mxRhsvg8TAbJxiHQ vzJiPzN+jWjQxCjuMlTox1n8iFJLdKjww/TGDPvcbydOmBNYjdzMKW3z65zmruWbm2Pn YXOWZdHXcGqn1tQvds+HeSkqcuG62N7qeBGmeO1tIzdNTfa2SeEw5F6kT14N5yWnxUut DIkQ== MIME-Version: 1.0 Received: by 10.52.29.141 with SMTP id k13mr25171647vdh.131.1354118812274; Wed, 28 Nov 2012 08:06:52 -0800 (PST) Received: by 10.221.7.9 with HTTP; Wed, 28 Nov 2012 08:06:52 -0800 (PST) In-Reply-To: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B240C8326B7@xmb-aln-x12.cisco.com> Date: Wed, 28 Nov 2012 17:06:52 +0100 Message-ID: From: Jean-Michel Combes To: "Gunter Van de Velde (gvandeve)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dhc@ietf.org" , "opsec@ietf.org" , "savi@ietf.org" , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Poll for WG adoption of "draft-gont-opsec-dhcpv6-shield" 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: Wed, 28 Nov 2012 16:06:54 -0000 Hi, >From my point of view, this document doesn't compete with SAVI works (i.e., SAVI goals are to prevent IP address spoofing, using address assignment/management protocols signaling). Now, with DHCP SAVI (cf. https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/), we have the same feature, but with less details (i.e., process to identify a DHCPv6 message is not described in DHCP SAVI). As I already told during OPSEC meetings, DHCP Shield may be necessary in environment where DHCP SAVI is not deployed. Moreover, DHCP SAVI may use the process described in this document when performing DHCP signaling filtering. Unlike RA Guard, which only provides a mitigation (i.e., if you want a strong security, SEND is the right solution), there is a real need for DHCP Shield because, IMHO, there is no strong security for DHCP signaling today (PSK based security, currently specified, is not usable from a scalability point of view and CGA based security needs that DHCP clients must know the DHCP servers' IP unicast addresses). So, I support the adoption of this document as WG document. Best regards. JMC. 2012/11/27 Gunter Van de Velde (gvandeve) : > Hi folks, > > > > During IETF85 meeting this draft was found useful as WG document by the > OPSEC WG. > > > > This is a call for WG adoption of this work. Please voice your comments in > OPSEC WG email alias. > > > > Latest document: > http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-shield/ > > > > Kind Regards, > > OPSEC chairs > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From jschiel@flowtools.net Thu Nov 29 21:26:25 2012 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 1296121F841B for ; Thu, 29 Nov 2012 21:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh9BOJ3Mf6jr for ; Thu, 29 Nov 2012 21:26:24 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84821F8201 for ; Thu, 29 Nov 2012 21:26:24 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so138298ieb.31 for ; Thu, 29 Nov 2012 21:26:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=xWadFvX7bA4Ff85qAH6iF1d7AqDhoK0J+QZkaeuaJxo=; b=JK+fDL6xKAHm3EtxINanp4Y+zhVhHNMrari+uTVkfqJ/SyzkepEGe1vHjqGC58AMFe vwOQ8dbFuUu/BvG2gvjsquBRKFZ60lLFMd/OdwSj2otXCZn5oybA4LB8jmUhxl9c1RzK rVHxFSzQC3V3t/BuiDGaTiJfmm+vlIccobFaPMpxvCXqnfioWX0avNlVQ9OzWoaZYhgP BeRTbs3Lke9hz9frMN6UksKEG7JEFYjZ8HhGHA8eRbz11zXnr9vLKHoID4nNOaltWEnD FPc2RKfL3ekwjGEKjqR4kInwDQRWjEzOTiFkretcRezRknuOUCnpyQj6m7Xl/6XpCzAJ UvDg== MIME-Version: 1.0 Received: by 10.42.22.198 with SMTP id p6mr96472icb.17.1354253183567; Thu, 29 Nov 2012 21:26:23 -0800 (PST) Received: by 10.50.20.131 with HTTP; Thu, 29 Nov 2012 21:26:23 -0800 (PST) X-Originating-IP: [63.227.55.100] In-Reply-To: <67832B1175062E48926BF3CB27C49B240C8326F5@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B240C8326F5@xmb-aln-x12.cisco.com> Date: Thu, 29 Nov 2012 22:26:23 -0700 Message-ID: From: John Schiel To: "Gunter Van de Velde (gvandeve)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkuv2pUKFFAoYOtDqa3Gjc7ge2l3sXutgNjpTSX/ziN88qXU48/cANVatSdYbR5g0Fpld51 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Call for WG adoption - Network Reconnaissance in IPv6 Networks 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, 30 Nov 2012 05:26:25 -0000 A few nits: * Third paragraph in the introduction, "One one hand". Perhaps "On one hand= " ? * Title of section 2 should be fully bolded, missing bold on 'Techniques' * 3.1.1.4. Stable Privacy-Enhanced Addresses In response to the predictability issues discussed in Section 3.1.1.1 and the privacy issues discussed in , the IETF is currently ** (discussed in what,3.1.1.2? ) --John On Tue, Nov 27, 2012 at 7:26 AM, Arturo Servin wrote: > > I support WG adoption of draft-gont-opsec-ipv6-host-scanning-02. > > There are some comments that I have and I will send them later, h= owever > their are not in opposition to wg adoption. > > Regards, > as > > > On 27/11/2012 10:44, Gunter Van de Velde (gvandeve) wrote: >> Dear, >> >> >> >> >> Please find this request for WG adoption for =93Network Reconnaissance >> in IPv6 Networks=94 >> >> >> This work is to update RFC5157. Please speak to voice your opinion. >> >> >> >> >> >> Latest draft can be found at: >> >> http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning-02 >> >> >> >> Kind Regards, >> >> OPSEC chairs >> >> >> >> _______________________________________________ >> 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 On Tue, Nov 27, 2012 at 5:44 AM, Gunter Van de Velde (gvandeve) wrote: > Dear, > > > > Please find this request for WG adoption for =93Network Reconnaissance in= IPv6 > Networks=94 > > This work is to update RFC5157. Please speak to voice your opinion. > > > > Latest draft can be found at: > > http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning-02 > > > > Kind Regards, > > OPSEC chairs > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From fgont@si6networks.com Fri Nov 30 14:47:21 2012 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 5106121F84E1 for ; Fri, 30 Nov 2012 14:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqA6hYzyog1T for ; Fri, 30 Nov 2012 14:47:20 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id BF7A521F84C6 for ; Fri, 30 Nov 2012 14:47:20 -0800 (PST) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TeZM2-0004ne-8D; Fri, 30 Nov 2012 23:47:07 +0100 Message-ID: <50B9348D.5030108@si6networks.com> Date: Fri, 30 Nov 2012 19:34:53 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Schiel References: <67832B1175062E48926BF3CB27C49B240C8326F5@xmb-aln-x12.cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: [OPSEC] Feedback on draft-gont-opsec-ipv6-host-scanning-02 (was Re: Call for WG adoption - Network Reconnaissance in IPv6 Networks) 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, 30 Nov 2012 22:47:21 -0000 Hi, John, Thanks so much for your feedback! Please find my comments in-line.... On 11/30/2012 02:26 AM, John Schiel wrote: > A few nits: > > * Third paragraph in the introduction, "One one hand". Perhaps "On one hand" ? Yep. Fixed! > * Title of section 2 should be fully bolded, missing bold on 'Techniques' This is an artifact of the tools at http://tools.ietf.org which d the automatic conversion from TXT to HTML (I will report this to the tool authors) -- the source itself (TXT) does not support formatting: > * 3.1.1.4. Stable Privacy-Enhanced Addresses > > In response to the predictability issues discussed in Section 3.1.1.1 > and the privacy issues discussed in , the IETF is currently ** > (discussed in what,3.1.1.2? ) I'd say "draft-ietf-6man-stable-privacy-addresses". Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492