From fgont@si6networks.com Mon Apr 1 10:59:51 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD161F0D26; Mon, 1 Apr 2013 10:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 dxYYQn2uIUui; Mon, 1 Apr 2013 10:59:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7216C1F0D22; Mon, 1 Apr 2013 10:59:50 -0700 (PDT) Received: from [186.134.3.135] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UMj1H-0003a4-4e; Mon, 01 Apr 2013 19:59:48 +0200 Message-ID: <515985E1.1000404@si6networks.com> Date: Mon, 01 Apr 2013 10:04:33 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com> <51559943.1010703@gmail.com> In-Reply-To: <51559943.1010703@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, ietf@ietf.org Subject: Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC 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, 01 Apr 2013 17:59:51 -0000 Brian, On 03/29/2013 10:38 AM, Brian E Carpenter wrote: > > My minimal request for this draft is for my name to be removed from > the Acknowledgements, as I do not think that my comments have been > acted on. That has been my intent, and I sent a note before publishing one of the latest revs to double-check that (not sure if I missed your respond, or you didn't respond). > In fact, I think that in its current state, this document is harmful > to IPv6 deployment. It in effect encourage sites to fence themselves > into an IPv4-only world. Particularly, it explicitly suggests a > default/deny approach to IPv6-in-IPv4 tunnels, which would prevent > the typical "baby steps" first approach to IPv6 deployment. Sites that implement any kind of security policy employ a "default deny policy" (for the simple reason that it's safer to open holes than explicitly close them). The bottom-line is that if your site enforces any kind of security policy, you should make an explicit decision regarding what you do with v6, rather than being unaware that it's there in your network. > I would like to see the document convey a positive message, suggesting > that an IPv4 site first decides which IPv6 deployment mechanism it > will use, and then configures security appropriately (to allow that > mechanism and block all others). There's an operational gap here: in many cases, operators have no tools to enforce security policies on such tunneled traffic. Besides, when thinking about v6, enterprise networks and the like should be doing native IPv6 (in which case v6 security controls would be enforced throughout the network), rather than having each node go their own way. > A specific aspect of this is that if a site provides one well-managed > 6in4 tunnel mechanism, all tunneled IPv6 packets will pass through > well-defined points where security mechanisms may be applied. In which case you'd be "enforcing IPv6 security controls", which is entirely in-line ith what this document is saying. > We shouldn't imply that not having an IPv6 plan and blocking all IPv6 > by default is a sound strategy. It's not, and I don't think we're implying that. However, I'd note that some people are in the position of blocking traffic, or not doing anything about it. Check for IPv6 support in different security products, and you might get depressed. Cheers, -- 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 Mon Apr 1 11:30:59 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C675211E80E3 for ; Mon, 1 Apr 2013 11:30:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+ujBsoUf1WE for ; Mon, 1 Apr 2013 11:30:58 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9F98C21F8E6A for ; Mon, 1 Apr 2013 11:30:57 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id k5so1364738qej.23 for ; Mon, 01 Apr 2013 11:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=7P1YFlUt1j63pS/8SZPh2Hqu2VkWkoHabYHp/whSWhs=; b=BV3bqMgXwAJSKKS0KYP/UXljPR0Hq3HpYCRdGOeNElFOG7n9ofPoo9Zt5Op4FB3/La NicHya56Rej2MaOvebp/bvWmZ43ixm4p97WaDAuPoGBHiHC1Wvx0LLDMW4+JRAWzIrdz fWnp7PrpH6tqYNntp5/x+9cf+/AARpTHKavYZB+yfVdl2Te7IiqZDPQAvfFGEr2kHA28 dQls0+1zJW9BqWP7arSV0aVBUdB972xp8Mslb9qoh/y+5JFprAekjyvIxzdV6jtYVD8q 5ajq9qHMZXmGedCBL0gfgzGmON5a4a42CgB2jEBk4RrqVikIJFJ13z84c4Jcty0BtSrC O2RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=7P1YFlUt1j63pS/8SZPh2Hqu2VkWkoHabYHp/whSWhs=; b=EFKE1EJLk0Ie5ErKFYpfXUv8wnlTw4CMuLBoy1ngAD/OyQ9QTed7P2XsXDFjpb0WQp rHAgl9syj8sQdBfol2IMwHYvOPObDBWbcJ5PpxI+2rP8ddLFJdI7wi4+QF0y4Kn6tOMy X04LdbsuMeZpLidfX5mJlZ4/igQ4whWkYz4Z+thZXLcDK8LgEDQG5CmgIiaF/D3GwUSH DR8vfol+dD+rYKPVA6DdEKTiz6IX/Vz7RrX+OKmulNu00+N1ydktMLbUIiIOKN2Zn8Fs HKSfDJpXmfW614jf9l38Y7vQ+S7sni61U7dUnZ3nekR6Sy/DfMu6UL0+hc0gjjq854rS /Qlw== X-Received: by 10.224.105.75 with SMTP id s11mr6853400qao.37.1364841053554; Mon, 01 Apr 2013 11:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.106.233 with HTTP; Mon, 1 Apr 2013 11:30:33 -0700 (PDT) In-Reply-To: References: From: KK Date: Mon, 1 Apr 2013 11:30:33 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=20cf3074d35c2c1fbe04d950d271 X-Gm-Message-State: ALoCoQmdYipeuj9U0fT+K7khRH8iUsZYqjLIMBCaOJaf8/8HfVEt2sHGxJYZYqnPaUREhDzDX+6nQoWU+aCqvDhrVxJqnV3AVwfnfJjWbvuoG3DkAciLWDgZdErL8FlAXdQVzi1d/gMyxCY99TOaCw95ISfr2M6SZTOT+XeMx3NItqj4DntJITMNO/tDCV8e9ntbe3+HPqLn Cc: "" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:30:59 -0000 --20cf3074d35c2c1fbe04d950d271 Content-Type: text/plain; charset=ISO-8859-1 Dear OpSec WG, The original link I sent out had an error and was pointing to a different draft, sorry! Here is the corrected link: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ Apologies for the inconvenience. Regards, KK (as Opsec WG co-chair) On Wed, Mar 27, 2013 at 10:48 AM, KK wrote: > * > > Dear OpSec WG, > > This starts a Working Group Last Call for draft-ietf-opsec-bgp-security. > > All three authors have replied, stating that they do not know of any IPR > associated with this draft. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ > > > > Please review this draft to see if you think it is ready for publication > and comments to the list, clearly stating your view. > > This WGLC ends 10-April-2013. > > Thanks, > > KK > > (as OpSec WG co-chair) > > > * > --20cf3074d35c2c1fbe04d950d271 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear OpSec WG,

