Re: [OPSEC] New Work: Protecting the control plane

George Jones <fooologist@gmail.com> Wed, 12 January 2011 14:51 UTC

Return-Path: <fooologist@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 6341028C12B for <opsec@core3.amsl.com>; Wed, 12 Jan 2011 06:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id go0HULfL0nC8 for <opsec@core3.amsl.com>; Wed, 12 Jan 2011 06:51:49 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6428628C108 for <opsec@ietf.org>; Wed, 12 Jan 2011 06:51:49 -0800 (PST)
Received: by qwi2 with SMTP id 2so688690qwi.31 for <opsec@ietf.org>; Wed, 12 Jan 2011 06:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=124l05dYbexxFxbOmirYrjuUfjxxonGjVdlSJmDsDAQ=; b=ogh4lx8+V96oSYydv/VCjVlWwtsZKVKAAelW9o8U9XjB3KWWTJCd9510ZTIQPRL354 KUAbV2AFq8x1MqTfHxINy+SR7qXppy4elBwTw6XrFjw05l2O0aD6U/zEm/VLb62qIdNv LKDNoQ5zDCFiA2SCfGVZVTivb9mUYhjzd45rY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V9ZKDtiaHBnBP4ol0+dofaU2D+kMGBnubmkYISbJTcEcJqu2e2+uKIvnnouJRyOcPs +W118v4+X6C7Fhym1NUq6hryArZM4cqQIfL3pZS9xZjbPBUjy1sXPLMKhzFFS0Dt1JyK nnDVcyYEWoq3X/I3LS2Oe5WvIre5/PubA+Pbo=
MIME-Version: 1.0
Received: by 10.224.11.137 with SMTP id t9mr1004292qat.138.1294844048902; Wed, 12 Jan 2011 06:54:08 -0800 (PST)
Received: by 10.220.164.146 with HTTP; Wed, 12 Jan 2011 06:54:08 -0800 (PST)
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net>
References: <13205C286662DE4387D9AF3AC30EF456B03C46D9F2@EMBX01-WF.jnpr.net> <AANLkTikiheBQPLJW7rf7U5gpjfN=NN8d1kEEuHBKM=AK@mail.gmail.com> <13205C286662DE4387D9AF3AC30EF456B03C46DA5B@EMBX01-WF.jnpr.net> <AANLkTikzAR9EkKzawMMVdabQ5fc1iCYHRdPXsbF865=Y@mail.gmail.com> <13205C286662DE4387D9AF3AC30EF456B03C46DE6D@EMBX01-WF.jnpr.net>
Date: Wed, 12 Jan 2011 14:54:08 +0000
Message-ID: <AANLkTinJjnNfss+os8Sz1vrxj9SLNGvYrz2ndyMa=C9v@mail.gmail.com>
From: George Jones <fooologist@gmail.com>
To: Ronald Bonica <rbonica@juniper.net>
Content-Type: multipart/alternative; boundary="0015175cd02a9309bc0499a75f61"
Cc: "opsec@ietf.org mailing list" <opsec@ietf.org>
Subject: Re: [OPSEC] New Work: Protecting the control plane
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, 12 Jan 2011 14:51:52 -0000

On Tue, Jan 11, 2011 at 11:00 PM, Ronald Bonica <rbonica@juniper.net> wrote:

> Vishwas,
>
> I think that draft-ietf-opsec-filter-caps answers a slightly different
> question. It has been three years since I looked at that draft, but as I
> recall, it attempts to describe all filtering capabilities that should be
> available on a router.
>

The capabilities drafts were all about "The Router Can do X [filtering]" to
enable testing.



>
> Today, we are asking a more specific question. Specifically we want to know
> what we should do to protect a router's control plane from either a) insider
> attack or b) attack from outsiders spoofing inside source addresses.
>


Filtering things aimed at the control plane, using features enumerated in
the capabilities drafts, would be one use case.



>
> That said, I would be very happy to see somebody resume work on
> draft-ietf-opsec-filter-caps. As I recall, the IESG comments were extensive.
> So, the person signing up for that task should be ready for lots of work.
>
>
I'll go back and have a look at the IESG comments....but I think, at a
WG/AD/Charter level we'd need to revisit the roll of capabilities drafts ...
do they fit in the current charter ?  Are they useful ?  Will they
be used/change anything for the better ?    Perhaps you, I, Chris, Joel and
Joe should *talk* ?

---George





>                                                     Ron
>
>
>
> > -----Original Message-----
> > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
> > Sent: Tuesday, January 11, 2011 1:19 PM
> > To: Ronald Bonica
> > Cc: opsec@ietf.org
> > Subject: Re: [OPSEC] New Work: Protecting the control plane
> >
> > Hi Ron,
> >
> > We already had a draft with that and a lot more:
> > http://tools.ietf.org/html/draft-ietf-opsec-filter-caps-09
> >
> > We could resurrect it, if that is a requirement. It had gone all the
> > way to the IESG.
> >
> > Thanks,
> > Vishwas
> >
> > On Tue, Jan 11, 2011 at 10:01 AM, Ronald Bonica <rbonica@juniper.net>
> > wrote:
> > > There are a few simple things that we can do (e.g., rate limit TCP
> > SYNs)
> > >
> > >                                    Ron
> > >
> > >
> > >> -----Original Message-----
> > >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
> > >> Sent: Tuesday, January 11, 2011 12:47 PM
> > >> To: Ronald Bonica
> > >> Cc: opsec@ietf.org
> > >> Subject: Re: [OPSEC] New Work: Protecting the control plane
> > >>
> > >> Hi Ron,
> > >>
> > >>
> > >> > - attacks from those spoofing the source address of a legitimate
> > >> control plane peer
> > >> This can be caught by authentication, mechanisms also using the
> > source
> > >> address as a part of the hash.
> > >>
> > >> > - attacks from legitimate control plane peers (that might be
> > >> compromised or otherwise misbehaving)
> > >> This is considerably harder to know for IGP's. For BGP we can verify
> > >> the origin . One thing that can be done is Public Key Cryptography.
> > >> There are mechanisms available for the same already, however the
> > >> documents are experimental.
> > >>
> > >> The question however is how important are these issues for the
> > >> operators to tackle?
> > >>
> > >> Thanks,
> > >> Vishwas
> > >
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>