[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: draft-ietf-opsec-filter-caps (Filtering and Rate Limiting Capabilities for IP Network Infrastructure) to BCP
I support the informational approach.
We need/desire many of the features in this soon but by letting the
vendors decide which they can tackle in near term releases we will
hopefully come to a real BCP in the near future.
To Barry's statement specifically for syslog you and other NE vendors
need to think about syslog aggregation ON box perhaps by a dedicated log
processor so that you can send off statements like "scan of port 22";
last statement repeated 1000 times.
Most syslog servers do this today and it makes it less stressful if you
only send the first message and the count of repeats.
01100101000010|10011010111101?
Hint 7 bit ascii
Donald.Smith@qwest.com giac
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of Barry Greene (bgreene)
> Sent: Wednesday, June 27, 2007 2:13 PM
> To: Chris L. Morrow; Ron Bonica
> Cc: opsec@ops.ietf.org
> Subject: RE: Last Call: draft-ietf-opsec-filter-caps
> (Filtering and Rate Limiting Capabilities for IP Network
> Infrastructure) to BCP
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> My concern was unilateral imposition of a BCP with no demonstrated
> "rough consensus" on the community it is suppose to apply.
>
> I would love to do everything in the document. But dealing with
> ASICs, FPGA, NPs, and other forms of hardware we use today,
> compliance to a BCP is going to be unsatisfactory. I've got many
> "ACLs" engineers who have looked and said "no way" can you do that
> with what is coming out in future hardware (given the technology we
> are using in the vendor community).
>
> To put this in context, take a statement like (from 4.3)
>
> "Logging can be burdensome to the network device, at no time should
> logging cause performance degradation to the device or services
> offered on the device."
>
> What does mean in hardware? It means you need to take a copy of the
> packet, convert it to a log statement, then move it to your control
> resource, store it on the devices log, then export it (if syslog is
> configured). So how do you do that at 10GE speeds with the capability
> to do this on every interface on the router?
>
> The fact of the matter is that we NEVER go from INTERNET DRAFT to and
> RFC which is an INTERNET STANDARD. Why should we go from an INERNET
> DRAFT to a RFC which is an BCP?
>
>
>
>
> > -----Original Message-----
> > From: Chris L. Morrow
> > [mailto:christopher.morrow@verizonbusiness.com] Sent: Wednesday,
> > June 27, 2007 1:02 PM
> > To: Ron Bonica
> > Cc: Barry Greene (bgreene); opsec@ops.ietf.org
> > Subject: Re: Last Call: draft-ietf-opsec-filter-caps
> > (Filtering and Rate Limiting Capabilities for IP Network
> > Infrastructure) to BCP
> >
> >
> >
> > On Wed, 27 Jun 2007, Ron Bonica wrote:
> >
> > > Folks,
> > >
> > > The last call has ended and AFAIKS, this was the only
> > comment. Would
> > > the authors object to publishing this document as INFORMATIONAL?
> > > If not, we can proceed immediately. If so, we need to work
> > through the issue.
> > >
> >
> > I'm 'ok' with informational, since I had thought that was
> > what it was intended to be in the beginning. I understand
> > that 'BCP' could be applied (as relayed to me by an IAB
> > person) since this is a 'best common practice for vendors to
> > comply with'. I suppose I agree that the proposal is to
> > propose 'best common practices' for equipment... so from that
> > standpoint a 'BCP' would apply.
> >
> > I think that Barry's original issue (and I hope he tells me I'm
> > wrong/right) was that 'BCP' (to me as well originally) meant
> > 'what operators do on a common basis' or 'best common
> > practice for operators of the said thing'.
> >
> > So, for me, either works.
> >
> > > Ron
> > >
> > >
> > > Barry Greene (bgreene) wrote:
> > > > I don't understand "BCP." Information RFC yes. Something
> > that can be
> > > > use for requirements yes. But Best Common Practice? How is an
> > > > operator's "I wish my equipment can do this in my
> > network" become a BCP?
> > > >
> > > > IESG - I think we are abusing the BCP system. It states:
> > > >
> > > > A BCP document is subject to the same basic set of
> > procedures as
> > > > standards track documents and thus is a vehicle by
> > which the IETF
> > > > community can define and ratify the community's best
> > current thinking
> > > > on a statement of principle or on what is believed to
> > be the best way
> > > > to perform some operations or IETF process function."
> > > >
> > > > Which means we should be going through the same lifecycle of
> > > > document status as the standards track.
> > > >
> > > > What we are getting now is the equivelent of a straight
> > to Internet
> > > > Standard status.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: The IESG [mailto:iesg-secretary@ietf.org]
> > > >>Sent: Monday, June 11, 2007 1:34 PM
> > > >>To: IETF-Announce
> > > >>Cc: opsec@ops.ietf.org
> > > >>Subject: Last Call: draft-ietf-opsec-filter-caps
> > (Filtering and Rate
> > > >>Limiting Capabilities for IP Network Infrastructure) to BCP
> > > >>
> > > >>The IESG has received a request from the Operational Security
> > > >>Capabilities for IP Network Infrastructure WG (opsec) to
> > > >>consider the following document:
> > > >>
> > > >>- 'Filtering and Rate Limiting Capabilities for IP Network
> > > >> Infrastructure '
> > > >> <draft-ietf-opsec-filter-caps-08.txt> as a BCP
> > > >>
> > > >>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
> > > >>2007-06-25. 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-filter-ca
> > > >>ps-08.txt
> > > >>
> > > >>
> > > >>IESG discussion can be tracked via
> > > >>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> > > >>w_id&dTag=13825&rfc_flag=0
> > > >>
> > > >>
> > > >>_______________________________________________
> > > >>IETF-Announce mailing list
> > > >>IETF-Announce@ietf.org
> > > >>https://www1.ietf.org/mailman/listinfo/ietf-announce
> > > >>
> > > >
> > > >
> > >
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBRoLEu7/UEA/xivvmEQJKIACfTOY20AJqWC+0aEbLGgSfYZpF1VkAoOL9
> CMGdmNaF/QYkKQFExEXNl6BA
> =mOQp
> -----END PGP SIGNATURE-----
>
>
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.