From kkumar@google.com Thu Jul 5 15:10:09 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 92B6821F86B5 for ; Thu, 5 Jul 2012 15:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m-b9ODkDKhd for ; Thu, 5 Jul 2012 15:10:09 -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 99ADE21F8663 for ; Thu, 5 Jul 2012 15:10:08 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so13582685lbb.31 for ; Thu, 05 Jul 2012 15:10:22 -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=8V+TbPiBs5DgfRLhAw9wdWwmSGmoTPSAO7tfy6IIKLc=; b=WJjftncO9W5TphXYEyWuwumfi87bddGIrokiqQ+kATnt2rCzm917sOZYmyJcX7w3U2 MtuGCe2q8rgPrqrH63Auz9VrFYBj8CpUdRKz42PFU7l5WU0TE0m0j5dn8lD+7rsd957W REvqD/3wwAMLPIBSfCjwjCoCAJCcm6Ty/EmaL7IjkqzrKi50zk1VGb+L2bpdlCcD9cOo WtUZoQwba3Nz0QGKlSwW6M78uvQFO8Z6CYmq0jkvqsN6GnGG6Vhf8kzpme28lbh8HJPU zkXDsHYO9myyPiSMJiT44VZqxoXiXHLYDiNjUCm0OgLEUfT9O2wnLtZTuXTutw6cNvtg /ubQ== 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=8V+TbPiBs5DgfRLhAw9wdWwmSGmoTPSAO7tfy6IIKLc=; b=EJi17e+FDxvKb/7TVHPeziF1qr80DkSGkeTJjyHBv4WFisyUiOLIB915mMDYEqbCIE vF1UQK6MJ2DL70A49uDhyCFXWB635CxyvRqJK/4tfF1BG2CQioTNh69fHTWiZjyMBKu1 Io95QvRVKSydSHGhZ/NIXkCU5zsM0eDacNDLASPPP+ekLEP8vMaTHJ6rQ0RM/TMKumNx yA4mgPzCOu0S+yMryh22Tgi9rZ00P1Bkgmb30NWAbc7thQ1DaGg5VuV6pNTswSey4t3Z Yar5meANRla0EdxrUTJvDPgIbIXae1xSRNikDbB4cpXmT7ppjhoiJakxeTTUuIboNUIA 8DjQ== Received: by 10.112.29.233 with SMTP id n9mr12644691lbh.91.1341526222413; Thu, 05 Jul 2012 15:10:22 -0700 (PDT) Received: by 10.112.29.233 with SMTP id n9mr12644686lbh.91.1341526222294; Thu, 05 Jul 2012 15:10:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.63.165 with HTTP; Thu, 5 Jul 2012 15:10:02 -0700 (PDT) From: KK Date: Thu, 5 Jul 2012 15:10:02 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=f46d04016b03efd03204c41c6952 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkcJ/BuOuI8eTQWltADmJ/9lws31GWAzJdsSme+JQR2B7A0vCyQaOHMmgYfYXuczlINWwfgDuScCGwYN+GYlQHcgqONTFeD/ds/Su31WJrvp82C9Vqs+y/ePzh6bhOxC+8cPPIwulam8K90xxeobCh/TWeLnzovU28xBWQnh3OVXmmtyK8= Subject: [OPSEC] Session Scheduled 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, 05 Jul 2012 22:10:09 -0000 --f46d04016b03efd03204c41c6952 Content-Type: text/plain; charset=ISO-8859-1 Just a quick FYI - ---------- Forwarded message ---------- Dear Gunter Van de Velde, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. opsec Session 1 (2:00:00) Monday, Afternoon Session I 1300-1500 Room Name: Regency E --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: v6ops Second Priority: 6man Special Requests: Remote participation is expected --------------------------------------------------------- --f46d04016b03efd03204c41c6952 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a quick FYI -=A0

---------- Forwarde= d message ----------
Dear Gunter Van de Velde,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

opsec Session 1 (2:00:00)
=A0 =A0 Monday, Afternoon Session I 1300-1500
=A0 =A0 Room Name: Regency E
=A0 =A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name:
Area Name:
Session Requester:

Number of Sessions: 1
Length of Session(s): =A02 Hours
Number of Attendees: 100
Conflicts to Avoid:
=A0First Priority: v6ops
=A0Second Priority: 6man



Special Requests:
=A0 Remote participation is expected
---------------------------------------------------------

--f46d04016b03efd03204c41c6952-- From abdussalambaryun@gmail.com Sat Jul 7 05:02:40 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 95DEF21F8629; Sat, 7 Jul 2012 05:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, DEAR_SOMETHING=1.605, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woSmBy6vL1gT; Sat, 7 Jul 2012 05:02:36 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A411221F8596; Sat, 7 Jul 2012 05:02:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7180893vbb.31 for ; Sat, 07 Jul 2012 05:02:54 -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=yuiP59dEvncHK3ydzVGqErSq7xVJFNxbF85ei0c9z0g=; b=fSY627+OXrtv5EqEg/IaKYJh+QGG+AV9L6Mq1X+ZcNKLhJKPTeTeBl3AhXRkLfKar+ OPlZgeBzfpiPq4Ez5yC1uTpaHiOZ20S61wwl38rhvHQF65LUILpjOjpBEo32xH+Krfbi JAq5A7DB3slzybXqsj84sMi5acVYW4QAfr92QetrJhlUowAcURHZJkKhZZ5f2KGY91zN WUEolxDjmAumITKdV2H3GJFL0sJrh+av++LEGADVTTOjmJtEtLhrPi6xIPnOuSMe70C/ q5yGn2N1xjyM+3gegAuxHK7ySUr6ACvWCA88WeDWmhmmoXmBeLSoUR+l3d42CyL4+x7c UYqA== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr13657353vdb.10.1341662574357; Sat, 07 Jul 2012 05:02:54 -0700 (PDT) Received: by 10.220.110.130 with HTTP; Sat, 7 Jul 2012 05:02:54 -0700 (PDT) Date: Sat, 7 Jul 2012 14:02:54 +0200 Message-ID: From: Abdussalam Baryun To: ietf Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 07 Jul 2012 08:35:30 -0700 Cc: kitten@ietf.org, websec@ietf.org, ipsec@ietf.org, opsec@ietf.org, "iesg@ietf.org" , sidr@ietf.org, stephen.farrell@cs.tcd.ie, hokey@ietf.org, karp@ietf.org Subject: [OPSEC] IETF Technology Terminology and Protocol Implications 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, 07 Jul 2012 12:02:41 -0000 Dear Sir or Madam, I suggest for terminology-documents in WGs to consider the security terms that are related to WG, and terms implication for security considerations. Security consideration section as required by RFC2223 (section-9), which can be used to define things. For example the approach was used in RFC2119 and in the I-D [AB]. Regarding RFCs that specify protocols, I suggest they mention in the security consideration section additionally to the protocol security implication also the related works of security WGs in IETF. This will build interaction between WGs and will help the readers and users. What do you think? please advise or comment, thanking you, References: [RFC2223] http://www.ietf.org/rfc/rfc2223.txt [RFC2119] http://www.ietf.org/rfc/rfc2119.txt [AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt Yours Faithfully, Abdussalam Baryun University of Glamorgan, UK ***************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any other purpose, nor disclose, nor distribute its contents to any other person. ***************************************************************************** From evyncke@cisco.com Wed Jul 18 07:34:05 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 89E0421F8797; Wed, 18 Jul 2012 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 oa7UyG9lVgUF; Wed, 18 Jul 2012 07:34:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9A24D21F8798; Wed, 18 Jul 2012 07:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=4015; q=dns/txt; s=iport; t=1342622095; x=1343831695; h=from:to:cc:subject:date:message-id:mime-version; bh=VXzsKwxg/ElBA5bbs+wzPgNOb50K7OxlisgVtKGxVqU=; b=WGUUu/+PFhGbu71CINJe8qfjVBfiNUG+hsYeUBonqhle2i3TFoYkoFGc Im+td9RzoAtvMeNY7SjwwjVnr7aH9OV57hcowr2u4qXrau+Ja5LLQu62k ZqFkdDEtt0VLf3oJJuaJ38kkmVL94GFbN9h+JtUrWz8hqTshrtjNlJb/w I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAAnJBlCtJXG+/2dsb2JhbABFgkqtZwGJAYEHgiIBBBIBGkwSAQweGT0mAQQBDQ0ah2sLnXCgF5EvYAOIGI4/jRCBZoJf X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208,217";a="103050281" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2012 14:34:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6IEYsQK008666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 14:34:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 09:34:54 -0500 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org WG" , "opsec@ietf.org" Thread-Topic: New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks) Thread-Index: Ac1k8n6y0ZuVpdOPQS+AAZ9+CBbUHw== Date: Wed, 18 Jul 2012 14:34:53 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--25.474200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_" MIME-Version: 1.0 Subject: [OPSEC] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for 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: Wed, 18 Jul 2012 14:34:05 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have posted a new version of our draft draft-vyncke-opsec-v6 at: http://tools.ietf.org/html/draft-vyncke-opsec-v6-01 As usual comments are welcome, at Paris, comments were 'yes this is require= d'. BTW, the intent is not to write 100's of pages but rather document exis= ting I-D and good practices. Best regards -merike, kk and =E9ric --_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We have posted a new versio= n of our draft draft-vyncke-opsec-v6 at:

http://tools.ietf.org/html/draft-vynck= e-opsec-v6-01

 

As usual comments are welco= me, at Paris, comments were ‘yes this is required’. BTW, the in= tent is not to write 100’s of pages but rather document existing I-D and good practices.

 

Best regards

 

-merike, kk and =E9ric=

 

