Re: Reply to reveiw comments from Pekka Savola (2 of ?)

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 26 Feb 2004, George Jones wrote:
> > Hmm. "The configuration MAY be compressed using a compression
> > algorithm which is openly available, as long as the fact is clearly
> > identified, and the compression can be disabled." ?
> 
> OK. Added to req for storing remote configs.

This doesn't mention compressed log files, but is generic enough as it 
is so that I don't have objections. [snip]

> > > ps> 2.5.4 Ability to Control Service Bindings for Listening Services
> > > ps>
> > > ps>   Requirement. The device MUST provide a means for the user to specify
> > > ps>       the bindings used for all listening services.  It MUST support
> > > ps>       binding to a list of addresses and netblocks.  It MUST also
> > > ps>       support configuration of binding services to any interface local
> > > ps>       to the device, physical or non-physical (e.g. "loopbacks").
> > > ps>
> > > ps> ==> it should be clearer what's in scope for this.  Is e.g. the his
> > > ps> like:
> > >
> > > no ?  Perhaps the longish justifcaiotn (result of discussinon on the
> > > opsec list IIRC) before that confused the issue ?
> >
> > I'm trying to figure out what my point was.  Oh yes, I believe it was
> > that currently, I'm not aware of implementations providing this kind
> > of binding feature.
> 
> I thought that IOS's "ip [logging|tacacs|telnet...] source-interface ..."
> provided this granularity of control, at least for some services.

Those are not services, they just specify the interface which is used 
by syslog, tacacs, telnet etc. packets leaving the router.
 
> >  The fact is achieved using access lists, which
> > are created by the user ("ip receive acl" in IOS or "loopback acl" in
> > JunOS).  I think one should be clearer whether such user-created
> > mechanisms are sufficient in this context, or do you require
> > additional mechanisms?
> 
> Added the following to "examples".
> 
> 04>      Similar effects may be achieved with the use of global filters,
> 04>      sometimes called "receive" or "loopback" ACLs, that filter
> 04>      traffic destined for the device itself on all interfaces.

But the good question is, which I'm not sure whether you took a stance 
on, whether this fulfills the requirement?  This isn't "binding", 
strictly speaking, but a slightly different kind of "service usage 
restriction".  Which one you want should be reflected in the 
requirement..
 
> 04> 2.7.5 Support Route Filtering
> 04>
> 04>    Requirement. The device MUST provide a means to filter routing
> 04>       updates for all protocols to be used to exchange external
> 04>       routing information.
> 04>
> 04>    Justification. See [RFC3013] and section 3.2 of [RFC2196].
> 04>
> 04>    Examples. Operators may wish to ignore advertisements for routes to
> 04>       addresses allocated for private internets. See eBGP.
> 04>
> 04>    Warnings. None.
> 
> Let me know if you think some language about interior/external gateway
> protocols would help (& possible refs).

Yes, I think that would be useful, because one could rightfully ask, 
"please define external routing information" :).  And that's a bit 
difficult.

Would it make sense to just make this MUST requirement for BGP?  
Additionally, one might want to note that it may be important to have
such features in other protocols as well.

E.g.:

2.7.5 Support Route Filtering

   Requirement. The device MUST provide a means to filter routing
   updates for all exterior gateway protocols protocols (e.g., BGP).
   The device MAY provide a means to filter routing updates for
   other protocols as well (e.g., OSPF, RIPv2).

   Justification. See [RFC3013] and section 3.2 of [RFC2196].

   Examples. Operators may wish to ignore advertisements for routes to 
   addresses allocated for private internets. In some cases, even
   running an IGP towards a customer may be necessary, requiring 
   route filtering capability. See eBGP.

   Warnings. None.

[[ note: MAY or SHOULD, makes no difference to me.. ]]