Re: [spam score 5/10 -pobox] draft-jones-opsec-01.txt comments

["Joel N. Weber II" <ietf-opsec@joelweber.com>]

> Sorry for the delay...I'll blame a hurricane and weekend for
> 3 days of delay...the rest is me being slow.

Well, I've been *much* worse about paying attention to my email lately...

> Either way, serial or IP, it is assumed that directly (or remotely)
> connected management devices are secure....at least their security
> is beyond the scope of the draft.

OK, and that even makes a lot of sense when I remind myself that this
is targeted at requirements for device makers.

> > Is ANSI.T1.276-200x publicly available at no charge?  A google search
> > for ANSI.T1.276-200x found me your draft on port111.com, and nothing
> > else.
>
> Chris posted the latest references.    Do people think references
> should removed if it's not freely available/citable ?

Yes, because I'm not really convinced that citing it really buys much
vs writing an appropriately tailored description of the requirements
for the opsec document.

> > I wonder if it would be useful to define two levels of management
> > access: access for a handful of people who maintain the authentication
> > infrastructure, and some of the core functionality of the network
> > devices, and then a second class of access for people who only need
> > access when things are mostly working.
> >
> > For example, if an NSP has a router with 100 customer circuits on it,
> > and a couple of circuits going to other routers the NSP has, the
> > technicians who troubleshoot customer circuits can reasonably use
> > Kerberos, or can use some sort of X.509 based system that does online
> > verification that there's no revocation certificate out there.  The
> > people responsible for keeping that router connected to the NSP's
> > backbone are probably going to need to know some kind of password that
> > they can use to log in on the console port.
>
> See if these do it for you.
>
>    2.12.13 Ability to Define Privilege Levels        . . . . . . . . . . . . 44
>    2.12.14 Ability to Assign Privilege Levels to Users        . . . . . . . 44
>    2.12.15 Default Privilege Level Must Be Read Only        . . . . . . . . 45

What I was thinking about there was more what sort of infrastructure
you could afford to rely on for the different classes of users.  There
are some authentication technologies out there which simply cannot
work when the only thing on the device that's working is an ASCII
console port.  Yet some of those technologies that require some more
infrastructure are more usable/scalable in a large environment.

> One of the bits of feedback I got at RIPE was that there needs to be
> more work on authorization....details are supposedly forthcoming.

given that that was a month ago, since I've been lame, I'm a bit
curious if anything has come of this.

> > One other interesting question is whether you could build a protocol
> > for automatic updates of that password.
>
> New protocols and database problems are outside the scope.

Is mentioning the possibility of heading in this direction out of
scope for the document that's not BCP, but future directions?

> > (Note that this may be a case
> > where you really do want to share a password between lots of people,
> > so that if the update breaks, you will actually notice; if you have an
> > account per user, and a disgruntled employee leaves and the protocol
> > only deletes his account on half the routers, is anyone ever really
> > going to notice?  My experience has been that anything that depends on
> > people checking logs and noticing that something is wrong will go
> > unnoticed sooner or later.)
>
> One can imagine a system whereby centalized AAA accounts are used to
> grant read access to a copy of the enable/line passwords for devices
> which the user is authorized, and automated procedures (scripts) are
> used to update the enable/line passwords...but again, outside the
> scope.

Ah, sure, that would work.  (And again, it feels like that should be
explored a bit in the future directions document.)

> > Of course, that default for the NAT case is a more strict requirement
> > than what is recommended in the non-NAT case, but I don't think that
> > necessarily makes it incorrect.  On the other hand, I'm thinking of
> > consumer-grade devices here,
>
> I think NAT is not a requirement in large network infrastructure
> (anybody using NAT between the core and edge ?)

If we're explicitly only targeting devices used by NSPs, then ignoring
NAT is fine.  But I was under the impression that the scope wasn't
necessarily just NSP hardware...

(Not that I would have any objection to explicitly restricting the
scope to NSP hardware.)

> > Sorry, I meant to say that that section seems to imply that if you
> > have a SOHO NAT box that does forwarding and filtering on a
> > microprocessor, it needs to delibrately waste cycles when it's not
> > filtering if it can't keep up with a full 10mb worth of traffic when
> > filtering.
>
> That would be backwards.   It's simply saying if you can pass N/pps
> w/o filtering, you should be able to passs N/pps with filtering.

So, if I'm implementing a routing stack on a microprocessor, it's hard
to guarentee that filtering will not affect performance.  If you
ignore the issue that there's a cache, and there's limited memory
bandwidth, it means you need your inner loop that decides what to do
with a packet to delibrately waste some cycles whenever there's no
filter in place.

(On a modern processor, you probably end up with the filtering code and
the filter table in the cache, whereas new incoming packets have to
come over the (relatively) slow external bus on the processor each
time, so a filter of some complexity may not actually slow things down
at all.)

Also, for the requirement to be meaningful, how complex are the
filtering rules where the device is supposed to have the same
performance as when it's not filtering?  What if someone configures a
device to check 10,000 rules against each and every packet?