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

[George Jones <gmj@pobox.com>]

> > > 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.

It's gone.   Crypto was the one place it would have been really good
to cite.

> >    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.

e.g. biometrics, remote auth-servers (no IP to reach them), others ?

I think what's missing is something that specifies a local enable
password (in IOS terms) or root user (unix) that will *always*
work, network or no, special devices or no...that and possibly
"password recovery" functionality with physical access.

Anybody want to take a quick stab at those ?

>
> > 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.

Got feedback more feedback, did not clearly translate into
requirements.

>
> > > 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?

The info draft is just a collecting point for ideas now.
It's things which are good ideas, but which are not BCP.
It's things that we hope someday to migrate to BCP.
As long as it's a draft, most anything can go in there.
So send in your well formed cards, letters and requirements.
If it goes to an INFO rfc, we might clean it up more and
only leave in the bits that are "realistic" in the near term.
If it stays draft, it can just remain a collecting point.

Those with more experience/influence/opinion about the
IETF processes are welcome to comment on this.

> > 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.)

That's more of how to set up an AAA infrastructure/product, not point
features for devices.

> > 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.)

That's pretty much where the scope settled (it's wadered around some).
Obvously many NSP reqs will apply to many ISP and enterprise setups,
but to get a workable set, you have to have something to shoot at.

> > 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?

So I know there's at least one person here who's implementing
*massive* line rate filtering and at least three who have done
some testing of fliters.   Would they care to speak up on what
they consider to be "best current practice" in implementing
multiple large line rate filtering ?  And, if it's not asking
too much, let's play requirements Jeprody.  Please phrase
your answer in the form of a requirement, with example,
justification and warning for bonus points.

Clearly "infinate filters, on all interfaces at line rate with
no impact on performance ever" is at one extreme, and kicking
every filtering decision up to the route processor is at the
other.   How close to the first is it reasonable to get ?

Thanks,
---George