Subject: [NSIS] review - some security comments on documents

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Feb 2004 22:38:38 -0400

-----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[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 9 Feb 2004 11:34:19 +0100

hi michael, 

it is great that you took your time to read our documents. please find my
comments inline:

> My general comment is that this protocol is too general.

as a background: this was our first document in the nsis working group.
at the beginning we haven't had a clear idea what we were addressing in the
working group in detail. 
for example, nat/fw signaling was not in scope at that time. 

hence, all requirements are rather high-level. later we decided that we
should move forward and finish the work on the requirements rather than
re-writing them again to, for example, reflect the two-layer architecture. 

> A 
> key symptom of

that's always a problem with requirements. if you look at other working
groups then you will notice that the requirements are not prioritized as
well. 

> requirements which are very hard to secure, how will things bend?

could you be more specific?

> requirements document. Most of the additions are very 

you are right. the framework is more specific than the requirements document
since it was written much later and we had more ideas what we are going to
solve and how. 

> one that isn't quite as big.
hmmm. in the past we have received a number of comments regarding document
restructering. restructuring the documents again and again is very time
consuming and might not add that much value. 

> the security protects these relationships.) 

certainly true. 
the initial focus of the working group was oriented towards qos signaling.  
we wrote a separate draft which addresses authorization aspects in qos
signaling to raise peoples attention (; actually two drafts have been
written). you might want to take a look at them: 
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-qos-authz-issues-00.t
xt and 
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.txt
http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-aaa-issues-01.pdf

unforunately, we have not received proper attention. 

another thing regarding the threat model: you have different security
requirements at different layers: first, you need to worry about the
signaling exchange between neighboring nodes itself itself and then you need
to worry about what you actually signal. you can compare this to diameter.
diameter itself needs some the same is true for sip. we tried to capture
these issues with Figure 2 in [THREATS]. 

a document handling issue: it is difficult to address all threats of all
possible signaling applications in the threats draft itself. it took us some
time to think about the threats and the problems of nat/firewall handling.
we have placed them in the nat/firewall nslp draft. some other threats are
very specific to some signaling protocols but not present in others. 

> existence.

nsis is not really an end-to-end signaling protocol, in most cases. you
might want to take a look at section 4 of the
<draft-tschofenig-nsis-aaa-issues-01.txt> draft. there we argue that
hop-by-hop security makes a lot of sense in qos signaling with the
corresponding authorization model (we called it New Jersey Turnpike Model,
just to give it a name). a different model (we called it New Jersey Parkway
Model) makes everything very, very difficult - with little utility. 
you have to trust the intermediate nodes to a certain degree since they can
do all sorts of things. 

> NSTL/NSLP need an NXT-like (DNSSEC) object which is always

certainly an interesting idea. if you look at the rsvp security property
drafts then you see that some people already proposed similar things but
they have never been deployed anywhere (in case of qos signaling). 

for nat/firewall signaling we are currently investigating the need for
end-to-end protection. 
there, however, you have the problem that you only signal a packet filter
which might change along the path and, in presence of nats, has no meaning
to the other end. 

> it must DEFEND that aggregation at the edges. 

i we need to talk about this issue in more detail. i am not sure what we
both mean the same with aggregation. 
which draft you are referring? 

> authenticator, (which might even be public key based) does not need to

we fully agree that you need to have integrity protection. 
steve bellovin was one of those persons that insisted on having support for
encryption (unlike in rsvp where only integrity protection is offered). 

performance considerations are a separate issue. usually signaling message
protection is the least thing we worry about. the key exchange creates more
headaches. additionally, if you propose end-to-end security then things get
really difficult. 

> before any other details are filled on.

do you have a draft were we can look at to see what you would like to see?

> framework and requirements document.
why do you think so? 

the requirements document was written before we started the work on the
threats document. 

 I think it should parallel the
> hop-by-hop security, or end-to-end object integrity, etc..
you are certainly right. we will double-check whether there is some
consistency in there. 
if there are inconsistencies then i am guilty for it since i wrote the
section in the requirements draft, threats draft and the framework draft. 

> documents, but I did take a look at them. 
which one? 

gimps ntlp?
the nat/firewall nslp or the qos nslp? 

i give you an answer for all three of them: 

- ntlp: we need to work on the security description. the next version will
contain more content. 
- qos nslp: we are working on the security issues. we basically have add the
content of the previously mentioned qos authorization drafts in there (and
at the same time try to keep the document at a low pagecount.) currently the
qos document contains no security since we haven't had time to finish all
the work. please note that this is not the first security document. it is a
merge of previous document which contained security. however, the process of
merging document takes some time - work in progress.if you look at the qos
authorization documents than you will be convienced that we serioulsly
tooked at qos authorization (based on steve bellovin's request). 
- nat/fw nslp: see below.

> I think that the NSTL is the key to the security.
ntlp - gimps: 

it is the key for security between neighboring nodes. it cannot address
authorization issues for nslp applications. 

> While I am 
> very impressed

agreed. the ntlp suffers from detailed threats. unfortunately, editing was
done in the last minute and i had no chance to add some text. we discussed
threats at the mailing list but we haven't incorporated them into the draft
yet. 

the ntlp is also not the first document in this area. we have had a number
of other documents before. some of them had such a detailed security
consideration section that people said: "this is not a security protection -
keep the security consideration section shorter."

> be strongly authenticated, etc.  Maybe that goes into the 

i guess we need to discuss this issue in more detail. 

> This may also conserve/preserve silicon!
certainly not my idea (since it also creates problems with some ipsec
implementations with regard to the supported traffic selectors).

> but what about those that aren't? 

this issue is, among many others, discussed in the analysis document. 
you might also want to take a look at michael's web page which talks about
the impact of ip option processing: http://www.welzl.at/ip-options/

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

we tried to scope our work. our work started with installation of packet
filters in a path-coupled way. we are not developing a solution for ike to
discover ipsec gateways. you might want to take a look at tunnel endpoint
discovery (ted) for such a solution.

> the trust relationships, or who may edit what mutable fields, 
> etc.

for nat-fw draft: actually the draft contains a fair amount of discussion on
trust relationships (see section 3.5, section 4., appendix b, appendix D).
that's more than i have ever seen in the are of path-coupled firewall
signaling.

there are no requirements for nat/firewall signaling. melinda shore
suggested the idea in the midcom working group. she presented her idea at
the tist bof and the work was moved to nsis. 

> I was

the framework focuses on qos signaling and not really on nat/firewall
signaling. 

> 	get the deployment that was originally envisioned?

that's a qos question which many folks in the nsis working group will be
glad to give you an answer for :-)

thanks again for your detailed comments and for the time looking at the
drafts. your comments will certainly improve the quality of the documents. 

ciao
hannes

> ] [email-masked]      
http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security
guy"); [

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 9 Feb 2004 12:01:10 -0000

Michael,

Thanks for these comments. I'll try to address those which affect
the framework and NTLP (my main focus).

NSLP authors should definitely read this (it is a request for input
for NTLP development).

On the document structure, I think everyone (including the authors)
would accept the structure we have for the 'informationals' is not
ideal. It's something that is too late to change now, but might be
avoided in the future if the IETF had better defined working processes
(although that might be a double-edged sword, of course). If we have
managed to set ourselves up to design the 'right' protocols, I think
that's the best we can do (and I think we have, maybe with one
exception you point out).

The primary open security issue - as it affects the NTLP, and as
maybe should have been explained more in the f/w but weren't - is 
how the trust and security models should be reflected in the actual 
operation of the protocol. 

Specifically, the NTLP draft currently says (mainly in section 7):
- there is some stuff about DoS attacks and routing integrity
attacks, which have to be handled (and handled non-cryptographically)
in the NTLP (in fact, I regard this as the main security service
provided by the NTLP)
- if you want channel protection, use existing security protocols
- BUT it doesn't say how those protocols should be invoked in
detail (or, really, at all).

The problem is that the trust/security models IMHO can't be fully
defined by the NTLP but are signalling application specific (and 
probably in fact also deployment specific). This issue is (implicitly)
defined as open in section 8.6 of the NTLP draft. Therefore:

Maybe what we need to do is to get the NSLP authors to say how their
trust/security models imply that channel security protocols should
be invoked, and then make sure that the NTLP can be used compatibly
with those requirements (and still maintain the DoS/routing integrity
protection which is its major goal).

I'm fairly certain in my own head, however, that the NTLP needs to be
flexible (i.e. not constrain) what trust/security models can be used.
To draw a comparison, 3436 and 3554 contain basically no discussion
of such issues; I think the NTLP needs to go a bit further, but not
very far.

robert h.

PS you also raise a couple of points about IP layer issues (RAO
processing, IP protocol number). Basically, I don't think there is a
'right' answer - all we can do is gather all the information we
can and make a (hard) judgement call. However, my impressions are:

- if RAO processing with some discrimination can't be done on the
fast path, we are stuffed anyway. I think the way the RAO has been
defined is a perfect fit to our requirements, and if people haven't
implemented it there isn't much we can do.

- I don't see much difference either way between "RSVPv2" and "UDP
to the RSVP port" from a complexity perspective. The motivation for
UDP comes mainly from NAT handling issues (maybe this should be
explained a bit more in section 8.2).

> -----Original Message-----
> From: Michael Richardson 
> [mailto:[email-masked]]
> Sent: Monday, February 09, 2004 02:39
> To: [email-masked]
> Subject: [NSIS] review - some security comments on documents
> 
> 
> etc. I was

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 25 Feb 2004 14:50:09 -0000

Hi Michael,

Thanks again for this; the belated reply is caused by a desire
to do some deeper thinking at leisure. Apologies for the long
mail.

I fully agree with the view that security attributes of a 
protocol cannot be divorced from thinking about the way that 
it is actually going to be used. What is less clear to me is 
how this desire translates into working methodology. I've 
tried to explain the "how we got here and how it's justified"
in a bit more detail in-line below. But the top level summary
is that the framework discussion and process (of which the
actual framework document only contains a small proportion)
identified the need for a common protocol with a similar 
degree of application/scenario neutrality to (say) SCTP
(i.e. something much less specific than e.g. Diameter or
SIP), i.e. a "thin" common protocol. 

Given that decision, our next step is to design the real 
NTLP protocol and make sure its security (and other) 
properties are actually well defined (i.e. not just a 
wish-list which might be impossible to fulfil in a real 
design once other requirements are also taken into account). It 
is then up to users of that protocol (the NSLP designers) to do a 
proper evaluation of the overall solution, including how they
use the NTLP, their other assumptions about the network environment,
and what 'internal' security measures they provide.

(If you think this is a bad way to proceed, please check out
the extra background below as well. The crucial point is
whether the amount of background work which was done matches
the thin-ness of the protocol we intend to provide.)

Since this is in many ways a process discussion, one thing that 
would be really helpful would be if you could provide some
pointers to other protocol development activities in the IETF
for similar types of protocol (i.e. - I claim - relatively
application-neutral container protocols) where a 'good' process
has been gone through in advance to pin down the protocol 
security requirements more precisely through use cases and 
so on. That would make it much easier for people like me to 
understand how to address the issue.

Thanks,

Robert H.

> From: Michael Richardson [mailto:[email-masked]]
> Sent: Thursday, February 12, 2004 15:41
> To: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] review - some security comments on documents
> 
> 
> >>>>> "Hancock" == Hancock, Robert <[email-masked]> writes:
>     Hancock> The problem is that the trust/security models 
> IMHO can't be
>     Hancock> fully defined by the NTLP but are signalling application
>     Hancock> specific (and probably in fact also deployment 
> specific). 
> 
>   This is a very serious issue. 
>   It means that it may be really inappropriate to have a 
> common protocol.
> 
>   Yes, other protocols, INCLUDING IPsec suffer from this as well. 
> Yes, this is a problem. 
>   I suggest more real-life use cases be developed and documented. 

I think the point here is that it may be really inappropriate to 
have a 'thick' common protocol, but that it may still be appropriate
to have a 'thin' common protocol. In fact, the common protocol got
progressively thinner during the framework evolution (it started 
out rather like Diameter-base, and it has ended up looking from the
outside as a sort of UDP+++). 

Reminiscing, the thought process we have been through was roughly
as follows:

1. During the framework activity, we did consider a range of
application scenarios, thinking how the signalling would work
in them and what features were common between them. A lot of this
work was done in separate documents about those signalling 
applications, and not formally documented. (Partly, we were
under constant pressure to keep things concise.) The end result
is essentially an educated guess about the right place to put
a split in a layer model, where the reasoning which is behind the
guesswork is given somewhat abstractly and referring to the concrete 
scenario work that was also done.

2. We assumed that it was not a good idea to attempt to be more
specific about exactly what the common protocol should do in the
framework, because there were still a lot of tradeoffs to be made
and feasibility to be established. In other words, to get more
concreteness, it was better to start the protocol design and just
use the framework as guidance.

3. For the security aspects of the common protocol design, we
now have a choice:
a) Describe how the NTLP could be used in a number of examples 
for different applications and what the security implications 
would be, or
b) Design a concrete protocol (currently GIMPS) which basically
matches the framework goals; establish its security properties
more precisely, and then check if it can actually be used.

4. I think we are doing stage (b), but your view is that doing 
this is premature without going through stage (a). My feeling 
is that to do (a) would be essentially to repeat the framework
activities in more detail and with more documentation, but 
probably (if we stick with the assumption of a thin NTLP) with
not much difference in the result. On the other hand, it would
still be a non-authoritative result, since we can only know what
are the security properties of something we have designed, not
something we would like to be able to design.

> 
>     Hancock> I'm fairly certain in my own head, however, that the NTLP needs
>     Hancock> to be flexible (i.e. not constrain) what trust/security models
>     Hancock> can be used.  To draw a comparison, 3436 and 3554 contain
>     Hancock> basically no discussion of such issues; I think the NTLP needs
>     Hancock> to go a bit further, but not very far.
> 
>   Flexible = complex => tends to be insecure.
> 

In general I would agree, but this is why we made the 'thin vs. thick'
tradeoff described above.

To try to be a bit less fluffy, I tried to write down what the
actual properties (especially security properties) of GIMPS are 
in a slightly more formal way. They seem to be:

a) To deliver individual messages referring to flow F from 
   node A to node B and back again.
b) To ensure that nodes A and B really are on the path
   taken by flow F.
c) To ensure that nodes A and B really are nearest 
   neighbours for a given signalling application.
d) To protect the message payloads from on-path attacks by
   non-NSIS nodes.
e) To ensure that signalling applications are only forced to
   process messages from authenticated peers (for the same 
   signalling application), including rejecting messages
   from off-path nodes.

It is not clear to me how much these would modified by more detailed
considerations of trust models for particular use cases (I could
be wildly wrong). (b) is done mainly internally by GIMPS based
on return-routability-types checks. Where more work might be needed
is on (c) and (d), which are basically entirely dependent on on
what cryptographic peer authentication method is to be used (which
also slightly supports the (e) property). The GIMPS requirement 
would I think be for "DoS-resistant mutual authentication, 
generating keying material suitable for protecting signalling
messages".

There are of course many authentication techniques, and many 
different methods for distributing credentials and shared keys
and so on. However, if the overall authentication goal is met
(somehow), how it is met should not have an impact on the 
other security properties or how the protocol is used. My 
instinct is to keep this aspect of the discussion as decoupled
as possible from the rest of the protocol design, but I know
other people disagree with me...

[snip]

>     Hancock> - I don't see much difference either way between "RSVPv2" and
>     Hancock> "UDP to the RSVP port" from a complexity perspective. The
>     Hancock> motivation for UDP comes mainly from NAT handling issues (maybe
>     Hancock> this should be explained a bit more in section 8.2).
> 
>   I don't know about UDP to the RSVP port. I guess that it new to me.

I should have said 'UDP to the RSVPv2 port' but the issues are the same.
I added a bit more in the GIMPS-01 draft to discuss this. Not the biggest
issue at the moment, fortunately ...

> 
> p.s. not on [email-masked].