--_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_-- From fgont@si6networks.com Thu Jul 19 05:54:50 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 5A5F521F8738; Thu, 19 Jul 2012 05:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4h5xiWJVG-M; Thu, 19 Jul 2012 05:54:49 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 728E521F8736; Thu, 19 Jul 2012 05:54:49 -0700 (PDT) Received: from bl10-131-211.dsl.telepac.pt ([85.243.131.211] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SrqGX-0001LD-A3; Thu, 19 Jul 2012 14:55:37 +0200 Message-ID: <5007643C.9050003@si6networks.com> Date: Thu, 19 Jul 2012 02:34:52 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" References: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" , "opsec@ietf.org" Subject: Re: [OPSEC] [v6ops] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for 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: Thu, 19 Jul 2012 12:54:50 -0000 Hi, Eric (et al), I think this document is filling an existing gap. Thanks for writing it! I've begun to read your I-D. I'll be sending some feedback in batches, since it will likely result in more timely feedback. Abstract: I wouldn't go as far as saying that "RFC 4942 describes the security issues in the protocol". Introduction: The I-D says "Network Address and Port Translation [RFC3022] has lead to the common feeling that NATPT equals security and with IPv6 NATPT is no more needed." A side effect of NATPT is that the *device* ends up operating as a stateful firewall that only allows return traffic. I'd personally find it challenging (?) to find a term for which one could claim "X equals security" (since there are many aspects of security, which can hardly be addressed by a single "device"). However, I'd note that there are security properties in firewalls (which a NATPT ends up acting as, as a side effect). Regarding "IPv6 NATPT", I seem to recall that it already ships with Linux? Nits: Section 2.1.1: "Once an address allocation has been assigned" This doesn't seem to parse well. Section 2.1.1: You should probably clarify that, when talking about "manually configured addresses", you're talking about devices (e.g. routers) that typically have their addresses manually-configured, and *not* encouraging manually-configured addresses in general devices. Section 2.1.2: I don't recall the details of the discussion regarding ULAs, but would guess that some have probably argued that they may make troubleshooting painful? Section 2.1.3: This section should probably reference draft-ietf-v6ops-v6nd-problems, since using /112 also works as a workaround for buggy implementations that fail to properly manage the Neighbor Cache. Some slideware I've used recently (e.g. , ) might be of help, too. Section 2.1.4: This section should reference RFC4941 rather than RFC3041. You may want to reference draft-gont-opsec-ipv6-host-scanning. Nit: s/know/known/ This section says "Privacy addressing attempts to mitigate this threat". However, privacy addresses are typically (*) configured *in addition* to IEEE-derived IIDS -- hence they do not mitigate the host scanning problem. draft-ietf-6man-stable-privacy-addresses does, since they are meant to replace the IEEE-derived IIDs. (*) with the notable exception of OpenBSD, which removes IEEE-derived IIDs when privacy addresses are enabled. This section says "While privacy addresses are truly generated randomly to protect against user tracking, but assuming that nodes use the EUI-64 format for global addressing, a list of expected pre-authorized host addresses can be generated." I don't follow... for outgoing connections, hosts would employ privacy addresses, so... Section 2.2: Nits: s/relied/relies/ s/not he/on the/ Section 2.2.1: You should probably note the many reasons for which SEND is challenging to deploy (PKI, not widely implemented, etc.) Additionally, as noted in draft-ietf-6man-nd-extension-headers, if you end up relying on fragmentation (which you shouldn't!), it could be possible for an attacker to circumvent SEND. Section 2.2.2: You may want to look at/reference: draft-gont-opsec-dhcpv6-shield. Section 2.2.3: Nit: s/DOS/DoS/ Section 2.2.4: The I-D says "However, several evasion techniques that circumvent the protection provided by RA Guard have surfaced. A key challenge to this mitigation technique is introduced by IPv6 fragmentation." Note that for existing implementations, you do not even need to use fragmentation: these RA-Guard implementations simply expect the ICMPv6 to follow the fixed IPv6 header -- hence simply including any IPv6 extension header is enough to circumvent them. [I-D.gont-6man-nd-extension-headers] should now be [I-D.ietf-6man-nd-extension-headers] ;-) Ok, 2:33 AM... more on this later.... ;-) Cheers, Fernando On 07/18/2012 03:34 PM, Eric Vyncke (evyncke) wrote: > We have posted a new version of our draft draft-vyncke-opsec-v6 at: > > http://tools.ietf.org/html/draft-vyncke-opsec-v6-01 > > > > As usual comments are welcome, at Paris, comments were ‘yes this is > required’. BTW, the intent is not to write 100’s of pages but rather > document existing I-D and good practices. > > > > Best regards > > > > -merike, kk and éric > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From pkampana@cisco.com Fri Jul 20 13:36:04 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 0645F11E8088 for ; Fri, 20 Jul 2012 13:36:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA9clQFXanUY for ; Fri, 20 Jul 2012 13:36:01 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF911E8080 for ; Fri, 20 Jul 2012 13:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=11007; q=dns/txt; s=iport; t=1342816618; x=1344026218; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9SA/Xs7M2Zh7XlEukJ4KYcjHpmXQjViFCM9bz5oFIaI=; b=eYDx8CZOKWqZcSLtQI+FRhLBKtnJbMs0WXtAcMLj+FJtAuNxq5lvbsZr P8uxMNQEwjtoobAWW4sjuHyi/J5roAqeP67PAs2BWAGviaWb+ErMA07SA wa85DdyAp4Asjh+DMmXUSTws7OUm4LfHQCnHX9fQcuilHAE7gbjqeaTj4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFABbBCVCtJXHA/2dsb2JhbABFgkquEAGIdYEHgiABAQEEEgEaOiICAQgRBAEBCxkEBzIUCQgBAQQBEggah2sLnlWgHYtOhgBgA4gYjkCNEYFmgl8 X-IronPort-AV: E=Sophos;i="4.77,626,1336348800"; d="scan'208,217";a="103926712" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 20 Jul 2012 20:36:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6KKawxV006438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Jul 2012 20:36:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.17]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 15:36:57 -0500 From: "Panos Kampanakis (pkampana)" To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" Thread-Topic: [OPSEC] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks) Thread-Index: Ac1k8n6y0ZuVpdOPQS+AAZ9+CBbUHwBv1ArQ Date: Fri, 20 Jul 2012 20:36:56 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7502512E@xmb-rcd-x10.cisco.com> References: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.89.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19054.001 x-tm-as-result: No--36.150200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_1C9F17D1873AFA47A969C4DD98F98A7502512Exmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [OPSEC] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for 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, 20 Jul 2012 20:36:04 -0000 --_000_1C9F17D1873AFA47A969C4DD98F98A7502512Exmbrcdx10ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Eric, This draft is indeed needed. I haven't reviewed the whole draft yet, but here are some comments/suggesti= ons: - 2.1.4. Privacy Addresses could mention draft-gont-opsec-ipv6-host-scanni= ng that explains some concerns even when using DHCPv6 or privacy addresses. - 2.2. Link Layer Security could mention ND cache DoS concerns and protect= ion - 2.2.1. SeND and CGA could mention the limitation of vendor support that = makes SeND challenging to deploy widely - 2.3. Control Plane Security mentions rate-limiting of the valid packets = should be done for Mgmnt and Control Plane. A spoofed legit source could st= ill cause DoS effect on the control and management plane, even when rate-li= miting is enabled. The device will still be alive, but the services could s= till see outages. That I think would be valuable to be pointed out as a con= sideration - 2.6.3.1. Carrier Grade Nat (CGN) could mention the log size concern and = draft-donley-behave-deterministic-cgn that alleviates it. - 3.1. External Security Considerations: could mention "Implement Anti-Spo= of filtering or other Anti-Spoof protections". Anti-Spoof filtering could b= e ACLs. But RTBH could also be implemented if BGP is used on the CPE. - 3.2. Internal Security Considerations: can mention "filtering IPv6 Tunne= ling that can bypass outbound security policy" (the usual Torrent over Tere= do tunnel example in Section 5). Thank you, Panos From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of E= ric Vyncke (evyncke) Sent: Wednesday, July 18, 2012 10:35 AM To: v6ops@ietf.org WG; opsec@ietf.org Subject: [OPSEC] New updated version of draft-vyncke-opsec-v6-01 (Operation= al Security Considerations for IPv6 Networks) We have posted a new version of our draft draft-vyncke-opsec-v6 at: http://tools.ietf.org/html/draft-vyncke-opsec-v6-01 As usual comments are welcome, at Paris, comments were 'yes this is require= d'. BTW, the intent is not to write 100's of pages but rather document exis= ting I-D and good practices. Best regards -merike, kk and =E9ric --_000_1C9F17D1873AFA47A969C4DD98F98A7502512Exmbrcdx10ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Eric,=

 

This draft is indeed n= eeded.

 

I haven’t review= ed the whole draft yet, but here are some comments/suggestions:

 

- 2.1.4.  Privacy Addresses could mention draft-gont-opsec-ipv6-host-scanning that explains s= ome concerns even when using DHCPv6 or privacy addresses.

- 2.2.  Link Layer Security could mention ND cache DoS concerns and protection

- 2.2.1.  SeND and CGA could mention the limitation of vendor= support that makes SeND challenging to deploy widely

- 2.3.  Control Plane Security mentions rate-limiting of the valid pa= ckets should be done for Mgmnt and Control Plane. A spoofed legit source co= uld still cause DoS effect on the control and management plane, even when r= ate-limiting is enabled. The device will still be alive, but the services could still see outages. That I thin= k would be valuable to be pointed out as a consideration<= /p>

- 2.6.3.1.  Carrier Grade Nat (CGN) could mention the log size concern and draft-donley-beh= ave-deterministic-cgn that alleviates it.

- 3.1.  External Security Considerations: could mention “Implement Anti-Sp= oof filtering or other Anti-Spoof protections”. Anti-Spoof filtering = could be ACLs. But RTBH could also be implemented if BGP is used on the CPE= .

- 3.2.  Internal Security Considerations: can mention “filtering IPv6 Tunneling that ca= n bypass outbound security policy” (the usual Torrent over Teredo tunnel example in Section 5).

 

Thank you,<= /span>

Panos

 

 

 

From: opsec-bo= unces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: Wednesday, July 18, 2012 10:35 AM
To: v6ops@ietf.org WG; opsec@ietf.org
Subject: [OPSEC] New updated version of draft-vyncke-opsec-v6-01 (Op= erational Security Considerations for IPv6 Networks)

 

We have posted a new version of our draft = draft-vyncke-opsec-v6 at:

http://tools.ietf.org/html/draft-vyncke-opsec-v6-01

 =

As usual comments are welcome, at Paris, c= omments were ‘yes this is required’. BTW, the intent is not to = write 100’s of pages but rather document existing I-D and good practices.

 =

Best regards=

 =

-merike, kk and =E9ric

 =

--_000_1C9F17D1873AFA47A969C4DD98F98A7502512Exmbrcdx10ciscocom_-- From kkumar@google.com Wed Jul 25 11:32:00 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 254A521F86DF for ; Wed, 25 Jul 2012 11:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkjiq0zr-Qzy for ; Wed, 25 Jul 2012 11:31:59 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 858E721F86C1 for ; Wed, 25 Jul 2012 11:31:59 -0700 (PDT) Received: by qaea16 with SMTP id a16so749041qae.10 for ; Wed, 25 Jul 2012 11:31:58 -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=zU6LoyCoCtgak27NgBukw3JgxTmTaDfDJgxilJuUcPs=; b=ggbF3VgDnkTcSaK379THV67Wa1XFz03jwJwIUCH6oGIc3DnShsPYa84GXkfG5hJXXE ilyEnhkDM5ZIi/VWY6N3N8vdbHZ3g64EzDlMpU/jcqZOisp7lddWk90Y8Tb1ZSrwzK0Q fEq0q9SqIkVVFP/Imrv3tPs+P9t6juHBMfeTKjtfeEBXzwxcZBtc0XvuGeswbgYSvmt9 nz6M9xFO49FYS2jINx76GyfGfcLQEbuujKGyr51/6ydGbR00PtIq+8pgoA/ndYuJ77qu 95yaieSRHYaf+QgX99yXPxE4xdXk2b1OPsz7rQmvCUX6TbhJFUNesRrQYn7XkJ7FIXgd e9tA== 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=zU6LoyCoCtgak27NgBukw3JgxTmTaDfDJgxilJuUcPs=; b=GMJ9gAu3dltC9UvKIiDDlaYUS70rMzECAxoPaDz9+VvhfNft5YqpU5hGvrJ8d8anVD dSmFfKMfLb11vwdst8seZyjdxHz5HTdTf6hGorYskH12JbnbkzTG/i1jqLPvWrlqtFEK tCfoTT77TyVNE9iXBpuc9OKsbU5kbYHNIPqbxZWo6J4wCVhno0qx1gCcUlsEY/jShaeV T5DJLWKzgxcyhCFaG8FTCsAUWR+8LtMX8QDtO3QWFlgLLe0V4gaghKBAQbVPoDTw9JnX DxuSL8sPa1Ujhu+TaB9mnLH4s3Q7Z+6Qsv4YHkz+GywnqBaHfYiyiKq80B9slP1o9t5g A7nA== Received: by 10.224.177.1 with SMTP id bg1mr40080659qab.68.1343241118652; Wed, 25 Jul 2012 11:31:58 -0700 (PDT) Received: by 10.224.177.1 with SMTP id bg1mr40080646qab.68.1343241118576; Wed, 25 Jul 2012 11:31:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.135.76 with HTTP; Wed, 25 Jul 2012 11:31:38 -0700 (PDT) From: KK Date: Wed, 25 Jul 2012 11:31:38 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=20cf30334ebbb8701f04c5abb1de X-System-Of-Record: true X-Gm-Message-State: ALoCoQkpqcPZ0gRpKOnBEyMF3sZ/cic3mScRYz5Cx3LpYMhRs/BdAKKO9jhtY3TGKBsY0b+yJqF0gHyAxrMdv4dJ2Mge7P6ttDuen1OutIhE0owhRwWEaOQTw/mQl+NXSWowam1qlIVDjd5tpjT0ZRal4uxxnKT7Qp5Nly2x3tkDC15Cxw7Ggvc= Subject: [OPSEC] OPSEC agenda for IETF84 has been published 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, 25 Jul 2012 18:32:00 -0000 --20cf30334ebbb8701f04c5abb1de Content-Type: text/plain; charset=ISO-8859-1 Hello, The agenda can be found at https://datatracker.ietf.org/meeting/84/agenda/opsec/ It would be greatly appreciated if you could provide the chairs with your presentations no later than EOD Monday. Thanks, Your friendly OPSEC Chairs --20cf30334ebbb8701f04c5abb1de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,


It = would be greatly appreciated if you could provide the chairs with your pres= entations no later than EOD Monday.

Thanks,
Your friendly OPSEC Chairs
--20cf30334ebbb8701f04c5abb1de-- From gvandeve@cisco.com Sun Jul 29 10:21:40 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 8E6F621F873A for ; Sun, 29 Jul 2012 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.993 X-Spam-Level: X-Spam-Status: No, score=-9.993 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 v8xCngrYI6s2 for ; Sun, 29 Jul 2012 10:21:39 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9189C21F848F for ; Sun, 29 Jul 2012 10:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2622; q=dns/txt; s=iport; t=1343582499; x=1344792099; h=from:to:subject:date:message-id:mime-version; bh=X/XwF6TTp0aNT2SqLhgpd6NE5gZzXFxuzM72HUEEhpI=; b=P2x/b07EcdcrR4MuK/EuvbqPqpKAyt+nbLWrPH+QJ3z754vbXePXk08N 2Zz8vTXgqZ/9Ss/f4HGcII2czpvSsEfuvmxDac7LyrDtr3w7RigToth2i rPBUh0U6GICL0NpXtUNl5mmMYMHXGO001p7USAcTnHfphn39eBlPbq/i0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK5vFVCtJXG8/2dsb2JhbABFgkq3FIEHgiIBBBIBGl4BDB5WJgEEGxqHa5hbgSifIZFSYAOjcIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,675,1336348800"; d="scan'208,217";a="106439356" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jul 2012 17:21:39 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6THLdqW022265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 29 Jul 2012 17:21:39 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.132]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Sun, 29 Jul 2012 12:21:38 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Scribe and minute takers volunteers requested Thread-Index: Ac1trlbvEzL74mGWRgmu4qn2t/verQ== Date: Sun, 29 Jul 2012 17:21:37 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2404057F@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.89.226] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19070.004 x-tm-as-result: No--31.375200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B2404057Fxmbalnx12ciscocom_" MIME-Version: 1.0 Subject: [OPSEC] Scribe and minute takers volunteers 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: Sun, 29 Jul 2012 17:21:40 -0000 --_000_67832B1175062E48926BF3CB27C49B2404057Fxmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, For using our time as optimized as possible during the meeting, can I ask f= or volunteers in advance for taking the minutes and scribe? Many thanks, G/ --_000_67832B1175062E48926BF3CB27C49B2404057Fxmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

For using our time as optimized as possible during t= he meeting, can I ask for volunteers in advance for taking the minutes and = scribe?

 

Many thanks,

G/

--_000_67832B1175062E48926BF3CB27C49B2404057Fxmbalnx12ciscocom_-- From simoneng56@gmail.com Sun Jul 29 21:02:27 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 E9DF111E810F for ; Sun, 29 Jul 2012 21:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvsvguQO6V07 for ; Sun, 29 Jul 2012 21:02:27 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57B3011E8106 for ; Sun, 29 Jul 2012 21:02:27 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4441996vcb.31 for ; Sun, 29 Jul 2012 21:02:26 -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:content-type; bh=enho+xUV3inCKOFLE7WrIYMLtFPrf8pGRaBbz9+b7Zs=; b=FwWOuqIgqtgWLdheuOXfW5TU1c1JXO1oaEyJ1pgnBCbeM8rjlGZp11tvbVK6dmlikA 8OZpLvfydbRqb7qu77QY0spoo0aVWZYyEOPPitbKSbd8q7YT4H/c6WFp32NaOwmSLqzv Bd4Kja5ehin3aprgIUyWVQ5ax6Vp3wkJlrNIk9Sgzn6cgWweIrelqZPffVsAXWVPlNdW 9nehMSuni0D6ykmbmddXlo+puqBjRud4oxTor9EWH+kYsknE1xoAdFrg8OIatLthZh9j Nw/RjX7G5+q/ZXhhaee/NL0gAA99Fa87GZDD1vlQJKqBDc2ylwSpixgqdAPwet8VGusk FimA== MIME-Version: 1.0 Received: by 10.220.218.133 with SMTP id hq5mr9532438vcb.60.1343620946851; Sun, 29 Jul 2012 21:02:26 -0700 (PDT) Received: by 10.58.29.82 with HTTP; Sun, 29 Jul 2012 21:02:26 -0700 (PDT) Date: Mon, 30 Jul 2012 12:02:26 +0800 Message-ID: From: Simon Eng To: opsec@ietf.org Content-Type: multipart/alternative; boundary=14dae9cfc7703ff8ea04c6042114 Subject: [OPSEC] Security Implications of IPv6 on IPv4 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: Mon, 30 Jul 2012 04:04:48 -0000 --14dae9cfc7703ff8ea04c6042114 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a few thoughts after reading the draft. a) In Section 2, attacks related to Layer 2 (e.g. IPv6 Router Advertisements) are mentioned discussed. In my humble opinion, in networks meant for IPv4 only (but with IPv6 turned on), Layer 2 attacks/mis-configurations will be the greatest to carry out. Perhaps more can be used to discuss ICMPv6 traffic filtering (especially since it will replace other Layer 2 protocols, such as ARP) and also other relevant Layer 2 protocols? b) DNS security is not mentioned (e.g. turning off AAAA). It may be good to discuss the implications of enabling default IPv6 on for DNS deployment. Since Section 2 & 3 describes more about Layer 2 & 3 respectively, perhaps a new Section 4 on "Application/Others" can discuss about DNS or even DHCPv6 filtering? Regards. Simon Eng (simon_sg_eng@nyp.gov.sg) "Question to learn, learn to question." --14dae9cfc7703ff8ea04c6042114 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0I have a few thoughts after reading the draft.=

