RE: draft status, BoF, replies to issues

[George Jones <gmj@pobox.com>]

On Tue, 17 Feb 2004, Harrington, David wrote:

> Hi,
>
> Some comments:
>
> Section 2.9.6 - 64bit counters per filter may be onerous on switching
> devices

Better ?

  04> 2.9.6 Filter Counters Must Be Accurate
  04>
  04>    Requirement. Filter counters MUST be accurate.  They MUST reflect
  04>       the actual number of matching packets since the last counter
  04>       reset.  Filter counters MUST be capable of holding up to 2^32 -
  04>       1 values without overflowing and SHOULD be capable of holding up
  04>       to 2^64 - 1 values.

> Section 2.13 - this, especially coupled with 2.9.6, would be onerous on
> a low-end L3/L4 policy switch.

For context:

  03> 2.13 Layer 2 Devices Must Meet Higher Layer Requirements

What this is saying is that we can't ignore layer 3+ security issues
for devices that are primarily layer 2 devices.   If you use layer3+
mechanisms to manage the device, you need layer3+ security features.
Hackers won't stop sniffing telnet passwords just because you're "only
telnetting to a switch".

Also, and here the scope may need refinement, the target of the doc is
not generally low end gear.

> Section 2.12.9 - From a security standpoint, this is good practice, and
> I personally drink the security koolaid,

:-)

> but not having default
> passwords would not be popular with many customers because it increases
> the burden of configuring a new device.

Again, back to target audience + scope.  I believe that for "large IP
networks" provisioning will be done according to a defined process
and/or by skilled network engineers.  Adding a step to the process
vs. having core networking elements compromised seems like a fair
tradeoff.  If we're talking about SOHO devices ("why do I need
password ?"), I could see your point.

>
> Section 2.4.6 - which is the BCP - SCP, SFTP, or FTP over a secure
> channel? Which is best under which circumstances? It would be good to
> provide guidance to those who need to decide on one approach, and it
> would be best to have a consistent answer to the question about which to
> use. (i.e. BEST current practice?)
>
> David Harrington
> dbh@enterasys.com
> co-chair, IETF SNMPv3 WG, concluded

The BEST practice is to have a way to store the config (principal).
The examples (which you cite) are there to illustrate at least one way
to implement the practice using current technology, with conscious
attention given to the fact that there may be better ways to do it in
the future.  The best practice is the principal (something that is
being done now), not the particular implementation.

Would you like SNMPv3 added to the list ?

Thanks,
---George Jones

>
>
> > -----Original Message-----
> > From: George Jones [mailto:gmj@pobox.com]
> > Sent: Tuesday, February 17, 2004 9:16 AM
> > To: opsec@ops.ietf.org
> > Subject: draft status, BoF, replies to issues
> >
> > OK.  It's been quite here.  Status of things is the -03 draft went to
> > IESG last call.  There have bee a number of comments in the id tracker
> > (https://datatracker.ietf.org/public/pidtracker.cgi?command=vi
> > ew_id&dTag=10387&rfc_flag=0)
> > as well as in other fora (routing-discuss mailing list, etc.) and
> > private mail to me.  I'm going to try to clear out the backlog and
> > respond to all issues raised, CCing this list with all responses.
> >
> > The doc apparently got a very mixed reception and there was enough
> > concern in the IESG that they've scheduled a BoF to discuss
> > what to do.
> > Likely options seem to be (in no particular order): nothing, spin up a
> > working group, publish current doc (with revisions) as an info RFC and
> > spin up a working group, revise current draft and publish as BCP rfc.
> >
> > As I've said all along, I will do whatever the wise Area Directors,
> > IESG, etc. see best.  I'm in this to produce useful substance in
> > whatever form makes sense.
> >
> > I will not be @ the BoF (though I might be able to do Jabber or AIM if
> > someone who will be there sets it up.)
> >
> > Thanks to all who have read the draft and provided feedback
> >
> > Responses to follow.
> >
> > George M. Jones    |  Gulta cavat lapidem non vi sed saepe
> > cadendo ("The drop
> >                    |  hollows the stone not by force but by
> > often falling")
> >                    |
> >                    |      Ovid (Latimer, 7th sermon)
> >
> >
>
>