Subject: [NSIS] Security threats

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 27 Feb 2003 09:14:30 +0100

Hello Hannes, 

I appreciate the work you've done with the "Security Threats for NSIS" draft and agree with most of the assumptions and conclusions you draw. However there's one point where I'd like to have some clarification:

Section 1.2, End-to-End Communication
concluding that end to end signaling is hard to secure and therefore not required, peer to peer protection will do. 

First of all, I'm not sure whether this paragraph says that end to end signaling is not required or whether it is just end to end security which is not required. If this paragraphs conclusion is limited to the e2e security, which isn't required, it may be an acceptable conclusion. Could you make that more explicit?

What is important to me is, that end to end signaling is a requirement. It seems acceptable to process e2e signaling messages by all NTLP units along a path. As long as intermediate NSLPs aren't required to process them. As a consequence, NTLP must be able to construct the downstream and upstream signaling path between NI and NR on its own. Otherwise your above assumption on peer to peer protection securing e2e signaling is broken. Do you assume that?

Regards, Rüdiger
 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 27 Feb 2003 14:32:20 +0100

hi ruediger!

thank you for reading the draft and for submitting your comments. 

> 
> Hello Hannes, 
> 
> I appreciate the work you've done with the "Security Threats 
> for NSIS" draft and agree with most of the assumptions and 
> conclusions you draw. However there's one point where I'd 
> like to have some clarification:
> 
> concluding that end to end signaling is hard to secure and 
> therefore not required, peer to peer protection will do. 
> 
> First of all, I'm not sure whether this paragraph says that 
> end to end signaling is not required or whether it is just 
> end to end security which is not required. If this paragraphs 
> conclusion is limited to the e2e security, which isn't 
> required, it may be an acceptable conclusion. Could you make 
> that more explicit?

there are several issues which go with your question:

(the term end-to-end refers to the communication between an NI and an NR. in
many cases the NI and the NR are the two end hosts.)

a) why is pure end-to-end communication an nsis issue?

b) is end-to-end communication relevant for certain objects or for the
entire messages?

c) and finally: how are these objects or messages transmitted (see (1) and
(2) below)? 

end-to-end signaling for (c) can mean two things: 

1) a signaling message is sent between the NI and the NR without addressing
the intermediate nodes (NF) at all. the nsis message simply skips all
intermediate nodes and is processed only by the the end hosts. 

2) a signaling message is sent between the NI and the NR addressing the
intermediate nodes (NFs) in a peer-to-peer session style (regular nsis
message forwarding). 

in the interim meeting i thought that we came to the conclusion that (1) is
a bad thing since the message processing does not seem to make use of the
state established at intermediate nodes. hence a protocol like http, sip,
etc. could also provide the required functionality to ship messages between
two nodes. this issue also refers to point (a) for a more abstract
discussion. if the entire message is transmitted with (1) then for (b) only
the entire message is meant. it might, from a performance point of view,
provide some advantages to add objects which only have a meaning for the end
hosts (b) into the nsis signaling protocol. i, however, guess that this is
not a discussion right now. 

note that the end-to-end issue is particularly relevant if the communication
is between the two end hosts. there are scenarios where nsis is, for
example, used in an intra-domain environement only between the ingress and
the egress. in these cases end-to-end security might not cause major
difficulties for authentication and key exchange for an end-to-end security
association. however, to support such a functionality as part of the main
protocol it would be necessary to address end-to-end security for the more
complex cases. this might turn out to make the protocol more difficult or
complex. 

> 
> What is important to me is, that end to end signaling is a 
> requirement. It seems acceptable to process e2e signaling 
> messages by all NTLP units along a path. As long as 
> intermediate NSLPs aren't required to process them. As a 
> consequence, NTLP must be able to construct the downstream 
> and upstream signaling path between NI and NR on its own. 
> Otherwise your above assumption on peer to peer protection 
> securing e2e signaling is broken. Do you assume that?

there seems to be an additional issue namely the "we skip some NF nodes
along the path". this seems to be an issue of discovery. an example: 

a number of nsis nodes along the path support a ntlp. however, for firewall
signaling only some of them need to be involved in the protocol processing
since the remaining nodes are, for example, qos aware nodes (qos nslps). 

the question is now:  
would we like to skip the qos nodes when we do firewall signaling and
address only those nodes which are able to process the firewall signaling
messages?

my preference: 
we should skip nodes which do not support a particular nslp implementation.
this simplifies security handling, refresh message handling and reliability
handling and provides improvements for message processing. the drawback is
that the discovery procedure needs to include some capability functionality
(i.e. the discovery message says: "i would like to discover the next
firewall along the path.").

conclusion for your draft question:
i can make the issue described in the nsis threats document more complete
once i know what some other people think about it. the issue, as it is
described in the draft today, only raises concerns about the additional
complexity when end-to-end signaling (and also end-to-end security) is added
as a main protocol feature. it might be true that in some scenarios security
is not an issue but for all other scenarios it has to be addressed
(including issues like delegation etc.). 

ciao
hannes

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 27 Feb 2003 15:47:26 +0100

Hi Hannes,

I'm having a less complex scenario in mind and add an 
example below, clarifying what I'd like get. 
Additional remarks in line.

Regards, Rüdiger

Here you mean NSLP, I guess.
H|a number of nsis nodes along the path support a ntlp. 
| however, for firewall signaling only some of them
| need to be involved in the protocol processing
| since the remaining nodes are, for example, qos aware nodes 
| (qos nslps). 
| 
| the question is now:  
| would we like to skip the qos nodes when we do firewall
| signaling and address only those nodes which are able
| to process the firewall signaling messages?
|
| my preference: 
| we should skip nodes which do not support a particular nslp 
| implementation.

If I remember right, we agreed on the Interim that NTLP
is processing all NTLP messages regardless of local NSLP
support.

H|this simplifies security handling, refresh message handling 
| and reliability handling and provides improvements for
| message processing. the drawback is that the discovery
| procedure needs to include some capability functionality
| (i.e. the discovery message says: "i would like to discover
| the next firewall along the path.").

I'm not sure whether that holds. A domain gateway router 
may support QoS-NSLP but no firewall-NSLP. The carrier 
may be interested in keeping unauthenticated signaling 
messages out of his domain in general. That isn't 
possible with your proposal (unless the gateway supports 
all NSLPs - which I don't feel to be useful).
 
Finally, my example. Lets assume a customer network with two
sites, making a QoS reservation to be used for VoIP calls 
accross a carrier network. To limit his backbone signaling 
processing requirements the carrier may prefer to stay out 
of per VoIP call signaling. So aggregation is applied between 
his edge nodes. Let's ignore how that is done with regard to 
QoS. With regard to signaling it means that the carrier 
routers only maintain state for a single reservation between 
the two customer sites. Per VoIP call NSIS state maintenance 
is restricted to the customer domain. Still, all related NSIS 
signaling messages traverse the carrier network. Path coupled, 
meaning NSIS path coupled (i.e. downstream and especially 
upstream). If only hop by hop security is available, the 
carriers NTLP still must process all per VoIP call signaling 
messages. Correct?