a) In Section 2, attacks related to Layer 2 (e.g.= IPv6 Router Advertisements) are mentioned discussed.=A0=A0In my humble opi= nion, in=A0networks meant for=A0IPv4 only (but with IPv6 turned on), Layer = 2 attacks/mis-configurations will be the greatest to carry out. =A0Perhaps = more can be used to discuss ICMPv6 traffic filtering (especially since it will replace other Layer 2 protocols, such as ARP) and also other relevant Layer 2 protocols?<= /p>


b)=A0DNS sec= urity is not mentioned (e.g. turning off AAAA). It may be good to discuss t= he implications of enabling default IPv6 on for DNS deployment. =A0Since Se= ction 2 & 3 describes more about Layer 2 & 3 respectively, perhaps = a new Section 4 on "Application/Others" can discuss about DNS or = even DHCPv6 filtering?


Regards.


Simon Eng (simon_sg_eng@nyp.gov.sg)

"Question to learn, learn to question."=

--14dae9cfc7703ff8ea04c6042114-- From fgont@si6networks.com Sun Jul 29 23:27:35 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 0454D11E8130 for ; Sun, 29 Jul 2012 23:27:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl1xtTIp6Y1i for ; Sun, 29 Jul 2012 23:27:34 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7030611E812F for ; Sun, 29 Jul 2012 23:27:34 -0700 (PDT) Received: from [2001:df8:0:64:5e26:aff:fe33:7063] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SvjRz-0005k0-RR; Mon, 30 Jul 2012 08:27:32 +0200 Message-ID: <5016292D.8000500@si6networks.com> Date: Mon, 30 Jul 2012 03:26:53 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Simon Eng References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 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: Mon, 30 Jul 2012 06:27:35 -0000 Hi, Simon, Thanks so much for your feedback! -- Please find my comments inline... On 07/30/2012 01:02 AM, Simon Eng wrote: > a) In Section 2, attacks related to Layer 2 (e.g. IPv6 Router > Advertisements) are mentioned discussed. In my humble opinion, > in networks meant for IPv4 only (but with IPv6 turned on), Layer 2 > attacks/mis-configurations will be the greatest to carry out. Perhaps > more can be used to discuss ICMPv6 traffic filtering (especially since > it will replace other Layer 2 protocols, such as ARP) and also other > relevant Layer 2 protocols? Do you mean mentioning things like RA-guard, ND-Shield, and DHCPv6-Shield? Or something else? > b) DNS security is not mentioned (e.g. turning off AAAA). It may be good > to discuss the implications of enabling default IPv6 on for DNS > deployment. Are you referring to enabling AAAA queries? Or something else? > Since Section 2 & 3 describes more about Layer 2 & 3 > respectively, perhaps a new Section 4 on "Application/Others" can > discuss about DNS or even DHCPv6 filtering? Yep, this is a possible way to go... although in the specific case of DHCPv6-filtering, one my want to discuss it along RA-filtering (RA-guard), since they complement each other... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gvandeve@cisco.com Mon Jul 30 10:45: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 695F121F8663 for ; Mon, 30 Jul 2012 10:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 buly+DtSIl8i for ; Mon, 30 Jul 2012 10:45:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B13A821F8661 for ; Mon, 30 Jul 2012 10:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=5453; q=dns/txt; s=iport; t=1343670333; x=1344879933; h=from:to:subject:date:message-id:mime-version; bh=A6ivqLNyxD80pcyC4fOYJhMXSHwTy8Yba+3RTU5+B+0=; b=jUJnD9/cA5oLJBpzG3sd3uAh9QatbuCKAPLn6MwrjZxTzy2hQFlOzVMs FRKGWOVkR+4hdh+8KFtEyVr18kqCl+4WIWEdyo6COx2thgEloL2LXRo9S u5gAd75ehPbt1lOIB1H0ICZm8xbIrwvQ8obB3H+7CM6OiUoNl7xFTpbL+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJLHFlCtJXG+/2dsb2JhbABFgkq3CYEHgiABAQEDARIBChBRDQEqHSgRFBIBBBMIDA6HXAMGBguZO4EoligNiUoEimiHEWADk3WMXoMdgWaCXw X-IronPort-AV: E=Sophos;i="4.77,681,1336348800"; d="scan'208,217";a="106725720" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2012 17:45:33 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6UHjXSj019211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jul 2012 17:45:33 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.132]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 12:45:32 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Need volunteers for NOMCOM Thread-Index: Ac1uewocrxyN4v35Q92WfvGOpyOO1g== Date: Mon, 30 Jul 2012 17:45:31 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B24042CE6@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.21.147.61] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19070.006 x-tm-as-result: No--22.066300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B24042CE6xmbalnx12ciscocom_" MIME-Version: 1.0 Subject: [OPSEC] Need volunteers for NOMCOM 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: Mon, 30 Jul 2012 17:45:34 -0000 --_000_67832B1175062E48926BF3CB27C49B24042CE6xmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >We are currently looking for volunteers to serve on the 2012-2013 NomCom. >As you know, the success of the NomCom process depends crucially on >having a large pool of volunteers from throughout the IETF community. >In particular, it is valuable for the pool of volunteers to have strong >representation from all of the technical areas within the IETF. > >I understand that not all IETF participants read the IETF announce list >frequently. Therefore, if you would be willing to inform active >participants in your working groups about this year's call for NomCom >volunteers, I would greatly appreciate it. > >The NomCom 2012-2013 Call for Volunteers is open until this Sunday, >August 5. Details can be found at: >https://datatracker.ietf.org/ann/nomcom/49851/ > >Thank you for your help, >- Matt Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org --_000_67832B1175062E48926BF3CB27C49B24042CE6xmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>We are currently looking for volunteers to se= rve on the 2012-2013 NomCom.

