Re: 03bis draft review

[Pekka Savola <pekkas@netcore.fi>]

Seems to be OK now.

On Mon, 22 Mar 2004, George Jones wrote:
> 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./

OK.

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

Fine with me.

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

Seems to be OK.
 
> > > > 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.

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

OK.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings