[NSIS] review - some security comments on documents

[Michael Richardson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----


I was asked to review the requirements, framework and theats documents,
from a security perspective. To be clear my background is Firewalls, IPsec,
key management, and I spent some time trying to build programmable fast
path policy-based classifiers.  I was also involved in the Security Policy
Protocol (SPP) as a firewall vendor - i.e. trying to solve the problem
of getting IPsec through firewalls before the term NAT was around. 

REQUIREMENTS

My general comment is that this protocol is too general. A key symptom of
this is that the requirements are not prioritized. The key thing is,
when compromises need to be made, on what basis will the compromise be made?

Since security is a major requirement, and there are multiple operational
requirements which are very hard to secure, how will things bend?

FRAMEWORK

The framework document excited me. I thought, this is going to be some
sophisticated protocol - end to end, plus hop-to-hop, with mutable objects,
and immutable objects, and some way to insert and delete objects while
avoiding unwanted manipulation by intermediate nodes. In the end, the
framework document actually specified far more requirements than the
requirements document. Most of the additions are very specific security
requirements. 

While I understand why there are two documents from a strict work-flow 
point of view, I think it may be simpler to have one document, perhaps 
one that isn't quite as big.

THREATS

The threats document needs work. I was expecting a threat-model. What things
need to be defended against. Well, again the protocol is too general to do
this, so the document is a bit of a mismash of different things. 

Who do we need to trust to make this protocol work? 

{And, is that a realistic business model? If not, can we change the trust
model to one what matches reality?}

{Please don't tell me that the IETF doesn't do business models. We do. "Best
effort zero-settlement" has been the business model for most of the
Internet. Our current protocols current support that model. QoS proposes
different business models, so we need to know who pays, who gains, and
where is the possible fraud. We need to know this so that we can find out if
the security protects these relationships.) 

A key thing that concerned me is that NSLP objects could be inserted/deleted,
reordered, or even replayed, by NE that are participating in the hop-by-hop
security.  End-to-end integrity would protect the objects, but not their
existence. NSTL/NSLP need an NXT-like (DNSSEC) object which is always
present, so that the receiver can know if objects were removed/inserted.

A major threat that I see is CPU exhaustion of the slow-path. Specifically,
NSTL's section 8.4 - the system MUST aggregate well. But more than that,
it must DEFEND that aggregation at the edges. 

I want to suggest that there are strong arguments for having an integrity
protocol where one can examine the contents of the message first, (since
that is often rather cheap to do) determine if it actually changes state,
and only if the message needs to be acted on, THEN confirm the integrity
of the message. AH, btw, is one integrity protocol that permits this. If
one needs hop-by-hop privacy, then one has to provision the decryptor to run
at anticipated wire-speed to be able to examine the packets, but the
authenticator, (which might even be public key based) does not need to
run at that speed.

I also want to suggest that the security and trust model be fully developed
before any other details are filled on.

The threats document also seems to have been written in isolation from the
framework and requirements document. I think it should parallel the
requirements, explaining why there is a requirement, for instance, for
hop-by-hop security, or end-to-end object integrity, etc..

OTHER DOCUMENTS

I was not asked specifically to review the nstl-00 or application specific
documents, but I did take a look at them. 

I think that the NSTL is the key to the security. While I am very impressed
with this -00 document, I think it is wrong to start with packet formats,
and whether or not TLS, UDP, IPsec, is useable. 

Please start with the public keys - when will they be used, how/if will they
be strongly authenticated, etc.  Maybe that goes into the framework document.

The QoS document claimed that all of this would be offloaded to some AAA
protocol -- I think that this is a cop out. I need to know how the AAA
will provide the integrity protection, the authentication and authorization
that is required.

Section 7 of NSTL basically reads as "just use IPsec".
NOT ENOUGH. Think about the relationships and where the keys will come from.
IKE is signaling. Maybe using signalling to secure signaling is the wrong 
choice. Maybe not.

Please find and read draft-ietf-ipsp-spp-01.txt.

I read: "An alternative approach would be to use raw IP with the RSVP
protocol numbers and a new RSVP version number."
This may also conserve/preserve silicon!

I have a question from ignorance of deployed hardware:
Are RAO filters really available in production fast-path silicon? I know that
some silicon vendors can cope, because they are programmable/configurable,
but what about those that aren't? 

In the NAT-FW document, it says: 
3.2
   "Discovering security gateways, which was also mentioned as an
    application for NSIS signaling, for the purpose of executing an IKE
    to create an IPsec SA, is already solved without requiring NSIS."

   really? I didn't know that it was solved. Do tell!

The QoS and NAT-FW document is clearly too preliminary for me to be able to
evaluate whether or not the requirements or features of the framework have
been satisfied by this protocol. In particular, no statements are made about 
the trust relationships, or who may edit what mutable fields, etc. I was
hoping that there might be enough meat here to saw whether or not the
framework requirement were useful/complete. 

OTHER:
	are there really RMF's capable of managing the resources for all
	paths through a network? I thought that the ATM folks tried to do
	this and failed, and this was one of the reasons that ATM didn't
	get the deployment that was originally envisioned?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [e-mail]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQCbyqoqHRg3pndX9AQFR/AQAsIXy5Ekd75e9BAWMqX1DdxeZKICdI8fi
2+SX3nd34LzTMI5kTsBtCm5Pohl2Gn0B8s3jFkIeZ5qClCZp/Q7yEqz0+52vjJoJ
vwPNNvbJM31bpdY8hlY4ajA9OkNlYCfnexfoMr6G6I0hqpHlwnpDCs+ykK9d8M19
pu0UFTKR09A=
=nK5K
-----END PGP SIGNATURE-----

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis