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

[George Jones <gmj@pobox.com>]

On Thu, 21 Aug 2003, Joel N. Weber II wrote:

> Comments on draft-jones-opsec-01.txt:
>
> There is a reference to SCP.  I believe the secsh working group is
> working on standardizing SFTP, and not SCP, so it probably would be
> better to refer to SFTP.

These are both in "Examples" sections, which are intended to give
ideas about ways to meet the requirement using technology available
a the time of writing.   SCP is available now, widely deployed and
would meet the requirement.    I'll add a reference to SFTP.

>
> Under ``2.1.6 Restrict Management to Local Interfaces'', I can easily
> imagine SOHO devices where limiting the TTL to 1 might not be
> sufficient.  For example, my understanding is that it is often the
> case on a cable modem that many other end users appear to be in the
> same ethernet broadcast domain.  And if you were using a NAT box on a
> typical college dorm network, the TTL of 1 on all ports approach
> certainly wouldn't provide complete security.

Correct.

>  I think restricting
> based on which interface is intended to be internal would be more
> effective.

This is intended to keep joe-hacker-who-is-23-hops-away from being
able to attempt remote management.  @ 23 hops, he's likely coming
from the external interface.

How would you use this on internal interfaces ?

I think this may accomplish what you want:

   2.5.3   Ability to Control Service Bindings for Listening Services

possibly in combination with

   2.5.2   Ability to Disable Any and All Services

>
> A warning that the ``internal'' interface may not be secure if it is a
> wireless interface might also be worthwhile.

It might also not be secure if it's in a college dorm :-)

The working assumption is that the operator can secure the management
device that is directly connected.  Should that be stated ?
The security of the devices that are connected is beyond the scope.

Note that "2.1.6 Restrict Management to Local Interfaces" is moving
from the BCP draft to the INFO draft[1] , as I'm not sure that this is
common practice outside BCP/that there is support for setting the TTLs.

>
> Under ``2.2 In-Band Management Requirements'', I think it would be
> worthwhile to better qualify this example:
>
> |   o  Since the same networking code and interfaces are shared for
> |      management and customer data, it is not possible to isolate
> |      management functions from failures in other areas (for example, a
> |      "magic packet" or buffer overrun that causes the data forwarding
> |      portions of a router to crash will also likely make it impossible
> |      to manage...this would not necessarily be the case if the
> |      management and data forwarding elements were completely separated)
>
> In particular, while that's true, isolating the management and data
> forwarding elements may be considerable effort for some devices; they
> either need seprate processors, or good memory protection.

Moving to the INFO draft for just that reason.

> Under ``2.2.2 Use Strong Encryption'' it may be worth discussing the
> importance of a strong MAC and a strong block chaining mode as well as
> a strong cipher.

Would you care to help with the wording/reqs ?

> Under ``2.2.3 Key Management Must Be Scalable'': one of the obvious
> things to consider is the use of Kerberos, but the warnings should
> probably explicitly say something about how in managing a network
> device, you may need to log in to fix it

Period.   I think 2.12.7 hits this (fallback to local if configured)

> s connectivity to a key
> server, and the importance of being able to use PKI in a way that
> doesn't depend on being able to talk to any external server once the
> key is configured.  (A dependence on OCSP should be warned against.)
>
> There should also be discussion of how you revoke a key on N devices
> when none of the devices check with a central server every time the
> key is used.

Right.  Hard problems.  This has been moved to the INFO doc.  If you'd
care to edit/discuss, I'll take contributions.

>
> It may be that the stuff in 2.2.3 should move to the 2.12 area, and
> some of my 2.2.3 comments apply to some of the stuff in 2.12.

Yes.  I think you're right.   If/when it moves back into the main
doc, it will probably go there.

>
> Does ``2.3.4 No Forwarding Between Management and Data Planes''
> prohibit a command on the console port from initiating an outbound
> telnet session to the data forwarding interface?

The intent here is primarily to make it impossible for management
to be attempted from the public/data forwarding side.   If you
can't get the packets there, you can't attempt management.

> For the ``separate IP stacks'' option, what counts as ``separate''?
> If they run on the same processor type and are compiled from the same
> code base, are they separate?

Yes.

You can crash/compromise one, but you will not crash/compromise the
other because a) you can't get there from here and b) they are not
sharing resources (memory, processor, etc.)

Do you think that needs to be spelled out more clearly ?

Again, this has moved to the info side.


>
> ``2.5.3 Ability to Control Service Bindings for Listening Services''
> should warn against depending on IP source addresses not being spoofed
> when ensuring security, and should perhaps say something about the
> need to do filtering on border routers.  ``2.5.4 Ability to Control
> Service Source Address'' should have similar warnings.

OK.   Will add.

>
> ``2.5.5 Support Automatic Anti-spoofing for Single-Homed Networks''
> should clearly state whether/how it applies to NAT.

Suggestions ?

>
> ``2.7.3 Ability to Filter Traffic Through the Device'' should mention
> that it's possible to tunnel any port over any other port, and that
> this is not necessarily a useful content filtering mechanism in the
> presence of hostile users.

Will add to warning section.

>
> If ``2.7.4 Ability to Filter Updates'' is going to advocate IP address
> ``security'' for in-band configuration protocols, it needs to include
> warnings about the limitations of IP address ``security''.

Yes.

Having address filtering is better than not having it.  That's all.

>
> The wording of ``2.7.7 Ability to Filter Without Performance
> Degradation'' seems to imply that if you have a SOHO NAT box that does
> forwarding and filtering on a microprocessor needs to delibrately
> waste cycles when it's not filtering if it can't keep up with a full
> 10mb worth of traffic when not filtering.

???

>  I think the more
> interesting thing to focus on may be that if forwarding is done by an
> ASIC, that ASIC needs to support filtering.  (I think the Cisco 2500
> and 2600 series routers are examples of routers that lose a *lot* of
> performance in certain filtering cases, because they switch from ASIC
> to microprocessor based filtering, but I may be a bit confused about
> that, and I haven't been paying much attention to Cisco's product line
> in the last couple years.)

ASICs are implmenation.   The requirement is fast filtering.
It has moved to the info doc, but I could be convinced, based
on Dave Newman's article/evaluations, to move it back to BCP.

> ``2.8.1 Ability to Filter on Protocols'' should warn about ICMP
> filtering breaking path MTU discovery.

Will do.

>
> ``2.8.5 Ability to Filter on Layer 2 MAC Addresses'' should warn about
> how it's trivial on many systems to change your interface's MAC
> address, such that MAC address ``security'' isn't really security.

Will do.  Again, being able to do it is better than not being able to
do it.

>
> The justification under ``2.9.1 Ability to Accurately Count Filter
> Hits'' seems bogus.  Things that automatically retry will be seen as a
> greater threat, if you go by packet count, even if the following
> packets don't differ in any interesting way.  Some of the subtle
> things that nmap can try to do make it very hard to get reliable
> information out of this.

The requirement is accurate counting of the matching traffic presented.
The requirment is not AI that does attack analysis.   We still need
humans for that.

> ``2.11.6 Ability to Maintain Accurate System Time'' should talk about
> spoofed timeservers

Wording ?

> and cryptographic authentication.

See

  2.1.1 Support Secure Management Channels

[1] Per earlier mention on the opsec mailing list, I've split the
    current draft in to clearly BCP items and "other" items that will
    probably come out as a seperate draft concurrent with the -02
    release of opsec, mid-septempber.


Thanks,
---George Jones