From rbonica@juniper.net  Fri Apr  9 09:13:26 2010
Return-Path: <rbonica@juniper.net>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE4C3A6993 for <opsec@core3.amsl.com>; Fri,  9 Apr 2010 09:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.74
X-Spam-Level: 
X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJmA6GKeZRhs for <opsec@core3.amsl.com>; Fri,  9 Apr 2010 09:13:24 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 6F89C3A69F9 for <opsec@ietf.org>; Fri,  9 Apr 2010 09:12:50 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS79R/hDJbockMjc54JJ+wvl+u4P1AP9X@postini.com; Fri, 09 Apr 2010 09:12:48 PDT
Received: from [172.28.134.28] (172.28.134.28) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 9 Apr 2010 09:10:27 -0700
Message-ID: <4BBF516F.5060508@juniper.net>
Date: Fri, 9 Apr 2010 12:10:23 -0400
From: Ron Bonica <rbonica@juniper.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
References: <C629017C-E5CF-4FD8-8B60-99901293423F@tcb.net>
In-Reply-To: <C629017C-E5CF-4FD8-8B60-99901293423F@tcb.net>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: opsec wg mailing list <opsec@ietf.org>
Subject: Re: [OPSEC] Comments on draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 16:13:26 -0000

Hi Folks,

<Speaking as individual contributor>

Danny McPherson wrote:
> I support this document becoming an OPSEC WG item.  A few
> mostly trivial comments below.  I do believe the document 
> would benefit from an overwrite for readability, but it 
> seems to be in pretty good shape (and that's the purpose of
> making it a WG item).

+1

> 
> One substantive item is that I believe it needs to be a lot 
> more detailed on IPv6 examples, in particular as they relate 
> to ICMP.  This is where lots of operators really need extra
> guidance today.  

I would like to suggest a sequel document specifically for operators who
are deploying dual stack. There are enough sharp edges in dual stack
deployment that it deserves some thought.



> 
> Also, it should be clear about how transit traffic with TTL 
> expiry isn't necessarily addressed to the device, but might get 
> punted to the control plane.  There is some text that touches
> on this, but this issue is not clear from the text.

+1

> 
> Finally, after giving RFC 1812 another read (phew), my comments
> at the microphone about references to that document aren't 
> really useful.  I had thought it had more detailed information
> on what it terms "in-band" access, however, the guidance there
> isn't particular useful in this context.
> 
> -danny
> 
> 
> ---
> S 1.
> 
> s/as as/as/
> 
> s/traffic unwanted traffic/unwanted traffic/
> 
> ---
> S 2. 
> 
> I think the document would benefit from IPv6 examples as well, and 
> should reference that use case here and provide it further along in 
> parallel to IPv6 examples.
> 
> ---
> S 3.
> 
> s/sample router introduced/sample router is introduced/
> 
> ---
> S 3.1.
> 
> While I realize it's for example only, it might well be useful to 
> add some sort of authentication packets to that example, so that 
> folks can login if they have non-local auth models.
> 
> Also, does anyone have recent rates of ICMP traffic destined to the
> control plane of high-end routers?  2 Mbps of ICMP seems pretty 
> high to me..  
> 
> ---
> S 3.2
> 
> It might be useful for the document, or the appendices to recommend
> allowing all traffic initially and auditing what hits the control 
> plane before applying explicit filters or rate limits.  Additionally, 
> use of flow-based behavioral analysis or even CLI functions to 
> identify what client/server functions a given control plane handles
> would be very useful during initial policy development phases (and 
> certainly for forensics afterwards).  Perhaps this belongs at the 
> end of S 3.3, in the last graf where you touch on some of this.
> 
> ---
> S 3.3 
> 
> I'm not sure what "sub-traffic" is..
> 
> It might be worth expanding this a bit to say that an astute operator
> would likely define varying rate limits for ICMP such than internal 
> traffic (i.e., from internal address blocks) obtains uninhibited 
> access to the control plane, while traffic from external blocks is 
> rate limited.  I think you meant to allude to this, but don't really
> make it clear in the current text.
> 
> 
> ---
> S 4.
> 
> I believe it'd be worthwhile to mention that while in the inter-domain 
> context express ingress anti-spoofing policies may be difficult, 
> operators should apply ingress infrastructure ACLs to limit access to
> infrastructure from external source address spoofing of internal address
> space.  I.e., allow no packet into the perimeter of the network that
> has a source address of internal prefixes.  Of course, iACLs and GTSM
> might well be a new section to this document, or a document entirely
> themselves.
> 
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> .
> 

From Donald.Smith@qwest.com  Fri Apr  9 12:42:11 2010
Return-Path: <Donald.Smith@qwest.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36B03A6A2F for <opsec@core3.amsl.com>; Fri,  9 Apr 2010 12:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5AJ7v51h0xV for <opsec@core3.amsl.com>; Fri,  9 Apr 2010 12:42:10 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 983153A6A34 for <opsec@ietf.org>; Fri,  9 Apr 2010 12:35:42 -0700 (PDT)
Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o39JZbdL006243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Apr 2010 14:35:38 -0500 (CDT)
Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o39JZVrL007114; Fri, 9 Apr 2010 14:35:32 -0500 (CDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Fri, 9 Apr 2010 13:35:31 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: "'Ron Bonica'" <rbonica@juniper.net>, "'Danny McPherson'" <danny@tcb.net>
Date: Fri, 9 Apr 2010 13:35:30 -0600
Thread-Topic: [OPSEC] Comments on draft-dugal-opsec-protect-control-plane-02
Thread-Index: AcrX/5hBt4524bfHTEejhJFmoiYU/wAG3nlA
Message-ID: <B01905DA0C7CDC478F42870679DF0F1007A3E98710@qtdenexmbm24.AD.QINTRA.COM>
References: <C629017C-E5CF-4FD8-8B60-99901293423F@tcb.net> <4BBF516F.5060508@juniper.net>
In-Reply-To: <4BBF516F.5060508@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 'opsec wg mailing list' <opsec@ietf.org>
Subject: Re: [OPSEC] Comments on draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 19:42:11 -0000

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
Donald.Smith@qwest.com gcia

> -----Original Message-----
> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org]
> On Behalf Of Ron Bonica
> Sent: Friday, April 09, 2010 10:10 AM
> To: Danny McPherson
> Cc: opsec wg mailing list
> Subject: Re: [OPSEC] Comments on
> draft-dugal-opsec-protect-control-plane-02
>
> Hi Folks,
>
> <Speaking as individual contributor>
>
> Danny McPherson wrote:
> > I support this document becoming an OPSEC WG item.  A few
> > mostly trivial comments below.  I do believe the document
> > would benefit from an overwrite for readability, but it
> > seems to be in pretty good shape (and that's the purpose of
> > making it a WG item).
>
> +1
+1
>
> >
> > One substantive item is that I believe it needs to be a lot
> > more detailed on IPv6 examples, in particular as they relate
> > to ICMP.  This is where lots of operators really need extra
> > guidance today.
>
> I would like to suggest a sequel document specifically for
> operators who
> are deploying dual stack. There are enough sharp edges in dual stack
> deployment that it deserves some thought.
>
>
>
> >
> > Also, it should be clear about how transit traffic with TTL
> > expiry isn't necessarily addressed to the device, but might get
> > punted to the control plane.  There is some text that touches
> > on this, but this issue is not clear from the text.

"The treatment of exception traffic in the forwarding plane, and the
   generation of specific messages by the control plane also requires
   protection from a DoS attack.  Specifically, the generation of ICMP
   Unreachable messages by the control plane needs to be rate-limited,
   either implicitly within the router's architecture or explicitly
   through configuration.  See Section 4.3.2.8 of [RFC1812].
   For example, rate limiting the TTL / Hop Limit expired
   traffic before sending the packets to the control plane component
   that will send the ICMP error, and distributing the sending of ICMP
   errors in a Line Card CPU are protection mechanisms that deter
   attacks before a rate limited in the main control plane component."


When some vendors moved the TTL expired work to the line cards they created=
 a really fast reflective attack surface which we have seen used in DDOS at=
tacks:(

Also explicit ratelimits are always better then implicit:)


>
> +1
>
> >
> > Finally, after giving RFC 1812 another read (phew), my comments
> > at the microphone about references to that document aren't
> > really useful.  I had thought it had more detailed information
> > on what it terms "in-band" access, however, the guidance there
> > isn't particular useful in this context.
> >
> > -danny
> >
> >
> > ---
> > S 1.
> >
> > s/as as/as/
> >
> > s/traffic unwanted traffic/unwanted traffic/
> >
> > ---
> > S 2.
> >
> > I think the document would benefit from IPv6 examples as well, and
> > should reference that use case here and provide it further along in
> > parallel to IPv6 examples.
> >
> > ---
> > S 3.
> >
> > s/sample router introduced/sample router is introduced/
> >
> > ---
> > S 3.1.
> >
> > While I realize it's for example only, it might well be useful to
> > add some sort of authentication packets to that example, so that
> > folks can login if they have non-local auth models.
> >
> > Also, does anyone have recent rates of ICMP traffic destined to the
> > control plane of high-end routers?  2 Mbps of ICMP seems pretty
> > high to me..
> >
> > ---
> > S 3.2
> >
> > It might be useful for the document, or the appendices to recommend
> > allowing all traffic initially and auditing what hits the control
> > plane before applying explicit filters or rate limits.
> Additionally,
> > use of flow-based behavioral analysis or even CLI functions to
> > identify what client/server functions a given control plane handles
> > would be very useful during initial policy development phases (and
> > certainly for forensics afterwards).  Perhaps this belongs at the
> > end of S 3.3, in the last graf where you touch on some of this.
> >
> > ---
> > S 3.3
> >
> > I'm not sure what "sub-traffic" is..
> >
> > It might be worth expanding this a bit to say that an
> astute operator
> > would likely define varying rate limits for ICMP such than internal
> > traffic (i.e., from internal address blocks) obtains uninhibited
> > access to the control plane, while traffic from external blocks is
> > rate limited.  I think you meant to allude to this, but don't really
> > make it clear in the current text.
> >
> >
> > ---
> > S 4.
> >
> > I believe it'd be worthwhile to mention that while in the
> inter-domain
> > context express ingress anti-spoofing policies may be difficult,
> > operators should apply ingress infrastructure ACLs to limit
> access to
> > infrastructure from external source address spoofing of
> internal address
> > space.  I.e., allow no packet into the perimeter of the network that
> > has a source address of internal prefixes.  Of course,
> iACLs and GTSM
> > might well be a new section to this document, or a document entirely
> > themselves.
> >
> >
> > _______________________________________________
> > OPSEC mailing list
> > OPSEC@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsec
> > .
> >
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

From joelja@bogus.com  Mon Apr 12 19:14:01 2010
Return-Path: <joelja@bogus.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0D53A687F for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 19:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level: 
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EowAEAwEmf0 for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 19:13:59 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 7CFC73A6852 for <opsec@ietf.org>; Mon, 12 Apr 2010 19:13:59 -0700 (PDT)
Received: from [192.168.1.151] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3D2DqvJ063320 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <opsec@ietf.org>; Tue, 13 Apr 2010 02:13:53 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BC3D35F.5020707@bogus.com>
Date: Mon, 12 Apr 2010 19:13:51 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100404 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 13 Apr 2010 02:13:54 +0000 (UTC)
Subject: [OPSEC] Draft IETF 77 minutes
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 02:14:01 -0000

Thanks to the efforts of Joe Abley and the jabber room posters.
Appologies for the the delay, the credit for that is all mine.

Tue 23 Mar 2010 17:39:47 PDT

opsec, IETF 77

note-taker joe abley
chairs joel jaeggli, joe abley

0. Agenda

1. achievements since ietf 76

  (slides presented by joel jaeggli)

2. document status

re: raft-ietf-opsec-ip-security:

ron bonica: for draft-ietf-opsec-ip-security, we might want to also ask
  for review in the ops area.

re: draft-ietf-opsec-routing-protocols-crypto-issues:

ron bonica: I don't know who the expert reviewer is for draft-
  ietf-opsec-routing-protocols-crypto-issues

ron bonica: BGP/MD5 will be obsolete in a day or two, section 5.2 of
  the draft talks about BGP/MD5

joel: we should revisit that

re: draft-ietf-opsec-igp-crypto-requirements

rich graveman: if people are using md5 for security and they have
  nothing else, and they read this document and turn it off, that's
  probably bad

joel: the document does attempt to call this out

...

joel: what to do with this document before last call?

ron bonica: I think the section on BGP needs to be re-thought.

joe touch: see a handful of documents that are having a rough time in
  tcpm. is there any coordination going on between the two areas? it
  seems that things are doing end runs here. specifically
  icmp-filtering. don't understand why we need another document on that.

ron bonica: rationale is that many ISPs block ICMP messages. There are
  some ISPs that let everything through. Others let some through, e.g.
  for pMTU discovery, but others they drop. what I wanted was a
  discussion for each ICMP message to allow an ISP to make informed
  decisions.

joe touch: some decisions are being made on what has been deployed,
  opinions of some individuals. had this discussion in tcpm. this
  document shouldn't repeat that discussion; it should refer to the
  tcpm discussion. second thing, why and whether it's appropriate
  to check the contents of icmp messages, check checksums, check fields
  inside. example: check sequence number. routers have no requiremnt
  to respond to icmp in a timely fashion; this can trip things up.
  worried about whether we are delaing with this set of issues in
  completely separate wgs that don't talk to each other.

joel: some danger of that. would observe that we have gone back and
  forth in this wg as to whether a document like this should be
  prescriptive. consensus of the wg was that it was more important to
  characterise what you would lose by filtering than whether you should
  filter.

ron bonica: first, agree with joe touch re referencing rather than
  reiterating. we should reference when we can. second, we should
  probably send the doc for external review, and send instructions for
  reviewer. document's goals are to explain what you lose if ou filter,
  what you  risk if you don't filter, let the operator make an informed
  decision. what we want is for him to make an informed decision.

joel: re original charters, pushing security requirements on vendors and
  by extension their customers tends not to be popular. if driven by
  application requirement that's great, but simply saying this is the
  way you should build your equipment and you need this features is not
  an easy sell. not something that I could have taken back to my then
  employer, for example.

joe touch: is that the intent of most documents here? I can see some of
  that coming out. ip security document has recommendations splattered
  all over the place and some of htem are insane.

joel: ...

joe touch: that document contains things that are insane. this speaks
  poorly to the competence of the working group. e.g. saying that
  everybody should always block LSR, that's insane. "a packet you did
  not expect is not a threat." the end state is that everybody will have
  to run their protocols over HTTP.

joel: firewalls apply policy to unsolicited packets. that's what they
  do. in the context of icmp filtering, the document characterises the
  consequences of applying that policy.

ron bonica: couple of words about our charter. this is an ops area wg.
  because we're in the ops area we don't get to change protocols, ever.
  we don't get to deprecate ip options. what we can discuss is whether
  an operator... we can talk about threat models, and we can talk about
  what those features offer than an operator would lose if he filtered
  them. give oeprators information so they can make informed decisions.

joel: in the context of LSR for example, as a strawman, I think it's
  entirely reasonable to say these are the consequences of carrying
  them.

david borman: co chair for the tcpm wg. on lsr, those options have been
  an issue from the early days and the main reason is that
  implementations ignore them. I think the cat's out of the bag on
  those, that trying to say that you shouldn't block those -- I don't
  think we can ever resurrect those the way they were intended. in
  general though, e.g. icmp filtering, it would be great to get it
  passed through the tcpm wg. glacing through it I noticed a lot of
  TBDs.

joel: yes, the section is not complete yet. difficult for it to make
  progress when contributions have not yet been incorporated, when the
  doc is not yet finished.

david: some people in the tcpm wg could help fill in some of those TBDs.

joel: that would be helpful.

david: suggest the doc be sent to the tcpm wg as a working draft and
  ask for contributions and review.

joel: additional authors would be very welcome.

joel: you guys have the tcp security assessment being socialised in your
  wg?

david: fernando's tcp document we have that in tcpm wg and tomorrow
  morning we are having a separate session at 1015-1030 in pacific a
  to walk through that document to identify those items that we feel
  are non-controversial. goal is to move that document forward. very
  much like the format of hte icmp filtering draft.

3. new work

draft-dugal-opsec-protect-control-plane-02

  (david dugal presenting from slides)

rich graveman: have not read the whole doc. don't see you talk about using
  security technology where we have it, e.g. it doesn't refer to OSPF
  with SHA1 integrity protection. no DNSSEC. you don't use security!

david: in our initial design we wanted to limit the scope to just
  control plane filters, e.g. lo0 filters in JUNOS. That's not to say
  there shouldn't be additional recommendations. please mention that on
  mailing list or by private mail.

ron bonica: I think much of that stuff is out of scope for this
  document. it may be that we want to do another document on the
  applications we run upon the control plane. but this draft is drawing
  attention to the firewall beteween the control plana and the data
  plane.

rich graveman: this draft contains no security!

chris morrow: no. there is a place for use of crypto in routing
  protocols, for dns hygeine, but this draft's purpose is controlling
  who can talk to my router.

rich: but using keys, not ip addresses!

chris: no [etc]

  (much animated discussion, following some agreement that this is a
  conversation that can happen on the mailing list.)

brian wise: draft says protect your control plane and gives some
  some examples, so I don't think BCP. I think it woudl be valuable
  though if the document contained specific advice for (e.g.)
  BGP-speaking routers.

joel: personal opinion is that to the extent it's possible vendor-
  specific examples should appear in appendices.

david: the more specific we get to a particular network design the less
  relevant it becomes to other ones. but there are some key roles that
  might be worth considering.

rich graveman: GMPLS, CCAMP, when they say control plane they mean
  something different. I understand you're talking about the IP
  router control plane. the phrase "control plane" is a little
  overloaded.

ron bonica: the words "control plane" are applicable. these things are
  all control planes.

rich graveman: correct, was suggesting the scope be reduced.

joel: think there's room to iterate on scope.

danny mcpherson: this is more about access to the devices, rather than
  the protocols themselves. but this about route processor handling
  in network devices, that's the primary motiviation, to protect these
  things. this is about access to those devices. but also
  infrastructure ACLs at the network perimeter, etc. perhaps also
  belongs here, or maybe a separate document.

david: we did think about that, but we also wanted to focus this
  document on protecting the control plane

rudiger volk: router control plane might be a better phrase

george: haven't read draft. when we implemented these layers of
  protection in our network we spent time categorising what was hitting
  the box to start with. this allowed us to characterise the traffic,
  iterative process of refining. perhaps instead of specific examples,
  describe a methodology. characterise traffic so you know what you
  care about. any bcp that talks about protecting the control plane
  definitely has to talk about that characterisation step.

warren kumari: should consider the audience of the document. document
  describes the architecture of a router, then jumps to "let's make a
  filter". If it's going to start that basic, it ought to provide more
  guidance for *how* to derive suitable filters.

david: intent was to keep it introductory. concern I had was the
  routers in the world that are completely unprotected.

warren: but unprotected routers are probably run by people who don't
  know *how* to filter.

chris: some of what richard brought up earlier, e.g. optical platforms,
  GMPLS, etc. nice if we had same protections not just for routers and
  switches but also for layer-1. Optical vendors have a lack of
  appreciation for this. it would be nice if whatever came out wasn't
  completely router-only. nothing there that couldn't be used to
  support a requirements document for other types of equipment.

joel: this doc generated some healthy discussion in the room and on
  the list. suggests people have read it. makes me want to ask some
  questions. who in the room has read it? [ten hands or so.]

joel: anybody have an opinion on accepting this as a wg document? the
  list is the final arbiter.

wes george: I believe this should be a wg doc.

warren: me too

rich: me too, 100%

joel: we will take this an action item after this meeting to poll the
  list for adoption. thank you.

warren: what about bcp vs. informational?

ron: I'm not going to give an opinion, but friendly advice. info is much
  easier than bcp. bcp is a club for beating other document authors.need
  to assess whether you need that club.

danny: referencing rfc 1812 might be useful. provides some terminology.

david: we reference a section of 1812 but we could look at expanding it.

4. any additional agenda items

  (no other business)

joel: that concludes our programme.


From fernando@gont.com.ar  Mon Apr 12 20:21:02 2010
Return-Path: <fernando@gont.com.ar>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7423A68D5 for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 20:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.442
X-Spam-Level: 
X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_40=-0.185, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7cXX7vjl8rJ for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 20:20:52 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id EE6803A6851 for <opsec@ietf.org>; Mon, 12 Apr 2010 20:20:49 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B70E06B8AF3; Tue, 13 Apr 2010 00:20:48 -0300 (ART)
Received: from [192.168.0.124] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o3D3KdJk022382; Tue, 13 Apr 2010 00:20:40 -0300
Message-ID: <4BC3E2FF.4050101@gont.com.ar>
Date: Tue, 13 Apr 2010 00:20:31 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 13 Apr 2010 00:20:47 -0300 (ART)
Cc: Joe Touch <touch@ISI.EDU>
Subject: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 03:21:02 -0000

Hi, folks,