The original link = I sent out had an error and was pointing to a different draft, sorry!
=


Apologies for the inconvenience.

Regards,
KK
(as = Opsec WG co-chair)


On Wed, Mar 27, 2013 at 10:48 AM, KK <kk@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Dear OpSec WG,


This starts a W= orking Group Last Call for draft-ietf-opsec-bgp-security.

All three authors have replied, stating that they do not kn= ow of any IPR associated with this draft.


The draft is av= ailable here: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-se= curity/


Please review this draft to see if you thi= nk it is ready for publication and comments to the list, clearly stating yo= ur view.


This WGLC ends = 10-April-2013.


Thanks,<= /p>

KK

(as OpSec WG co-chair)




--20cf3074d35c2c1fbe04d950d271-- From wesley.george@twcable.com Mon Apr 1 14:41:56 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC34E21E80D6 for ; Mon, 1 Apr 2013 14:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=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 rEVDF-U+H8Hm for ; Mon, 1 Apr 2013 14:41:52 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7CD111E80F4 for ; Mon, 1 Apr 2013 14:41:51 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,387,1363147200"; d="scan'208,217";a="50360074" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Apr 2013 17:41:34 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Mon, 1 Apr 2013 17:41:51 -0400 From: "George, Wes" To: KK , "opsec@ietf.org" Date: Mon, 1 Apr 2013 17:41:49 -0400 Thread-Topic: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security Thread-Index: Ac4rE2LHnh+evxipSjOqcDCbuHeBKAD8oDlQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4PRVPEXVS15cor_" MIME-Version: 1.0 Cc: "" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:41:56 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 4.1: TCP MD5 (and the resulting reference 2385) is obsoleted. While= I support mentioning it here, because it is still in wide use for many rea= sons, it really shouldn't be used as a normative reference, and the current= text really isn't adequate without recommending AO (instead of MD5) in a b= it stronger terms, especially for a BCP document. It may also be appropriate to reference one or more of the KARP documents, = especially the BGP sections of draft-ietf-karp-routing-tcp-analysis, RFC 65= 18/6862, all of which are concerned with securing the communication of rout= ing protocols (compared with SIDR, which is concerned with securing BGP's s= emantics). 5.1.2.4 - typically I-Ds do not refer to WGs, which tend to be ephemeral, b= ut rather their document output, which is not. While it may not be within t= he scope of this document to discuss the relative level of success that SID= R has achieved in providing new ways to secure BGP, it might be useful to a= t least be clearer on what is in operation today (origin validation) vs sti= ll in progress (path validation), and be clearer about how this dovetails w= ith the other recommendations made in this document. IMO, most of the recom= mendations made in this document stand on their own, and should remain in u= se independent of SIDR's level of deployment, and I think it's useful for t= he document to say this. This document's recommendations are all foundation= al, things that SIDR could eventually build on to improve things further. I= t's ok to assume that the reader is familiar with SIDR, but references shou= ld be provided for the reader to review if they are not. References to 6480= , the bgpsec-reqs and bgpsec-threats documents might be a good start, and p= erhaps even draft-ietf-grow-simple-leak-attack-bgpsec-no-help. Also, "the rest of this section assumes...." This is only a few sentences f= rom the end of the section. Is (or was) there more intended to be added to = this section, or is this sentence misplaced, or what? 5.2.2.1 - inconsistent use of MUST (should be caps?) 8 - this probably needs to discuss the security aspects of an AS migration = and the attending exceptions to some of these rules. A draft is in progress= to document these vendor-specific migration knobs here: draft-ga-idr-as-mi= gration, because while it doesn't necessarily need to be standardized (it's= mostly local to the router where the knobs are turned, is largely transpar= ent to the remote peer, and doesn't need interop) it's pretty important for= things that want to protect the AS-Path from manipulation or spoofing (the= y shouldn't break this legitimate use). Also, the beginning of this sections says "the following rules SHOULD..." b= ut then the 5th bullet says "must" - if the must is not normative, it might= be worth rewording this bullet to eliminate confusion/conflict between the= two normative keywords 10 - rationale for community scrubbing recommendation? 14 - the statement here, while true, is incomplete. Are there security cons= iderations created by implementing any of the things recommended in this do= cument, or open BGP security issues that are not resolved by this document'= s recommendations? Those should be discussed here. One that I can think of = is that many of the items in this draft don't do much to protect against cr= afted-packet attacks that cause the BGP machinery to choke on itself, espec= ially of the zero-day variety. Some of this is implementation-specific (lim= itations on whether you can filter against known vulnerabilities), some of = it is related to the way that the BGP state machine itself deals with error= s, etc. (more on this in draft-ietf-grow-ops-reqs-for-bgp-error-handling) Generally, I support this document. It's really useful to have all of this = in one place, because that's been lacking in the past. However, this is a d= ocument that would benefit from additional operational feedback. I'd encour= age the authors to take the feedback from WGLC, spin an update, and then re= quest review and input on the *NOG lists before this goes to IETF last call= . It's a much wider community than the folks that hang out on opsec, or in = IETF in general, and given the amount of discussion in government-land and = in other interested groups around best practice for securing routing infras= tructure, I can see this being used as a prescriptive tool, so it's in our = best interest to make sure that it's well-vetted and complete. Not to say t= hat the current recommendations don't represent BCP in this space, but I'm = sure that there's stuff that we're forgetting that would be good to add, an= d additional pairs of eyes are more likely to remember some of those things= . Thanks, Wes George From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of K= K Sent: Wednesday, March 27, 2013 1:49 PM To: opsec@ietf.org Cc: Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security Dear OpSec WG, This starts a Working Group Last Call for draft-ietf-opsec-bgp-security. All three authors have replied, stating that they do not know of any IPR as= sociated with this draft. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-op= sec-bgp-security/ Please review this draft to see if you think it is ready for publication an= d comments to the list, clearly stating your view. This WGLC ends 10-April-2013. Thanks, KK (as OpSec WG co-chair) ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 4.1: TCP MD5 (and= the resulting reference 2385) is obsoleted. While I support mentioning it = here, because it is still in wide use for many reasons, it really shouldn’t be used as a normative reference, and the curren= t text really isn’t adequate without recommending AO (instead of MD5)= in a bit stronger terms, especially for a BCP document.<= /p>

 <= /p>

It may also be appropriat= e to reference one or more of the KARP documents, especially the BGP sectio= ns of draft-ietf-karp-routing-tcp-analysis, RFC 6518/6862, all of which are concerned with securing the communication of routing prot= ocols (compared with SIDR, which is concerned with securing BGP’s sem= antics).

 <= /p>

5.1.2.4 – typically= I-Ds do not refer to WGs, which tend to be ephemeral, but rather their doc= ument output, which is not. While it may not be within the scope of this document to discuss the relative level of success that SIDR has ac= hieved in providing new ways to secure BGP, it might be useful to at least = be clearer on what is in operation today (origin validation) vs still in pr= ogress (path validation), and be clearer about how this dovetails with the other recommendations made in th= is document. IMO, most of the recommendations made in this document stand o= n their own, and should remain in use independent of SIDR’s level of = deployment, and I think it’s useful for the document to say this. This document’s recommendations are all fo= undational, things that SIDR could eventually build on to improve things fu= rther. It’s ok to assume that the reader is familiar with SIDR, but r= eferences should be provided for the reader to review if they are not. References to 6480, the bgpsec-reqs and bgpsec-= threats documents might be a good start, and perhaps even draft-ietf-grow-s= imple-leak-attack-bgpsec-no-help.

 <= /p>

Also, “the rest of = this section assumes….” This is only a few sentences from the e= nd of the section. Is (or was) there more intended to be added to  thi= s section, or is this sentence misplaced, or what?

 <= /p>

5.2.2.1 – inconsist= ent use of MUST (should be caps?)

 <= /p>

8 – this probably n= eeds to discuss the security aspects of an AS migration and the attending e= xceptions to some of these rules. A draft is in progress to document these vendor-specific migration knobs here: draft-ga-idr-as-migration, bec= ause while it doesn’t necessarily need to be standardized (it’s= mostly local to the router where the knobs are turned, is largely transpar= ent to the remote peer, and doesn’t need interop) it’s pretty important for things that want to protect the AS-Path fr= om manipulation or spoofing (they shouldn’t break this legitimate use= ).

 <= /p>

Also, the beginning of th= is sections says “the following rules SHOULD…” but then t= he 5th bullet says “must” – if the must is not= normative, it might be worth rewording this bullet to eliminate confusion/conflict between the= two normative keywords

 <= /p>

10 – rationale for = community scrubbing recommendation?

 <= /p>

14 – the statement = here, while true, is incomplete. Are there security considerations created = by implementing any of the things recommended in this document, or open BGP security issues that are not resolved by this document’s= recommendations? Those should be discussed here. One that I can think of i= s that many of the items in this draft don’t do much to protect again= st crafted-packet attacks that cause the BGP machinery to choke on itself, especially of the zero-day variety. Some of = this is implementation-specific (limitations on whether you can filter agai= nst known vulnerabilities), some of it is related to the way that the BGP s= tate machine itself deals with errors, etc.  (more on this in draft-ietf-grow-ops-reqs-for-bgp-error-handlin= g)

 <= /p>

Generally, I support this= document. It’s really useful to have all of this in one place, becau= se that’s been lacking in the past. However, this is a document that would benefit from additional operational feedback. I’d encoura= ge the authors to take the feedback from WGLC, spin an update, and then req= uest review and input on the *NOG lists before this goes to IETF last call.= It’s a much wider community than the folks that hang out on opsec, or in IETF in general, and given the amount = of discussion in government-land and in other interested groups around best= practice for securing routing infrastructure, I can see this being used as= a prescriptive tool, so it’s in our best interest to make sure that it’s well-vetted and complete. N= ot to say that the current recommendations don’t represent BCP in thi= s space, but I’m sure that there’s stuff that we’re forge= tting that would be good to add, and additional pairs of eyes are more likely to remember some of those things.

 <= /p>

Thanks,=

 <= /p>

Wes George

 <= /p>

 <= /p>

From: opsec-bo= unces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of KK
Sent: Wednesday, March 27, 2013 1:49 PM
To: opsec@ietf.org
Cc: <draft-ietf-opsec-bgp-security@tools.ietf.org>
Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security

 

Dear OpSec WG,<= o:p>

 

This starts a Working G= roup Last Call for draft-ietf-opsec-bgp-security.=

All three authors have = replied, stating that they do not know of any IPR associated with this draf= t.

 

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



Please review this draf= t to see if you think it is ready for publication and comments to the list,= clearly stating your view.

 

This WGLC ends 10-April= -2013.

 

Thanks,

KK

(as OpSec WG co-chair)<= /span>

 


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD5923042CFA42B4PRVPEXVS15cor_-- From gvandeve@cisco.com Tue Apr 2 02:11:26 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C521F9892 for ; Tue, 2 Apr 2013 02:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnFXLwGjWixz for ; Tue, 2 Apr 2013 02:11:26 -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 D6DC621F9895 for ; Tue, 2 Apr 2013 02:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1364893886; x=1366103486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qJdfg0qAG1zRsFS9ndDG1fb8EKGuBO+2J/WBPLdDoeg=; b=SSS+3oWsDuikxBw/FiYit+R+6yU3M7uI4LkE0Xe9z28ZKB17+hdZ5fK3 sKnbw1kPGNc3Rs9UAs1Cuk34AoCNpEmwZn0Q4LmULfeb20yzBSHsFnZyj xOHAoLYSP7ROchTIgOPBWqIrA3Y2Zp78wYvNH7awD3f/1cL/WwrmkgDa7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFefWlGtJV2b/2dsb2JhbABAA4M7v0SBAhZ0gh8BAQEDAQEBATc0CwULAgEIEQMBAgsUECcLGwEBBQMCBA4FCBOHcwYMsRKQDI1ogREhBQsHEYJOYQOYCo9sgwuBczU X-IronPort-AV: E=Sophos;i="4.87,392,1363132800"; d="scan'208";a="194005954" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 02 Apr 2013 09:11:25 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r329BP8E024107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 09:11:25 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.138]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 04:11:25 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational Thread-Index: AQHOLxXw3vWrcjE1GEWl9qEmYdf7sZjCpHeQ Date: Tue, 2 Apr 2013 09:11:24 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C8C7837@xmb-aln-x12.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.93.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joel Halpern Subject: [OPSEC] FW: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational 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, 02 Apr 2013 09:11:26 -0000 Dear OPSEC WG, Please take some time to comment upon draft-ietf-karp-ops-model-05. Make take your comments direct to the authors and copy the KARP WG. The KARP working group is designing improvements to the cryptographic authentication of IETF routing protocols. These improvements include improvements to how integrity functions are handled within each protocol as well as designing an automated key management solution. Kind Regards, G/ (OPSEC Co-chair) > From: Brian Weis > Subject: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational > Date: March 26, 2013 5:00:19 PM PDT > To: "karp@ietf.org" >=20 > This begins a two week WG last call to determine if folks will support th= e chairs to submit > > to our AD for publication as an Informational RFC. >=20 > Please send comments of support, or raising issues or concerns, to the WG= email list by 5pm PDT on 9-April-2013. >=20 > Thank you, > Joel M. Halpern > and Brian Weis > co-chairs > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp --=20 Brian Weis Security Engineering, SRG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From brian.e.carpenter@gmail.com Tue Apr 2 02:45:28 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EC921F9858; Tue, 2 Apr 2013 02:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.48 X-Spam-Level: X-Spam-Status: No, score=-101.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, 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 72pC3uAcsPxg; Tue, 2 Apr 2013 02:45:28 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B821F9850; Tue, 2 Apr 2013 02:45:27 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so2972609wiw.0 for ; Tue, 02 Apr 2013 02:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XRgv9LTx9/KXB2UTkDmdxcNEuuw5ZUIgIC8IDRIYeoo=; b=XsF5aKFPjXREIU7Niaa4faHdNrUi7SqZNTqKb3G+p6oUKWNNq4CNBK5KAMrCLr61wJ gOEPzWOLp/SSkn19NaPNuT5NpPuOGHUZYJLcLJHMBfi84I6sIpVSP3nvUnDtai2j29Yj 4DZFqOk9bus7El+wewaUxyVvWXhB1RLOxukZHfWYad1iHxA+cPcg/Mb3EON8OMfc0b6k B+B625JeriNCnv0c2uRYiIwDmdxLJuMHuPP0oLouftjCmnrwALhBMY9O2hLzImzSjsv8 3dAqZE2WtXG5JrZ6N6rNHaodvdjxJv9DLjtiA2B09hqyA4mYPvOVqHtK/HTUmaUvnaXF G5Bw== X-Received: by 10.194.220.70 with SMTP id pu6mr20384298wjc.27.1364895923349; Tue, 02 Apr 2013 02:45:23 -0700 (PDT) Received: from [128.232.110.128] (c128.al.cl.cam.ac.uk. [128.232.110.128]) by mx.google.com with ESMTPS id er1sm17900398wib.5.2013.04.02.02.45.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 02:45:22 -0700 (PDT) Message-ID: <515AA8B4.5020707@gmail.com> Date: Tue, 02 Apr 2013 10:45:24 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com> <51559943.1010703@gmail.com> <515985E1.1000404@si6networks.com> In-Reply-To: <515985E1.1000404@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, ietf@ietf.org Subject: Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC 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, 02 Apr 2013 09:45:28 -0000 Fernando, Rather than repeating myself, I'll suggest a change to the Introduction that would (IMHO) improve the message: OLD: 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. For cases in which the corresponding devices are deployed on networks that are assumed to be IPv4-only, NEW: 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default [RFC6434]. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. As a result, networks will need to plan for and deploy IPv6 and its security mechanisms. Some enterprise networks might, however, choose to delay active use of IPv6. For networks that are assumed to be IPv4-only, It would be nice to refer to draft-ietf-v6ops-enterprise-incremental-ipv6 but I think that is too far from RFC publication to be very useful. Regards Brian On 01/04/2013 14:04, Fernando Gont wrote: > Brian, > > On 03/29/2013 10:38 AM, Brian E Carpenter wrote: >> My minimal request for this draft is for my name to be removed from >> the Acknowledgements, as I do not think that my comments have been >> acted on. > > That has been my intent, and I sent a note before publishing one of the > latest revs to double-check that (not sure if I missed your respond, or > you didn't respond). > > >> In fact, I think that in its current state, this document is harmful >> to IPv6 deployment. It in effect encourage sites to fence themselves >> into an IPv4-only world. Particularly, it explicitly suggests a >> default/deny approach to IPv6-in-IPv4 tunnels, which would prevent >> the typical "baby steps" first approach to IPv6 deployment. > > Sites that implement any kind of security policy employ a "default deny > policy" (for the simple reason that it's safer to open holes than > explicitly close them). The bottom-line is that if your site enforces > any kind of security policy, you should make an explicit decision > regarding what you do with v6, rather than being unaware that it's there > in your network. > > > >> I would like to see the document convey a positive message, suggesting >> that an IPv4 site first decides which IPv6 deployment mechanism it >> will use, and then configures security appropriately (to allow that >> mechanism and block all others). > > There's an operational gap here: in many cases, operators have no tools > to enforce security policies on such tunneled traffic. > > Besides, when thinking about v6, enterprise networks and the like should > be doing native IPv6 (in which case v6 security controls would be > enforced throughout the network), rather than having each node go their > own way. > > >> A specific aspect of this is that if a site provides one well-managed >> 6in4 tunnel mechanism, all tunneled IPv6 packets will pass through >> well-defined points where security mechanisms may be applied. > > In which case you'd be "enforcing IPv6 security controls", which is > entirely in-line ith what this document is saying. > > >> We shouldn't imply that not having an IPv6 plan and blocking all IPv6 >> by default is a sound strategy. > > It's not, and I don't think we're implying that. However, I'd note that > some people are in the position of blocking traffic, or not doing > anything about it. Check for IPv6 support in different security > products, and you might get depressed. > > Cheers, From fgont@si6networks.com Tue Apr 2 18:18:17 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E9A21F85EB for ; Tue, 2 Apr 2013 18:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, J_CHICKENPOX_93=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 Cutl696H-XKN for ; Tue, 2 Apr 2013 18:18:16 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5F621F85DA for ; Tue, 2 Apr 2013 18:18:16 -0700 (PDT) Received: from [186.134.38.231] (helo=[192.168.123.125]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UNCL1-0000VD-Tg; Wed, 03 Apr 2013 03:18:08 +0200 Message-ID: <515B7731.6000506@si6networks.com> Date: Tue, 02 Apr 2013 21:26:25 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: mbehring@cisco.com, "Eric Vyncke (evyncke)" X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-03 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, 03 Apr 2013 01:18:17 -0000 Folks, As promised, here's my review of the aforementioned I-D: * Section 1.: > We propose to configure neither globally routable IPv6 addresses nor > unique local addresses on infrastructure links of routers, wherever > possible. We recommend to use exclusively link-local addresses on > such links. If the document is meant as a discussion of pros and cons, this paragraph should probably be rephrased (since it's actually recommending the use of link-local (only)). * Section 2: > 2. Using Link-Local Address on Infrastructure Links > > This document proposes to use only link-local addresses (LLA) on all > router interfaces on infrastructure links. Same as above. * Section 2: > For an network operator there may be reasons to send > packets to an infrastructure link for certain monitoring tasks; many > of those tasks could also be handled differently, not requiring > routable address space on infrastructure links. Please elaborate, or provide references. * Section 2.1: > These link-local addresses SHOULD be hard-coded to prevent the change > of EUI-64 addresses when changing of MAC address (such as after > changing a network interface card). The need not. PLease see draft-ietf-6man-stable-privacy-addresses (under IETF LC, IIRC). * Section 2.1: > ICMPv6 [RFC4443] error messages (packet-too-big, time-exceeded...) > are required for routers, therefore a loopback interface must be > configured with an IPv6 address with a greater scope than link-local > (this will usually be a global scope). This greater than link-local > scope IPv6 address must be used as the source IPv6 address for all > generated ICMPv6 messages sent to a non link-local address and must > belong to the operator and be part of an announced prefix (with a > suitable prefix length) to avoid being dropped by other routers > implementing [RFC3704]. Does this happen auto-magically? i.e., would the ICMPv6 sending rules and source-address selection RFC agree that such address would be employed (particularly when it doesn't belong to the interface being employed to send the packet)? If it does, you should probably make this explicit and reference the aforementioned RFCs. If it doesn't, then this issue might deserve more text. * Section 2.1: Do most implementations allow the use of this kind of aliases for loopback? (I'm not arguin that they don't, but just asking). * Section 2.1: > o Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM > work by default or can be configured to work with link-local > addresses. Please add informative references for each of these. Additionally, if they don't by default with link-local addresses (as you suggest), it might be useful to provide pointers to relvant documentation that describes how to do so (even if that's just a reference to the corresponding Cisco manual). * Section 2.1: > o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo > request ... can be addressed to loopback addresses of routers with > a greater than link-local scope address. mmm.. not sure what you mean. You meant that such traffic would be directed to the loopback alias you've created? If so, this seems to imply that the aforementioned router implements the Weak ES Model (see Section 3.3.4.1 of RFC 1122). If this doesn't happen automagically, this issue would require further thoughts/elaboration. > Router management can > also be done over out-of-band channels. Does this imply "dial up"? Something else? -- I believe this one (along with troubleshooting) is very important,and requires further elaboration. * Section 2.1: > o ICMP error message can be sourced from a loopback address. They > must not be sourced from link-local addresses when the destination > is non link-local. Same as above. Does this happen automagically? Does this comply with RFC 4443 and the source address selection RFCs? * Section 2.2: > Every routable address on a router > constitutes a potential attack point: a remote attacker can send > traffic to that address, for example a TCP SYN flood, or he can > intent SSH brute force password attacks. We have an RFC about SYN floods (authored by W. Eddy... although I don't recall the number of the top of my head) -- would be good to reference. * Section 2.2: > If a network only uses > loopback addresses for the routers, only those loopback addresses > need to be protected from outside the network. But, if you still need global addresses, and you still need to protect them, does the benefits of this approach outweigh the posible drawbacks (in the management/onitoring and troubleshooting space)? Section 2.2: > Reduced attack surface: Every routable address on a router > constitutes a potential attack point: a remote attacker can send > traffic to that address, for example a TCP SYN flood, or he can > intent SSH brute force password attacks. If a network only uses > loopback addresses for the routers, only those loopback addresses > need to be protected from outside the network. This may ease > protection measures, such as infrastructure access control lists. If > the addressing scheme is set up such that all link addresses and all > loopback addresses are aggregatable, and if the infrastructure access > list covers that entire aggregated space, then changing to link-local > addresses does not reduce the attack surface significantly. Throughout this apragrpah you seem to use "loopback addresses" as referring to the alias (with global scope) that you've added to the loopback interface. If that's the case, it might be could to rephrase the text or add a note about this, since one is mostly used to thing about ::1 or 127.0.0.0/8 when thinking about "loopback addresses". (Proably the correct term for this case would be "global addresses assigned to the loopback interfaces). * Section 2.2: > Lower configuration complexity: LLAs require no specific > configuration (except when they are statically configured), Note that earlier in this document you required these addresses to be statically configured (actually, "hardcoded"). BTW, I think this is the first instance of LLA... but the acronym was never expanded (yes, I do know it stands for link-local addresses). * Section 2.2: > thereby > lowering the complexity and size of router configurations. This also > reduces the likelihood of configuration mistakes. (Me thinking out loud) I'm not sure about this one... My take is that whatever makes a human deviate from what he's most used to will imply more mistakes. * Section 2.2: > Simpler DNS: Less routable address space in use also means less DNS > mappings to maintain. Are you meaning reverse mappings? Forward mappings? Both? * Section 2.3 (editorial): > interface identifier of the interface a packet was received on in the > ICMP response; it must be noted that there are little implemention of > this ICMP extension. s/little implemention/few implementations/ * Section 2.3: > Traceroute: Similar to the ping case, a reply to a traceroute packet > would come from a loopback address with a greater than link-local > address. As noted above, it'd probably clearrer to say ".. from a global address assigned to the loopback interface" * Section 2.3: > Hardware dependency: LLAs are usually EUI-64 based, hence, they > change when the MAC address is changed. This could pose problem in a > case where the routing neighbor must be configured explicitly (e.g. > BGP) and a line card needs to be physically replaced hence changing > the EUI-64 LLA and breaking the routing neighborship. But, LLAs can > be statically configured such as fe80::1 and fe80::2 which can be > used to configure any required static routing neighborship. This > static configuration is similar in complexity to statically > configured greater than link-local addresses, however, it is only > required where routing peers are explicitly configured. This problem is tackled by draft-ietf-6man-stable-privacy-addresses. * Section 2.4: > Also all the > loopback addresses on the IXP can be discovered by a potential > attacker by a simple traceroute; a generic attack is therefore still > possible, but it would require significantly more work. I haven't given this one much of a thought... but it looks that mapping such addresses would still be within the category of "trivial"... 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 fgont@si6networks.com Tue Apr 9 22:21:36 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BCF21F93BF; Tue, 9 Apr 2013 22:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONZepnlA06K9; Tue, 9 Apr 2013 22:21:35 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4653221F93BD; Tue, 9 Apr 2013 22:21:35 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UPnSm-0004Hk-Ve; Wed, 10 Apr 2013 07:21:31 +0200 Message-ID: <5164F5F3.9030007@si6networks.com> Date: Wed, 10 Apr 2013 02:17:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com> <51559943.1010703@gmail.com> <515985E1.1000404@si6networks.com> <515AA8B4.5020707@gmail.com> In-Reply-To: <515AA8B4.5020707@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, ietf@ietf.org Subject: Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC 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, 10 Apr 2013 05:21:36 -0000 Hi, Brian, My apologies for the delay in my response. Please find my comments in-line... On 04/02/2013 06:45 AM, Brian E Carpenter wrote: > Fernando, > > Rather than repeating myself, I'll suggest a change to the Introduction > that would (IMHO) improve the message: > > OLD: > > 1. Introduction > > Most general-purpose operating systems implement and enable native > IPv6 [RFC2460] support and a number of transition/co-existence > technologies by default. For cases in which the corresponding > devices are deployed on networks that are assumed to be IPv4-only, > > NEW: > > 1. Introduction > > Most general-purpose operating systems implement and enable native > IPv6 [RFC2460] support and a number of transition/co-existence > technologies by default [RFC6434]. Support of IPv6 by all nodes is > intended to become best current practice [RFC6540]. As a result, > networks will need to plan for and deploy IPv6 and its security > mechanisms. Some enterprise networks might, however, choose to delay > active use of IPv6. For networks that are assumed to be IPv4-only, I've checked with a few folks, and it seems that the suggested text would make everyone happy, except for the sentence that says "As a result, networks will need to plan for and deploy IPv6 and its security mechanisms.", on the basis that this is not the document to make a case for v6 deployment. The suggestions has been to remove that sentence, and apply the rest of your proposed text (or, alternatively, to tone down that sentence). For simplicity sake (and because I'm not sure how one would tone that one down), my suggestion would be to apply you proposed text, modulo that sentence. Would that be okay with you? -- If not, please do let me know, so that we can try to find a way forward that keeps everyone happy. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Wed Apr 10 09:06:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B8621F98D2; Wed, 10 Apr 2013 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.96 X-Spam-Level: X-Spam-Status: No, score=-99.96 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 CeaqOGhhcTxI; Wed, 10 Apr 2013 09:06:15 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4321F9942; Wed, 10 Apr 2013 09:06:15 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so6173580wgg.2 for ; Wed, 10 Apr 2013 09:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Pvjq292gh7+UPVP5FivluKL/DfVTB1wtXrzVK1ar5d0=; b=VB6n+mwQpQHquXjZWDSwASZMJYKUm9rxPUZU8JYbNvPegsEXY7N44quFcf38vbpJxw cyKzr0DVK/cjBJRnHPUBxjtkh2+3Rdp/eGTKxoCF1hiXR5N8Ero8Y8zq4pMSZeBGzakY IP08wBNAvRYZvazfyD4CGtzgdN0433HPNLGHgBleFZlBE+flq/stzcAPEE+wl95hu69l ib/Puvrks4HRV15MeRId6tIr2V4CcttuDsn99OR2jAnJx3CdN3Y3iDCFNOdfahkisLRH RxQu1VRx0BHeV8I05Cmi8/K7eVnbxbBMVENyHGHPbE0SDiBGAYsWplQrMBHt1mD4qWlf otng== X-Received: by 10.194.77.110 with SMTP id r14mr4751342wjw.2.1365609974544; Wed, 10 Apr 2013 09:06:14 -0700 (PDT) Received: from [192.168.1.65] (host-2-101-189-175.as13285.net. [2.101.189.175]) by mx.google.com with ESMTPS id du2sm32657248wib.0.2013.04.10.09.06.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 09:06:13 -0700 (PDT) Message-ID: <51658DFC.7010504@gmail.com> Date: Wed, 10 Apr 2013 17:06:20 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com> <51559943.1010703@gmail.com> <515985E1.1000404@si6networks.com> <515AA8B4.5020707@gmail.com> <5164F5F3.9030007@si6networks.com> In-Reply-To: <5164F5F3.9030007@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, ietf@ietf.org Subject: Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC 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, 10 Apr 2013 16:06:16 -0000 Hi Fernando, On 10/04/2013 06:17, Fernando Gont wrote: > Hi, Brian, > > My apologies for the delay in my response. Please find my comments > in-line... > > > On 04/02/2013 06:45 AM, Brian E Carpenter wrote: >> Fernando, >> >> Rather than repeating myself, I'll suggest a change to the Introduction >> that would (IMHO) improve the message: >> >> OLD: >> >> 1. Introduction >> >> Most general-purpose operating systems implement and enable native >> IPv6 [RFC2460] support and a number of transition/co-existence >> technologies by default. For cases in which the corresponding >> devices are deployed on networks that are assumed to be IPv4-only, >> >> NEW: >> >> 1. Introduction >> >> Most general-purpose operating systems implement and enable native >> IPv6 [RFC2460] support and a number of transition/co-existence >> technologies by default [RFC6434]. Support of IPv6 by all nodes is >> intended to become best current practice [RFC6540]. As a result, >> networks will need to plan for and deploy IPv6 and its security >> mechanisms. Some enterprise networks might, however, choose to delay >> active use of IPv6. For networks that are assumed to be IPv4-only, > > I've checked with a few folks, and it seems that the suggested text > would make everyone happy, except for the sentence that says "As a > result, networks will need to plan for and deploy IPv6 and its security > mechanisms.", on the basis that this is not the document to make a case > for v6 deployment. The suggestions has been to remove that sentence, and > apply the rest of your proposed text (or, alternatively, to tone down > that sentence). > > For simplicity sake (and because I'm not sure how one would tone that > one down), my suggestion would be to apply you proposed text, modulo > that sentence. > > Would that be okay with you? -- If not, please do let me know, so that > we can try to find a way forward that keeps everyone happy. Well, it's not for me to call the consenus, but with that sentence removed I would personally enter the "no objection" state. Thanks Brian From kkumar@google.com Fri Apr 12 18:28:37 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6752E21F8E9A for ; Fri, 12 Apr 2013 18:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6f9s5hWVGEEz for ; Fri, 12 Apr 2013 18:28:37 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id D61D321F8E72 for ; Fri, 12 Apr 2013 18:28:36 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id p6so79915qad.14 for ; Fri, 12 Apr 2013 18:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1zUagoR3XSMq0fkkDKrUrxJ0zmLJxYOb85AaH10cmS0=; b=CuRwnvex4NhaI46IxyjAdQDzXkoVKP+g7W1YWnJbGWa0YAvRTB2kQsDpbCQgRHJi/r 6NKvwbtiOItDtu0IjFLtV8uNH+gKJQ4zqFqzu+GAR93BvoFGTskZ7fnBUfYhUZrgxFeU ecsZCGjvCNN/9SDMy5VDo1RS0VtmGIJOfkvG1l+4bDBdmZi/PcdmSuIdoyL1lJlhP2mG xStV84lBpUHoAxTLuZGZATDfmRqjwabhG63/IOI1UhwDzLQWDdV6FeTkw2mzAGHZJe6s 7GbLJOGSHgOy/cExBhpV1ZSMCL6S3wkL6BS5yo+6CDCAB7RbxsiY4sEl+zF5wK7c6f+Q BHqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=1zUagoR3XSMq0fkkDKrUrxJ0zmLJxYOb85AaH10cmS0=; b=cXkOkFwpmA5k9C0j2e2Q1kzl8ourXLEnBt/KxokqtBCVAKt4XmeHMgSlCyI2ZED+rY Qk5mZ6xjYQPq/r8kHw+oDCdsxy4aOPviWQ/vGgYLv65EQb9M38p+jXEFJ49H/9NhkH9L sMrnAUYUKavgH+sir9SdeBnMoTVTWyuBAW8163NbOrs79g0Ed9Kmansqzty+PVwt5S/z zi7MWPgkdTqhkkifj689bP+2K8j9uZh6e2+rbIa3JDAZ+sC5XLxyBnU3g1q1PN5U97Tw IbxxXkFEwUZqfVjLpB75JFeMZ1y6Dzhtp4X0Mak++f1kIzb4ewuX89bJqFTkJtBU8oER KaDQ== X-Received: by 10.49.25.81 with SMTP id a17mr9247796qeg.58.1365816516209; Fri, 12 Apr 2013 18:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.50.33 with HTTP; Fri, 12 Apr 2013 18:28:16 -0700 (PDT) In-Reply-To: References: From: KK Date: Fri, 12 Apr 2013 18:28:16 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkqus6PLB1zb1wsbupRetw3U6xnzQg1Vn35Q8VgL5ogRitSty7mWe07NHy9ybgyoi1fBTl+LqUR7KCy82P2rq0spz3sK9JipitrrrYi6C/t0uYd56IzXgjITdLPS7Eauxc8YT2EzbEK6UKMhWlvwT3hD91o0BI2f5754jz0zoxgOgMEQ/doHBF2kZZSgVeFj/juqpnY Cc: "" Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-bgp-security X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 01:28:37 -0000 Dear OpSec WG, The chairs feel that there have been insufficient reviews to progress towards publication request at this time. We recommend that the authors take the feedback received so far and revise the doc. Once the doc is updated, we will seek additional review from folks in GROW, IDR and SIDR prior to proceeding further with a last call. Regards, KK (as OpSec WG co-chair) On Wed, Mar 27, 2013 at 10:48 AM, KK wrote: > Dear OpSec WG, > > > This starts a Working Group Last Call for draft-ietf-opsec-bgp-security. > > All three authors have replied, stating that they do not know of any IPR > associated with this draft. > > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ > > > Please review this draft to see if you think it is ready for publication and > comments to the list, clearly stating your view. > > > This WGLC ends 10-April-2013. > > > Thanks, > > KK > > (as OpSec WG co-chair) > > > From fgont@si6networks.com Fri Apr 12 20:30:21 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FC821F8EBE; Fri, 12 Apr 2013 20:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lIYa9o7-Y3C; Fri, 12 Apr 2013 20:30:21 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE9921F8E47; Fri, 12 Apr 2013 20:30:20 -0700 (PDT) Received: from 26-174-16-190.fibertel.com.ar ([190.16.174.26] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UQrAN-0008Cz-Gt; Sat, 13 Apr 2013 05:30:15 +0200 Message-ID: <5168D137.4090305@si6networks.com> Date: Sat, 13 Apr 2013 00:29:59 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian E Carpenter References: <20130329130326.13012.1402.idtracker@ietfa.amsl.com> <51559943.1010703@gmail.com> <515985E1.1000404@si6networks.com> <515AA8B4.5020707@gmail.com> <5164F5F3.9030007@si6networks.com> <51658DFC.7010504@gmail.com> In-Reply-To: <51658DFC.7010504@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, ietf@ietf.org Subject: Re: [OPSEC] Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC 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, 13 Apr 2013 03:30:22 -0000 Hi, Brian, On 04/10/2013 01:06 PM, Brian E Carpenter wrote: >> For simplicity sake (and because I'm not sure how one would tone that >> one down), my suggestion would be to apply you proposed text, modulo >> that sentence. >> >> Would that be okay with you? -- If not, please do let me know, so that >> we can try to find a way forward that keeps everyone happy. > > Well, it's not for me to call the consenus, but with that sentence > removed I would personally enter the "no objection" state. Good. BTW, it's unclear to me whether I should keep in in the acks or not... so please do let me know how you'd like me to proceed in this respect. P.S.: For any other future reviews: I usually do my best to address others' comments. In the event that you submit feedback, and it looks like I have not tried to address it, please resend/ping me (most likely I tried but failed, the feedback slipped by, or whatever... ) 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 internet-drafts@ietf.org Sat Apr 13 00:07:55 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFDD21F86DD; Sat, 13 Apr 2013 00:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ52wZ49CyfX; Sat, 13 Apr 2013 00:07:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 823A621F86BB; Sat, 13 Apr 2013 00:07:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130413070751.22832.40027.idtracker@ietfa.amsl.com> Date: Sat, 13 Apr 2013 00:07:51 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-efforts-20.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, 13 Apr 2013 07:07:55 -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 : Security Best Practices Efforts and Documents Author(s) : Chris Lonvick David Spak Filename : draft-ietf-opsec-efforts-20.txt Pages : 41 Date : 2013-04-13 Abstract: This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-efforts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-efforts-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-efforts-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johnsonhammond1@hushmail.com Sat Apr 27 15:47:16 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B2E21F9901 for ; Sat, 27 Apr 2013 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 SkhpGyXudoqb for ; Sat, 27 Apr 2013 15:47:16 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id E199F21F98EC for ; Sat, 27 Apr 2013 15:47:14 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id B8AE7E7BA9 for ; Sat, 27 Apr 2013 17:32:01 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:32:01 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 8077CE6739; Sat, 27 Apr 2013 17:32:01 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:32:01 -0400 To: opsec@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173201.8077CE6739@smtp.hushmail.com> Subject: [OPSEC] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 22:47:16 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From internet-drafts@ietf.org Tue Apr 30 06:15:54 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F41C21F9BE3; Tue, 30 Apr 2013 06:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWRqMKYRCJA1; Tue, 30 Apr 2013 06:15:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A8E21F9BD4; Tue, 30 Apr 2013 06:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130430131552.11965.72824.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2013 06:15:52 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-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: Tue, 30 Apr 2013 13:15:54 -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 : Network Reconnaissance in IPv6 Networks Author(s) : Fernando Gont Tim Chown Filename : draft-ietf-opsec-ipv6-host-scanning-01.txt Pages : 34 Date : 2013-04-30 Abstract: IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore IPv6 address scanning attacks have long been considered unfeasible. This document analyzes how traditional address scanning techniques apply to IPv6 networks, and also explores a number of other techniques that can be employed for IPv6 network reconnaissance. Additionally, this document formally obsoletes RFC 5157. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-host-scanning-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/