Re: 03bis draft review

[George Jones <gmj@pobox.com>]

On Wed, 17 Mar 2004, Pekka Savola wrote:

> > > 2.5.1 Ability to Identify All Listening Services
> > >
> > 04>     *  Display the addresses to which each service is bound.
> > 04>     *  Display the interfaces to which each address is bound.
>
> Still, is the latter correct?  How do you bind to an "interface"?
> You just pick the addresses corresponding to an interface...

try, try again:

s/Display the interfaces to which each address is bound./
  Display the addresses assigned to each interface./

> > >  (Note that that is not commonly
> > > supported either, I think -- but at least one vendor does.)
> >
> > Maybe not...but this is not a high bar ("netstat -an","lsof -i", and
> > "ifconfig" in Unix terms) and has high utility from a security
> > standpoint.
>
> Totally agree that this is simple to do, but it may still not be out
> there at least all that often.  We'd really want it though :)


Given a) the high utility b) the low bar to implement c) the fact that
the draft has moved from BCP to INFO with the addition of a sevaral big fat
"your requirements may vary" warnings, I'm going to leave this one as
is unless someone else screams intellegently that it should be removed.

> > 04>   Requirement.
> > 04>
> > 04>      The device MUST provide a means for the user to specify the
> > 04>      bindings used for all listening services. ...
>
> Is there some text missing after "Requirement." ?

I don't think so...your reply had some weird line formatting...maybe
that was messing you up.   Current reads:

04> 2.5.3 Ability to Control Service Bindings for Listening Services
04>
04>    Requirement.
04>
04>       The device MUST provide a means for the user to specify the
04>       bindings used for all listening services.  It MUST support
04>       binding to any address or net-block associated with any
04>       interface local to the device. This must include addresses bound
04>       to physical or
04>
04>    Justification.

> > > 3.2 Document Service Defaults
> > >
> > >    Requirement.
> > >
> > >       The vendor MUST provide a list of the default state of all
> > >       services.
>
> Sure, it's not difficult to get that, but that's different from the
> vendor doing that.  But I have no objection, just a concern on how
> this maps to the reality :)

Leaving for now.  Same rational.  High utility.  low bar. info not bcp.

> I mean -- if the box has BGP sessions, do you count that as management
> traffic?  Same for other kinds of sessions which are not obviously
> management (such as SSH, syslog, SNMP, etc.)

The principal is ability filter all traffic from any source directed
to the box on any interface/address.   Call it management.  Call it
control.   Call it what you like.  If it's headed TO the box, it
needs to be able to be filtered.   Try:

04> Examples of this might include filters that permit only BGP from peers
04> and SNMP and SSH from an authorized management segment and directed to
04> the device itself, while dropping all other traffic addressed to the
04> device.

Thanks,
---George