Re: 03bis draft review

[Pekka Savola <pekkas@netcore.fi>]

Thanks for the quick reply..

On Tue, 16 Mar 2004, George Jones wrote:
> > ==> maybe it would be useful to state that MD5 (as it's commonly used
> > -- e.g., the BGP MD5 checksums would not fulfill the requirements if
> > so) is (not) sufficient (and maybe why).  Or is this taking it too
> > far?
> 
> smb and friends said it better than I could in 3631, so:
> 
> 04>     Per [3] "Simple keyed hashes based on MD5 [17], such as that
> 04>     used in the BGP session security mechanism [18], are especially
> 04>     to be avoided in new protocols, given the hints of weakness in
> 04>     MD5".

Fine with me :)

> > 2.2.3 Use Cryptography in Protocols Subject To Open Review
> >
> > ==> I don't quite understand the title, so maybe a rewording might
> > not hurt, e.g. "Cryptographic Protocols Subject to Open Review"
> 
> Better ?
> 
> 04> 2.2.3 Use Protocols Subject To Open Review For Management

Yep.

> > 2.4.7 Support Remote Configuration Restore
> >
> >    Requirement.
> >
> >       The device MUST provide a means to restore a configuration that
> >       was saved as described in Section 2.4.6. The system MUST be
> >       restored to its operational state at the time the configuration
> >       was saved.
> >
> > ==> how does this relate to 2.4.6 where passwords in the configs MAY
> > be excluded from the saved config?  I.e., how would such excluded
> > config be restored in particular wrt. passwords and other info (e.g.,
> > BGP MD5 secrets which are typically excluded but critical to restore
> > the box)?  Maybe need a bit rewording, or at least a note in
> > "Warnings" section if nothing else...
> 
> Paragraph added to warning:
> 
> 04>      Note that if passwords or other sensitive information is
> 04>      excluded from the saved copy of the configuration, as allowed by
> 04>      Section 2.1.1, then the restore may not be complete.  The
> 04>      operator may have to set new passwords or supply other
> 04>      information that was not saved.

Good enough for me.

> > 2.5.1 Ability to Identify All Listening Services
> >
> >    Requirement.
> >
> >       The vendor MUST:
> >
> >       *  Display the interfaces on which each service is listening.
> >
> > ==> services aren't bound to interfaces, but IP addresses (which
> > may in turn be bound to interfaces, but their access might not be
> > limited to such).. so this is a bit non-sensical requirement.  
> > Maybe must display which IP addresses the service is bound to?
> 
> Better ?
> 
> 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...
 
> >  (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 :)

> > ==> this may also require small finetuning of text in section 2.5.3,
> 
> OK.  Tweeked.
> 
> 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 netblock associated with any interface
> 04>      local to the device. This must include addresses bound to
> 04>      physical or non-physical (e.g. loopback) interfaces.

Is there some text missing after "Requirement." ?

> > "Ability to Control Service Bindings for Listening Services".
> >
> >       *  which network element received the packet (interface, MAC
> >          address or other layer 2 information that identifies the
> >          previous hop source of the packet)
> >
> > ==> related to the previous point, this is good in principle, but
> > might not give sufficient advice (or sufficiently tight leash to
> > the operators :), as interface is not sufficient in e.g. Ethernet
> > media.
> 
> I think it is sufficient even in the ethernet case ..given a flood of
> spoofed addresses, if you can find out which interface packets came
> in on, you can do hop-by-hop tracing if necessary.

Yep -- except if the flood comes through an IX.
 
> > Maybe some notion of
> > PtP vs non-PtP interface requirements needs to go in here
> > somewhere..
> 
> Do you have counter examples ?  Wording ?

Sorry -- not out of hand.

> >    Examples.
> >
> >       This requirement implies that it is possible to filter based on
> >       TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits,
> >       and ICMP type and code fields. One common example is to reject
> >       "inbound" TCP connection attempts (TCP, SYN bit set).
> >
> > ==> This "established/initial" -check is not actually as simple as
> > that, and there is variance about this with the vendors, so this
> > text may need rewording (or picking a different example).
> >
> > That is, some check, "SYN & !ACK" for initial, and "ACK | RST" for
> > established.  Others check for "SYN & !(ACK|FIN|RST)" for initial.  
> > (The difference is practically that one approach allows SYN+RST
> > christmas packets in through the established rule, and the other
> > does not.)  I had a long rant amount that with a few vendors a
> > year or two ago but I don't remember the exact details.
> 
> Better ?
> 
> 04>      "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit
> 04>      clear or SYN bit set+ACK,FIN and RST bits clear).  Another
> 04>      common

Should fix that.

> > 2.12.3 Support Simultaneous Connections
> >
> >    Requirement.
> >
> >       The device SHOULD support multiple simultaneous connections by
> >       distinct users, possibly at different authorization levels.
> >
> > ==> should the SHOULD be a MUST?  I think this is pretty important, at
> > least, and AFAIK, pretty widely implemented as well..
> 
> Good point.   Especially important given the scope ("I'm sorry, you
> can't log in now to fix the security problem, someone else logged in
> to fix a performance issue 3 weeks ago and forgot to disconnect...")

OK.
 
> > 3.2 Document Service Defaults
> >
> >    Requirement.
> >
> >       The vendor MUST provide a list of the default state of all
> >       services.
> >
> > ==> has this been done in practice?  I sure would love to get this
> > info, but haven't seen it myself at least...
> 
> Again, this may not be universal, but it's not a high bar:
> 
>   - log into box with default config
>   - list running + non-runing services
>   - include output in system docs

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 :)
 
> >    Examples.
> >
> >       Examples of this might include filters that permit only SNMP and
> >       SSH traffic from an authorized management segment directed to the
> >       device itself, while dropping all other traffic addressed to the
> >       device.
> >
> > ==> (this may be semi-editorial) -- maybe s/other/other such/ -- you make a
> > leap of faith that SNMP/SSH is the only thing the device needs (which might
> > be OK for an ethernet switch, maybe, but certainly not routers I
> > think :-).
> 
> This is just an example...not intended to be exhaustive.
>  s/SNMP and SSH/SNMP, SSH and other managment traffic/

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

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