I wasn't at the opsec wg meeting, and have jut sync'ed with the meeting
(I've just read the minutes). Here are some comments regarding the
discussion about icmp-filtering:


> ron bonica: rationale is that many ISPs block ICMP messages. There are
>   some ISPs that let everything through. Others let some through, e.g.
>   for pMTU discovery, but others they drop. what I wanted was a
>   discussion for each ICMP message to allow an ISP to make informed
>   decisions.
> 
> joe touch: some decisions are being made on what has been deployed,
>   opinions of some individuals. had this discussion in tcpm. 

This is entirely misleading. The discussion in tcpm was about ICMP hard
errors, and about what countermeasures could be implemented in TCP to
mitigate them.

This I-D is orthogonal to that.


>   this
>   document shouldn't repeat that discussion; it should refer to the
>   tcpm discussion. second thing, why and whether it's appropriate
>   to check the contents of icmp messages, check checksums, check fields
>   inside. example: check sequence number. 

Can you please point the specific section in the icmp-filtering I-D that
recommends this? (or that even mentions this???)


> ron bonica: first, agree with joe touch re referencing rather than
>   reiterating. we should reference when we can. second, we should
>   probably send the doc for external review, and send instructions for
>   reviewer. document's goals are to explain what you lose if ou filter,
>   what you  risk if you don't filter, let the operator make an informed
>   decision. what we want is for him to make an informed decision.

+1.

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






From touch@ISI.EDU  Mon Apr 12 21:00:11 2010
Return-Path: <touch@ISI.EDU>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EEFB3A67B1 for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 21:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.432
X-Spam-Level: 
X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=0.567,  BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD92Evw0aPuW for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 21:00:10 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 6D0C03A659C for <opsec@ietf.org>; Mon, 12 Apr 2010 21:00:10 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o3D3xgSI010387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2010 20:59:44 -0700 (PDT)
Message-ID: <4BC3EC2E.30509@isi.edu>
Date: Mon, 12 Apr 2010 20:59:42 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <4BC3E2FF.4050101@gont.com.ar>
In-Reply-To: <4BC3E2FF.4050101@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig12F102F4186F1556656EA43E"
X-MailScanner-ID: o3D3xgSI010387
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 04:00:11 -0000

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

Fernando,

Also, the doc cites the need to

Fernando Gont wrote:
> Hi, folks,
>=20
> I wasn't at the opsec wg meeting, and have jut sync'ed with the meeting=

> (I've just read the minutes). Here are some comments regarding the
> discussion about icmp-filtering:
>=20
>=20
>> ron bonica: rationale is that many ISPs block ICMP messages. There are=

>>   some ISPs that let everything through. Others let some through, e.g.=

>>   for pMTU discovery, but others they drop. what I wanted was a
>>   discussion for each ICMP message to allow an ISP to make informed
>>   decisions.
>>
>> joe touch: some decisions are being made on what has been deployed,
>>   opinions of some individuals. had this discussion in tcpm.=20
>=20
> This is entirely misleading. The discussion in tcpm was about ICMP hard=

> errors, and about what countermeasures could be implemented in TCP to
> mitigate them.
>=20
> This I-D is orthogonal to that.

First, I'm referring to the decisions of operators, not the decisions in
the document.

Second, the document is clearly not orthogonal to the TCPM ICMP docs
(see numerous citations to both RFC5461 and ICMP attacks ID).

In specific, this doc repeatedly states:

   May lead to long delays between connection establishment attempts or
   long response times that could have been avoided by aborting non-
   synchronized connections in response to ICMP soft errors [RFC5461].

This implicitly endorses the soft errors solution, which, as noted in
RFC5461 in the abstract:

   This document describes a non-standard, but widely implemented,
   modification to TCP's handling of ICMP soft error messages

This is why I consider some of the suggestions and discussion in this
document to be based on what has been deployed, and is clearly the
opinion of some individuals, but not the advice of TCPM.

>>   this
>>   document shouldn't repeat that discussion; it should refer to the
>>   tcpm discussion. second thing, why and whether it's appropriate
>>   to check the contents of icmp messages, check checksums, check field=
s
>>   inside. example: check sequence number.=20
>=20
> Can you please point the specific section in the icmp-filtering I-D tha=
t
> recommends this? (or that even mentions this???)

My point is that the icmp-filtering doc makes ample reference to the
tcpm-icmp-attacks doc, without stating that the mechanisms in that tcpm
doc are not necessarily appropriate.

>> ron bonica: first, agree with joe touch re referencing rather than
>>   reiterating. we should reference when we can. second, we should
>>   probably send the doc for external review, and send instructions for=

>>   reviewer. document's goals are to explain what you lose if ou filter=
,
>>   what you  risk if you don't filter, let the operator make an informe=
d
>>   decision. what we want is for him to make an informed decision.

+1

Informed decisions include knowing that you're playing with deployed
code that is not recommended, and in cases oversteps the standards.

Joe


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkvD7C4ACgkQE5f5cImnZruXFQCfWU6/TOZ7uFn2YexhRqZIz0zH
g4AAoPkPGYKm9j2UAk/Co8BIpOL+9479
=oYPT
-----END PGP SIGNATURE-----

--------------enig12F102F4186F1556656EA43E--

From touch@ISI.EDU  Mon Apr 12 21:02:59 2010
Return-Path: <touch@ISI.EDU>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E028E3A687C for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 21:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.813
X-Spam-Level: 
X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.786,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DFSDHVJUh-S for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 21:02:59 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 3BC6C3A67E1 for <opsec@ietf.org>; Mon, 12 Apr 2010 21:02:59 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o3D42MfU010869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2010 21:02:26 -0700 (PDT)
Message-ID: <4BC3ECCE.8030903@isi.edu>
Date: Mon, 12 Apr 2010 21:02:22 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu>
In-Reply-To: <4BC3EC2E.30509@isi.edu>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2AEB0EA647D2D60D11BA91CA"
X-MailScanner-ID: o3D42MfU010869
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 04:03:00 -0000

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



Joe Touch wrote:
> Fernando,
>=20
> Also, the doc cites the need to

Skip this snippet. Not needed.

Joe


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkvD7M4ACgkQE5f5cImnZrt0DACg70hfFdX12thou9ggsNQsjERv
ngoAnR2TFg4ueeWagmHKd7u+w7F0Ksb1
=8sfr
-----END PGP SIGNATURE-----

--------------enig2AEB0EA647D2D60D11BA91CA--

From fernando@gont.com.ar  Mon Apr 12 22:08:33 2010
Return-Path: <fernando@gont.com.ar>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9095F3A682D for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 22:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.936,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDMeDUpEAfgF for <opsec@core3.amsl.com>; Mon, 12 Apr 2010 22:08:30 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 54DDB3A67E5 for <opsec@ietf.org>; Mon, 12 Apr 2010 22:08:29 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7A9B96B88B0; Tue, 13 Apr 2010 02:08:29 -0300 (ART)
Received: from [192.168.0.124] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o3D58LNv013059; Tue, 13 Apr 2010 02:08:21 -0300
Message-ID: <4BC3FC3B.2030101@gont.com.ar>
Date: Tue, 13 Apr 2010 02:08:11 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu>
In-Reply-To: <4BC3EC2E.30509@isi.edu>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 13 Apr 2010 02:08:28 -0300 (ART)
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 05:08:33 -0000

Joe,

> First, I'm referring to the decisions of operators, not the decisions in
> the document.
> 
> Second, the document is clearly not orthogonal to the TCPM ICMP docs
> (see numerous citations to both RFC5461 and ICMP attacks ID).
> 
> In specific, this doc repeatedly states:
> 
>    May lead to long delays between connection establishment attempts or
>    long response times that could have been avoided by aborting non-
>    synchronized connections in response to ICMP soft errors [RFC5461].
> 
> This implicitly endorses the soft errors solution, which, as noted in
> RFC5461 in the abstract:

That was not the intent. We may weak the wording, if that's an issue.

We don't want to endorse anything. But as there are numerous stacks that
implement the behavior in RFC 5461, this was noted. In particular,
implementation of RFC 5461 is quite popular in the v6 world, and
probably expected (for instance, that's where the soft-errors I-D was born)



>    This document describes a non-standard, but widely implemented,
>    modification to TCP's handling of ICMP soft error messages
> 
> This is why I consider some of the suggestions and discussion in this
> document to be based on what has been deployed, and is clearly the
> opinion of some individuals, but not the advice of TCPM.

Why do you think we're endorsing RFC 5461? The idea was to mention that
if you filter soft errors, then the non-standard workaround described in
RFC5461 will fail. That's it.



>>>   document shouldn't repeat that discussion; it should refer to the
>>>   tcpm discussion. second thing, why and whether it's appropriate
>>>   to check the contents of icmp messages, check checksums, check fields
>>>   inside. example: check sequence number. 
>> Can you please point the specific section in the icmp-filtering I-D that
>> recommends this? (or that even mentions this???)
> 
> My point is that the icmp-filtering doc makes ample reference to the
> tcpm-icmp-attacks doc, without stating that the mechanisms in that tcpm
> doc are not necessarily appropriate.

The reference to icmp-attacks is for the description of the
vulnerabilities, rather than for the counter-measures. Yes, it does
references icmp-attacks. But it doesn't endorse the countermeasures. --
It does not even mention them!



>>> ron bonica: first, agree with joe touch re referencing rather than
>>>   reiterating. we should reference when we can. second, we should
>>>   probably send the doc for external review, and send instructions for
>>>   reviewer. document's goals are to explain what you lose if ou filter,
>>>   what you  risk if you don't filter, let the operator make an informed
>>>   decision. what we want is for him to make an informed decision.
> 
> +1
> 
> Informed decisions include knowing that you're playing with deployed
> code that is not recommended, and in cases oversteps the standards.

In the case of icmp-attacks, there's no play with deployed code at all.
As I've already mentioned the I-D/RFC is referenced because it's the
first documentation of those vulnerabilities. In the case of soft-errors
(RFC5461), I may note that it's a non-standard behavior, if you want.

Honestly speaking, there's no intent at all to encourage or endorse
icmp-attacks or RFC5461, or anything.

I'll note that of RFC5461 being "widely deployed, but non-standard" in
the next rev. If you have any specific proposal for the wording, please
post it. -- there's no need to fight for this document.

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





From root@core3.amsl.com  Tue Apr 13 00:30:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 6ED0928C1BF; Tue, 13 Apr 2010 00:30:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100413073002.6ED0928C1BF@core3.amsl.com>
Date: Tue, 13 Apr 2010 00:30:02 -0700 (PDT)
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action:draft-ietf-opsec-ip-security-03.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 07:30:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.


	Title           : Security Assessment of the Internet Protocol version 4
	Author(s)       : F. Gont
	Filename        : draft-ietf-opsec-ip-security-03.txt
	Pages           : 77
	Date            : 2010-04-13

This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of
mechanisms and policies in use by popular IPv4 implementations.  It
is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsec-ip-security-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-opsec-ip-security-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-04-13001752.I-D@ietf.org>


--NextPart--

From touch@ISI.EDU  Thu Apr 15 16:00:22 2010
Return-Path: <touch@ISI.EDU>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7F83A6860 for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 16:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY4b7I1edRQg for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 16:00:21 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 363DE3A6A79 for <opsec@ietf.org>; Thu, 15 Apr 2010 16:00:21 -0700 (PDT)
Received: from [75.214.39.82] (82.sub-75-214-39.myvzw.com [75.214.39.82]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o3FMxdtb009028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 15:59:42 -0700 (PDT)
Message-ID: <4BC79A5B.3010809@isi.edu>
Date: Thu, 15 Apr 2010 15:59:39 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu> <4BC3FC3B.2030101@gont.com.ar>
In-Reply-To: <4BC3FC3B.2030101@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE93D3B4452199C79E11FB8E2"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 23:00:22 -0000

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



Fernando Gont wrote:
> Joe,
>=20
>> First, I'm referring to the decisions of operators, not the decisions =
in
>> the document.
>>
>> Second, the document is clearly not orthogonal to the TCPM ICMP docs
>> (see numerous citations to both RFC5461 and ICMP attacks ID).
>>
>> In specific, this doc repeatedly states:
>>
>>    May lead to long delays between connection establishment attempts o=
r
>>    long response times that could have been avoided by aborting non-
>>    synchronized connections in response to ICMP soft errors [RFC5461].=

>>
>> This implicitly endorses the soft errors solution, which, as noted in
>> RFC5461 in the abstract:
>=20
> That was not the intent. We may weak the wording, if that's an issue.
>=20
> We don't want to endorse anything. But as there are numerous stacks tha=
t
> implement the behavior in RFC 5461, this was noted. In particular,
> implementation of RFC 5461 is quite popular in the v6 world, and
> probably expected (for instance, that's where the soft-errors I-D was b=
orn)

Repeating it is endorsing it. I don't agree with either.

>>    This document describes a non-standard, but widely implemented,
>>    modification to TCP's handling of ICMP soft error messages
>>
>> This is why I consider some of the suggestions and discussion in this
>> document to be based on what has been deployed, and is clearly the
>> opinion of some individuals, but not the advice of TCPM.
>=20
> Why do you think we're endorsing RFC 5461? The idea was to mention that=

> if you filter soft errors, then the non-standard workaround described i=
n
> RFC5461 will fail. That's it.

The text (see ** above) says that you get long delays that could be
avoided by USING the nonstandard workarounds in 5461.

I.e., it says the opposite of what you're saying here, so at best the
text needs revision if that's the case.

>>>>   document shouldn't repeat that discussion; it should refer to the
>>>>   tcpm discussion. second thing, why and whether it's appropriate
>>>>   to check the contents of icmp messages, check checksums, check fie=
lds
>>>>   inside. example: check sequence number.=20
>>>
>>> Can you please point the specific section in the icmp-filtering I-D t=
hat
>>> recommends this? (or that even mentions this???)
>>
>> My point is that the icmp-filtering doc makes ample reference to the
>> tcpm-icmp-attacks doc, without stating that the mechanisms in that tcp=
m
>> doc are not necessarily appropriate.
>=20
> The reference to icmp-attacks is for the description of the
> vulnerabilities, rather than for the counter-measures. Yes, it does
> references icmp-attacks. But it doesn't endorse the countermeasures. --=

> It does not even mention them!

That's worth noting explicitly, e.g., as a note somewhere (e.g., in the
background or intro) - i.e., the following doc is cited to explain the
details of certain attacks, but also includes countermeasures that this
document does not endorse.
=2E..

> I'll note that of RFC5461 being "widely deployed, but non-standard" in
> the next rev. If you have any specific proposal for the wording, please=

> post it. ...

See just above. I think we're agreeing on this, but it does need
clarification in the doc.

Joe


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkvHmlsACgkQE5f5cImnZrtoTgCgkl+f5xiXoVhpIMuUJ62WlBO7
OykAoJECrV9jCrWXqrWdohBxv2hQpkL0
=XVG0
-----END PGP SIGNATURE-----

--------------enigE93D3B4452199C79E11FB8E2--

From fernando.gont.netbook.win@gmail.com  Thu Apr 15 16:23:58 2010
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCDD3A6A87 for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 16:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.34
X-Spam-Level: 
X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgqm8hGeyXbL for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 16:23:56 -0700 (PDT)
Received: from mail-yx0-f117.google.com (mail-yx0-f117.google.com [209.85.210.117]) by core3.amsl.com (Postfix) with ESMTP id B365F3A6AA5 for <opsec@ietf.org>; Thu, 15 Apr 2010 16:23:35 -0700 (PDT)
Received: by yxe15 with SMTP id 15so116375yxe.5 for <opsec@ietf.org>; Thu, 15 Apr 2010 16:23:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Kvqre/rAtBoqRcjnNUB+5mNRb8ytfUvoBYh5IU8DraU=; b=uvdRkj0dLklLETXzh2WDgZi04o8stzcJ5c+z375FYjouM8SHn/4aBk4sCC8FKMCvhl nvTHpfW+cdoXqmkt5oFPAohQ8fz0S/iJWec2b4Y33bU7AGXAHK1iKyvGXQKsRYbBBokM jpOJ5jaAIPLj5BKMaE6NejsLpZYIj3ijUIVV0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=GniMrdGpiR0CtnPc2mav10t9g5cTmZTSnEXPHF75jKbozCTL3i8CZMyNuG5A1wS2ET HXht14wYRPEHncsrZTz1ECemyyqO8fJZOIFMGf3SZXz0eomqEwq8I9zgdHNihvSo3/nO vOpZoYvGceLffTnL6kJqKHkZKEgDkYiA8Yka0=
Received: by 10.101.197.14 with SMTP id z14mr1660717anp.57.1271373805478; Thu, 15 Apr 2010 16:23:25 -0700 (PDT)
Received: from [192.168.0.124] (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 30sm6005328anp.11.2010.04.15.16.23.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 16:23:24 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4BC79FDC.1060704@gont.com.ar>
Date: Thu, 15 Apr 2010 20:23:08 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu> <4BC3FC3B.2030101@gont.com.ar> <4BC79A5B.3010809@isi.edu>
In-Reply-To: <4BC79A5B.3010809@isi.edu>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2010 23:23:58 -0000

Joe Touch wrote:

>>> This implicitly endorses the soft errors solution, which, as noted in
>>> RFC5461 in the abstract:
>> That was not the intent. We may weak the wording, if that's an issue.
>>
>> We don't want to endorse anything. But as there are numerous stacks that
>> implement the behavior in RFC 5461, this was noted. In particular,
>> implementation of RFC 5461 is quite popular in the v6 world, and
>> probably expected (for instance, that's where the soft-errors I-D was born)
> 
> Repeating it is endorsing it. I don't agree with either.

That's *your* take. Again, I will note that of "widely implemented, but
non-standard behavior", though.



>>>    This document describes a non-standard, but widely implemented,
>>>    modification to TCP's handling of ICMP soft error messages
>>>
>>> This is why I consider some of the suggestions and discussion in this
>>> document to be based on what has been deployed, and is clearly the
>>> opinion of some individuals, but not the advice of TCPM.
>> Why do you think we're endorsing RFC 5461? The idea was to mention that
>> if you filter soft errors, then the non-standard workaround described in
>> RFC5461 will fail. That's it.
> 
> The text (see ** above) says that you get long delays that could be
> avoided by USING the nonstandard workarounds in 5461.
> 
> I.e., it says the opposite of what you're saying here, so at best the
> text needs revision if that's the case.

Ok, will do.



>>>>>   document shouldn't repeat that discussion; it should refer to the
>>>>>   tcpm discussion. second thing, why and whether it's appropriate
>>>>>   to check the contents of icmp messages, check checksums, check fields
>>>>>   inside. example: check sequence number. 
>>>> Can you please point the specific section in the icmp-filtering I-D that
>>>> recommends this? (or that even mentions this???)
>>> My point is that the icmp-filtering doc makes ample reference to the
>>> tcpm-icmp-attacks doc, without stating that the mechanisms in that tcpm
>>> doc are not necessarily appropriate.
>> The reference to icmp-attacks is for the description of the
>> vulnerabilities, rather than for the counter-measures. Yes, it does
>> references icmp-attacks. But it doesn't endorse the countermeasures. --
>> It does not even mention them!
> 
> That's worth noting explicitly, e.g., as a note somewhere (e.g., in the
> background or intro) - i.e., the following doc is cited to explain the
> details of certain attacks, but also includes countermeasures that this
> document does not endorse.

Joe, do we really need to start polluting this doc, and make it result
in 100-page of disclaimers?

Your argument has been considered. But your voice (by itself) does not
represent wg consensus for such a change.



> ...
> 
>> I'll note that of RFC5461 being "widely deployed, but non-standard" in
>> the next rev. If you have any specific proposal for the wording, please
>> post it. ...
> 
> See just above. I think we're agreeing on this, but it does need
> clarification in the doc.

Will fix this as noted above (i.e., "if you filter soft errors, then the
non-standard workaround described in RFC5461 will fail...").

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





From touch@ISI.EDU  Thu Apr 15 17:09:29 2010
Return-Path: <touch@ISI.EDU>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76153A6846 for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 17:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnLTp30sSCxB for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 17:09:29 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 1285B3A6AD1 for <opsec@ietf.org>; Thu, 15 Apr 2010 17:09:29 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o3G08mW3000809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2010 17:08:49 -0700 (PDT)
Message-ID: <4BC7AA8F.7000405@isi.edu>
Date: Thu, 15 Apr 2010 17:08:47 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu> <4BC3FC3B.2030101@gont.com.ar> <4BC79A5B.3010809@isi.edu> <4BC79FDC.1060704@gont.com.ar>
In-Reply-To: <4BC79FDC.1060704@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig96FE1EAB6E55BE1B69BBC596"
X-MailScanner-ID: o3G08mW3000809
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 00:09:30 -0000

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

Keeping this short...

Fernando Gont wrote:
=2E..
>>>>>>   document shouldn't repeat that discussion; it should refer to th=
e
>>>>>>   tcpm discussion. second thing, why and whether it's appropriate
>>>>>>   to check the contents of icmp messages, check checksums, check f=
ields
>>>>>>   inside. example: check sequence number.=20
>>>>> Can you please point the specific section in the icmp-filtering I-D=
 that
>>>>> recommends this? (or that even mentions this???)
>>>> My point is that the icmp-filtering doc makes ample reference to the=

>>>> tcpm-icmp-attacks doc, without stating that the mechanisms in that t=
cpm
>>>> doc are not necessarily appropriate.
>>> The reference to icmp-attacks is for the description of the
>>> vulnerabilities, rather than for the counter-measures. Yes, it does
>>> references icmp-attacks. But it doesn't endorse the countermeasures. =
--
>>> It does not even mention them!
>> That's worth noting explicitly, e.g., as a note somewhere (e.g., in th=
e
>> background or intro) - i.e., the following doc is cited to explain the=

>> details of certain attacks, but also includes countermeasures that thi=
s
>> document does not endorse.
>=20
> Joe, do we really need to start polluting this doc, and make it result
> in 100-page of disclaimers?

That's *your* take. Mine is that this is needed for understanding the
context and avoiding giving a mistaken impression to the reader.

> Your argument has been considered. But your voice (by itself) does not
> represent wg consensus for such a change.

Agreed. And your voice (by itself) doesn't represent WG consensus for
when an argument has been considered (as you claim above) or whether a
change is needed or not.

>>> I'll note that of RFC5461 being "widely deployed, but non-standard" i=
n
>>> the next rev. If you have any specific proposal for the wording, plea=
se
>>> post it. ...
>> See just above. I think we're agreeing on this, but it does need
>> clarification in the doc.
>=20
> Will fix this as noted above (i.e., "if you filter soft errors, then th=
e
> non-standard workaround described in RFC5461 will fail...").

At this point, I'd like to point out that the repeated mention of a
nonstandard workaround is *itself* pollution, which could just as easily
be omitted.

Joe


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkvHqo8ACgkQE5f5cImnZru34ACg05B0rgi7CDM55eeSoMbyx33f
dbMAoNUsliEEqZLpxnA8Hb7Pq1LDMuwf
=VLuG
-----END PGP SIGNATURE-----

--------------enig96FE1EAB6E55BE1B69BBC596--

From fernando.gont.netbook.win@gmail.com  Thu Apr 15 17:42:06 2010
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC083A697A for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 17:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level: 
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVaHmbzaDqy1 for <opsec@core3.amsl.com>; Thu, 15 Apr 2010 17:42:05 -0700 (PDT)
Received: from mail-vw0-f66.google.com (mail-vw0-f66.google.com [209.85.212.66]) by core3.amsl.com (Postfix) with ESMTP id 4F2E73A69F4 for <opsec@ietf.org>; Thu, 15 Apr 2010 17:42:05 -0700 (PDT)
Received: by vws10 with SMTP id 10so138412vws.1 for <opsec@ietf.org>; Thu, 15 Apr 2010 17:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=5cHoURxPAEBVQuiWtxQxjByOeBWDfRUhkPtySHcDW/s=; b=O+dbGT61xGybqV/MLzjfpw75DZAlSRGouuH80HXNMZB08svJvFEb5T21AZK30Jpzib tgkqscc/7o7eHf+oLsbPgSD8Blfew/oLJnI8fXndsiBTgMTCs1KQgVM2IMoW0v45gbLe 4c9i0Uoel6jK2gwNVf77wqYUs/v1QNSeeLMYg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=EKQN0QJpYIpDfXK+qGL5Vs+778tY0kYW7p2gNCKjDPgrHghkPYmL/UlGSEw6+wiLwR l4zKAUcH8Dj5sdhFZyZZtwH42joISsUWUqRsso7TY1s2vGt2WKgKvArmE/0SLn3qgVtB zP2eNCJ+RgAxrPTB2fBr2zOk0hAvLbYTr6ijM=
Received: by 10.220.124.214 with SMTP id v22mr466672vcr.101.1271378515762; Thu, 15 Apr 2010 17:41:55 -0700 (PDT)
Received: from [192.168.0.124] (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id z22sm652705vco.10.2010.04.15.17.41.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 17:41:55 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4BC7B242.2030204@gont.com.ar>
Date: Thu, 15 Apr 2010 21:41:38 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu> <4BC3FC3B.2030101@gont.com.ar> <4BC79A5B.3010809@isi.edu> <4BC79FDC.1060704@gont.com.ar> <4BC7AA8F.7000405@isi.edu>
In-Reply-To: <4BC7AA8F.7000405@isi.edu>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 00:42:06 -0000

Joe Touch wrote:

>>> That's worth noting explicitly, e.g., as a note somewhere (e.g., in the
>>> background or intro) - i.e., the following doc is cited to explain the
>>> details of certain attacks, but also includes countermeasures that this
>>> document does not endorse.
>> Joe, do we really need to start polluting this doc, and make it result
>> in 100-page of disclaimers?
> 
> That's *your* take. 

Agreed.


>> Your argument has been considered. But your voice (by itself) does not
>> represent wg consensus for such a change.
> 
> Agreed. And your voice (by itself) doesn't represent WG consensus for
> when an argument has been considered (as you claim above) or whether a
> change is needed or not.

I have considered your argument. If there's strong consensus for that
change, of course I'll apply it. that's it.


>>>> I'll note that of RFC5461 being "widely deployed, but non-standard" in
>>>> the next rev. If you have any specific proposal for the wording, please
>>>> post it. ...
>>> See just above. I think we're agreeing on this, but it does need
>>> clarification in the doc.
>> Will fix this as noted above (i.e., "if you filter soft errors, then the
>> non-standard workaround described in RFC5461 will fail...").
> 
> At this point, I'd like to point out that the repeated mention of a
> nonstandard workaround is *itself* pollution, which could just as easily
> be omitted.

Joe, what's the change you expect? You mention a problem. I propose a
solution, but you don't like it.

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





From touch@ISI.EDU  Fri Apr 16 06:52:41 2010
Return-Path: <touch@ISI.EDU>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F473A6C13 for <opsec@core3.amsl.com>; Fri, 16 Apr 2010 06:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.19
X-Spam-Level: 
X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM1WgDSlOlrq for <opsec@core3.amsl.com>; Fri, 16 Apr 2010 06:52:41 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 20D093A6B99 for <opsec@ietf.org>; Fri, 16 Apr 2010 06:47:09 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o3GDkCix001918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Apr 2010 06:46:13 -0700 (PDT)
Message-ID: <4BC86A24.6090809@isi.edu>
Date: Fri, 16 Apr 2010 06:46:12 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <4BC3E2FF.4050101@gont.com.ar> <4BC3EC2E.30509@isi.edu> <4BC3FC3B.2030101@gont.com.ar> <4BC79A5B.3010809@isi.edu> <4BC79FDC.1060704@gont.com.ar> <4BC7AA8F.7000405@isi.edu> <4BC7B242.2030204@gont.com.ar>
In-Reply-To: <4BC7B242.2030204@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3C1F9ACB0BB02E741837956"
X-MailScanner-ID: o3GDkCix001918
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] A clarification on icmp-filtering I-D
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 13:52:41 -0000

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



Fernando Gont wrote:
=2E..
>>>>> I'll note that of RFC5461 being "widely deployed, but non-standard"=
 in
>>>>> the next rev. If you have any specific proposal for the wording, pl=
ease
>>>>> post it. ...
>>>> See just above. I think we're agreeing on this, but it does need
>>>> clarification in the doc.
>>> Will fix this as noted above (i.e., "if you filter soft errors, then =
the
>>> non-standard workaround described in RFC5461 will fail...").
>> At this point, I'd like to point out that the repeated mention of a
>> nonstandard workaround is *itself* pollution, which could just as easi=
ly
>> be omitted.
>=20
> Joe, what's the change you expect? You mention a problem. I propose a
> solution, but you don't like it.

I'll repeat the solution:

Avoid repeated mention (and thus, IMO, implied endorsement) of a
nonstandard workaround as being affected by soft error filtering.

That issue is worth - at best - one mention in this doc. It is not worth
noting at every single soft error affected.

Joe


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkvIaiQACgkQE5f5cImnZrsxlwCbBiagt8vYec+uCk5wmaUnsCIE
DvEAmgJwh8vJYyeK3vLvNXo9Y+6e2d6o
=qsC5
-----END PGP SIGNATURE-----

--------------enigC3C1F9ACB0BB02E741837956--

From joelja@bogus.com  Sun Apr 18 11:39:08 2010
Return-Path: <joelja@bogus.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE3428C134 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.627
X-Spam-Level: 
X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPgj3He9EWmG for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:08 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 9807728C136 for <opsec@ietf.org>; Sun, 18 Apr 2010 11:38:55 -0700 (PDT)
Received: from [192.168.2.101] (m355636d0.tmodns.net [208.54.86.53]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3IIcfXR029910 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <opsec@ietf.org>; Sun, 18 Apr 2010 18:38:46 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BCB49DB.8020104@bogus.com>
Date: Sun, 18 Apr 2010 11:05:15 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100404 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 18 Apr 2010 18:38:47 +0000 (UTC)
Subject: [OPSEC] draft-ietf-opsec-ip-security-03
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2010 18:39:08 -0000

http://tools.ietf.org/html/draft-ietf-opsec-ip-security-03

has been published by Fernando, reflecting the changes made as a result
of last call commentary.

diff2 is here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-ip-security-03.txt

if yu have anything to add it would be helpful if it were done this week.

joel

From joelja@bogus.com  Sun Apr 18 11:39:14 2010
Return-Path: <joelja@bogus.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1CC28C123 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.585
X-Spam-Level: 
X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=1.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w4u0SEaa5l9 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:13 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 90D7228C13A for <opsec@ietf.org>; Sun, 18 Apr 2010 11:39:12 -0700 (PDT)
Received: from [192.168.2.101] (m455636d0.tmodns.net [208.54.86.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3IIcvjs029918 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 18 Apr 2010 18:39:03 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BCB4CCB.60803@bogus.com>
Date: Sun, 18 Apr 2010 11:17:47 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100404 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>, David Dugal <ddugal@juniper.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 18 Apr 2010 18:39:04 +0000 (UTC)
Subject: [OPSEC] Test for acceptance as WG document draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2010 18:39:14 -0000

http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-02

was discussed at IETF 77 and previous drafts have hadfeedback from this
this list lodged against them...

This email kicks of the mailing list call for consensus to accept this
work as a working group document.

Commentary in the wg meeting was as noted in the minutes was favorable
among those who had read it. and subsequent comments on the list hae
also been favorable, this exercise is intended to formalize that
understanding.

Deadline for commnentary is sunday april 25th.

thanks
joel

From joelja@bogus.com  Sun Apr 18 11:39:38 2010
Return-Path: <joelja@bogus.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112BA28C132 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level: 
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRli0f8nfPol for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:37 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 5A4EB28C133 for <opsec@ietf.org>; Sun, 18 Apr 2010 11:39:36 -0700 (PDT)
Received: from [192.168.2.101] (m455636d0.tmodns.net [208.54.86.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3IIdBxc029922 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 18 Apr 2010 18:39:26 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BCB50A5.9010805@bogus.com>
Date: Sun, 18 Apr 2010 11:34:13 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100404 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>, David Dugal <ddugal@juniper.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 18 Apr 2010 18:39:27 +0000 (UTC)
Subject: [OPSEC] comments: draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2010 18:39:38 -0000

Some thoughts as a contributor not as working group chair...

I'd like to see the configuration examples in appendix a and b extended
to handle the ipv6 case as well.

In the juniper section I think the icmp rule is missing a directive:

               term icmp {
                   from {
                       protocol icmp;
                   }
                   policer 2Mbps;
		^
		then?

                   then accept;
               }

at least with the router I have to the lab running 10.1 it doesn't
accept that stanza as written.

From joelja@bogus.com  Sun Apr 18 11:39:51 2010
Return-Path: <joelja@bogus.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B10E28C139 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.323
X-Spam-Level: 
X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_50=0.001, J_CHICKENPOX_74=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9wUU6mb8Qkw for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:39:49 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 9D34128C132 for <opsec@ietf.org>; Sun, 18 Apr 2010 11:39:49 -0700 (PDT)
Received: from [192.168.2.101] (m455636d0.tmodns.net [208.54.86.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3IIdZa4029943 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <opsec@ietf.org>; Sun, 18 Apr 2010 18:39:40 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BCB5172.9020901@bogus.com>
Date: Sun, 18 Apr 2010 11:37:38 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100404 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>
References: <4BC3D35F.5020707@bogus.com>
In-Reply-To: <4BC3D35F.5020707@bogus.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 18 Apr 2010 18:39:41 +0000 (UTC)
Subject: Re: [OPSEC] Draft IETF 77 minutes
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2010 18:39:51 -0000

since there are been no corrections to the minutes I will submit them as
final.

Thanks
joel

On 04/12/2010 07:13 PM, Joel Jaeggli wrote:
> Thanks to the efforts of Joe Abley and the jabber room posters.
> Appologies for the the delay, the credit for that is all mine.
> 
> Tue 23 Mar 2010 17:39:47 PDT
> 
> opsec, IETF 77
> 
> note-taker joe abley
> chairs joel jaeggli, joe abley
> 
> 0. Agenda
> 
> 1. achievements since ietf 76
> 
>   (slides presented by joel jaeggli)
> 
> 2. document status
> 
> re: raft-ietf-opsec-ip-security:
> 
> ron bonica: for draft-ietf-opsec-ip-security, we might want to also ask
>   for review in the ops area.
> 
> re: draft-ietf-opsec-routing-protocols-crypto-issues:
> 
> ron bonica: I don't know who the expert reviewer is for draft-
>   ietf-opsec-routing-protocols-crypto-issues
> 
> ron bonica: BGP/MD5 will be obsolete in a day or two, section 5.2 of
>   the draft talks about BGP/MD5
> 
> joel: we should revisit that
> 
> re: draft-ietf-opsec-igp-crypto-requirements
> 
> rich graveman: if people are using md5 for security and they have
>   nothing else, and they read this document and turn it off, that's
>   probably bad
> 
> joel: the document does attempt to call this out
> 
> ...
> 
> joel: what to do with this document before last call?
> 
> ron bonica: I think the section on BGP needs to be re-thought.
> 
> joe touch: see a handful of documents that are having a rough time in
>   tcpm. is there any coordination going on between the two areas? it
>   seems that things are doing end runs here. specifically
>   icmp-filtering. don't understand why we need another document on that.
> 
> ron bonica: rationale is that many ISPs block ICMP messages. There are
>   some ISPs that let everything through. Others let some through, e.g.
>   for pMTU discovery, but others they drop. what I wanted was a
>   discussion for each ICMP message to allow an ISP to make informed
>   decisions.
> 
> joe touch: some decisions are being made on what has been deployed,
>   opinions of some individuals. had this discussion in tcpm. this
>   document shouldn't repeat that discussion; it should refer to the
>   tcpm discussion. second thing, why and whether it's appropriate
>   to check the contents of icmp messages, check checksums, check fields
>   inside. example: check sequence number. routers have no requiremnt
>   to respond to icmp in a timely fashion; this can trip things up.
>   worried about whether we are delaing with this set of issues in
>   completely separate wgs that don't talk to each other.
> 
> joel: some danger of that. would observe that we have gone back and
>   forth in this wg as to whether a document like this should be
>   prescriptive. consensus of the wg was that it was more important to
>   characterise what you would lose by filtering than whether you should
>   filter.
> 
> ron bonica: first, agree with joe touch re referencing rather than
>   reiterating. we should reference when we can. second, we should
>   probably send the doc for external review, and send instructions for
>   reviewer. document's goals are to explain what you lose if ou filter,
>   what you  risk if you don't filter, let the operator make an informed
>   decision. what we want is for him to make an informed decision.
> 
> joel: re original charters, pushing security requirements on vendors and
>   by extension their customers tends not to be popular. if driven by
>   application requirement that's great, but simply saying this is the
>   way you should build your equipment and you need this features is not
>   an easy sell. not something that I could have taken back to my then
>   employer, for example.
> 
> joe touch: is that the intent of most documents here? I can see some of
>   that coming out. ip security document has recommendations splattered
>   all over the place and some of htem are insane.
> 
> joel: ...
> 
> joe touch: that document contains things that are insane. this speaks
>   poorly to the competence of the working group. e.g. saying that
>   everybody should always block LSR, that's insane. "a packet you did
>   not expect is not a threat." the end state is that everybody will have
>   to run their protocols over HTTP.
> 
> joel: firewalls apply policy to unsolicited packets. that's what they
>   do. in the context of icmp filtering, the document characterises the
>   consequences of applying that policy.
> 
> ron bonica: couple of words about our charter. this is an ops area wg.
>   because we're in the ops area we don't get to change protocols, ever.
>   we don't get to deprecate ip options. what we can discuss is whether
>   an operator... we can talk about threat models, and we can talk about
>   what those features offer than an operator would lose if he filtered
>   them. give oeprators information so they can make informed decisions.
> 
> joel: in the context of LSR for example, as a strawman, I think it's
>   entirely reasonable to say these are the consequences of carrying
>   them.
> 
> david borman: co chair for the tcpm wg. on lsr, those options have been
>   an issue from the early days and the main reason is that
>   implementations ignore them. I think the cat's out of the bag on
>   those, that trying to say that you shouldn't block those -- I don't
>   think we can ever resurrect those the way they were intended. in
>   general though, e.g. icmp filtering, it would be great to get it
>   passed through the tcpm wg. glacing through it I noticed a lot of
>   TBDs.
> 
> joel: yes, the section is not complete yet. difficult for it to make
>   progress when contributions have not yet been incorporated, when the
>   doc is not yet finished.
> 
> david: some people in the tcpm wg could help fill in some of those TBDs.
> 
> joel: that would be helpful.
> 
> david: suggest the doc be sent to the tcpm wg as a working draft and
>   ask for contributions and review.
> 
> joel: additional authors would be very welcome.
> 
> joel: you guys have the tcp security assessment being socialised in your
>   wg?
> 
> david: fernando's tcp document we have that in tcpm wg and tomorrow
>   morning we are having a separate session at 1015-1030 in pacific a
>   to walk through that document to identify those items that we feel
>   are non-controversial. goal is to move that document forward. very
>   much like the format of hte icmp filtering draft.
> 
> 3. new work
> 
> draft-dugal-opsec-protect-control-plane-02
> 
>   (david dugal presenting from slides)
> 
> rich graveman: have not read the whole doc. don't see you talk about using
>   security technology where we have it, e.g. it doesn't refer to OSPF
>   with SHA1 integrity protection. no DNSSEC. you don't use security!
> 
> david: in our initial design we wanted to limit the scope to just
>   control plane filters, e.g. lo0 filters in JUNOS. That's not to say
>   there shouldn't be additional recommendations. please mention that on
>   mailing list or by private mail.
> 
> ron bonica: I think much of that stuff is out of scope for this
>   document. it may be that we want to do another document on the
>   applications we run upon the control plane. but this draft is drawing
>   attention to the firewall beteween the control plana and the data
>   plane.
> 
> rich graveman: this draft contains no security!
> 
> chris morrow: no. there is a place for use of crypto in routing
>   protocols, for dns hygeine, but this draft's purpose is controlling
>   who can talk to my router.
> 
> rich: but using keys, not ip addresses!
> 
> chris: no [etc]
> 
>   (much animated discussion, following some agreement that this is a
>   conversation that can happen on the mailing list.)
> 
> brian wise: draft says protect your control plane and gives some
>   some examples, so I don't think BCP. I think it woudl be valuable
>   though if the document contained specific advice for (e.g.)
>   BGP-speaking routers.
> 
> joel: personal opinion is that to the extent it's possible vendor-
>   specific examples should appear in appendices.
> 
> david: the more specific we get to a particular network design the less
>   relevant it becomes to other ones. but there are some key roles that
>   might be worth considering.
> 
> rich graveman: GMPLS, CCAMP, when they say control plane they mean
>   something different. I understand you're talking about the IP
>   router control plane. the phrase "control plane" is a little
>   overloaded.
> 
> ron bonica: the words "control plane" are applicable. these things are
>   all control planes.
> 
> rich graveman: correct, was suggesting the scope be reduced.
> 
> joel: think there's room to iterate on scope.
> 
> danny mcpherson: this is more about access to the devices, rather than
>   the protocols themselves. but this about route processor handling
>   in network devices, that's the primary motiviation, to protect these
>   things. this is about access to those devices. but also
>   infrastructure ACLs at the network perimeter, etc. perhaps also
>   belongs here, or maybe a separate document.
> 
> david: we did think about that, but we also wanted to focus this
>   document on protecting the control plane
> 
> rudiger volk: router control plane might be a better phrase
> 
> george: haven't read draft. when we implemented these layers of
>   protection in our network we spent time categorising what was hitting
>   the box to start with. this allowed us to characterise the traffic,
>   iterative process of refining. perhaps instead of specific examples,
>   describe a methodology. characterise traffic so you know what you
>   care about. any bcp that talks about protecting the control plane
>   definitely has to talk about that characterisation step.
> 
> warren kumari: should consider the audience of the document. document
>   describes the architecture of a router, then jumps to "let's make a
>   filter". If it's going to start that basic, it ought to provide more
>   guidance for *how* to derive suitable filters.
> 
> david: intent was to keep it introductory. concern I had was the
>   routers in the world that are completely unprotected.
> 
> warren: but unprotected routers are probably run by people who don't
>   know *how* to filter.
> 
> chris: some of what richard brought up earlier, e.g. optical platforms,
>   GMPLS, etc. nice if we had same protections not just for routers and
>   switches but also for layer-1. Optical vendors have a lack of
>   appreciation for this. it would be nice if whatever came out wasn't
>   completely router-only. nothing there that couldn't be used to
>   support a requirements document for other types of equipment.
> 
> joel: this doc generated some healthy discussion in the room and on
>   the list. suggests people have read it. makes me want to ask some
>   questions. who in the room has read it? [ten hands or so.]
> 
> joel: anybody have an opinion on accepting this as a wg document? the
>   list is the final arbiter.
> 
> wes george: I believe this should be a wg doc.
> 
> warren: me too
> 
> rich: me too, 100%
> 
> joel: we will take this an action item after this meeting to poll the
>   list for adoption. thank you.
> 
> warren: what about bcp vs. informational?
> 
> ron: I'm not going to give an opinion, but friendly advice. info is much
>   easier than bcp. bcp is a club for beating other document authors.need
>   to assess whether you need that club.
> 
> danny: referencing rfc 1812 might be useful. provides some terminology.
> 
> david: we reference a section of 1812 but we could look at expanding it.
> 
> 4. any additional agenda items
> 
>   (no other business)
> 
> joel: that concludes our programme.
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> 

From Donald.Smith@qwest.com  Sun Apr 18 11:40:39 2010
Return-Path: <Donald.Smith@qwest.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A484D3A6AA1 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level: 
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930,  BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SGIiUZ0VPF4 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 11:40:38 -0700 (PDT)
Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id AF77A3A6872 for <opsec@ietf.org>; Sun, 18 Apr 2010 11:40:38 -0700 (PDT)
Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o3IIeSvX028679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 18 Apr 2010 12:40:28 -0600 (MDT)
Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o3IIeMP1006462; Sun, 18 Apr 2010 13:40:23 -0500 (CDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Sun, 18 Apr 2010 12:40:22 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: Joel Jaeggli <joelja@bogus.com>, "'opsec@ietf.org'" <opsec@ietf.org>, David Dugal <ddugal@juniper.net>
Content-Class: urn:content-classes:message
Date: Sun, 18 Apr 2010 12:40:19 -0600
Thread-Topic: [OPSEC] Test for acceptance as WG document draft-dugal-opsec-protect-control-plane-02
Thread-Index: AcrfJm9PqWIxTejgTEeZhHZekZFhVgAAB4vWAAACsT0=
Message-ID: <E6E684A6-8781-40BD-A87A-9DD09FAE90C2@mimectl>
References: <4BCB4CCB.60803@bogus.com>
In-Reply-To: <4BCB4CCB.60803@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-mimectl: Produced By Microsoft Exchange V8.2.176.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OPSEC] Test for acceptance as WG document	draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Apr 2010 18:40:39 -0000

I support this proposal.

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@qwest.com<mailto:Donald.Smith@qwest.com>
________________________________
From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Joel Jae=
ggli [joelja@bogus.com]
Sent: Sunday, April 18, 2010 12:17 PM
To: 'opsec@ietf.org'; David Dugal
Subject: [OPSEC] Test for acceptance as WG document draft-dugal-opsec-prote=
ct-control-plane-02

http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-02

was discussed at IETF 77 and previous drafts have hadfeedback from this
this list lodged against them...

This email kicks of the mailing list call for consensus to accept this
work as a working group document.

Commentary in the wg meeting was as noted in the minutes was favorable
among those who had read it. and subsequent comments on the list hae
also been favorable, this exercise is intended to formalize that
understanding.

Deadline for commnentary is sunday april 25th.

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

________________________________
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

From christopher.morrow@gmail.com  Sun Apr 18 20:13:41 2010
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744B73A6A59 for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 20:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.052
X-Spam-Level: 
X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=1.548,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1-GFDIAlytx for <opsec@core3.amsl.com>; Sun, 18 Apr 2010 20:13:40 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 931073A6933 for <opsec@ietf.org>; Sun, 18 Apr 2010 20:13:30 -0700 (PDT)
Received: by gyh4 with SMTP id 4so2432205gyh.31 for <opsec@ietf.org>; Sun, 18 Apr 2010 20:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JX9wMaAkaC/a3upRu/Ms4QlWNAkwQMJo1UF7g0Etkl0=; b=esxXrtXjMYrc87LiVFL40e2al/aOGzgeRq+I6T+EOrPP+bfdxtGqoA3kuJCCYeNihP 8Yaxnv0Dyzwn43YvzRqpkQwPKrypgYHs4RTfHhFfV4jrWAFNmIKfidBcx82y76MSzubX 6b+fN+tYa1gCu2c9ByoMGiKaQAbAxd5umZVhU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kaa9h1lm1gGHDpzBdPKHsrDW8xYYlmi/t5qkOTYFwErug6hjAV+xRjU6bAM+O94lf3 9U/E0YpRuFy6nSHNf/ZrKDUCH1BLk3IZBDiw6HgohBWUvq7s15Cow0XilrhGBT5baxte Yb1jViY7ja7ohqjN46G5sfVvGLOEfRhe0ApEc=
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.231.156.135 with HTTP; Sun, 18 Apr 2010 20:13:18 -0700 (PDT)
In-Reply-To: <E6E684A6-8781-40BD-A87A-9DD09FAE90C2@mimectl>
References: <4BCB4CCB.60803@bogus.com> <E6E684A6-8781-40BD-A87A-9DD09FAE90C2@mimectl>
Date: Sun, 18 Apr 2010 23:13:18 -0400
X-Google-Sender-Auth: 420471bc49877c52
Received: by 10.150.120.2 with SMTP id s2mr5206323ybc.278.1271646798869; Sun,  18 Apr 2010 20:13:18 -0700 (PDT)
Message-ID: <v2h75cb24521004182013qbca587ebj9e737faa202c374b@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Smith, Donald" <Donald.Smith@qwest.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] Test for acceptance as WG document draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 03:13:41 -0000

ditto

On Sun, Apr 18, 2010 at 2:40 PM, Smith, Donald <Donald.Smith@qwest.com> wro=
te:
> I support this proposal.
>
> (coffee !=3D sleep) & (!coffee =3D=3D sleep)
> =A0Donald.Smith@qwest.com<mailto:Donald.Smith@qwest.com>
> ________________________________
> From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Joel J=
aeggli [joelja@bogus.com]
> Sent: Sunday, April 18, 2010 12:17 PM
> To: 'opsec@ietf.org'; David Dugal
> Subject: [OPSEC] Test for acceptance as WG document draft-dugal-opsec-pro=
tect-control-plane-02
>
> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-02
>
> was discussed at IETF 77 and previous drafts have hadfeedback from this
> this list lodged against them...
>
> This email kicks of the mailing list call for consensus to accept this
> work as a working group document.
>
> Commentary in the wg meeting was as noted in the minutes was favorable
> among those who had read it. and subsequent comments on the list hae
> also been favorable, this exercise is intended to formalize that
> understanding.
>
> Deadline for commnentary is sunday april 25th.
>
> thanks
> joel
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>
> ________________________________
> This communication is the property of Qwest and may contain confidential =
or
> privileged information. Unauthorized use of this communication is strictl=
y
> prohibited and may be unlawful. If you have received this communication
> in error, please immediately notify the sender by reply e-mail and destro=
y
> all copies of the communication and any attachments.
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>

From ddugal@juniper.net  Mon Apr 19 10:26:29 2010
Return-Path: <ddugal@juniper.net>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41E73A6B1A for <opsec@core3.amsl.com>; Mon, 19 Apr 2010 10:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.74
X-Spam-Level: 
X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iog2ZS-9XBN for <opsec@core3.amsl.com>; Mon, 19 Apr 2010 10:26:28 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id A39F83A6BF1 for <opsec@ietf.org>; Mon, 19 Apr 2010 10:20:46 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKS8yQ1NpJuGIBB5uE47c2GOR5aJ82JkGR@postini.com; Mon, 19 Apr 2010 10:20:46 PDT
Received: from [127.0.0.1] (172.28.40.119) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.436.0; Mon, 19 Apr 2010 10:17:44 -0700
Message-ID: <4BCC8FB9.7010003@juniper.net>
Date: Mon, 19 Apr 2010 13:15:37 -0400
From: David Dugal <ddugal@juniper.net>
Organization: Juniper Networks, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Joel Jaeggli <joelja@bogus.com>
References: <4BCB50A5.9010805@bogus.com>
In-Reply-To: <4BCB50A5.9010805@bogus.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: "draft-dugal-opsec-protect-control-plane@tools.ietf.org" <draft-dugal-opsec-protect-control-plane@tools.ietf.org>, "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] comments: draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 17:26:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the comments, Joel.  The IPv6 suggestion is a recurring
theme.  We plan to add references to IPv6 in -03.

Not sure how that JUNOS typo got past the editors (me).  I'll fix it in
- -03 as well.

- - Dave

On Sun Apr 18 2010 14:34:13 GMT-0400 (Eastern Daylight Time), Joel
Jaeggli <joelja@bogus.com> proclaimed ...
> Some thoughts as a contributor not as working group chair...
> 
> I'd like to see the configuration examples in appendix a and b extended
> to handle the ipv6 case as well.
> 
> In the juniper section I think the icmp rule is missing a directive:
> 
>                term icmp {
>                    from {
>                        protocol icmp;
>                    }
>                    policer 2Mbps;
> 		^
> 		then?
> 
>                    then accept;
>                }
> 
> at least with the router I have to the lab running 10.1 it doesn't
> accept that stanza as written.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iEYEARECAAYFAkvMj7gACgkQh59lzatuAqWK0gCfSjcRMHmyNNS8N5zcJVmAZm0s
8AgAoIZt+MdqhuDR2gUyFcpvCAcMkSkf
=92el
-----END PGP SIGNATURE-----


From jason_livingood@cable.comcast.com  Wed Apr 21 08:28:38 2010
Return-Path: <jason_livingood@cable.comcast.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEF128C531 for <opsec@core3.amsl.com>; Wed, 21 Apr 2010 08:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.566
X-Spam-Level: ***
X-Spam-Status: No, score=3.566 tagged_above=-999 required=5 tests=[AWL=-2.035,  BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,  HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dEkPsn0JtG6 for <opsec@core3.amsl.com>; Wed, 21 Apr 2010 08:27:59 -0700 (PDT)
Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 6E1BC28C556 for <opsec@ietf.org>; Wed, 21 Apr 2010 08:01:27 -0700 (PDT)
Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.80351339; Wed, 21 Apr 2010 11:00:52 -0400
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 11:00:30 -0400
Received: from 147.191.227.151 ([147.191.227.151]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Apr 2010 15:00:29 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 21 Apr 2010 11:00:29 -0400
From: Jason Livingood <jason_livingood@cable.comcast.com>
To: "Smith, Donald" <Donald.Smith@qwest.com>, Joel Jaeggli <joelja@bogus.com>, Danny McPherson <danny@tcb.net>
Message-ID: <C7F48B4D.21D25%jason_livingood@cable.comcast.com>
Thread-Topic: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
Thread-Index: Acqtx42/UyVFz2xtQbKi5RBxrqoIrwAomV5oDL5bnCQ=
In-Reply-To: <B01905DA0C7CDC478F42870679DF0F100787A47F9A@qtdenexmbm24.AD.QINTRA.COM>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3354692430_4731869"
X-OriginalArrivalTime: 21 Apr 2010 15:00:30.0273 (UTC) FILETIME=[626BE310:01CAE163]
Cc: Mike O'Reirdan <michael_oreirdan@cable.comcast.com>, opsec wg mailing list <opsec@ietf.org>, Nirmal Mody <nirmal_mody@cable.comcast.com>
Subject: Re: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2010 15:28:38 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3354692430_4731869
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I=B9m just getting around to doing a =AD08 document update now that IETF-77 has
concluded.  (Joel=B9s feedback has been incorporated into =AD08 as well.)

Thanks for this feedback, now incorporated into
draft-oreirdan-mody-bot-remediation-08 (
http://www.ietf.org/id/draft-oreirdan-mody-bot-remediation-08.txt).

Specific comments/replies inline below if you are so inclined.

Regards
Jason

On 2/15/10 1:16 PM, "Smith, Donald" <Donald.Smith@qwest.com> wrote:

>> >    This document contains recommendations on how Internet Service
>> >    Providers can manage the effects of computers used by their
> * subscribers, which have been infected with malicious bots, via
>=20
> donald: A bot is a tool. It can't really be malicious nor benign any more=
 that
> a gun, or screwdriver is malicious however I understand as this is widely
> used, incorrectly, within the industry. But malicious implies intent to d=
o
> harm.
> As long as that is addressed in the malicious bot/bot definition it's pro=
bably
> acceptable to use it in this way.
>=20
> [JL] Quite true.  I have tried to ensure when using bots in the doc that =
I am
> referring to malicious bots, rather than other bots which may have positi=
ve
> uses.  I try to define this at length in Terminology, Section 2.1.  (I
> received similar feedback from Robb Topolski in an earlier draft.)
>=20
>> >    various remediation techniques.  Internet users with infected
>> >    computers are exposed to risks such as loss of personal data, as we=
ll
>> >    as increased susceptibility to online fraud and/or phishing.  Such
>> >    computers can also become an inadvertent participant in or componen=
t
>> >    of an online crime network, spam network, and/or phishing network, =
as
>> >    well as be used as a part of a distributed denial of service attack=
.
>=20
> donald: The risks to users of infected systems and others are included/de=
fined
> in many places within this document.
> It should probably be defined clearly in one place and referenced in all =
other
> places.
>=20
> [JL] Fair point.  I=B9m going to call that out in my open issues list and
> address in a future version if I don=B9t have the chance to get it into -08=
.
>=20
>> > 2.1.  Malicious Bots, or Bots
>> >
>> >    A malicious "bot" (derived from the word "robot", hereafter simply
>=20
> donald: Malicious bot implies intent to do harm, while these are really b=
ots
> that can be used to perform potentially harmful tasks for the bot master.
> Perhaps potentially harmful bot?
>=20
> [JL] I=B9ve added a bunch of new text to 2.1 to address this.  Please let m=
e
> know if there=B9s anything that could be improved upon.
>=20
>> >    referred to as a "bot") refers to a program that is surreptitiously
>=20
> donald: Some times they are installed on purpose but the user doesn't
> understand the full functionality of the software installed or the amount=
 of
> remote control the application provides to the remote controller (bot mas=
ter)
>=20
> [JL] Ack, and addressed in 2.1 of the doc.
>=20
>> >    It is important to note that there are 'good', or benign bots.  Suc=
h
>> >    benign bots are often found in such environments such as gaming and
>> >    Internet Relay Chat (IRC) [RFC1459], where a continual, interactive
>> >    presence can be a requirement for participating in the games,
>> >    interacting with a computing resource, or other purposes.  Since su=
ch
>> >    benign bots are performing useful, lawful, and non-disruptive
>> >    functions, there is no reason for a provider to monitor for their
>> >    presence and/or alert users to their presence.
>=20
> donald: Again Benign implies intent. Perhaps harmless instead?
>=20
> [JL] I=B9ve retained benign since it seems to be used a great deal but adde=
d
> harmless as well: =B3Thus, while there may be benign, or harmless bots, for=
 the
> purposes of this document...=B2
>=20
>> >    include: identity theft, spam, distributed denial of service (DDoS)
>> >    attacks, key-logging, fraudulent DNS (pharming), proxy services, fa=
st
> * flux hosting and click fraud.
>=20
> donald: This is a pretty good risk identification. You might want to add =
spim,
> spit, email address harvesting, hosting of highly questionable or illegal
> content (BulletProof hosting), various MITM attacks (banking ssl ala Zeus=
) and
> web site scraping.
>=20
> [JL] Added =AD good suggestions.
>=20
>> >
>> >    Infection vectors include un-patched operating systems, software
>> >    vulnerabilities, weak/non-existent passwords, malicious websites, u=
n-
>> >    patched browsers, malware, vulnerable helper applications and socia=
l
>> >        engineering techniques to gain access to the user's computer.
>=20
> donald: The use of vulnerable and un-patched seems slightly redundant.
> An un-patched piece of software is likely to be vulnerable.
> I think your trying to cover the concept of un-patched vs zero day (no pa=
tch
> publicly available) exploitation.
>=20
> [JL] Correct. I modified to =B3... software vulnerabilities (which include
> so-called zero-day vulnerabilities where no patch yet exists)=B2
>=20
>> >         Initially, bots used IRC to communicate but were easy to shutd=
own
>> if
>=20
> donald: Initally SOME bots used IRC, Q, TFN, Trinoo, etc... all had non-I=
RC
> based control.
>=20
> [JL] Modified as suggested
>=20
>> >    Increasingly, other household systems and devices contain embedded
>> >    computers which are connected to or can connect to the public
>> >    Internet and/or private IP networks.  However, these devices may no=
t
>> >    be under interactive control of the Internet user, such as may be t=
he
>> >    case with various smart home and smart grid devices.
>=20
> donald: So do you intend for your computer definition to include smart ip
> enabled  devices or not. It's hard to tell from this definitation.
> I would limit the definition to computers that humans use as general purp=
ose
> computers.
>=20
> [JL] I did intend to refer to these sorts of devices.  As I have generali=
zed
> =B3computers=B2 to now be =B3hosts=B2 I=B9ve made some modifications to make this
> hopefully more clear in the next version.  But I expressly want to includ=
e
> both typical PC-type devices as well as, say, Internet-connected picture
> frames.
>=20
>> >    can sometimes cause their computer to be infected with malware, whi=
ch
>> >    may include a bot or cause a bot to install itself, via inadvertent=
ly
>> >    accessing a specific website, downloading a specific file, or other
>=20
> donald: a website, downloading a file ...
>=20
> [JL] Change made
>=20
>> >    Alternatively, Internet-connected computers may become infected wit=
h
> donald: Not really alternatively, since you mention vulnerabilities above=
 but
> I think your trying to say without user interaction (scan and spolit) rig=
ht?
>=20
> [JL] Correct.  Changed =B3Alternatively=B2 to =B3In other cases=B2
>=20
>> >    DNS Fast Flux is typically used in conjunction with proxies which
>> >    then route the web requests to the real host which serves the data
>> >    being sought.  The proxies are normally hosted on compromised user
>> >    computers.  The effect of this is to make the detection of the real
>> >    host for a piece of content much more difficult and to ensure that
>> >    the site remains up for as long as possible.
> donald: The backend/hidden site
>=20
> [JL] Change made
>=20
>> >    Threats in 2009 and Beyond].  Bots are frequently used as part of
>> >    concerted Distributed Denial of Service (DDoS) attacks for criminal=
,
> donald: coordinated
>=20
> [JL] Change made
>=20
>> >    operating in their networks.  Furthermore, ISPs may also be in a
>> >    unique position to be able to communicate to Internet users which a=
re
> donald: unique position to be able to notify their customers of potential
> infection by
> bots or other infections.
>=20
> [JL] Change made
>=20
>> >    From an end user perspective, knowing that their computer has been
> donald: From an end user perspective, being notified that they may have a=
n
> infected computer on their network is important information.
>=20
> [JL] change made
>=20
>> >    infected with one or more bots is very important information.  Once
>> >    they know this, they can take steps to remove the bot, protect
>> >    themselves in the future, and resolve any problems which may stem
>> >    from the bot infection.  Given that bots can drain local computing
> donald: Given that bots can consume vast amounts of local computing and
> network resources ...
>=20
> [JL] change made
>=20
>> >    As a result, the intent of this document is to provide a guide to
> donald: The intent of this document is to provide guidence to ISPs...
>=20
> [JL] change made
>=20
>> >    generally, as well as on individual Internet users.  Efforts by ISP=
s
>> >    and other organizations could therefore, over time, reduce the pool
> donald: and other organizations can over time reduce the pool of ...
>=20
> [JL] change made
>=20
>> >    The potential mitigation of bots is accomplished through a process =
of
>> >    detection, notification to Internet users, and remediation of that
>> >    bot with a variety of tools, as described later in this document.
> donald: bot infections with a variety ...
>=20
> [JL] change made
>=20
>> >    ability of average users.  Attempts at bot removal may frequently b=
e
>> >    unsuccessful, or only partially successful, and may leave a user's
> donald: unsuccessful or only partially successful leaving the system ...
>=20
> [JL] change made
>=20
>> >    system in an unstable and unsatisfactory state or even in a state
>> >    where it is still infected.  Attempts at bot removal can also resul=
t
>> >    in side effects ranging from a loss of data or other files, all the
>> >    way through partial or complete loss of system usability.
> donald: Attempts at bot removal can result in side effects from a loss of=
 data
> to partial or complete loss of system usablility.
>=20
> [JL] change made
>=20
>> >    In general, the only way a user can be sure they have removed some =
of
>> >    today's increasingly sophisticated malware is by 'nuking-and-paving=
'
>> >    the system: reformatting the drive, reinstalling the operating syst=
em
>> >    and applications (including all patches) from scratch, and then
>> >    restoring user files from a clean backup.  However the introduction
> donald: restoring user files from a known clean backup...
>=20
> [JL] chg made
>=20
>> >    of BIOS-based malware may mean that, in some cases, this will not b=
e
> donald: of persistent memory based malware may meant that, in some cases,=
 this
> may not be ...
>=20
> [JL] chg made
>=20
>> >    enough and may prove to be more than any end user can be reasonably
>> >    expected to resolve [Persistent BIOS Infection].  Experienced users
> donald: Persistent memory infections.
>=20
> [JL] chg made=20
>=20
>> >    would have to re-flash BIOS in their machines in order to remove
>> >    BIOS-based malware.  However, in some cases, not even 'nuking-and-
> donald: would have to re-flash or re-image persistent memory sections on =
their
> machines in order ...
>=20
> [JL] chg made
>=20
>> >    Devices with embedded operating systems, such as video gaming
>> >    consoles and smart home appliances, will most likely be beyond a
>> >    user's capability to remediate by themselves, and will typically
>> >    require the aid of vendor-specific advice, updates and tools.  Care
>> >    must be taken when imparting remediation advice to Internet users
>> >    given the increasingly wide array of computing devices that can be,
>> >    or could be, infected by bots in the future.
> donald: Many such devices have a "reset to factory defaults" switch which=
 will
> be the main method to clear such devices if infected.
>=20
> [JL] Good suggestion.  Added =B3However, in some cases, such devices will h=
ave a
> function or switch to enable the user to reset that device to a factory
> default configuration, which may in some cases enable the user to remedia=
te
> the infection.=B2
>> >
>> >
>> > 5.  Detection of Bots
>> >
>> >    An ISP must first identify that an Internet user, in this case a us=
er
>> >    that is assumed to be their customer or otherwise connected to the
>> >    ISP's network, is determined to be infected, or likely to have been
>> >    infected with a bot.  The ISP must attempt to detect the presence o=
f
>> >    bots using methods, processes, and tools which maintain the privacy
>> >    of the personally identifiable information (PII) of their customers=
.
>> >    The ISP also must not block legitimate traffic in the course of bot
>> >    detection, and must instead employ detection methods, tools, and
>> >    processes which seek to be non-disruptive, as well as being
>> >    transparent to Internet users and end-user applications.
> donald: You can't be totally transparent nor completely non-disruptive.
> Nothing can be observed without affecting what your observing.
> Perhaps rewrite with the concept of MINUMIZING such effects?
>=20
> [JL] I see what you mean but it=B9s tough to get that across.  I think ther=
e=B9s
> enough wiggle room insofar as I have  said =B3seek to be non-disruptive=B2 wh=
ich
> means it is really simply a goal.
>=20
>> >
>> >    Detection methods, tools, and processes may include things such as
> donald: may include analysis of specific ...
>=20
> [JL] change made
> =20
>> >    or other Internet users, as well as a wide variety of other
>> >    possibilities.  It is likely that a combination of multiple bot
> donald: In order to validate any bot net detection source a combination o=
f
> multiple bot
> detection sources has proven to be an effective approach ...
>=20
> [JL] made a change to address your concern
>=20
>> >    detection data points will prove to be an effective approach in ord=
er
>> >    to corroborate information of varying dependability or consistency,
>> >    as well as to avoid or minimize the possibility of false positive
>> >    identification of computers.  Detection should also, where possible
>> >    and feasible, attempt to classify a bot in order to confirm that it
> donald: to classify the specific bot infection type in order to ...
>=20
> [JL] chg made
>=20
>> >    can be stopped.  This may mean that an ISP may need to balance the
>> >    desire or need to definitively classify and/or confirm a bot, which
>> >    may take an extended period of time, with the ability to predict th=
e
>> >    strong likelihood of a bot in a very short period of time.  This
>> >    'definitive-vs-likely' challenge is difficult and, when in doubt,
>> >    ISPs should probably err on the side of caution by communicating wh=
en
> donald: I agree erring on the side of caution BUT that should be don't
> communicate with your customers unless your fairly certain they are infec=
ted
> (False positive rate of 5% or less)! Notifying customers just on "likely"=
 (ie
> greater then 50%) will cause customers loose faith in such notification.
>=20
> [JL] Good point =AD added text to address this
> =20
>> >    a likely bot infection has taken place.  This also means that
>> >    Internet users may benefit from the deployment of client-based
>> >    software protections or other software tools, which can enable rapi=
d
>> >    performance of heuristically-based detection bot activity, such as
> donald: There is a risk here in that this teaches users to install softwa=
re on
> their computer that may not be effective given todays botnet + root kit h=
iding
> abilities. Thus a false sense of security plus you've trained them to ins=
tall
> software outside of normal OS maintenance. Would this even be included if=
 it
> weren't the approach you choose?
>=20
> [JL] It=B9s not a statement that we should only rely on host-based protecti=
ons,
> merely an argument for layered defenses.  I don=B9t want to see things like=
 I
> used to see in enterprises, where folks felt that since a firewall existe=
d in
> the network that hosts could go largely unprotected. In this case, just
> because an ISP may have detection and perhaps protection measures in plac=
e, I
> don=B9t want to obviate users of the responsibility to run some local softw=
are
> to protect themselves (something > nothing).  :-)
>=20
>> >    the detection of a bot as it starts to communicate a bot net and
> donald: communicate to a bot net ...
>=20
> [JL] chg made. =20
>=20
>> >    execute some type of command.  Any bot detection systems should als=
o
> donald: execute commands.
>=20
> [JL] chg made
>> >    be capable of learning and adapting, either via manual intervention
>> >    or automatically, in order to cope with a rapidly evolving threat.
> donald: If done learning is done automatically you have just solved the t=
uring
> test.
> Computers don't learn.
>=20
> [JL] I removed =8Clearning=B9
>> >
>> >    As noted above, detection methods, tools, and processes should ensu=
re
>> >    that privacy of customers' PII is maintained.  While bot detection
>> >    methods, tools, and processes are similar to spam and virus defense=
s
>> >    deployed by the ISP for the benefit of their customers (and may be
>> >    directly related to those defenses), attempts to detect bots should
>> >    take into account the need of an ISP to take care to ensure any PII
>> >    collected or incidentally detected is properly protected.  The
>> >    definition of PII varies from one jurisdiction to the next so prope=
r
>> >    care must be taken to ensure that any actions taken comply with
>> >    legislation and good practice in the jurisdiction in which the PII =
is
>> >    gathered.  Finally, depending upon the geographic region within whi=
ch
> donald: While this is true in many cases the customers PII is already at =
risk
> from criminal elements that want to exploit it. So being overly concerned
> about the privacy of PII (such as hiding PII from internal analysis teams=
)
> should be recommended against.
>=20
> [JL] That=B9s why I say =B3should=B2 and not =B3must=B2 since as you point out ther=
e may
> be cases where this is not possible.  Also, what legally constitutes PII =
is
> typically fairly small.  I added this text into the section though: =B3This=
 is
> important, as just as spam defenses may involve scanning the content of e=
mail
> messages which may contain PII, then so to may bot defenses similarly com=
e
> into incidental contact with PII.=B2
>=20
>  a.  Where legally permissible or otherwise an industry accepted
>> >        practice in a particular market region, an ISP may in some mann=
er
>> >        "scan" their IP space in order to detect un-patched or otherwis=
e
>> >        vulnerable hosts.  This may provide the ISP with the opportunit=
y
>> >        to easily identify Internet users who appear to already be or a=
re
>> >        at great risk of being infected with a bot.  ISP's should note
>> >        that some types of port scanning may leave network services in =
a
>> >        hung state or render them unusable due to common frailties, and
>> >        that many modern firewall and host-based intrusion detection
>> >        implementations may alert the Internet user to the scan.  As a
>> >        result the scan may be interpreted as a malicious attack agains=
t
>> >        the computer.  Vulnerability scanning has a higher probability =
of
>> >        leaving accessible network services and applications in a damag=
ed
>> >        state and will often result in a higher probability of detectio=
n
>> >        by the Internet user and subsequent interpretation as a targete=
d
>> >        attack.  Depending upon the vulnerability being scanned, some
>> >        automated methods of vulnerability checking may result in data
>> >        being altered or created afresh on the Internet users computer
>> >        which be a problem in many legal environments.
> donald: I would strongly recommend against this as a common practice. You
> provided most of the risks that make this a dangerous course.
>=20
> [JL] Good point.  If we delete it, we=B9ll just be asked later to add it ba=
ck I
> fear.  So I have added this to the end: =B3Thus, while we note that this is=
 one
> technique which may be utilized, it is unlikely to be particularly effect=
ive
> and it has problematic side effects, which leads the authors to recommend
> against the use of this particular method.=B2
>=20
>> >        monitoring to identify network anomalies that may be indicative
>> >        of botnet attacks or bot communications.  For example, an ISP m=
ay
>> >        be able to identify compromised hosts by identifying traffic
>> >        destined to IP addresses associated with the command and contro=
l
> donald: destined to an IP address and control port associated with the ..=
.
> Most of the time the host associated with c and c has other legit traffic=
 so
> having the control port helps a LOT when running potentially infected bot=
 net
> reports.
>=20
> [JL] good point =AD added some text to address this
>=20
>> >        of botnets.  In addition, bots can be identified when a remote
>> >        host is under a DDoS attack because computers participating in
>> >        the attack will likely be infected by a bot, frequently as
> donald: I would caution against FPs due to spoofing of source IP addresse=
s.
> With netflow you can check which router and interface the attack traffic =
is
> coming in from as method to reduce FPs.
>=20
> [JL] added: =B3...(though ISPs should beware of source IP address spoofing
> techniques to avoid or confuse detection).=B2
>=20
>> >    e.  User complaints: Because hosts infected by bots are frequently
>> >        used to send spam or participate in DDoS attacks, the ISP
>> >        servicing those hosts will normally receive complaints about th=
e
>> >        malicious network traffic.  Those complaints may be sent to
>> >        RFC2142-specified [RFC2142] role accounts, such as abuse@ or
>> >        postmaster@ or to abuse or security addresses specified by the
> donald: postmaster is for email delivery issues and we shouldn't be
> encouraging people to use it for abuse unless no other contact info is
> available.
> NOC or security should be encouraged instead if abuse@ doesn't work.
>=20
> [JL] made a change to address this
>=20
>> >        site as part of its WHOIS (or other) contact data.
>> >
>> >    f.  ISPs may also discover likely bot infected hosts located at oth=
er
>> >        sites; when legally permissible or otherwise an industry accept=
ed
> donald: located on other ISPs networks; when legally ...
> You mention industry accepted practice here as an or legally permissible =
but I
> think you mean and not or. It has to be legal or you shouldn't do it peri=
od.
> If it is an industry accepted practice shouldn't really come in to it. Th=
e
> first of us that started share such reports to other ISPs we were the fir=
st to
> do so. It wasn't the industry accepted practice at that time.
>=20
> [JL] Good catch =AD made a change to address that
>=20
>> > 6.  Notification to Internet Users
>> >
>> >    Once an ISP has detected a bot, or the strong likelihood of a bot,
>> >    steps should be undertaken to inform the Internet user that they ma=
y
>> >    have a bot-related problem.  Depending upon a range of factors, fro=
m
>> >    the technical capabilities of the ISP, to the technical attributes =
of
>> >    their network, financial considerations, available server resources=
,
>> >    available organizational resources, the number of likely infected
>> >    computers detected at any given time, and the severity of any
>> >    possible threats, among many other things, an ISP should decide the
>> >    most appropriate method or methods for providing notification to on=
e
>=20
> donald: Ideally the customer should be notified via as many methods as
> possible at nearly the same time if possible. While most ISPs could do mo=
re
> then one notification method most of the "bad guys" won't be able to spoo=
f
> many different
> notification types within a small amount of time.
> I don't know anyone that has implemented this but it seems like a really =
good
> recommendation.
>=20
> [JL] Good suggestion, and added text to that effect.
> =20
>> >    or more of their customers or Internet users.  Such notification
>> >    methods may include one or more of the following, as well as other
>> >    possible methods not described below
>> >
>> >    It is important to note that none of these methods are guaranteed t=
o
>> >    be successful, and that each has its own set of limitations.  In
> donald: 100% successful,
>=20
> [JL] Ack, added.
>=20
>> >    addition, in some cases, an ISP may determine that a combination of
>> >    two or more methods is most appropriate.  Finally, notification is
>> >    also considered time sensitive; if the user does not receive or vie=
w
>> >    the notification or a timely basis, then a particular bot could
>> >    launch an attack, exploit the user, or cause other harm.  If
>> >    possible, an ISP should establish a preferred means of communicatio=
n
>> >    when the subscriber first signs up for service.  As a part of the
>> >    notification process, ISPs should maintain a record of the allocati=
on
>> >    of IP addresses to subscribers for such a period as allows any bot
> donald: commonly used bot detection
>=20
> [JL] ack, added
>=20
>> >    detection technology to be accurately able to link an infected IP
> donald: to be able to accurately link an infected ...
>=20
> [JL] change made
>=20
>> >    address to a subscriber.  This record should only be maintained for=
 a
>> >    period of time which is necessary, in order to maintain the
>> >    protection of the privacy of an individual subscriber.
>> >
>> >    One important factor to bear in mind is that notification to end
>> >    users needs to be defended against spoofing by third parties.  This
>> >    must be done to protect against the possibility of notifications
>> >    being spoofed and used by bots to deliver additional malware.
> donald: must be done to protect as well as reasonably possible against th=
e
> possibility of legitimate notifications being spoofed and used by persons=
 with
> malicious intent to perform additional malicious acts against the victims=
.
>=20
> They may not be bots and they may not use this to "infect" with a bot in =
many
> cases "they" will be an AD that sells fake AV/scareware.
>=20
> [JL] Good suggestion =AD change made
>=20
>> >
>> > 6.1.  Email Notification
>> >
>> >    This is probably the most common form of notification used by ISPs.
> donald: Is it? Do we have any surveys or stats on this? I think your corr=
ect
> but it would be good to have some kind of backup.
>=20
> [JL] changed to =B3common=B2 since I have no data to backup that it=B9s the mos=
t
> common.
>=20
>> >    delete the message or otherwise file it in an email folder that the
>> >    user may not check on a regular and/or timely basis.  Bot masters
>> >    have also been known to impersonate the ISP or trusted sender and
>> >    send fradulent emails to the users.  This technique of social
> donald: fraudulent
>=20
> [JL] corrected
>=20
>> >    engineering, generally referred to as 'phishing', often leads to ne=
w
>=20
> donald: Phishing is generally defined as attempting to gain user credenti=
als
> or other sensitive information by spoofing a trusted source.
> What your describing is a method used by some viruses such as beagle to s=
pread
> by convincing customers to install it thinking it was a fix to some malwa=
re or
> other issue. This is commonly refered to as social engineering as you sta=
te
> but not phishing.
>=20
> [JL] That may have been an artifact of an earlier draft, but in any case =
I
> dropping the phishing part.
>=20
>> >    as such not welcome it, or not accept the call at all.  Finally, ev=
en
>> >    if a representative of the ISP is able to connect with and speak to=
 a
>> >    user, that user is very likely to lack the necessary technical
>> >    expertise to understand or be able to effectively deal with the
>> >    threat.
> donald: Isn't this last statement true for ALL notifications methods.
> I agree it is true, but it probably needs to be a caveat for all notifica=
tion
> methods. You mention it else where but perhaps a special paragraph at the
> beginning that states this is true for all notification types.
>=20
> [JL] I=B9ll take that into consideration =AD added to my open issues list for=
 the
> next version.
>=20
>> >
>> > 6.3.  Postal Mail Notification
>> >
>> >    This form of notification is probably the least popular and effecti=
ve
>> >    means of communication, due to both preparation time, delivery time=
,
>> >    the cost of printing and paper, and the cost of postage.
>=20
> donald: For ISPs that are already billing their customers there wouldn't =
need
> to be additional cost of postage, printing or paper it could be incorpora=
ted
> into the bill its self. The biggest risk here is delivery time and the fa=
ct
> that some customers don't review their bills (similar to the email issue
> identified above).
>=20
> [JL] In most cases, it=B9s not realistic to get that sort of info into a bi=
lling
> system.  Thus, a mailer is likely to be separate.
>> >
>> > 6.4.  Walled Garden Notification
>> >
>> >    Placing a user in a walled garden is another approach that ISPs may
>> >    take to notify users.  A walled garden refers to an environment tha=
t
>> >    controls the information and services that a subscriber is allowed =
to
>> >    utilize and what network access permissions are granted.  This is a=
n
> donald: That is really the definition of a quarantine walled garden.
> Walled garden's don't have to quarantine the user (much) to notify the
> customer.
> They can be fairly leaky and still notify the customer of their infection=
.
>=20
> [JL] I=B9d like to ponder that more, so have added to our open issues list.
>=20
>> >    not always the case that a user is actively using a computer that
>> >    uses a web browser or which has a web browser actively running on i=
t.
> donald: not always the case that a user is using a application that used =
the
> ports being redirected to the walled garden.
>=20
> This is more of an application issue then the "computer".
>=20
> [JL] Was modified to =8Chost.=B9  Also added the reference to other ports.
>=20
>> >    In one example, a user could be playing a game online, via the use =
of
>> >    a dedicated, Internet-connected game console.  In another example,
>> >    the user may not be using a computer with a web browser when they a=
re
>> >    placed in the walled garden and may instead be in the course of a
>> >    telephone conversation, or may be expecting to receive a call, usin=
g
>> >    a Voice Over IP (VoIP) device of some type.  As a result, the ISP m=
ay
>> >    feel the need to maintain a potentially lengthy white list of domai=
ns
>> >    which are not subject to the typical restrictions of a walled garde=
n,
>> >    which could well prove to be an onerous task, from an operational
>> >    perspective.
> donald: Or design a leaky walled garden that allows most traffic without
> interference only redirecting the traffic needed to mitigate or notify.
>=20
> [JL] Seems related to the question raised before re a quarantine WG.  I=B9l=
l
> keep it on the open issues list.
>=20
>> >        This option is suggested when the purpose of the
> donald: primary purpose of the
>=20
> [JL] change made
>=20
>> >    Once the user acknowledges the notification, then the user decides =
to
> donald: the notification, decides to remediate and exit the walled garden=
 or
> exit the walled garden without remediating the issue.
>=20
> [JL] made a chg to address this
>=20
>> >    either remediate and then exit the walled garden, or exit the walle=
d
>> >    garden without addressing the issue.  Another approach may be to
>> >    enforce a stricter policy and require the user to clean the compute=
r
>> >    prior to permitting the user to exit the walled garden, though this
>> >    may not be technically feasible depending upon the type of bot,
>> >    obfuscation techniques employed by a bot, and/or a range of other
>> >    factors.  Thus, the ISP may also need to support tools to scan the
>> >    infected computer and determine whether it is still infected or rel=
y
>> >    on user judgment that the bot has been disabled or removed.  One
>=20
> donald: Scanning is risky and should be identified as such.
> Port scanning or vulnerability scanning is dangerous as you identified el=
se
> where.
> Anti-virus scanning is also risky if the ISP initiates it as that means y=
ou
> have taken some level of control (and responsibility) for that infected
> machine.
> A better method would be to use SNORT or similar tool to passively watch =
for
> packets indicating an continued infection.
> Another good approach is just to keep track of whom was put into the wall=
ed
> garden for which infection and if they keep showing up as infected via th=
e
> trusted third party reports then you can assume they are unable/unwilling=
 to
> remediate and take what ever additional actions you deem appropriate.
>=20
> [JL] Added a clarifying statement =B3(in the style of a virus scan, rather =
than
> a port scan)=B2
>=20
>> >    There are several drawbacks with this communications method.  There
>> >    is a high probability that subscriber may interpret the communicati=
on
>> >    to be spam, and as such ignore it.  Also, not every user uses IM
>> >    and/or the user may not provide their IM identity to the ISP so som=
e
>> >    alternative means have to be used.  Even in those cases where a use=
r
>> >    does have an IM address, they may not be signed onto that IM system
>> >    when the notification is attempted.  There maybe also be a privacy
>> >    concern on the part of users, when such an IM notification must be
>> >    transmitted over a third-party network and/or IM service.  As such,
>> >    should this method be used, the notification should be discreet and
>> >    not include any PII in the notification itself.
>=20
> donald: Isn't this true for email, sms and possibly other methods.
> Again if so it could become part of the opening statement rather then tie=
d to=20
> just one notification type.
>=20
> [JL] Good suggestion to ponder  =AD I will drop that into my open issues fo=
r a=20
> future rev.
>=20
>=20
>> > Livingood, et al.        Expires August 16, 2010               [Page 1=
5]
>> >
>> > Internet-Draft     Remediation of Bots in ISP Networks     February 20=
10
>> >
>> >
>> >    typically pay on a per-message basis to send SMS notifications.  An
>=20
> donald: No in most cases the ISP would use the customers SMS providers SM=
TP to=20
> SMS gateway and wouldn't encore additional costs for an sms msg.
>=20
> [JL] I just generalized to the following: =B3In both cases an ISP may incur=
 fees=20
> related to SMS notifications, depending upon the method used to send the=20
> notifications=B2
>=20
>> >    additional downside is that SMS messages sent to a user may result =
in
>> >    a charge to the user by their wireless provider, depending upon the
>> >    plat to which they subscribe.  Another minor disadvantage is that i=
t
>=20
> donald: did you mean platform or feature set here?
>=20
> [JL] I meant =8Cplan=B9 and corrected it.
>=20
>> >    is possible to notify the wrong user if the intended user changes
>> >    their mobile number but forgets to update it with the ISP.
>=20
> donald: Again this applies to more then just sms, certainly to email acco=
unts=20
> and probably other notification methods.
>=20
> [JL] True, but given that most users are metered in some manner for their=
 SMS=20
> messages, this is more pronounced of a risk.  An SMS could cost a user a =
few=20
> cents.
>=20
>> > 6.9.  Considerations for Notification to Network Locations Using a
>> >       Shared IP Address
>> >
>> >    Delivering a notification to a location that Internet access routed
>> >    through one or more shared public IP addresses may be of low value
>> >    since it may be quite difficult to differentiate between users when
>> >    providing a notification.  For example, on a business network of 50=
0
>> >    users, all sharing one public IP address, it may be sub-optimal to
>> >    provide a notification to all 500 users if you only need one specif=
ic
>> >    user to be notified and take action.  As a result, such networks ma=
y
>=20
> donald: In cases like this to assist the business network you describe=20
> providing a date/timestamp, source port of the infected system, and malic=
ious=20
> sites it was visiting often helps them find the infected system.
>=20
> [JL] Added: However, should an ISP implement some form of notification to=
 such=20
> networks, it may be better to simply send notifications to a designated=20
> network administrator at the site. In such a case the local network=20
> administrator may like to receive additional information in such a=20
> notification, such as a date and timestamp, the source port of the infect=
ed=20
> system, and malicious sites that may have been visited.
>=20
>> >          notice regular disk activity even when you are not doing
>> >          anything.  Ignoring this problem is not really an option sinc=
e
> donald: Ignoring this problem is risky to you and your personal informati=
on ..
>=20
> [JL]  change made
>=20
>> >    As an additional consideration, it may be useful to create a proces=
s
>> >    by which users could choose, at their option and with their express
>> >    consent, to share data regarding their bot infection with their ISP
>> >    and/or another authorized third party.  Such third parties may
>> >    include governmental entities that aggregate threat data, such as t=
he
>> >    Internet Crime Complaint Center referred to earlier in this documen=
t,
>> >    to academic institutions, and/or security researchers.  While in ma=
ny
>> >    cases the information shared with the user's ISP or designated thir=
d
>> >    parties will only be used for aggregated statistical analysis, it i=
s
>> >    also possible that certain research needs may be best met with more
>> >    detailed data.  Thus, any such data sharing from a user to the ISP =
or
>> >    authorized third party may contain some type of personally
>> >    identifiable information, either by design or inadvertently.  As a
>> >    result, any such data sharing must be enabled on an opt-in based,
>> >    where users review and approve of the data being shared and the
>> >    parties with which it is to be shared.
>=20
> donald: Unless the ISP is already required to provide said information du=
e=20
> local laws or judicial requirements (subpoena)...
>=20
> [JL] change made
>=20
>> >    In addition, regarding notifications, as described in the Section 6=
,
>> >    care should be taken to assure users that notifications have been
>> >    provided by a trustworthy site and/or party, so that the notificati=
on
>> >    is more difficult for phishers to mimic, or that the user has some
>=20
> donald: I think you are talking social engineers not phishers.
>=20
> [JL] changed to include both.
>=20
> Thanks again for this highly detailed feedback!!
>=20
>=20




--B_3354692430_4731869
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-reme=
diation-06</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I&#8217;m just getting around to doing a &#8211;08 document update now tha=
t IETF-77 has concluded. &nbsp;(Joel&#8217;s feedback has been incorporated =
into &#8211;08 as well.)<BR>
<BR>
Thanks for this feedback, now incorporated into draft-oreirdan-mody-bot-rem=
ediation-08 ( <a href=3D"http://www.ietf.org/id/draft-oreirdan-mody-bot-remedi=
ation-08.txt">http://www.ietf.org/id/draft-oreirdan-mody-bot-remediation-08.=
txt</a>).<BR>
<BR>
Specific comments/replies inline below if you are so inclined.<BR>
<BR>
Regards<BR>
Jason<BR>
<BR>
On 2/15/10 1:16 PM, &quot;Smith, Donald&quot; &lt;<a href=3D"Donald.Smith@qwe=
st.com">Donald.Smith@qwest.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt; &nbsp;&nbsp;&nbsp;This document contains re=
commendations on how Internet Service<BR>
&gt; &nbsp;&nbsp;&nbsp;Providers can manage the effects of computers used b=
y their<BR>
* subscribers, which have been infected with malicious bots, via<BR>
<BR>
<B>donald</B>: A bot is a tool. It can't really be malicious nor benign any=
 more that a gun, or screwdriver is malicious however I understand as this i=
s widely used, incorrectly, within the industry. But malicious implies inten=
t to do harm.<BR>
As long as that is addressed in the malicious bot/bot definition it's proba=
bly acceptable to use it in this way.<BR>
<BR>
<B>[JL] Quite true. &nbsp;I have tried to ensure when using bots in the doc=
 that I am referring to malicious bots, rather than other bots which may hav=
e positive uses. &nbsp;I try to define this at length in Terminology, Sectio=
n 2.1. &nbsp;(I received similar feedback from Robb Topolski in an earlier d=
raft.)<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;various remediation techniques. &nbsp;Internet users=
 with infected<BR>
&gt; &nbsp;&nbsp;&nbsp;computers are exposed to risks such as loss of perso=
nal data, as well<BR>
&gt; &nbsp;&nbsp;&nbsp;as increased susceptibility to online fraud and/or p=
hishing. &nbsp;Such<BR>
&gt; &nbsp;&nbsp;&nbsp;computers can also become an inadvertent participant=
 in or component<BR>
&gt; &nbsp;&nbsp;&nbsp;of an online crime network, spam network, and/or phi=
shing network, as<BR>
&gt; &nbsp;&nbsp;&nbsp;well as be used as a part of a distributed denial of=
 service attack.<BR>
<BR>
<B>donald</B>: The risks to users of infected systems and others are includ=
ed/defined in many places within this document.<BR>
It should probably be defined clearly in one place and referenced in all ot=
her places.<BR>
<BR>
<B>[JL] Fair point. &nbsp;I&#8217;m going to call that out in my open issue=
s list and address in a future version if I don&#8217;t have the chance to g=
et it into -08.<BR>
</B><BR>
&gt; 2.1. &nbsp;Malicious Bots, or Bots<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;A malicious &quot;bot&quot; (derived from the word &=
quot;robot&quot;, hereafter simply<BR>
<BR>
<B>donald</B>: Malicious bot implies intent to do harm, while these are rea=
lly bots that can be used to perform potentially harmful tasks for the bot m=
aster. Perhaps potentially harmful bot?<BR>
<BR>
<B>[JL] I&#8217;ve added a bunch of new text to 2.1 to address this. &nbsp;=
Please let me know if there&#8217;s anything that could be improved upon.<BR=
>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;referred to as a &quot;bot&quot;) refers to a progra=
m that is surreptitiously<BR>
<BR>
<B>donald</B>: Some times they are installed on purpose but the user doesn'=
t understand the full functionality of the software installed or the amount =
of remote control the application provides to the remote controller (bot mas=
ter)<BR>
<BR>
<B>[JL] Ack, and addressed in 2.1 of the doc.<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;It is important to note that there are 'good', or be=
nign bots. &nbsp;Such<BR>
&gt; &nbsp;&nbsp;&nbsp;benign bots are often found in such environments suc=
h as gaming and<BR>
&gt; &nbsp;&nbsp;&nbsp;Internet Relay Chat (IRC) [RFC1459], where a continu=
al, interactive<BR>
&gt; &nbsp;&nbsp;&nbsp;presence can be a requirement for participating in t=
he games,<BR>
&gt; &nbsp;&nbsp;&nbsp;interacting with a computing resource, or other purp=
oses. &nbsp;Since such<BR>
&gt; &nbsp;&nbsp;&nbsp;benign bots are performing useful, lawful, and non-d=
isruptive<BR>
&gt; &nbsp;&nbsp;&nbsp;functions, there is no reason for a provider to moni=
tor for their<BR>
&gt; &nbsp;&nbsp;&nbsp;presence and/or alert users to their presence.<BR>
<BR>
<B>donald</B>: Again Benign implies intent. Perhaps harmless instead?<BR>
<BR>
<B>[JL] I&#8217;ve retained benign since it seems to be used a great deal b=
ut added harmless as well: &#8220;Thus, while there may be benign, or harmle=
ss bots, for the purposes of this document...&#8221;<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;include: identity theft, spam, distributed denial of=
 service (DDoS)<BR>
&gt; &nbsp;&nbsp;&nbsp;attacks, key-logging, fraudulent DNS (pharming), pro=
xy services, fast<BR>
* flux hosting and click fraud.<BR>
<BR>
<B>donald: </B>This is a pretty good risk identification. You might want to=
 add spim, spit, email address harvesting, hosting of highly questionable or=
 illegal content (BulletProof hosting), various MITM attacks (banking ssl al=
a Zeus) and web site scraping.<BR>
<B><BR>
[JL] Added &#8211; good suggestions.<BR>
</B><BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;Infection vectors include un-patched operating syste=
ms, software<BR>
&gt; &nbsp;&nbsp;&nbsp;vulnerabilities, weak/non-existent passwords, malici=
ous websites, un-<BR>
&gt; &nbsp;&nbsp;&nbsp;patched browsers, malware, vulnerable helper applica=
tions and social<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;engineering techniques to ga=
in access to the user's computer.<BR>
<B><BR>
donald: </B>The use of vulnerable and un-patched seems slightly redundant.<=
BR>
An un-patched piece of software is likely to be vulnerable.<BR>
I think your trying to cover the concept of un-patched vs zero day (no patc=
h publicly available) exploitation.<BR>
<BR>
<B>[JL] Correct. I modified to &#8220;... software vulnerabilities (which i=
nclude so-called zero-day vulnerabilities where no patch yet exists)&#8221;<=
BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Initially, bots used I=
RC to communicate but were easy to shutdown if<BR>
<BR>
<B>donald: </B>Initally SOME bots used IRC, Q, TFN, Trinoo, etc... all had =
non-IRC based control.<BR>
<BR>
<B>[JL] Modified as suggested<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;Increasingly, other household systems and devices co=
ntain embedded<BR>
&gt; &nbsp;&nbsp;&nbsp;computers which are connected to or can connect to t=
he public<BR>
&gt; &nbsp;&nbsp;&nbsp;Internet and/or private IP networks. &nbsp;However, =
these devices may not<BR>
&gt; &nbsp;&nbsp;&nbsp;be under interactive control of the Internet user, s=
uch as may be the<BR>
&gt; &nbsp;&nbsp;&nbsp;case with various smart home and smart grid devices.=
<BR>
<BR>
<B>donald: </B>So do you intend for your computer definition to include sma=
rt ip enabled &nbsp;devices or not. It's hard to tell from this definitation=
.<BR>
I would limit the definition to computers that humans use as general purpos=
e computers.<BR>
<BR>
<B>[JL] I did intend to refer to these sorts of devices. &nbsp;As I have ge=
neralized &#8220;computers&#8221; to now be &#8220;hosts&#8221; I&#8217;ve m=
ade some modifications to make this hopefully more clear in the next version=
. &nbsp;But I expressly want to include both typical PC-type devices as well=
 as, say, Internet-connected picture frames.<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;can sometimes cause their computer to be infected wi=
th malware, which<BR>
&gt; &nbsp;&nbsp;&nbsp;may include a bot or cause a bot to install itself, =
via inadvertently<BR>
&gt; &nbsp;&nbsp;&nbsp;accessing a specific website, downloading a specific=
 file, or other<BR>
<BR>
<B>donald: </B>a website, downloading a file ...<BR>
<BR>
<B>[JL] Change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;Alternatively, Internet-connected computers may beco=
me infected with<BR>
<B>donald: </B>Not really alternatively, since you mention vulnerabilities =
above but I think your trying to say without user interaction (scan and spol=
it) right?<BR>
<BR>
<B>[JL] Correct. &nbsp;Changed &#8220;Alternatively&#8221; to &#8220;In oth=
er cases&#8221;<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;DNS Fast Flux is typically used in conjunction with =
proxies which<BR>
&gt; &nbsp;&nbsp;&nbsp;then route the web requests to the real host which s=
erves the data<BR>
&gt; &nbsp;&nbsp;&nbsp;being sought. &nbsp;The proxies are normally hosted =
on compromised user<BR>
&gt; &nbsp;&nbsp;&nbsp;computers. &nbsp;The effect of this is to make the d=
etection of the real<BR>
&gt; &nbsp;&nbsp;&nbsp;host for a piece of content much more difficult and =
to ensure that<BR>
&gt; &nbsp;&nbsp;&nbsp;the site remains up for as long as possible.<BR>
<B>donald: </B>The backend/hidden site<BR>
<BR>
<B>[JL] Change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;Threats in 2009 and Beyond]. &nbsp;Bots are frequent=
ly used as part of<BR>
&gt; &nbsp;&nbsp;&nbsp;concerted Distributed Denial of Service (DDoS) attac=
ks for criminal,<BR>
<B>donald: </B>coordinated<BR>
<BR>
<B>[JL] Change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;operating in their networks. &nbsp;Furthermore, ISPs=
 may also be in a<BR>
&gt; &nbsp;&nbsp;&nbsp;unique position to be able to communicate to Interne=
t users which are<BR>
<B>donald: </B>unique position to be able to notify their customers of pote=
ntial infection by<BR>
bots or other infections.<BR>
<BR>
<B>[JL] Change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;From an end user perspective, knowing that their com=
puter has been<BR>
<B>donald: </B>From an end user perspective, being notified that they may h=
ave an infected computer on their network is important information.<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;infected with one or more bots is very important inf=
ormation. &nbsp;Once<BR>
&gt; &nbsp;&nbsp;&nbsp;they know this, they can take steps to remove the bo=
t, protect<BR>
&gt; &nbsp;&nbsp;&nbsp;themselves in the future, and resolve any problems w=
hich may stem<BR>
&gt; &nbsp;&nbsp;&nbsp;from the bot infection. &nbsp;Given that bots can dr=
ain local computing<BR>
<B>donald: </B>Given that bots can consume vast amounts of local computing =
and network resources ...<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;As a result, the intent of this document is to provi=
de a guide to<BR>
<B>donald: </B>The intent of this document is to provide guidence to ISPs..=
.<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;generally, as well as on individual Internet users. =
&nbsp;Efforts by ISPs<BR>
&gt; &nbsp;&nbsp;&nbsp;and other organizations could therefore, over time, =
reduce the pool<BR>
<B>donald: </B>and other organizations can over time reduce the pool of ...=
<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;The potential mitigation of bots is accomplished thr=
ough a process of<BR>
&gt; &nbsp;&nbsp;&nbsp;detection, notification to Internet users, and remed=
iation of that<BR>
&gt; &nbsp;&nbsp;&nbsp;bot with a variety of tools, as described later in t=
his document.<BR>
<B>donald: </B>bot infections with a variety ...<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;ability of average users. &nbsp;Attempts at bot remo=
val may frequently be<BR>
&gt; &nbsp;&nbsp;&nbsp;unsuccessful, or only partially successful, and may =
leave a user's<BR>
<B>donald: </B>unsuccessful or only partially successful leaving the system=
 ...<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;system in an unstable and unsatisfactory state or ev=
en in a state<BR>
&gt; &nbsp;&nbsp;&nbsp;where it is still infected. &nbsp;Attempts at bot re=
moval can also result<BR>
&gt; &nbsp;&nbsp;&nbsp;in side effects ranging from a loss of data or other=
 files, all the<BR>
&gt; &nbsp;&nbsp;&nbsp;way through partial or complete loss of system usabi=
lity.<BR>
<B>donald: </B>Attempts at bot removal can result in side effects from a lo=
ss of data to partial or complete loss of system usablility.<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;In general, the only way a user can be sure they hav=
e removed some of<BR>
&gt; &nbsp;&nbsp;&nbsp;today's increasingly sophisticated malware is by 'nu=
king-and-paving'<BR>
&gt; &nbsp;&nbsp;&nbsp;the system: reformatting the drive, reinstalling the=
 operating system<BR>
&gt; &nbsp;&nbsp;&nbsp;and applications (including all patches) from scratc=
h, and then<BR>
&gt; &nbsp;&nbsp;&nbsp;restoring user files from a clean backup. &nbsp;Howe=
ver the introduction<BR>
<B>donald: </B>restoring user files from a known clean backup...<BR>
<BR>
<B>[JL] chg made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;of BIOS-based malware may mean that, in some cases, =
this will not be<BR>
<B>donald: </B>of persistent memory based malware may meant that, in some c=
ases, this may not be ...<BR>
<BR>
<B>[JL] chg made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;enough and may prove to be more than any end user ca=
n be reasonably<BR>
&gt; &nbsp;&nbsp;&nbsp;expected to resolve [Persistent BIOS Infection]. &nb=
sp;Experienced users<BR>
<B>donald: </B>Persistent memory infections.<BR>
<BR>
<B>[JL] chg made <BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;would have to re-flash BIOS in their machines in ord=
er to remove<BR>
&gt; &nbsp;&nbsp;&nbsp;BIOS-based malware. &nbsp;However, in some cases, no=
t even 'nuking-and-<BR>
<B>donald: </B>would have to re-flash or re-image persistent memory section=
s on their machines in order ...<BR>
<BR>
<B>[JL] chg made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;Devices with embedded operating systems, such as vid=
eo gaming<BR>
&gt; &nbsp;&nbsp;&nbsp;consoles and smart home appliances, will most likely=
 be beyond a<BR>
&gt; &nbsp;&nbsp;&nbsp;user's capability to remediate by themselves, and wi=
ll typically<BR>
&gt; &nbsp;&nbsp;&nbsp;require the aid of vendor-specific advice, updates a=
nd tools. &nbsp;Care<BR>
&gt; &nbsp;&nbsp;&nbsp;must be taken when imparting remediation advice to I=
nternet users<BR>
&gt; &nbsp;&nbsp;&nbsp;given the increasingly wide array of computing devic=
es that can be,<BR>
&gt; &nbsp;&nbsp;&nbsp;or could be, infected by bots in the future.<BR>
<B>donald: </B>Many such devices have a &quot;reset to factory defaults&quo=
t; switch which will be the main method to clear such devices if infected.<B=
R>
<BR>
<B>[JL] Good suggestion. &nbsp;Added <I>&#8220;However, in some cases, such=
 devices will have a function or switch to enable the user to reset that dev=
ice to a factory default configuration, which may in some cases enable the u=
ser to remediate the infection.&#8221;<BR>
</I></B>&gt;<BR>
&gt;<BR>
&gt; 5. &nbsp;Detection of Bots<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;An ISP must first identify that an Internet user, in=
 this case a user<BR>
&gt; &nbsp;&nbsp;&nbsp;that is assumed to be their customer or otherwise co=
nnected to the<BR>
&gt; &nbsp;&nbsp;&nbsp;ISP's network, is determined to be infected, or like=
ly to have been<BR>
&gt; &nbsp;&nbsp;&nbsp;infected with a bot. &nbsp;The ISP must attempt to d=
etect the presence of<BR>
&gt; &nbsp;&nbsp;&nbsp;bots using methods, processes, and tools which maint=
ain the privacy<BR>
&gt; &nbsp;&nbsp;&nbsp;of the personally identifiable information (PII) of =
their customers.<BR>
&gt; &nbsp;&nbsp;&nbsp;The ISP also must not block legitimate traffic in th=
e course of bot<BR>
&gt; &nbsp;&nbsp;&nbsp;detection, and must instead employ detection methods=
, tools, and<BR>
&gt; &nbsp;&nbsp;&nbsp;processes which seek to be non-disruptive, as well a=
s being<BR>
&gt; &nbsp;&nbsp;&nbsp;transparent to Internet users and end-user applicati=
ons.<BR>
<B>donald: </B>You can't be totally transparent nor completely non-disrupti=
ve.<BR>
Nothing can be observed without affecting what your observing.<BR>
Perhaps rewrite with the concept of MINUMIZING such effects?<BR>
<BR>
<B>[JL] I see what you mean but it&#8217;s tough to get that across. &nbsp;=
I think there&#8217;s enough wiggle room insofar as I have &nbsp;said &#8220=
;seek to be non-disruptive&#8221; which means it is really simply a goal.<BR=
>
</B><BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;Detection methods, tools, and processes may include =
things such as<BR>
<B>donald: </B>may include analysis of specific ...<BR>
<BR>
<B>[JL] change made<BR>
&nbsp;<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;or other Internet users, as well as a wide varie=
ty of other<BR>
&gt; &nbsp;&nbsp;&nbsp;possibilities. &nbsp;It is likely that a combination=
 of multiple bot<BR>
<B>donald: </B>In order to validate any bot net detection source a combinat=
ion of multiple bot<BR>
detection sources has proven to be an effective approach ...<BR>
<BR>
<B>[JL] made a change to address your concern<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;detection data points will prove to be an effective =
approach in order<BR>
&gt; &nbsp;&nbsp;&nbsp;to corroborate information of varying dependability =
or consistency,<BR>
&gt; &nbsp;&nbsp;&nbsp;as well as to avoid or minimize the possibility of f=
alse positive<BR>
&gt; &nbsp;&nbsp;&nbsp;identification of computers. &nbsp;Detection should =
also, where possible<BR>
&gt; &nbsp;&nbsp;&nbsp;and feasible, attempt to classify a bot in order to =
confirm that it<BR>
<B>donald: </B>to classify the specific bot infection type in order to ...<=
BR>
<BR>
<B>[JL] chg made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;can be stopped. &nbsp;This may mean that an ISP may =
need to balance the<BR>
&gt; &nbsp;&nbsp;&nbsp;desire or need to definitively classify and/or confi=
rm a bot, which<BR>
&gt; &nbsp;&nbsp;&nbsp;may take an extended period of time, with the abilit=
y to predict the<BR>
&gt; &nbsp;&nbsp;&nbsp;strong likelihood of a bot in a very short period of=
 time. &nbsp;This<BR>
&gt; &nbsp;&nbsp;&nbsp;'definitive-vs-likely' challenge is difficult and, w=
hen in doubt,<BR>
&gt; &nbsp;&nbsp;&nbsp;ISPs should probably err on the side of caution by c=
ommunicating when<BR>
<B>donald: </B>I agree erring on the side of caution BUT that should be don=
't communicate with your customers unless your fairly certain they are infec=
ted (False positive rate of 5% or less)! Notifying customers just on &quot;l=
ikely&quot; (ie greater then 50%) will cause customers loose faith in such n=
otification.<BR>
<BR>
<B>[JL] Good point &#8211; added text to address this<BR>
&nbsp;<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;a likely bot infection has taken place. &nbsp;Th=
is also means that<BR>
&gt; &nbsp;&nbsp;&nbsp;Internet users may benefit from the deployment of cl=
ient-based<BR>
&gt; &nbsp;&nbsp;&nbsp;software protections or other software tools, which =
can enable rapid<BR>
&gt; &nbsp;&nbsp;&nbsp;performance of heuristically-based detection bot act=
ivity, such as<BR>
<B>donald: </B>There is a risk here in that this teaches users to install s=
oftware on their computer that may not be effective given todays botnet + ro=
ot kit hiding abilities. Thus a false sense of security plus you've trained =
them to install software outside of normal OS maintenance. Would this even b=
e included if it weren't the approach you choose?<BR>
<BR>
<B>[JL] It&#8217;s not a statement that we should only rely on host-based p=
rotections, merely an argument for layered defenses. &nbsp;I don&#8217;t wan=
t to see things like I used to see in enterprises, where folks felt that sin=
ce a firewall existed in the network that hosts could go largely unprotected=
. In this case, just because an ISP may have detection and perhaps protectio=
n measures in place, I don&#8217;t want to obviate users of the responsibili=
ty to run some local software to protect themselves (something &gt; nothing)=
. &nbsp;:-)<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;the detection of a bot as it starts to communicate a=
 bot net and<BR>
<B>donald: </B>communicate to a bot net ...<BR>
<BR>
<B>[JL] chg made. &nbsp;<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;execute some type of command. &nbsp;Any bot detectio=
n systems should also<BR>
<B>donald: </B>execute commands.<BR>
<BR>
<B>[JL] chg made<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;be capable of learning and adapting, either via =
manual intervention<BR>
&gt; &nbsp;&nbsp;&nbsp;or automatically, in order to cope with a rapidly ev=
olving threat.<BR>
<B>donald: </B>If done learning is done automatically you have just solved =
the turing test.<BR>
Computers don't learn.<BR>
<BR>
<B>[JL] I removed &#8216;learning&#8217;<BR>
</B>&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;As noted above, detection methods, tools, and proces=
ses should ensure<BR>
&gt; &nbsp;&nbsp;&nbsp;that privacy of customers' PII is maintained. &nbsp;=
While bot detection<BR>
&gt; &nbsp;&nbsp;&nbsp;methods, tools, and processes are similar to spam an=
d virus defenses<BR>
&gt; &nbsp;&nbsp;&nbsp;deployed by the ISP for the benefit of their custome=
rs (and may be<BR>
&gt; &nbsp;&nbsp;&nbsp;directly related to those defenses), attempts to det=
ect bots should<BR>
&gt; &nbsp;&nbsp;&nbsp;take into account the need of an ISP to take care to=
 ensure any PII<BR>
&gt; &nbsp;&nbsp;&nbsp;collected or incidentally detected is properly prote=
cted. &nbsp;The<BR>
&gt; &nbsp;&nbsp;&nbsp;definition of PII varies from one jurisdiction to th=
e next so proper<BR>
&gt; &nbsp;&nbsp;&nbsp;care must be taken to ensure that any actions taken =
comply with<BR>
&gt; &nbsp;&nbsp;&nbsp;legislation and good practice in the jurisdiction in=
 which the PII is<BR>
&gt; &nbsp;&nbsp;&nbsp;gathered. &nbsp;Finally, depending upon the geograph=
ic region within which<BR>
<B>donald: </B>While this is true in many cases the customers PII is alread=
y at risk from criminal elements that want to exploit it. So being overly co=
ncerned about the privacy of PII (such as hiding PII from internal analysis =
teams) should be recommended against.<BR>
<BR>
<B>[JL] That&#8217;s why I say &#8220;should&#8221; and not &#8220;must&#82=
21; since as you point out there may be cases where this is not possible. &n=
bsp;Also, what legally constitutes PII is typically fairly small. &nbsp;I ad=
ded this text into the section though: <I>&#8220;This is important, as just =
as spam defenses may involve scanning the content of email messages which ma=
y contain PII, then so to may bot defenses similarly come into incidental co=
ntact with PII.&#8221;<BR>
</I></B><BR>
&nbsp;a. &nbsp;Where legally permissible or otherwise an industry accepted<=
BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;practice in a particular mar=
ket region, an ISP may in some manner<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;scan&quot; their IP sp=
ace in order to detect un-patched or otherwise<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;vulnerable hosts. &nbsp;This=
 may provide the ISP with the opportunity<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to easily identify Internet =
users who appear to already be or are<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at great risk of being infec=
ted with a bot. &nbsp;ISP's should note<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;that some types of port scan=
ning may leave network services in a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hung state or render them un=
usable due to common frailties, and<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;that many modern firewall an=
d host-based intrusion detection<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implementations may alert th=
e Internet user to the scan. &nbsp;As a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result the scan may be inter=
preted as a malicious attack against<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the computer. &nbsp;Vulnerab=
ility scanning has a higher probability of<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;leaving accessible network s=
ervices and applications in a damaged<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;state and will often result =
in a higher probability of detection<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;by the Internet user and sub=
sequent interpretation as a targeted<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;attack. &nbsp;Depending upon=
 the vulnerability being scanned, some<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;automated methods of vulnera=
bility checking may result in data<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;being altered or created afr=
esh on the Internet users computer<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;which be a problem in many l=
egal environments.<BR>
<B>donald: </B>I would strongly recommend against this as a common practice=
. You provided most of the risks that make this a dangerous course.<BR>
<BR>
<B>[JL] Good point. &nbsp;If we delete it, we&#8217;ll just be asked later =
to add it back I fear. &nbsp;So I have added this to the end: <I>&#8220;Thus=
, while we note that this is one technique which may be utilized, it is unli=
kely to be particularly effective and it has problematic side effects, which=
 leads the authors to recommend against the use of this particular method.&#=
8221;<BR>
</I></B><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;monitoring to identify netwo=
rk anomalies that may be indicative<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of botnet attacks or bot com=
munications. &nbsp;For example, an ISP may<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be able to identify compromi=
sed hosts by identifying traffic<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;destined to IP addresses ass=
ociated with the command and control<BR>
<B>donald: </B>destined to an IP address and control port associated with t=
he ...<BR>
Most of the time the host associated with c and c has other legit traffic s=
o having the control port helps a LOT when running potentially infected bot =
net reports.<BR>
<BR>
<B>[JL] good point &#8211; added some text to address this<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of botnets. &nbsp;In additio=
n, bots can be identified when a remote<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;host is under a DDoS attack =
because computers participating in<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the attack will likely be in=
fected by a bot, frequently as<BR>
<B>donald: </B>I would caution against FPs due to spoofing of source IP add=
resses.<BR>
With netflow you can check which router and interface the attack traffic is=
 coming in from as method to reduce FPs.<BR>
<BR>
<B>[JL] added: <I>&#8220;...(though ISPs should beware of source IP address=
 spoofing techniques to avoid or confuse detection).&#8221;<BR>
</I></B><BR>
&gt; &nbsp;&nbsp;&nbsp;e. &nbsp;User complaints: Because hosts infected by =
bots are frequently<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;used to send spam or partici=
pate in DDoS attacks, the ISP<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;servicing those hosts will n=
ormally receive complaints about the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;malicious network traffic. &=
nbsp;Those complaints may be sent to<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC2142-specified [RFC2142] =
role accounts, such as abuse@ or<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;postmaster@ or to abuse or s=
ecurity addresses specified by the<BR>
<B>donald: </B>postmaster is for email delivery issues and we shouldn't be =
encouraging people to use it for abuse unless no other contact info is avail=
able.<BR>
NOC or security should be encouraged instead if abuse@ doesn't work.<BR>
<BR>
<B>[JL] made a change to address this <BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;site as part of its WHOIS (o=
r other) contact data.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;f. &nbsp;ISPs may also discover likely bot infected =
hosts located at other<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;sites; when legally permissi=
ble or otherwise an industry accepted<BR>
<B>donald: </B>located on other ISPs networks; when legally ...<BR>
You mention industry accepted practice here as an or legally permissible bu=
t I think you mean and not or. It has to be legal or you shouldn't do it per=
iod. If it is an industry accepted practice shouldn't really come in to it. =
The first of us that started share such reports to other ISPs we were the fi=
rst to do so. It wasn't the industry accepted practice at that time.<BR>
<BR>
<B>[JL] Good catch &#8211; made a change to address that<BR>
</B><BR>
&gt; 6. &nbsp;Notification to Internet Users<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;Once an ISP has detected a bot, or the strong likeli=
hood of a bot,<BR>
&gt; &nbsp;&nbsp;&nbsp;steps should be undertaken to inform the Internet us=
er that they may<BR>
&gt; &nbsp;&nbsp;&nbsp;have a bot-related problem. &nbsp;Depending upon a r=
ange of factors, from<BR>
&gt; &nbsp;&nbsp;&nbsp;the technical capabilities of the ISP, to the techni=
cal attributes of<BR>
&gt; &nbsp;&nbsp;&nbsp;their network, financial considerations, available s=
erver resources,<BR>
&gt; &nbsp;&nbsp;&nbsp;available organizational resources, the number of li=
kely infected<BR>
&gt; &nbsp;&nbsp;&nbsp;computers detected at any given time, and the severi=
ty of any<BR>
&gt; &nbsp;&nbsp;&nbsp;possible threats, among many other things, an ISP sh=
ould decide the<BR>
&gt; &nbsp;&nbsp;&nbsp;most appropriate method or methods for providing not=
ification to one<BR>
<BR>
<B>donald: </B>Ideally the customer should be notified via as many methods =
as possible at nearly the same time if possible. While most ISPs could do mo=
re then one notification method most of the &quot;bad guys&quot; won't be ab=
le to spoof many different<BR>
notification types within a small amount of time.<BR>
I don't know anyone that has implemented this but it seems like a really go=
od recommendation.<BR>
<BR>
<B>[JL] Good suggestion, and added text to that effect.<BR>
&nbsp;<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;or more of their customers or Internet users. &n=
bsp;Such notification<BR>
&gt; &nbsp;&nbsp;&nbsp;methods may include one or more of the following, as=
 well as other<BR>
&gt; &nbsp;&nbsp;&nbsp;possible methods not described below<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;It is important to note that none of these methods a=
re guaranteed to<BR>
&gt; &nbsp;&nbsp;&nbsp;be successful, and that each has its own set of limi=
tations. &nbsp;In<BR>
<B>donald: </B>100% successful,<BR>
<BR>
<B>[JL] Ack, added.<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;addition, in some cases, an ISP may determine th=
at a combination of<BR>
&gt; &nbsp;&nbsp;&nbsp;two or more methods is most appropriate. &nbsp;Final=
ly, notification is<BR>
&gt; &nbsp;&nbsp;&nbsp;also considered time sensitive; if the user does not=
 receive or view<BR>
&gt; &nbsp;&nbsp;&nbsp;the notification or a timely basis, then a particula=
r bot could<BR>
&gt; &nbsp;&nbsp;&nbsp;launch an attack, exploit the user, or cause other h=
arm. &nbsp;If<BR>
&gt; &nbsp;&nbsp;&nbsp;possible, an ISP should establish a preferred means =
of communication<BR>
&gt; &nbsp;&nbsp;&nbsp;when the subscriber first signs up for service. &nbs=
p;As a part of the<BR>
&gt; &nbsp;&nbsp;&nbsp;notification process, ISPs should maintain a record =
of the allocation<BR>
&gt; &nbsp;&nbsp;&nbsp;of IP addresses to subscribers for such a period as =
allows any bot<BR>
<B>donald: </B>commonly used bot detection<BR>
<BR>
<B>[JL] ack, added<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;detection technology to be accurately able to link a=
n infected IP<BR>
<B>donald: </B>to be able to accurately link an infected ...<BR>
<BR>
<B>[JL] change made<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;address to a subscriber. &nbsp;This record shoul=
d only be maintained for a<BR>
&gt; &nbsp;&nbsp;&nbsp;period of time which is necessary, in order to maint=
ain the<BR>
&gt; &nbsp;&nbsp;&nbsp;protection of the privacy of an individual subscribe=
r.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;One important factor to bear in mind is that notific=
ation to end<BR>
&gt; &nbsp;&nbsp;&nbsp;users needs to be defended against spoofing by third=
 parties. &nbsp;This<BR>
&gt; &nbsp;&nbsp;&nbsp;must be done to protect against the possibility of n=
otifications<BR>
&gt; &nbsp;&nbsp;&nbsp;being spoofed and used by bots to deliver additional=
 malware.<BR>
<B>donald: </B>must be done to protect as well as reasonably possible again=
st the possibility of legitimate notifications being spoofed and used by per=
sons with malicious intent to perform additional malicious acts against the =
victims.<BR>
<BR>
They may not be bots and they may not use this to &quot;infect&quot; with a=
 bot in many cases &quot;they&quot; will be an AD that sells fake AV/scarewa=
re.<BR>
<BR>
<B>[JL] Good suggestion &#8211; change made<BR>
</B><BR>
&gt;<BR>
&gt; 6.1. &nbsp;Email Notification<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;This is probably the most common form of notificatio=
n used by ISPs.<BR>
<B>donald: </B>Is it? Do we have any surveys or stats on this? I think your=
 correct but it would be good to have some kind of backup.<BR>
<BR>
<B>[JL] changed to &#8220;common&#8221; since I have no data to backup that=
 it&#8217;s the most common.<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;delete the message or otherwise file it in an em=
ail folder that the<BR>
&gt; &nbsp;&nbsp;&nbsp;user may not check on a regular and/or timely basis.=
 &nbsp;Bot masters<BR>
&gt; &nbsp;&nbsp;&nbsp;have also been known to impersonate the ISP or trust=
ed sender and<BR>
&gt; &nbsp;&nbsp;&nbsp;send fradulent emails to the users. &nbsp;This techn=
ique of social<BR>
<B>donald: </B>fraudulent<BR>
<BR>
<B>[JL] corrected<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;engineering, generally referred to as 'phishing'=
, often leads to new<BR>
<BR>
<B>donald: </B>Phishing is generally defined as attempting to gain user cre=
dentials or other sensitive information by spoofing a trusted source.<BR>
What your describing is a method used by some viruses such as beagle to spr=
ead by convincing customers to install it thinking it was a fix to some malw=
are or other issue. This is commonly refered to as social engineering as you=
 state but not phishing.<BR>
<BR>
<B>[JL] That may have been an artifact of an earlier draft, but in any case=
 I dropping the phishing part.<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;as such not welcome it, or not accept the call at al=
l. &nbsp;Finally, even<BR>
&gt; &nbsp;&nbsp;&nbsp;if a representative of the ISP is able to connect wi=
th and speak to a<BR>
&gt; &nbsp;&nbsp;&nbsp;user, that user is very likely to lack the necessary=
 technical<BR>
&gt; &nbsp;&nbsp;&nbsp;expertise to understand or be able to effectively de=
al with the<BR>
&gt; &nbsp;&nbsp;&nbsp;threat.<BR>
<B>donald: </B>Isn't this last statement true for ALL notifications methods=
.<BR>
I agree it is true, but it probably needs to be a caveat for all notificati=
on methods. You mention it else where but perhaps a special paragraph at the=
 beginning that states this is true for all notification types.<BR>
<BR>
<B>[JL] I&#8217;ll take that into consideration &#8211; added to my open is=
sues list for the next version.<BR>
</B><BR>
&gt;<BR>
&gt; 6.3. &nbsp;Postal Mail Notification<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;This form of notification is probably the least popu=
lar and effective<BR>
&gt; &nbsp;&nbsp;&nbsp;means of communication, due to both preparation time=
, delivery time,<BR>
&gt; &nbsp;&nbsp;&nbsp;the cost of printing and paper, and the cost of post=
age.<BR>
<BR>
<B>donald: </B>For ISPs that are already billing their customers there woul=
dn't need to be additional cost of postage, printing or paper it could be in=
corporated into the bill its self. The biggest risk here is delivery time an=
d the fact that some customers don't review their bills (similar to the emai=
l issue identified above).<BR>
<BR>
<B>[JL] In most cases, it&#8217;s not realistic to get that sort of info in=
to a billing system. &nbsp;Thus, a mailer is likely to be separate.<BR>
</B>&gt;<BR>
&gt; 6.4. &nbsp;Walled Garden Notification<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;Placing a user in a walled garden is another approac=
h that ISPs may<BR>
&gt; &nbsp;&nbsp;&nbsp;take to notify users. &nbsp;A walled garden refers t=
o an environment that<BR>
&gt; &nbsp;&nbsp;&nbsp;controls the information and services that a subscri=
ber is allowed to<BR>
&gt; &nbsp;&nbsp;&nbsp;utilize and what network access permissions are gran=
ted. &nbsp;This is an<BR>
<B>donald: </B>That is really the definition of a quarantine walled garden.=
<BR>
Walled garden's don't have to quarantine the user (much) to notify the cust=
omer.<BR>
They can be fairly leaky and still notify the customer of their infection.<=
BR>
<BR>
<B>[JL] I&#8217;d like to ponder that more, so have added to our open issue=
s list.<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;not always the case that a user is actively using a =
computer that<BR>
&gt; &nbsp;&nbsp;&nbsp;uses a web browser or which has a web browser active=
ly running on it.<BR>
<B>donald: </B>not always the case that a user is using a application that =
used the ports being redirected to the walled garden.<BR>
<BR>
This is more of an application issue then the &quot;computer&quot;.<BR>
<BR>
<B>[JL] Was modified to &#8216;host.&#8217; &nbsp;Also added the reference =
to other ports.<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;In one example, a user could be playing a game o=
nline, via the use of<BR>
&gt; &nbsp;&nbsp;&nbsp;a dedicated, Internet-connected game console. &nbsp;=
In another example,<BR>
&gt; &nbsp;&nbsp;&nbsp;the user may not be using a computer with a web brow=
ser when they are<BR>
&gt; &nbsp;&nbsp;&nbsp;placed in the walled garden and may instead be in th=
e course of a<BR>
&gt; &nbsp;&nbsp;&nbsp;telephone conversation, or may be expecting to recei=
ve a call, using<BR>
&gt; &nbsp;&nbsp;&nbsp;a Voice Over IP (VoIP) device of some type. &nbsp;As=
 a result, the ISP may<BR>
&gt; &nbsp;&nbsp;&nbsp;feel the need to maintain a potentially lengthy whit=
e list of domains<BR>
&gt; &nbsp;&nbsp;&nbsp;which are not subject to the typical restrictions of=
 a walled garden,<BR>
&gt; &nbsp;&nbsp;&nbsp;which could well prove to be an onerous task, from a=
n operational<BR>
&gt; &nbsp;&nbsp;&nbsp;perspective.<BR>
<B>donald: </B>Or design a leaky walled garden that allows most traffic wit=
hout interference only redirecting the traffic needed to mitigate or notify.=
<BR>
<BR>
<B>[JL] Seems related to the question raised before re a quarantine WG. &nb=
sp;I&#8217;ll keep it on the open issues list.<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This option is suggested whe=
n the purpose of the<BR>
<B>donald: </B>primary purpose of the<BR>
<BR>
<B>[JL] change made<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;Once the user acknowledges the notification, the=
n the user decides to<BR>
<B>donald: </B>the notification, decides to remediate and exit the walled g=
arden or exit the walled garden without remediating the issue.<BR>
<BR>
<B>[JL] made a chg to address this<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;either remediate and then exit the walled garden=
, or exit the walled<BR>
&gt; &nbsp;&nbsp;&nbsp;garden without addressing the issue. &nbsp;Another a=
pproach may be to<BR>
&gt; &nbsp;&nbsp;&nbsp;enforce a stricter policy and require the user to cl=
ean the computer<BR>
&gt; &nbsp;&nbsp;&nbsp;prior to permitting the user to exit the walled gard=
en, though this<BR>
&gt; &nbsp;&nbsp;&nbsp;may not be technically feasible depending upon the t=
ype of bot,<BR>
&gt; &nbsp;&nbsp;&nbsp;obfuscation techniques employed by a bot, and/or a r=
ange of other<BR>
&gt; &nbsp;&nbsp;&nbsp;factors. &nbsp;Thus, the ISP may also need to suppor=
t tools to scan the<BR>
&gt; &nbsp;&nbsp;&nbsp;infected computer and determine whether it is still =
infected or rely<BR>
&gt; &nbsp;&nbsp;&nbsp;on user judgment that the bot has been disabled or r=
emoved. &nbsp;One<BR>
<BR>
<B>donald: </B>Scanning is risky and should be identified as such.<BR>
Port scanning or vulnerability scanning is dangerous as you identified else=
 where.<BR>
Anti-virus scanning is also risky if the ISP initiates it as that means you=
 have taken some level of control (and responsibility) for that infected mac=
hine.<BR>
A better method would be to use SNORT or similar tool to passively watch fo=
r packets indicating an continued infection.<BR>
Another good approach is just to keep track of whom was put into the walled=
 garden for which infection and if they keep showing up as infected via the =
trusted third party reports then you can assume they are unable/unwilling to=
 remediate and take what ever additional actions you deem appropriate.<BR>
<BR>
<B>[JL] Added a clarifying statement &#8220;(in the style of a virus scan, =
rather than a port scan)&#8221;<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;There are several drawbacks with this communications=
 method. &nbsp;There<BR>
&gt; &nbsp;&nbsp;&nbsp;is a high probability that subscriber may interpret =
the communication<BR>
&gt; &nbsp;&nbsp;&nbsp;to be spam, and as such ignore it. &nbsp;Also, not e=
very user uses IM<BR>
&gt; &nbsp;&nbsp;&nbsp;and/or the user may not provide their IM identity to=
 the ISP so some<BR>
&gt; &nbsp;&nbsp;&nbsp;alternative means have to be used. &nbsp;Even in tho=
se cases where a user<BR>
&gt; &nbsp;&nbsp;&nbsp;does have an IM address, they may not be signed onto=
 that IM system<BR>
&gt; &nbsp;&nbsp;&nbsp;when the notification is attempted. &nbsp;There mayb=
e also be a privacy<BR>
&gt; &nbsp;&nbsp;&nbsp;concern on the part of users, when such an IM notifi=
cation must be<BR>
&gt; &nbsp;&nbsp;&nbsp;transmitted over a third-party network and/or IM ser=
vice. &nbsp;As such,<BR>
&gt; &nbsp;&nbsp;&nbsp;should this method be used, the notification should =
be discreet and<BR>
&gt; &nbsp;&nbsp;&nbsp;not include any PII in the notification itself.<BR>
<BR>
<B>donald: </B>Isn't this true for email, sms and possibly other methods.<B=
R>
Again if so it could become part of the opening statement rather then tied =
to just one notification type.<BR>
<BR>
<B>[JL] Good suggestion to ponder &nbsp;&#8211; I will drop that into my op=
en issues for a future rev.<BR>
</B><BR>
<BR>
&gt; Livingood, et al. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Expires Au=
gust 16, 2010 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;[Page 15]<BR>
&gt;<BR>
&gt; Internet-Draft &nbsp;&nbsp;&nbsp;&nbsp;Remediation of Bots in ISP Netw=
orks &nbsp;&nbsp;&nbsp;&nbsp;February 2010<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;typically pay on a per-message basis to send SMS not=
ifications. &nbsp;An<BR>
<BR>
<B>donald: </B>No in most cases the ISP would use the customers SMS provide=
rs SMTP to SMS gateway and wouldn't encore additional costs for an sms msg.<=
BR>
<BR>
<B>[JL] I just generalized to the following: &#8220;In both cases an ISP ma=
y incur fees related to SMS notifications, depending upon the method used to=
 send the notifications&#8221;<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;additional downside is that SMS messages sent to a u=
ser may result in<BR>
&gt; &nbsp;&nbsp;&nbsp;a charge to the user by their wireless provider, dep=
ending upon the<BR>
&gt; &nbsp;&nbsp;&nbsp;plat to which they subscribe. &nbsp;Another minor di=
sadvantage is that it<BR>
<BR>
<B>donald: </B>did you mean platform or feature set here?<BR>
<BR>
<B>[JL] I meant &#8216;plan&#8217; and corrected it.<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;is possible to notify the wrong user if the inte=
nded user changes<BR>
&gt; &nbsp;&nbsp;&nbsp;their mobile number but forgets to update it with th=
e ISP.<BR>
<BR>
<B>donald: </B>Again this applies to more then just sms, certainly to email=
 accounts and probably other notification methods.<BR>
<BR>
<B>[JL] True, but given that most users are metered in some manner for thei=
r SMS messages, this is more pronounced of a risk. &nbsp;An SMS could cost a=
 user a few cents.<BR>
</B><BR>
&gt; 6.9. &nbsp;Considerations for Notification to Network Locations Using =
a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Shared IP Address<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;Delivering a notification to a location that Interne=
t access routed<BR>
&gt; &nbsp;&nbsp;&nbsp;through one or more shared public IP addresses may b=
e of low value<BR>
&gt; &nbsp;&nbsp;&nbsp;since it may be quite difficult to differentiate bet=
ween users when<BR>
&gt; &nbsp;&nbsp;&nbsp;providing a notification. &nbsp;For example, on a bu=
siness network of 500<BR>
&gt; &nbsp;&nbsp;&nbsp;users, all sharing one public IP address, it may be =
sub-optimal to<BR>
&gt; &nbsp;&nbsp;&nbsp;provide a notification to all 500 users if you only =
need one specific<BR>
&gt; &nbsp;&nbsp;&nbsp;user to be notified and take action. &nbsp;As a resu=
lt, such networks may<BR>
<BR>
<B>donald: </B>In cases like this to assist the business network you descri=
be providing a date/timestamp, source port of the infected system, and malic=
ious sites it was visiting often helps them find the infected system.<BR>
<BR>
<B>[JL] Added: However, should an ISP implement some form of notification t=
o such networks, it may be better to simply send notifications to a designat=
ed network administrator at the site. In such a case the local network admin=
istrator may like to receive additional information in such a notification, =
such as a date and timestamp, the source port of the infected system, and ma=
licious sites that may have been visited.<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;notice regul=
ar disk activity even when you are not doing<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;anything. &nbsp;=
Ignoring this problem is not really an option since<BR>
<B>donald: </B>Ignoring this problem is risky to you and your personal info=
rmation ..<BR>
<BR>
<B>[JL] &nbsp;change made<BR>
<BR>
</B>&gt; &nbsp;&nbsp;&nbsp;As an additional consideration, it may be useful=
 to create a process<BR>
&gt; &nbsp;&nbsp;&nbsp;by which users could choose, at their option and wit=
h their express<BR>
&gt; &nbsp;&nbsp;&nbsp;consent, to share data regarding their bot infection=
 with their ISP<BR>
&gt; &nbsp;&nbsp;&nbsp;and/or another authorized third party. &nbsp;Such th=
ird parties may<BR>
&gt; &nbsp;&nbsp;&nbsp;include governmental entities that aggregate threat =
data, such as the<BR>
&gt; &nbsp;&nbsp;&nbsp;Internet Crime Complaint Center referred to earlier =
in this document,<BR>
&gt; &nbsp;&nbsp;&nbsp;to academic institutions, and/or security researcher=
s. &nbsp;While in many<BR>
&gt; &nbsp;&nbsp;&nbsp;cases the information shared with the user's ISP or =
designated third<BR>
&gt; &nbsp;&nbsp;&nbsp;parties will only be used for aggregated statistical=
 analysis, it is<BR>
&gt; &nbsp;&nbsp;&nbsp;also possible that certain research needs may be bes=
t met with more<BR>
&gt; &nbsp;&nbsp;&nbsp;detailed data. &nbsp;Thus, any such data sharing fro=
m a user to the ISP or<BR>
&gt; &nbsp;&nbsp;&nbsp;authorized third party may contain some type of pers=
onally<BR>
&gt; &nbsp;&nbsp;&nbsp;identifiable information, either by design or inadve=
rtently. &nbsp;As a<BR>
&gt; &nbsp;&nbsp;&nbsp;result, any such data sharing must be enabled on an =
opt-in based,<BR>
&gt; &nbsp;&nbsp;&nbsp;where users review and approve of the data being sha=
red and the<BR>
&gt; &nbsp;&nbsp;&nbsp;parties with which it is to be shared.<BR>
<BR>
<B>donald: </B>Unless the ISP is already required to provide said informati=
on due local laws or judicial requirements (subpoena)...<BR>
<BR>
<B>[JL] change made<BR>
</B><BR>
&gt; &nbsp;&nbsp;&nbsp;In addition, regarding notifications, as described i=
n the Section 6,<BR>
&gt; &nbsp;&nbsp;&nbsp;care should be taken to assure users that notificati=
ons have been<BR>
&gt; &nbsp;&nbsp;&nbsp;provided by a trustworthy site and/or party, so that=
 the notification<BR>
&gt; &nbsp;&nbsp;&nbsp;is more difficult for phishers to mimic, or that the=
 user has some<BR>
<BR>
<B>donald: </B>I think you are talking social engineers not phishers.<BR>
<BR>
<B>[JL] changed to include both.<BR>
<BR>
Thanks again for this highly detailed feedback!!<BR>
</B><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3354692430_4731869--


From Donald.Smith@qwest.com  Wed Apr 21 09:58:19 2010
Return-Path: <Donald.Smith@qwest.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289A128C1AA for <opsec@core3.amsl.com>; Wed, 21 Apr 2010 09:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.834
X-Spam-Level: 
X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByHr5YTMlmsb for <opsec@core3.amsl.com>; Wed, 21 Apr 2010 09:58:15 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id CEAA828C211 for <opsec@ietf.org>; Wed, 21 Apr 2010 09:39:27 -0700 (PDT)
Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o3LGdE9c029246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Apr 2010 11:39:14 -0500 (CDT)
Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o3LGd8jD015423; Wed, 21 Apr 2010 11:39:09 -0500 (CDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Wed, 21 Apr 2010 10:39:08 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: "'Jason Livingood'" <jason_livingood@cable.comcast.com>, "'Joel Jaeggli'" <joelja@bogus.com>, "'Danny McPherson'" <danny@tcb.net>
Date: Wed, 21 Apr 2010 10:39:06 -0600
Thread-Topic: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
Thread-Index: Acqtx42/UyVFz2xtQbKi5RBxrqoIrwAomV5oDL5bnCQAAMqW4A==
Message-ID: <B01905DA0C7CDC478F42870679DF0F1007B32A90B8@qtdenexmbm24.AD.QINTRA.COM>
References: <B01905DA0C7CDC478F42870679DF0F100787A47F9A@qtdenexmbm24.AD.QINTRA.COM> <C7F48B4D.21D25%jason_livingood@cable.comcast.com>
In-Reply-To: <C7F48B4D.21D25%jason_livingood@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 'Mike O'Reirdan' <michael_oreirdan@cable.comcast.com>, 'opsec wg mailing list' <opsec@ietf.org>, 'Nirmal Mody' <nirmal_mody@cable.comcast.com>
Subject: Re: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2010 16:58:19 -0000

Thanks Jason, a few minor comments below.
Mostly I agreed with your changes.
Danny there is one comment aimed at you wrt the SP survey you do every year=
.


(coffee !=3D sleep) & (!coffee =3D=3D sleep)
Donald.Smith@qwest.com gcia

> -----Original Message-----
> From: Jason Livingood [mailto:jason_livingood@cable.comcast.com]
> Sent: Wednesday, April 21, 2010 9:00 AM
> To: Smith, Donald; Joel Jaeggli; Danny McPherson
> Cc: Nirmal Mody; opsec wg mailing list; Mike O'Reirdan
> Subject: Re: [OPSEC] Fwd: Last Call for
> Comments:draft-oreirdan-mody-bot-remediation-06
>
> I'm just getting around to doing a -08 document update now
> that IETF-77 has concluded.  (Joel's feedback has been
> incorporated into -08 as well.)
>
> Thanks for this feedback, now incorporated into
> draft-oreirdan-mody-bot-remediation-08 (
> http://www.ietf.org/id/draft-oreirdan-mody-bot-remediation-08.txt).
>
> Specific comments/replies inline below if you are so inclined.
>
> Regards
> Jason
>
> On 2/15/10 1:16 PM, "Smith, Donald" <Donald.Smith@qwest.com> wrote:
>
>
>
>       >    This document contains recommendations on how
> Internet Service
>       >    Providers can manage the effects of computers used by their
>       * subscribers, which have been infected with malicious bots, via
>
>       donald: A bot is a tool. It can't really be malicious
> nor benign any more that a gun, or screwdriver is malicious
> however I understand as this is widely used, incorrectly,
> within the industry. But malicious implies intent to do harm.
>       As long as that is addressed in the malicious bot/bot
> definition it's probably acceptable to use it in this way.
>
>       [JL] Quite true.  I have tried to ensure when using
> bots in the doc that I am referring to malicious bots, rather
> than other bots which may have positive uses.  I try to
> define this at length in Terminology, Section 2.1.  (I
> received similar feedback from Robb Topolski in an earlier draft.)
>
>       >    various remediation techniques.  Internet users
> with infected
>       >    computers are exposed to risks such as loss of
> personal data, as well
>       >    as increased susceptibility to online fraud and/or
> phishing.  Such
>       >    computers can also become an inadvertent
> participant in or component
>       >    of an online crime network, spam network, and/or
> phishing network, as
>       >    well as be used as a part of a distributed denial
> of service attack.
>
>       donald: The risks to users of infected systems and
> others are included/defined in many places within this document.
>       It should probably be defined clearly in one place and
> referenced in all other places.
>
>       [JL] Fair point.  I'm going to call that out in my open
> issues list and address in a future version if I don't have
> the chance to get it into -08.
>
>       > 2.1.  Malicious Bots, or Bots
>       >
>       >    A malicious "bot" (derived from the word "robot",
> hereafter simply
>
>       donald: Malicious bot implies intent to do harm, while
> these are really bots that can be used to perform potentially
> harmful tasks for the bot master. Perhaps potentially harmful bot?
>
>       [JL] I've added a bunch of new text to 2.1 to address
> this.  Please let me know if there's anything that could be
> improved upon.
>
>       >    referred to as a "bot") refers to a program that
> is surreptitiously
>
>       donald: Some times they are installed on purpose but
> the user doesn't understand the full functionality of the
> software installed or the amount of remote control the
> application provides to the remote controller (bot master)
>
>       [JL] Ack, and addressed in 2.1 of the doc.
>
>       >    It is important to note that there are 'good', or
> benign bots.  Such
>       >    benign bots are often found in such environments
> such as gaming and
>       >    Internet Relay Chat (IRC) [RFC1459], where a
> continual, interactive
>       >    presence can be a requirement for participating in
> the games,
>       >    interacting with a computing resource, or other
> purposes.  Since such
>       >    benign bots are performing useful, lawful, and
> non-disruptive
>       >    functions, there is no reason for a provider to
> monitor for their
>       >    presence and/or alert users to their presence.
>
>       donald: Again Benign implies intent. Perhaps harmless instead?
>
>       [JL] I've retained benign since it seems to be used a
> great deal but added harmless as well: "Thus, while there may
> be benign, or harmless bots, for the purposes of this document..."
>
>       >    include: identity theft, spam, distributed denial
> of service (DDoS)
>       >    attacks, key-logging, fraudulent DNS (pharming),
> proxy services, fast
>       * flux hosting and click fraud.
>
>       donald: This is a pretty good risk identification. You
> might want to add spim, spit, email address harvesting,
> hosting of highly questionable or illegal content
> (BulletProof hosting), various MITM attacks (banking ssl ala
> Zeus) and web site scraping.
>
>       [JL] Added - good suggestions.
>
>       >
>       >    Infection vectors include un-patched operating
> systems, software
>       >    vulnerabilities, weak/non-existent passwords,
> malicious websites, un-
>       >    patched browsers, malware, vulnerable helper
> applications and social
>       >        engineering techniques to gain access to the
> user's computer.
>
>       donald: The use of vulnerable and un-patched seems
> slightly redundant.
>       An un-patched piece of software is likely to be vulnerable.
>       I think your trying to cover the concept of un-patched
> vs zero day (no patch publicly available) exploitation.
>
>       [JL] Correct. I modified to "... software
> vulnerabilities (which include so-called zero-day
> vulnerabilities where no patch yet exists)"
>
>       >         Initially, bots used IRC to communicate but
> were easy to shutdown if
>
>       donald: Initally SOME bots used IRC, Q, TFN, Trinoo,
> etc... all had non-IRC based control.
>
>       [JL] Modified as suggested
>
>       >    Increasingly, other household systems and devices
> contain embedded
>       >    computers which are connected to or can connect to
> the public
>       >    Internet and/or private IP networks.  However,
> these devices may not
>       >    be under interactive control of the Internet user,
> such as may be the
>       >    case with various smart home and smart grid devices.
>
>       donald: So do you intend for your computer definition
> to include smart ip enabled  devices or not. It's hard to
> tell from this definitation.
>       I would limit the definition to computers that humans
> use as general purpose computers.
>
>       [JL] I did intend to refer to these sorts of devices.
> As I have generalized "computers" to now be "hosts" I've made
> some modifications to make this hopefully more clear in the
> next version.  But I expressly want to include both typical
> PC-type devices as well as, say, Internet-connected picture frames.
>
>       >    can sometimes cause their computer to be infected
> with malware, which
>       >    may include a bot or cause a bot to install
> itself, via inadvertently
>       >    accessing a specific website, downloading a
> specific file, or other
>
>       donald: a website, downloading a file ...
>
>       [JL] Change made
>
>       >    Alternatively, Internet-connected computers may
> become infected with
>       donald: Not really alternatively, since you mention
> vulnerabilities above but I think your trying to say without
> user interaction (scan and spolit) right?
>
>       [JL] Correct.  Changed "Alternatively" to "In other cases"
>
>       >    DNS Fast Flux is typically used in conjunction
> with proxies which
>       >    then route the web requests to the real host which
> serves the data
>       >    being sought.  The proxies are normally hosted on
> compromised user
>       >    computers.  The effect of this is to make the
> detection of the real
>       >    host for a piece of content much more difficult
> and to ensure that
>       >    the site remains up for as long as possible.
>       donald: The backend/hidden site
>
>       [JL] Change made
>
>       >    Threats in 2009 and Beyond].  Bots are frequently
> used as part of
>       >    concerted Distributed Denial of Service (DDoS)
> attacks for criminal,
>       donald: coordinated
>
>       [JL] Change made
>
>       >    operating in their networks.  Furthermore, ISPs
> may also be in a
>       >    unique position to be able to communicate to
> Internet users which are
>       donald: unique position to be able to notify their
> customers of potential infection by
>       bots or other infections.
>
>       [JL] Change made
>
>       >    From an end user perspective, knowing that their
> computer has been
>       donald: From an end user perspective, being notified
> that they may have an infected computer on their network is
> important information.
>
>       [JL] change made
>
>       >    infected with one or more bots is very important
> information.  Once
>       >    they know this, they can take steps to remove the
> bot, protect
>       >    themselves in the future, and resolve any problems
> which may stem
>       >    from the bot infection.  Given that bots can drain
> local computing
>       donald: Given that bots can consume vast amounts of
> local computing and network resources ...
>
>       [JL] change made
>
>       >    As a result, the intent of this document is to
> provide a guide to
>       donald: The intent of this document is to provide
> guidence to ISPs...
>
>       [JL] change made
>
>       >    generally, as well as on individual Internet
> users.  Efforts by ISPs
>       >    and other organizations could therefore, over
> time, reduce the pool
>       donald: and other organizations can over time reduce
> the pool of ...
>
>       [JL] change made
>
>       >    The potential mitigation of bots is accomplished
> through a process of
>       >    detection, notification to Internet users, and
> remediation of that
>       >    bot with a variety of tools, as described later in
> this document.
>       donald: bot infections with a variety ...
>
>       [JL] change made
>
>       >    ability of average users.  Attempts at bot removal
> may frequently be
>       >    unsuccessful, or only partially successful, and
> may leave a user's
>       donald: unsuccessful or only partially successful
> leaving the system ...
>
>       [JL] change made
>
>       >    system in an unstable and unsatisfactory state or
> even in a state
>       >    where it is still infected.  Attempts at bot
> removal can also result
>       >    in side effects ranging from a loss of data or
> other files, all the
>       >    way through partial or complete loss of system usability.
>       donald: Attempts at bot removal can result in side
> effects from a loss of data to partial or complete loss of
> system usablility.
>
>       [JL] change made
>
>       >    In general, the only way a user can be sure they
> have removed some of
>       >    today's increasingly sophisticated malware is by
> 'nuking-and-paving'
>       >    the system: reformatting the drive, reinstalling
> the operating system
>       >    and applications (including all patches) from
> scratch, and then
>       >    restoring user files from a clean backup.  However
> the introduction
>       donald: restoring user files from a known clean backup...
>
>       [JL] chg made
>
>       >    of BIOS-based malware may mean that, in some
> cases, this will not be
>       donald: of persistent memory based malware may meant
> that, in some cases, this may not be ...
>
>       [JL] chg made
>
>       >    enough and may prove to be more than any end user
> can be reasonably
>       >    expected to resolve [Persistent BIOS Infection].
> Experienced users
>       donald: Persistent memory infections.
>
>       [JL] chg made
>
>       >    would have to re-flash BIOS in their machines in
> order to remove
>       >    BIOS-based malware.  However, in some cases, not
> even 'nuking-and-
>       donald: would have to re-flash or re-image persistent
> memory sections on their machines in order ...
>
>       [JL] chg made
>
>       >    Devices with embedded operating systems, such as
> video gaming
>       >    consoles and smart home appliances, will most
> likely be beyond a
>       >    user's capability to remediate by themselves, and
> will typically
>       >    require the aid of vendor-specific advice, updates
> and tools.  Care
>       >    must be taken when imparting remediation advice to
> Internet users
>       >    given the increasingly wide array of computing
> devices that can be,
>       >    or could be, infected by bots in the future.
>       donald: Many such devices have a "reset to factory
> defaults" switch which will be the main method to clear such
> devices if infected.
>
>       [JL] Good suggestion.  Added "However, in some cases,
> such devices will have a function or switch to enable the
> user to reset that device to a factory default configuration,
> which may in some cases enable the user to remediate the infection."
>       >
>       >
>       > 5.  Detection of Bots
>       >
>       >    An ISP must first identify that an Internet user,
> in this case a user
>       >    that is assumed to be their customer or otherwise
> connected to the
>       >    ISP's network, is determined to be infected, or
> likely to have been
>       >    infected with a bot.  The ISP must attempt to
> detect the presence of
>       >    bots using methods, processes, and tools which
> maintain the privacy
>       >    of the personally identifiable information (PII)
> of their customers.
>       >    The ISP also must not block legitimate traffic in
> the course of bot
>       >    detection, and must instead employ detection
> methods, tools, and
>       >    processes which seek to be non-disruptive, as well as being
>       >    transparent to Internet users and end-user applications.
>       donald: You can't be totally transparent nor completely
> non-disruptive.
>       Nothing can be observed without affecting what your observing.
>       Perhaps rewrite with the concept of MINUMIZING such effects?
>
>       [JL] I see what you mean but it's tough to get that
> across.  I think there's enough wiggle room insofar as I have
>  said "seek to be non-disruptive" which means it is really
> simply a goal.
>
>       >
>       >    Detection methods, tools, and processes may
> include things such as
>       donald: may include analysis of specific ...
>
>       [JL] change made
>
>       >    or other Internet users, as well as a wide variety of other
>       >    possibilities.  It is likely that a combination of
> multiple bot
>       donald: In order to validate any bot net detection
> source a combination of multiple bot
>       detection sources has proven to be an effective approach ...
>
>       [JL] made a change to address your concern
>
>       >    detection data points will prove to be an
> effective approach in order
>       >    to corroborate information of varying
> dependability or consistency,
>       >    as well as to avoid or minimize the possibility of
> false positive
>       >    identification of computers.  Detection should
> also, where possible
>       >    and feasible, attempt to classify a bot in order
> to confirm that it
>       donald: to classify the specific bot infection type in
> order to ...
>
>       [JL] chg made
>
>       >    can be stopped.  This may mean that an ISP may
> need to balance the
>       >    desire or need to definitively classify and/or
> confirm a bot, which
>       >    may take an extended period of time, with the
> ability to predict the
>       >    strong likelihood of a bot in a very short period
> of time.  This
>       >    'definitive-vs-likely' challenge is difficult and,
> when in doubt,
>       >    ISPs should probably err on the side of caution by
> communicating when
>       donald: I agree erring on the side of caution BUT that
> should be don't communicate with your customers unless your
> fairly certain they are infected (False positive rate of 5%
> or less)! Notifying customers just on "likely" (ie greater
> then 50%) will cause customers loose faith in such notification.
>
>       [JL] Good point - added text to address this
>
>       >    a likely bot infection has taken place.  This also
> means that
>       >    Internet users may benefit from the deployment of
> client-based
>       >    software protections or other software tools,
> which can enable rapid
>       >    performance of heuristically-based detection bot
> activity, such as
>       donald: There is a risk here in that this teaches users
> to install software on their computer that may not be
> effective given todays botnet + root kit hiding abilities.
> Thus a false sense of security plus you've trained them to
> install software outside of normal OS maintenance. Would this
> even be included if it weren't the approach you choose?
>
>       [JL] It's not a statement that we should only rely on
> host-based protections, merely an argument for layered
> defenses.  I don't want to see things like I used to see in
> enterprises, where folks felt that since a firewall existed
> in the network that hosts could go largely unprotected. In
> this case, just because an ISP may have detection and perhaps
> protection measures in place, I don't want to obviate users
> of the responsibility to run some local software to protect
> themselves (something > nothing).  :-)

Agreed and in some cases I realize providing a link to a tool to find/remov=
e the malware is pretty much a requirement if you want the customer to be a=
ble to clean up.
So there is a bit of an conundrum here as bad guys have used fake notificat=
ions to socially engineer vicitims to install malware. That is the primary =
method used for the class of malware refered to as scareware/fakeAV.



>
>       >    the detection of a bot as it starts to communicate
> a bot net and
>       donald: communicate to a bot net ...
>
>       [JL] chg made.
>
>       >    execute some type of command.  Any bot detection
> systems should also
>       donald: execute commands.
>
>       [JL] chg made
>       >    be capable of learning and adapting, either via
> manual intervention
>       >    or automatically, in order to cope with a rapidly
> evolving threat.
>       donald: If done learning is done automatically you have
> just solved the turing test.
>       Computers don't learn.
>
>       [JL] I removed 'learning'
>       >
>       >    As noted above, detection methods, tools, and
> processes should ensure
>       >    that privacy of customers' PII is maintained.
> While bot detection
>       >    methods, tools, and processes are similar to spam
> and virus defenses
>       >    deployed by the ISP for the benefit of their
> customers (and may be
>       >    directly related to those defenses), attempts to
> detect bots should
>       >    take into account the need of an ISP to take care
> to ensure any PII
>       >    collected or incidentally detected is properly
> protected.  The
>       >    definition of PII varies from one jurisdiction to
> the next so proper
>       >    care must be taken to ensure that any actions
> taken comply with
>       >    legislation and good practice in the jurisdiction
> in which the PII is
>       >    gathered.  Finally, depending upon the geographic
> region within which
>       donald: While this is true in many cases the customers
> PII is already at risk from criminal elements that want to
> exploit it. So being overly concerned about the privacy of
> PII (such as hiding PII from internal analysis teams) should
> be recommended against.
>
>       [JL] That's why I say "should" and not "must" since as
> you point out there may be cases where this is not possible.
> Also, what legally constitutes PII is typically fairly small.
>  I added this text into the section though: "This is
> important, as just as spam defenses may involve scanning the
> content of email messages which may contain PII, then so to
> may bot defenses similarly come into incidental contact with PII."
Good thanks.


>
>        a.  Where legally permissible or otherwise an industry accepted
>       >        practice in a particular market region, an ISP
> may in some manner
>       >        "scan" their IP space in order to detect
> un-patched or otherwise
>       >        vulnerable hosts.  This may provide the ISP
> with the opportunity
>       >        to easily identify Internet users who appear
> to already be or are
>       >        at great risk of being infected with a bot.
> ISP's should note
>       >        that some types of port scanning may leave
> network services in a
>       >        hung state or render them unusable due to
> common frailties, and
>       >        that many modern firewall and host-based
> intrusion detection
>       >        implementations may alert the Internet user to
> the scan.  As a
>       >        result the scan may be interpreted as a
> malicious attack against
>       >        the computer.  Vulnerability scanning has a
> higher probability of
>       >        leaving accessible network services and
> applications in a damaged
>       >        state and will often result in a higher
> probability of detection
>       >        by the Internet user and subsequent
> interpretation as a targeted
>       >        attack.  Depending upon the vulnerability
> being scanned, some
>       >        automated methods of vulnerability checking
> may result in data
>       >        being altered or created afresh on the
> Internet users computer
>       >        which be a problem in many legal environments.
>       donald: I would strongly recommend against this as a
> common practice. You provided most of the risks that make
> this a dangerous course.
>
>       [JL] Good point.  If we delete it, we'll just be asked
> later to add it back I fear.  So I have added this to the
> end: "Thus, while we note that this is one technique which
> may be utilized, it is unlikely to be particularly effective
> and it has problematic side effects, which leads the authors
> to recommend against the use of this particular method."
Agreed!


I missed something in b.
" Good examples of this include SNDS from Microsoft, XBL and PBL
  from Spamhaus and the DSHIELD AS tool from the SANS Institute."

That is a list of good examples but there are a lot of other good 3rd party=
 infected client notification resources. Arbor via atlas, ShadowServer, Cym=
ru, SIE, Support Intelligence and many others.
It might be worth having a seperate section near the end that
has a list of 3rd parties that are willing to share this kind of informatio=
n with ISPs and provide contact info such as was done for conficker.
http://www.confickerworkinggroup.org/wiki/pmwiki.php/SP/ServiceProviders

That list is NOT complete in any sense of the word.
Providing contact information may help other ISPs get a more complete set o=
f third party reports.
I am a bit concerned that some of the 3rd party contact information could c=
hange later and be outdated but I believe most of them will use a role base=
d email account or a link.





>
>       >        monitoring to identify network anomalies that
> may be indicative
>       >        of botnet attacks or bot communications.  For
> example, an ISP may
>       >        be able to identify compromised hosts by
> identifying traffic
>       >        destined to IP addresses associated with the
> command and control
>       donald: destined to an IP address and control port
> associated with the ...
>       Most of the time the host associated with c and c has
> other legit traffic so having the control port helps a LOT
> when running potentially infected bot net reports.
>
>       [JL] good point - added some text to address this
>
>       >        of botnets.  In addition, bots can be
> identified when a remote
>       >        host is under a DDoS attack because computers
> participating in
>       >        the attack will likely be infected by a bot,
> frequently as
>       donald: I would caution against FPs due to spoofing of
> source IP addresses.
>       With netflow you can check which router and interface
> the attack traffic is coming in from as method to reduce FPs.
>
>       [JL] added: "...(though ISPs should beware of source IP
> address spoofing techniques to avoid or confuse detection)."
>
>       >    e.  User complaints: Because hosts infected by
> bots are frequently
>       >        used to send spam or participate in DDoS
> attacks, the ISP
>       >        servicing those hosts will normally receive
> complaints about the
>       >        malicious network traffic.  Those complaints
> may be sent to
>       >        RFC2142-specified [RFC2142] role accounts,
> such as abuse@ or
>       >        postmaster@ or to abuse or security addresses
> specified by the
>       donald: postmaster is for email delivery issues and we
> shouldn't be encouraging people to use it for abuse unless no
> other contact info is available.
>       NOC or security should be encouraged instead if abuse@
> doesn't work.
>
>       [JL] made a change to address this
>
>       >        site as part of its WHOIS (or other) contact data.
>       >
>       >    f.  ISPs may also discover likely bot infected
> hosts located at other
>       >        sites; when legally permissible or otherwise
> an industry accepted
>       donald: located on other ISPs networks; when legally ...
>       You mention industry accepted practice here as an or
> legally permissible but I think you mean and not or. It has
> to be legal or you shouldn't do it period. If it is an
> industry accepted practice shouldn't really come in to it.
> The first of us that started share such reports to other ISPs
> we were the first to do so. It wasn't the industry accepted
> practice at that time.
>
>       [JL] Good catch - made a change to address that
>
>       > 6.  Notification to Internet Users
>       >
>       >    Once an ISP has detected a bot, or the strong
> likelihood of a bot,
>       >    steps should be undertaken to inform the Internet
> user that they may
>       >    have a bot-related problem.  Depending upon a
> range of factors, from
>       >    the technical capabilities of the ISP, to the
> technical attributes of
>       >    their network, financial considerations, available
> server resources,
>       >    available organizational resources, the number of
> likely infected
>       >    computers detected at any given time, and the
> severity of any
>       >    possible threats, among many other things, an ISP
> should decide the
>       >    most appropriate method or methods for providing
> notification to one
>
>       donald: Ideally the customer should be notified via as
> many methods as possible at nearly the same time if possible.
> While most ISPs could do more then one notification method
> most of the "bad guys" won't be able to spoof many different
>       notification types within a small amount of time.
>       I don't know anyone that has implemented this but it
> seems like a really good recommendation.
>
>       [JL] Good suggestion, and added text to that effect.
>
>       >    or more of their customers or Internet users.
> Such notification
>       >    methods may include one or more of the following,
> as well as other
>       >    possible methods not described below
>       >
>       >    It is important to note that none of these methods
> are guaranteed to
>       >    be successful, and that each has its own set of
> limitations.  In
>       donald: 100% successful,
>
>       [JL] Ack, added.
>
>       >    addition, in some cases, an ISP may determine that
> a combination of
>       >    two or more methods is most appropriate.  Finally,
> notification is
>       >    also considered time sensitive; if the user does
> not receive or view
>       >    the notification or a timely basis, then a
> particular bot could
>       >    launch an attack, exploit the user, or cause other
> harm.  If
>       >    possible, an ISP should establish a preferred
> means of communication
>       >    when the subscriber first signs up for service.
> As a part of the
>       >    notification process, ISPs should maintain a
> record of the allocation
>       >    of IP addresses to subscribers for such a period
> as allows any bot
>       donald: commonly used bot detection
>
>       [JL] ack, added
>
>       >    detection technology to be accurately able to link
> an infected IP
>       donald: to be able to accurately link an infected ...
>
>       [JL] change made
>
>       >    address to a subscriber.  This record should only
> be maintained for a
>       >    period of time which is necessary, in order to maintain the
>       >    protection of the privacy of an individual subscriber.
>       >
>       >    One important factor to bear in mind is that
> notification to end
>       >    users needs to be defended against spoofing by
> third parties.  This
>       >    must be done to protect against the possibility of
> notifications
>       >    being spoofed and used by bots to deliver
> additional malware.
>       donald: must be done to protect as well as reasonably
> possible against the possibility of legitimate notifications
> being spoofed and used by persons with malicious intent to
> perform additional malicious acts against the victims.
>
>       They may not be bots and they may not use this to
> "infect" with a bot in many cases "they" will be an AD that
> sells fake AV/scareware.
>
>       [JL] Good suggestion - change made
>
>       >
>       > 6.1.  Email Notification
>       >
>       >    This is probably the most common form of
> notification used by ISPs.
>       donald: Is it? Do we have any surveys or stats on this?
> I think your correct but it would be good to have some kind of backup.
>
>       [JL] changed to "common" since I have no data to backup
> that it's the most common.

Good enough. I would still like to see a survey at some point maybe we coul=
d get Danny at Arbor to add a set of customer notification questions to the=
ir SP survey for 2011.

>
>       >    delete the message or otherwise file it in an
> email folder that the
>       >    user may not check on a regular and/or timely
> basis.  Bot masters
>       >    have also been known to impersonate the ISP or
> trusted sender and
>       >    send fradulent emails to the users.  This
> technique of social
>       donald: fraudulent
>
>       [JL] corrected
>
>       >    engineering, generally referred to as 'phishing',
> often leads to new
>
>       donald: Phishing is generally defined as attempting to
> gain user credentials or other sensitive information by
> spoofing a trusted source.
>       What your describing is a method used by some viruses
> such as beagle to spread by convincing customers to install
> it thinking it was a fix to some malware or other issue. This
> is commonly refered to as social engineering as you state but
> not phishing.
>
>       [JL] That may have been an artifact of an earlier
> draft, but in any case I dropping the phishing part.
>
>       >    as such not welcome it, or not accept the call at
> all.  Finally, even
>       >    if a representative of the ISP is able to connect
> with and speak to a
>       >    user, that user is very likely to lack the
> necessary technical
>       >    expertise to understand or be able to effectively
> deal with the
>       >    threat.
>       donald: Isn't this last statement true for ALL
> notifications methods.
>       I agree it is true, but it probably needs to be a
> caveat for all notification methods. You mention it else
> where but perhaps a special paragraph at the beginning that
> states this is true for all notification types.
>
>       [JL] I'll take that into consideration - added to my
> open issues list for the next version.
>
>       >
>       > 6.3.  Postal Mail Notification
>       >
>       >    This form of notification is probably the least
> popular and effective
>       >    means of communication, due to both preparation
> time, delivery time,
>       >    the cost of printing and paper, and the cost of postage.
>
>       donald: For ISPs that are already billing their
> customers there wouldn't need to be additional cost of
> postage, printing or paper it could be incorporated into the
> bill its self. The biggest risk here is delivery time and the
> fact that some customers don't review their bills (similar to
> the email issue identified above).
>
>       [JL] In most cases, it's not realistic to get that sort
> of info into a billing system.  Thus, a mailer is likely to
> be separate.
Ok, I haven't tried to use billing for notification so you could be correct=
.
It doesn't sound HARD to me but no real background doing so ...

>       >
>       > 6.4.  Walled Garden Notification
>       >
>       >    Placing a user in a walled garden is another
> approach that ISPs may
>       >    take to notify users.  A walled garden refers to
> an environment that
>       >    controls the information and services that a
> subscriber is allowed to
>       >    utilize and what network access permissions are
> granted.  This is an
>       donald: That is really the definition of a quarantine
> walled garden.
>       Walled garden's don't have to quarantine the user
> (much) to notify the customer.
>       They can be fairly leaky and still notify the customer
> of their infection.
>
>       [JL] I'd like to ponder that more, so have added to our
> open issues list.
Sounds good we can talk about the qwest walled garden seperately if you lik=
e to better understand our "leaky" approach:)

>
>       >    not always the case that a user is actively using
> a computer that
>       >    uses a web browser or which has a web browser
> actively running on it.
>       donald: not always the case that a user is using a
> application that used the ports being redirected to the walled garden.
>
>       This is more of an application issue then the "computer".
>
>       [JL] Was modified to 'host.'  Also added the reference
> to other ports.
>
>       >    In one example, a user could be playing a game
> online, via the use of
>       >    a dedicated, Internet-connected game console.  In
> another example,
>       >    the user may not be using a computer with a web
> browser when they are
>       >    placed in the walled garden and may instead be in
> the course of a
>       >    telephone conversation, or may be expecting to
> receive a call, using
>       >    a Voice Over IP (VoIP) device of some type.  As a
> result, the ISP may
>       >    feel the need to maintain a potentially lengthy
> white list of domains
>       >    which are not subject to the typical restrictions
> of a walled garden,
>       >    which could well prove to be an onerous task, from
> an operational
>       >    perspective.
>       donald: Or design a leaky walled garden that allows
> most traffic without interference only redirecting the
> traffic needed to mitigate or notify.
>
>       [JL] Seems related to the question raised before re a
> quarantine WG.  I'll keep it on the open issues list.
>
>       >        This option is suggested when the purpose of the
>       donald: primary purpose of the
>
>       [JL] change made
>
>       >    Once the user acknowledges the notification, then
> the user decides to
>       donald: the notification, decides to remediate and exit
> the walled garden or exit the walled garden without
> remediating the issue.
>
>       [JL] made a chg to address this
>
>       >    either remediate and then exit the walled garden,
> or exit the walled
>       >    garden without addressing the issue.  Another
> approach may be to
>       >    enforce a stricter policy and require the user to
> clean the computer
>       >    prior to permitting the user to exit the walled
> garden, though this
>       >    may not be technically feasible depending upon the
> type of bot,
>       >    obfuscation techniques employed by a bot, and/or a
> range of other
>       >    factors.  Thus, the ISP may also need to support
> tools to scan the
>       >    infected computer and determine whether it is
> still infected or rely
>       >    on user judgment that the bot has been disabled or
> removed.  One
>
>       donald: Scanning is risky and should be identified as such.
>       Port scanning or vulnerability scanning is dangerous as
> you identified else where.
>       Anti-virus scanning is also risky if the ISP initiates
> it as that means you have taken some level of control (and
> responsibility) for that infected machine.
>       A better method would be to use SNORT or similar tool
> to passively watch for packets indicating an continued infection.
>       Another good approach is just to keep track of whom was
> put into the walled garden for which infection and if they
> keep showing up as infected via the trusted third party
> reports then you can assume they are unable/unwilling to
> remediate and take what ever additional actions you deem appropriate.
>
>       [JL] Added a clarifying statement "(in the style of a
> virus scan, rather than a port scan)"
>
>       >    There are several drawbacks with this
> communications method.  There
>       >    is a high probability that subscriber may
> interpret the communication
>       >    to be spam, and as such ignore it.  Also, not
> every user uses IM
>       >    and/or the user may not provide their IM identity
> to the ISP so some
>       >    alternative means have to be used.  Even in those
> cases where a user
>       >    does have an IM address, they may not be signed
> onto that IM system
>       >    when the notification is attempted.  There maybe
> also be a privacy
>       >    concern on the part of users, when such an IM
> notification must be
>       >    transmitted over a third-party network and/or IM
> service.  As such,
>       >    should this method be used, the notification
> should be discreet and
>       >    not include any PII in the notification itself.
>
>       donald: Isn't this true for email, sms and possibly
> other methods.
>       Again if so it could become part of the opening
> statement rather then tied to just one notification type.
>
>       [JL] Good suggestion to ponder  - I will drop that into
> my open issues for a future rev.
>
>
>       > Livingood, et al.        Expires August 16, 2010
>          [Page 15]
>       >
>       > Internet-Draft     Remediation of Bots in ISP
> Networks     February 2010
>       >
>       >
>       >    typically pay on a per-message basis to send SMS
> notifications.  An
>
>       donald: No in most cases the ISP would use the
> customers SMS providers SMTP to SMS gateway and wouldn't
> encore additional costs for an sms msg.
>
>       [JL] I just generalized to the following: "In both
> cases an ISP may incur fees related to SMS notifications,
> depending upon the method used to send the notifications"
Ok

>
>       >    additional downside is that SMS messages sent to a
> user may result in
>       >    a charge to the user by their wireless provider,
> depending upon the
>       >    plat to which they subscribe.  Another minor
> disadvantage is that it
>
>       donald: did you mean platform or feature set here?
>
>       [JL] I meant 'plan' and corrected it.
>
>       >    is possible to notify the wrong user if the
> intended user changes
>       >    their mobile number but forgets to update it with the ISP.
>
>       donald: Again this applies to more then just sms,
> certainly to email accounts and probably other notification methods.
>
>       [JL] True, but given that most users are metered in
> some manner for their SMS messages, this is more pronounced
> of a risk.  An SMS could cost a user a few cents.

Ok but the fact that an email account could be retired and reused is still =
a risk.
I am sure some of the other notification methods could be directed to the w=
rong party due to account
reuse also so we may need to add some generic statement to that effect.

I agree sms could cost an invalid end user so we can put some emphisis on t=
hat.

>
>       > 6.9.  Considerations for Notification to Network
> Locations Using a
>       >       Shared IP Address
>       >
>       >    Delivering a notification to a location that
> Internet access routed
>       >    through one or more shared public IP addresses may
> be of low value
>       >    since it may be quite difficult to differentiate
> between users when
>       >    providing a notification.  For example, on a
> business network of 500
>       >    users, all sharing one public IP address, it may
> be sub-optimal to
>       >    provide a notification to all 500 users if you
> only need one specific
>       >    user to be notified and take action.  As a result,
> such networks may
>
>       donald: In cases like this to assist the business
> network you describe providing a date/timestamp, source port
> of the infected system, and malicious sites it was visiting
> often helps them find the infected system.
>
>       [JL] Added: However, should an ISP implement some form
> of notification to such networks, it may be better to simply
> send notifications to a designated network administrator at
> the site.
Most ISPs have a "network contact" for their enterprise customers.
That is whom would normally be notified.

That happens in the broadband world via the primary email account
that is used for any type of notification.


> In such a case the local network administrator may
> like to receive additional information in such a
> notification, such as a date and timestamp, the source port
> of the infected system, and malicious sites that may have
> been visited.
malicious sites and ports that may have been visited.

When notifying enterprises they can often find an infected system behind a =
NAT/PAT system
if they have the date/timestamp, malicious site (ip or url) and port if the=
y have logs.

>
>       >          notice regular disk activity even when you
> are not doing
>       >          anything.  Ignoring this problem is not
> really an option since
>       donald: Ignoring this problem is risky to you and your
> personal information ..
>
>       [JL]  change made
>
>       >    As an additional consideration, it may be useful
> to create a process
>       >    by which users could choose, at their option and
> with their express
>       >    consent, to share data regarding their bot
> infection with their ISP
>       >    and/or another authorized third party.  Such third
> parties may
>       >    include governmental entities that aggregate
> threat data, such as the
>       >    Internet Crime Complaint Center referred to
> earlier in this document,
>       >    to academic institutions, and/or security
> researchers.  While in many
>       >    cases the information shared with the user's ISP
> or designated third
>       >    parties will only be used for aggregated
> statistical analysis, it is
>       >    also possible that certain research needs may be
> best met with more
>       >    detailed data.  Thus, any such data sharing from a
> user to the ISP or
>       >    authorized third party may contain some type of personally
>       >    identifiable information, either by design or
> inadvertently.  As a
>       >    result, any such data sharing must be enabled on
> an opt-in based,
>       >    where users review and approve of the data being
> shared and the
>       >    parties with which it is to be shared.
>
>       donald: Unless the ISP is already required to provide
> said information due local laws or judicial requirements (subpoena)...
>
>       [JL] change made
>
>       >    In addition, regarding notifications, as described
> in the Section 6,
>       >    care should be taken to assure users that
> notifications have been
>       >    provided by a trustworthy site and/or party, so
> that the notification
>       >    is more difficult for phishers to mimic, or that
> the user has some
>
>       donald: I think you are talking social engineers not phishers.
>
>       [JL] changed to include both.
>
>       Thanks again for this highly detailed feedback!!
>
>
>
>
>
>
>
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

From jason_livingood@cable.comcast.com  Thu Apr 22 08:11:38 2010
Return-Path: <jason_livingood@cable.comcast.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5431428C19C for <opsec@core3.amsl.com>; Thu, 22 Apr 2010 08:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.507
X-Spam-Level: **
X-Spam-Status: No, score=2.507 tagged_above=-999 required=5 tests=[AWL=-0.956,  BAYES_20=-0.74, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ6sM0ludCK2 for <opsec@core3.amsl.com>; Thu, 22 Apr 2010 08:11:37 -0700 (PDT)
Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id B99813A6A62 for <opsec@ietf.org>; Thu, 22 Apr 2010 08:11:31 -0700 (PDT)
Received: from ([10.195.246.152]) by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.80411331; Thu, 22 Apr 2010 11:11:09 -0400
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 11:11:09 -0400
Received: from 147.191.227.151 ([147.191.227.151]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Apr 2010 15:11:08 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Thu, 22 Apr 2010 11:11:09 -0400
From: Jason Livingood <jason_livingood@cable.comcast.com>
To: "Smith, Donald" <Donald.Smith@qwest.com>, 'Joel Jaeggli' <joelja@bogus.com>, 'Danny McPherson' <danny@tcb.net>
Message-ID: <C7F5DF4D.21F4C%jason_livingood@cable.comcast.com>
Thread-Topic: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
Thread-Index: Acqtx42/UyVFz2xtQbKi5RBxrqoIrwAomV5oDL5bnCQAAMqW4AAx32MR
In-Reply-To: <B01905DA0C7CDC478F42870679DF0F1007B32A90B8@qtdenexmbm24.AD.QINTRA.COM>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Apr 2010 15:11:09.0649 (UTC) FILETIME=[09EEAC10:01CAE22E]
Cc: Mike O'Reirdan <michael_oreirdan@cable.comcast.com>, 'opsec wg mailing list' <opsec@ietf.org>, Nirmal Mody <nirmal_mody@cable.comcast.com>
Subject: Re: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2010 15:11:38 -0000

Inline.

>>       [JL] Good point.  If we delete it, we'll just be asked
>> later to add it back I fear.  So I have added this to the
>> end: "Thus, while we note that this is one technique which
>> may be utilized, it is unlikely to be particularly effective
>> and it has problematic side effects, which leads the authors
>> to recommend against the use of this particular method."
> Agreed!
> 
> 
> I missed something in b.
> " Good examples of this include SNDS from Microsoft, XBL and PBL
>   from Spamhaus and the DSHIELD AS tool from the SANS Institute."
> 
> That is a list of good examples but there are a lot of other good 3rd party
> infected client notification resources. Arbor via atlas, ShadowServer, Cymru,
> SIE, Support Intelligence and many others.
> It might be worth having a seperate section near the end that
> has a list of 3rd parties that are willing to share this kind of information
> with ISPs and provide contact info such as was done for conficker.
> http://www.confickerworkinggroup.org/wiki/pmwiki.php/SP/ServiceProviders
> 
> That list is NOT complete in any sense of the word.
> Providing contact information may help other ISPs get a more complete set of
> third party reports.
> I am a bit concerned that some of the 3rd party contact information could
> change later and be outdated but I believe most of them will use a role based
> email account or a link.

[JL] I have added this to my issues tracker for -09.


>> In such a case the local network administrator may
>> like to receive additional information in such a
>> notification, such as a date and timestamp, the source port
>> of the infected system, and malicious sites that may have
>> been visited.
> malicious sites and ports that may have been visited.
> 
> When notifying enterprises they can often find an infected system behind a
> NAT/PAT system
> if they have the date/timestamp, malicious site (ip or url) and port if they
> have logs.

[JL] Change made.

Thanks again,
Jason


From root@core3.amsl.com  Thu Apr 22 13:30:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 574DC3A698A; Thu, 22 Apr 2010 13:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100422203002.574DC3A698A@core3.amsl.com>
Date: Thu, 22 Apr 2010 13:30:02 -0700 (PDT)
Cc: opsec@ietf.org
Subject: [OPSEC] I-D ACTION:draft-ietf-opsec-routing-protocols-crypto-issues-04.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2010 20:30:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.

	Title		: Issues with existing Cryptographic Protection Methods for Routing Protocols
	Author(s)	: J. Jaeggli, S. Hares, M. Bhatia, V. Manral, R. White
	Filename	: draft-ietf-opsec-routing-protocols-crypto-issues-04.txt
	Pages		: 18
	Date		: 2010-4-22
	
Routing protocols have over time been extended to use cryptographic 
   mechanisms to validate data being received from a neighboring router 
   to ensure that:  
    
   o it has not been modified in transit.   
   o actually originated from an authorized neighboring router .   
    
   The cryptographic mechanisms defined to date and described in this 
   document rely on a digest produced with a hash algorithm applied to 
   the payload encapsulated in the routing protocol packet.      
    
   This document outlines some of the limitations of the current 
   mechanism, problems with manual keying of these cryptographic 
   algorithms, and possible vectors for the exploitation of these 
   limitations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-opsec-routing-protocols-crypto-issues-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-4-22132654.I-D@ietf.org>


--NextPart--


From danny@tcb.net  Thu Apr 22 14:07:19 2010
Return-Path: <danny@tcb.net>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9503D3A62C1 for <opsec@core3.amsl.com>; Thu, 22 Apr 2010 14:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.792
X-Spam-Level: 
X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=-1.607, BAYES_40=-0.185, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsMnhZjHDERj for <opsec@core3.amsl.com>; Thu, 22 Apr 2010 14:07:18 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 74C563A67A2 for <opsec@ietf.org>; Thu, 22 Apr 2010 14:07:18 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id AF8F526866F; Thu, 22 Apr 2010 15:07:08 -0600 (MDT)
Received: from [10.2.15.69] (204.118.128.2 [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 22 Apr 2010 15:07:08 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=204.118.128.2; client-port=31200; client-dnsfail=204.118.128.2: name server failure; syn-fingerprint=65535:45:1:64:M1360,N,W3,N,N,T,S; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <B01905DA0C7CDC478F42870679DF0F1007B32A90B8@qtdenexmbm24.AD.QINTRA.COM>
Date: Thu, 22 Apr 2010 15:06:50 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF87C447-A22E-4463-AABF-5D795A24593A@tcb.net>
References: <B01905DA0C7CDC478F42870679DF0F100787A47F9A@qtdenexmbm24.AD.QINTRA.COM> <C7F48B4D.21D25%jason_livingood@cable.comcast.com> <B01905DA0C7CDC478F42870679DF0F1007B32A90B8@qtdenexmbm24.AD.QINTRA.COM>
To: "Smith, Donald" <Donald.Smith@qwest.com>
X-Mailer: Apple Mail (2.1077)
Cc: Roland Dobbins <rdobbins@arbor.net>, Nirmal Mody <nirmal_mody@cable.comcast.com>, Craig Labovitz <labovit@arbor.net>, opsec wg mailing list <opsec@ietf.org>, Mike O'Reirdan <michael_oreirdan@cable.comcast.com>, Jason Livingood <jason_livingood@cable.comcast.com>
Subject: Re: [OPSEC] Fwd: Last Call for Comments:draft-oreirdan-mody-bot-remediation-06
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2010 21:07:19 -0000

On Apr 21, 2010, at 10:39 AM, Smith, Donald wrote:

> Good enough. I would still like to see a survey at some point maybe we =
could get Danny at Arbor to add a set of customer notification questions =
to their SP survey for 2011.

Good idea Don.  We'd be happy to add some questions related to
this in attempts to quantify and qualify.  Year before last we=20
had a few but not directly along these lines.  If any of you would=20
like to have something added to the survey to better support work=20
here, we most welcome it. =20

I've cc'd a couple colleagues (Mike Hollyman, Craig Labovitz, and
Roland Dobbins) that are charged with compiling the new questionnaire=20
this year, please drop them an email and we'll get it in there.

Thanks!

-danny=

From warren@kumari.net  Mon Apr 26 14:30:00 2010
Return-Path: <warren@kumari.net>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791623A68D4 for <opsec@core3.amsl.com>; Mon, 26 Apr 2010 14:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0on3AjMJWelG for <opsec@core3.amsl.com>; Mon, 26 Apr 2010 14:29:57 -0700 (PDT)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 4DD4E3A67A4 for <opsec@ietf.org>; Mon, 26 Apr 2010 14:29:57 -0700 (PDT)
Received: by smtp.kumari.net (Postfix, from userid 5001) id 0E6B8228464A; Mon, 26 Apr 2010 17:27:35 -0400 (EDT)
Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id D05642284090; Mon, 26 Apr 2010 17:27:33 -0400 (EDT)
Message-Id: <891D8A4E-66FA-4FDB-874E-B9469F0313E1@kumari.net>
From: Warren Kumari <warren@kumari.net>
To: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <4BCB4CCB.60803@bogus.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 26 Apr 2010 17:29:42 -0400
References: <4BCB4CCB.60803@bogus.com>
X-Mailer: Apple Mail (2.936)
Cc: "'opsec@ietf.org'" <opsec@ietf.org>
Subject: Re: [OPSEC] Test for acceptance as WG document draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 21:30:00 -0000

I support this...

W
On Apr 18, 2010, at 2:17 PM, Joel Jaeggli wrote:

> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-02
>
> was discussed at IETF 77 and previous drafts have hadfeedback from  
> this
> this list lodged against them...
>
> This email kicks of the mailing list call for consensus to accept this
> work as a working group document.
>
> Commentary in the wg meeting was as noted in the minutes was favorable
> among those who had read it. and subsequent comments on the list hae
> also been favorable, this exercise is intended to formalize that
> understanding.
>
> Deadline for commnentary is sunday april 25th.
>
> thanks
> joel
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec

--
Some people are like Slinkies......Not really good for anything but  
they still bring a smile to your face when you push them down the  
stairs.




From wwwrun@core3.amsl.com  Mon Apr 26 07:18:22 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 53F973A659C; Mon, 26 Apr 2010 07:18:20 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20100426141821.53F973A659C@core3.amsl.com>
Date: Mon, 26 Apr 2010 07:18:20 -0700 (PDT)
X-Mailman-Approved-At: Thu, 29 Apr 2010 14:55:05 -0700
Cc: opsec@ietf.org
Subject: [OPSEC] Last Call: draft-ietf-opsec-routing-protocols-crypto-issues (Issues with existing Cryptographic Protection Methods for Routing Protocols) to Informational RFC
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2010 14:18:22 -0000

The IESG has received a request from the Operational Security 
Capabilities for IP Network Infrastructure WG (opsec) to consider the 
following document:

- 'Issues with existing Cryptographic Protection Methods for Routing 
   Protocols '
   <draft-ietf-opsec-routing-protocols-crypto-issues-04.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-05-10. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-04.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17807&rfc_flag=0


From joelja@bogus.com  Fri Apr 30 10:42:31 2010
Return-Path: <joelja@bogus.com>
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AE33A6936 for <opsec@core3.amsl.com>; Fri, 30 Apr 2010 10:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QewGbzuWc5a8 for <opsec@core3.amsl.com>; Fri, 30 Apr 2010 10:42:30 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id D8B9D3A690A for <opsec@ietf.org>; Fri, 30 Apr 2010 10:42:29 -0700 (PDT)
Received: from [192.103.16.172] ([192.103.16.172]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o3UHg8Os089783 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 30 Apr 2010 17:42:09 GMT (envelope-from joelja@bogus.com)
Message-ID: <4BDB1664.5070208@bogus.com>
Date: Fri, 30 Apr 2010 10:41:56 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: "'opsec@ietf.org'" <opsec@ietf.org>, David Dugal <ddugal@juniper.net>, Joe Abley <jabley@hopcount.ca>
References: <4BCB4CCB.60803@bogus.com>
In-Reply-To: <4BCB4CCB.60803@bogus.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 30 Apr 2010 17:42:09 +0000 (UTC)
Subject: Re: [OPSEC] Test for acceptance as WG document	draft-dugal-opsec-protect-control-plane-02
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 17:42:31 -0000

Deadline has come and gone,

Opinion expressed by additional comments to the list has been favorable. 
There have been no objections.

there appears no barrier to acceptance as a WG document.

thanks
joel

On 4/18/2010 11:17 AM, Joel Jaeggli wrote:
> http://tools.ietf.org/html/draft-dugal-opsec-protect-control-plane-02
>
> was discussed at IETF 77 and previous drafts have hadfeedback from this
> this list lodged against them...
>
> This email kicks of the mailing list call for consensus to accept this
> work as a working group document.
>
> Commentary in the wg meeting was as noted in the minutes was favorable
> among those who had read it. and subsequent comments on the list hae
> also been favorable, this exercise is intended to formalize that
> understanding.
>
> Deadline for commnentary is sunday april 25th.
>
> thanks
> joel
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>