>As you know, the success of the NomCom proces= s depends crucially on

>having a large pool of volunteers from throug= hout the IETF community.

>In particular, it is valuable for the pool of= volunteers to have strong

>representation from all of the technical area= s within the IETF.

> 

>I understand that not all IETF participants r= ead the IETF announce list

>frequently. Therefore, if you would be willin= g to inform active

>participants in your working groups about thi= s year's call for NomCom

>volunteers, I would greatly appreciate it.

> 

>The NomCom 2012-2013 Call for Volunteers is o= pen until this Sunday,

>August 5. Details can be found at:=

>https://datatracker.ietf.org/ann/nomcom/49851/=

> 

>Thank you for your help,

>- Matt Lepinski

>   mlepinski.ietf@gmail.com

>   nomcom-chair@ietf.org

--_000_67832B1175062E48926BF3CB27C49B24042CE6xmbalnx12ciscocom_-- From Donald.Smith@CenturyLink.com Mon Jul 30 16:09:03 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 054F111E80AE for ; Mon, 30 Jul 2012 16:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 0pXGkugytxfz for ; Mon, 30 Jul 2012 16:09:02 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id ED54811E80C5 for ; Mon, 30 Jul 2012 16:09:01 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q6UN8wnt011977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 18:08:59 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7A7621E00BF; Mon, 30 Jul 2012 17:08:52 -0600 (MDT) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 4AE141E00B8; Mon, 30 Jul 2012 17:08:52 -0600 (MDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q6UN7eo4018739; Mon, 30 Jul 2012 18:07:40 -0500 (CDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id q6UN7efm018724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jul 2012 18:07:40 -0500 (CDT) Received: from PDDCWMBXEX501.ctl.intranet ([fe80::409c:426a:5818:95bc]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0283.003; Mon, 30 Jul 2012 17:07:39 -0600 From: "Smith, Donald" To: Fernando Gont , Simon Eng Thread-Topic: [OPSEC] Security Implications of IPv6 on IPv4 Networks Thread-Index: AQHNbgh6B7pl2dqhQUqjS+2XXiVhbZdBwSKAgACxBQY= Date: Mon, 30 Jul 2012 23:07:39 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D04BB6B@PDDCWMBXEX501.ctl.intranet> References: , <5016292D.8000500@si6networks.com> In-Reply-To: <5016292D.8000500@si6networks.com> 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 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 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: Mon, 30 Jul 2012 23:09:03 -0000 This should be NAPT and statefull firewalling. Finally, some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network. The real issue isn't NAT per say, it is the fact that no ports are open on = the outside that easily map to a service on the inside. You have to know which port (external) is open to even begin. So it is the = PAT and the statefull firewall (allow based 5tuple state) that provides thi= s "minimal" level of security. I quote the "minimal" as scan and sploit worms simply don't propagate throu= gh non1:1 PAT and a stateful firewall. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Fernando= Gont [fgont@si6networks.com] Sent: Monday, July 30, 2012 12:26 AM To: Simon Eng Cc: opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks Hi, Simon, Thanks so much for your feedback! -- Please find my comments inline... On 07/30/2012 01:02 AM, Simon Eng wrote: > a) In Section 2, attacks related to Layer 2 (e.g. IPv6 Router > Advertisements) are mentioned discussed. In my humble opinion, > in networks meant for IPv4 only (but with IPv6 turned on), Layer 2 > attacks/mis-configurations will be the greatest to carry out. Perhaps > more can be used to discuss ICMPv6 traffic filtering (especially since > it will replace other Layer 2 protocols, such as ARP) and also other > relevant Layer 2 protocols? Do you mean mentioning things like RA-guard, ND-Shield, and DHCPv6-Shield? Or something else? > b) DNS security is not mentioned (e.g. turning off AAAA). It may be good > to discuss the implications of enabling default IPv6 on for DNS > deployment. Are you referring to enabling AAAA queries? Or something else? > Since Section 2 & 3 describes more about Layer 2 & 3 > respectively, perhaps a new Section 4 on "Application/Others" can > discuss about DNS or even DHCPv6 filtering? Yep, this is a possible way to go... although in the specific case of DHCPv6-filtering, one my want to discuss it along RA-filtering (RA-guard), since they complement each other... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From fgont@si6networks.com Tue Jul 31 02:15:06 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 6730A21F8438 for ; Tue, 31 Jul 2012 02:15:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy7JF9HyxNkW for ; Tue, 31 Jul 2012 02:15:05 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1321F843E for ; Tue, 31 Jul 2012 02:15:04 -0700 (PDT) Received: from [2001:df8:0:64:5e26:aff:fe33:7063] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sw8XW-0007St-Bs; Tue, 31 Jul 2012 11:14:54 +0200 Message-ID: <5017A1E5.1050806@si6networks.com> Date: Tue, 31 Jul 2012 06:14:13 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Smith, Donald" References: , <5016292D.8000500@si6networks.com> <68EFACB32CF4464298EA2779B058889D04BB6B@PDDCWMBXEX501.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D04BB6B@PDDCWMBXEX501.ctl.intranet> X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 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, 31 Jul 2012 09:15:06 -0000 Hi, Donald, Thanks so much for your feedback! Please find my comments in-line... On 07/30/2012 08:07 PM, Smith, Donald wrote: > > This should be NAPT and statefull firewalling. Agreed. -- Will fix this. > Finally, some transition/co-existence mechanisms (notably Teredo) are > designed to traverse Network Address Translators (NATs), which in > many deployments provide a minimum level of protection by only > allowing those instances of communication that have been initiated > from the internal network. > > The real issue isn't NAT per say, it is the fact that no ports are > open on the outside that easily map to a service on the inside. You > have to know which port (external) is open to even begin. And if no communication was ever initiated from the inside, this might simple be "none". > So it is > the PAT and the statefull firewall (allow based 5tuple state) that > provides this "minimal" level of security. > > I quote the "minimal" as scan and sploit worms simply don't propagate > through non1:1 PAT and a stateful firewall. I didn't say "minimal" to mean "worthless", but rather "even if the NAT-PT was deployed for other reasons, it is providing "some" level of security as a result of the (side effect) policy of 'only allow return traffic'" -- maybe I should reword the aforementioned "minimal"? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Donald.Smith@CenturyLink.com Tue Jul 31 07:19:43 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 8D07B21F86F1 for ; Tue, 31 Jul 2012 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 BK2i3al1yMZh for ; Tue, 31 Jul 2012 07:19:43 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id E248521F86EC for ; Tue, 31 Jul 2012 07:19:42 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q6VEJePo008181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 09:19:40 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 391CA1E006F; Tue, 31 Jul 2012 08:19:35 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 1CCF41E004E; Tue, 31 Jul 2012 08:19:35 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q6VEJYrA004134; Tue, 31 Jul 2012 08:19:34 -0600 (MDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q6VEJYrY004116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 08:19:34 -0600 (MDT) Received: from PDDCWMBXEX501.ctl.intranet ([fe80::409c:426a:5818:95bc]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0283.003; Tue, 31 Jul 2012 08:19:34 -0600 From: "Smith, Donald" To: Fernando Gont Thread-Topic: [OPSEC] Security Implications of IPv6 on IPv4 Networks Thread-Index: AQHNbgh6B7pl2dqhQUqjS+2XXiVhbZdBwSKAgACxBQaAARARgP//7+1G Date: Tue, 31 Jul 2012 14:19:34 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D04C094@PDDCWMBXEX501.ctl.intranet> References: , <5016292D.8000500@si6networks.com> <68EFACB32CF4464298EA2779B058889D04BB6B@PDDCWMBXEX501.ctl.intranet>, <5017A1E5.1050806@si6networks.com> In-Reply-To: <5017A1E5.1050806@si6networks.com> 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 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 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, 31 Jul 2012 14:19:43 -0000 Rather than minor I would prefer basic or simple. Thanks for your feed back and responses. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: Fernando Gont [fgont@si6networks.com] Sent: Tuesday, July 31, 2012 3:14 AM To: Smith, Donald Cc: Simon Eng; opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks Hi, Donald, Thanks so much for your feedback! Please find my comments in-line... On 07/30/2012 08:07 PM, Smith, Donald wrote: > > This should be NAPT and statefull firewalling. Agreed. -- Will fix this. > Finally, some transition/co-existence mechanisms (notably Teredo) are > designed to traverse Network Address Translators (NATs), which in > many deployments provide a minimum level of protection by only > allowing those instances of communication that have been initiated > from the internal network. > > The real issue isn't NAT per say, it is the fact that no ports are > open on the outside that easily map to a service on the inside. You > have to know which port (external) is open to even begin. And if no communication was ever initiated from the inside, this might simple be "none". > So it is > the PAT and the statefull firewall (allow based 5tuple state) that > provides this "minimal" level of security. > > I quote the "minimal" as scan and sploit worms simply don't propagate > through non1:1 PAT and a stateful firewall. I didn't say "minimal" to mean "worthless", but rather "even if the NAT-PT was deployed for other reasons, it is providing "some" level of security as a result of the (side effect) policy of 'only allow return traffic'" -- maybe I should reword the aforementioned "minimal"? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492= From Donald.Smith@CenturyLink.com Tue Jul 31 07:36:44 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 47E0721F85CC for ; Tue, 31 Jul 2012 07:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 Dz7bYNkvX9PQ for ; Tue, 31 Jul 2012 07:36:43 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5888421F85C4 for ; Tue, 31 Jul 2012 07:36:43 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id q6VEagSl028387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Jul 2012 08:36:42 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5E4C11E005F; Tue, 31 Jul 2012 08:36:37 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 4170E1E0053; Tue, 31 Jul 2012 08:36:37 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q6VEaasT005524; Tue, 31 Jul 2012 08:36:36 -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 q6VEaar3005520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 08:36:36 -0600 (MDT) Received: from PDDCWMBXEX501.ctl.intranet ([fe80::409c:426a:5818:95bc]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0283.003; Tue, 31 Jul 2012 08:36:37 -0600 From: "Smith, Donald" To: Fernando Gont Thread-Topic: [OPSEC] Security Implications of IPv6 on IPv4 Networks Thread-Index: AQHNbgh6B7pl2dqhQUqjS+2XXiVhbZdBwSKAgACxBQaAARARgP//7+1GgAAEPXA= Date: Tue, 31 Jul 2012 14:36:36 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D04C0B2@PDDCWMBXEX501.ctl.intranet> References: , <5016292D.8000500@si6networks.com> <68EFACB32CF4464298EA2779B058889D04BB6B@PDDCWMBXEX501.ctl.intranet>, <5017A1E5.1050806@si6networks.com>, <68EFACB32CF4464298EA2779B058889D04C094@PDDCWMBXEX501.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D04C094@PDDCWMBXEX501.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 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, 31 Jul 2012 14:36:44 -0000 Right after I said that I remembered this rfc. http://tools.ietf.org/html/rfc6092 Which talks to "simple security" which is nearly the same as what we were d= iscussing. It doesn't rely on NAPT but does provide the stateful and non-stateful fire= walling only allowing traffic thru that was initiated from the "inside". So I recommend "simple" instead of basic or minor :) (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Smith, D= onald Sent: Tuesday, July 31, 2012 8:19 AM To: Fernando Gont Cc: opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks Rather than minor I would prefer basic or simple. Thanks for your feed back and responses. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com ________________________________________ From: Fernando Gont [fgont@si6networks.com] Sent: Tuesday, July 31, 2012 3:14 AM To: Smith, Donald Cc: Simon Eng; opsec@ietf.org Subject: Re: [OPSEC] Security Implications of IPv6 on IPv4 Networks Hi, Donald, Thanks so much for your feedback! Please find my comments in-line... On 07/30/2012 08:07 PM, Smith, Donald wrote: > > This should be NAPT and statefull firewalling. Agreed. -- Will fix this. > Finally, some transition/co-existence mechanisms (notably Teredo) are > designed to traverse Network Address Translators (NATs), which in > many deployments provide a minimum level of protection by only > allowing those instances of communication that have been initiated > from the internal network. > > The real issue isn't NAT per say, it is the fact that no ports are > open on the outside that easily map to a service on the inside. You > have to know which port (external) is open to even begin. And if no communication was ever initiated from the inside, this might simple be "none". > So it is > the PAT and the statefull firewall (allow based 5tuple state) that > provides this "minimal" level of security. > > I quote the "minimal" as scan and sploit worms simply don't propagate > through non1:1 PAT and a stateful firewall. I didn't say "minimal" to mean "worthless", but rather "even if the NAT-PT was deployed for other reasons, it is providing "some" level of security as a result of the (side effect) policy of 'only allow return traffic'" -- maybe I should reword the aforementioned "minimal"? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec=