[NSIS] ntlp security thoughts

["Hannes Tschofenig" <[e-mail]>]

hi all,

i have compiled some thoughts on ntlp security. please see below:

ciao
hannes

----------------------------------------------------------

NTLP Security Considerations
============================

1. Introduction

Based on the discussions at the IETF #56 NSIS working group meeting two new 
NTLP proposals have been submitted (see [1] and [2]).

The architectural two-layer split into an NTLP (a generic transport 
mechanism) and an NSLP part (the NSLP part contains the application specific 
signaling payloads). Although this layer split (with regard to security) was 
already introduced with policy-aware and policy-ignorant nodes in RSVP, the 
question was raised what type of security should be enforced at which layer.

There is conconsus that

- at least some authorization decisions should be handled specific for 
certain applications.

- non peer-to-peer security must be handled at the application layer

Some members, however, believe that security protection for the signaling 
messages at the NTLP layer is not necessary.

It should be noted that the introduction of the two-layer split might cause 
that signaling messages traversing n NTLP nodes whereby only m of these 
nodes (possibly with m<<n) support the required NSLP functionality required.

Goal of this document is to describe some threats against the NTLP protocol. 
The reader should by itself decide whether these threats require 
countermeasures.

Some architectural questions might also influence the decisions - these 
architectural decisions are, however, not described in this document (TBD: 
future version).

2. Protocol Vulnerabilities

Analysing the protocol proposal [1] and [2] the following protocol 
vulnerabilities are apparent:

- Force NTLP node todo more processing

Some protocol fields (such as epoch or MESSAGE_ID in [1]) allow an adversary 
to force an NTLP node todo more processing. Additionally it might be able to 
interfear with the conguestion control procedure.

Furthermore it might be possible to force other entities to cause some 
additional actions or signaling message exchanges.

- Flooding

An adversary might benefit from flooding an NTLP node with messages which 
must be stored (e.g. due to fragmentation handling) before detecting the 
correctness of signaling messages.

It was also noticed that a large number of small NTLP messages might require 
a large amount of CPU processing since the processing of Router Alert 
messages is highly inefficient (additional CPU processing due to the context 
switching).

- Terminate signaling

Unprotected error messages allow an adversary to delete NTLP state (and 
possibly NSLP state) when returned unprotected.

- Combined discovery and signaling message delivery

Combining discovery together with signaling message delivery prevents usage 
of security mechanisms (even at the NSLP layer). Furthermore it does not 
allow summary refreshes to be used in the expected way since the summary 
refresh assumes knowledge about the recepient.

- Create NTLP state

An RSVP path-alike message allows an adversary to create NTLP state at a 
number of NSIS nodes along the path. This might be seen as an amplification 
attack.

- Modification to the HOP address

When an RSVP path-alike signaling message is intercepted by an NTLP node the 
HOP address is stored in the NTLP state table. This allows an adversary to 
change routing of NTLP (and therefore NSLP messages). This might either lead 
to messages routed to unreachable IP addresses or to other NSIS nodes or to 
the adversary itself.

- Modification of the refresh period

An adversary changing the refresh period is able to control the rate at 
which refresh messages are expected. Together with bogus state creation 
messages this might allow an adversary to store state much longer resulting 
in a more effective DoS attack.

Reducing the refresh interval causes NTLP nodes to expect refresh messages 
at a higher rate. This might cause state timeouts due to the absence of 
refresh messages.

- Teardown NTLP state

The NTLP protocol defines different operations on the NTLP state. One of 
this operation allows to delete NTLP state information. An adversary can 
issue a teardown message in both direction. A RSVP path-alike teardown 
message might restrict the location of the adversary whereas the RSVP 
resv-alike teardown message can be initiated from any location to any NTLP 
node along the path.

The implications of deleted NTLP has implications for NSLPs (e.g. reverse 
routing is not possible if reverse routing information is not present).

- Session Ownership

Including the session identifier into the NTLP might be exploited by an 
adversary as described in [3].

- Flow ID modification

It was mentioned that the inclusion of the flow identifier in the NTLP 
allows NAT aware NTLPs to perform address translation independent of the 
NSLP. It needs to be verified whether the inclusion of the flow identifier 
for the purpose of network address translation helps in all cases. As an 
other alternative it is necessary to enable NATs to understand all NSLP 
protocols.

In any case if a flow identifier is included in the NTLP (unprotected) then 
an adversary is able to modify the flow identifier to e.g. make QoS 
reservations inefficient, exploit if for other purposes (e.g. theft of 
service), for DoS attacks etc. The same implications can be considered in 
case of NAT/firewall signaling.

3. Summary


As a summary it is possible to add, modify and delete any state information 
available. This might cause NSLP signaling to become ineffective or to 
abort. Various denial of service attacks are possible.

4. References

[1]  M. Shore: "The NSIS Transport Layer Protocol (NTLP)", 
<draft-shore-ntlp-00.txt>, (work in progress), May 2003.

[2] H. Schulzrinne: "GIMPS: General Internet Messaging Protocol for 
Signaling" <draft-schulzrinne-nsis-ntlp-00.txt>, (work in progress), June 
2003.

[3] H. Tschofenig, et al.: "Security Implications of the Session 
Identifier", <draft-tschofenig-nsis-sid-00.txt>, (work in progress), May 
2003.

_________________________________________________________________
MSN Hotmail  -  Absolut kostenfrei! Der weltweit größte E-Mail-Anbieter im 
Netz:  http://www.msn.de/hotmail


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