Subject: [NSIS] ntlp security thoughts

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 13 Jul 2003 14:47:51 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 13 Jul 2003 09:32:10 -0400

Hannes Tschofenig wrote:

Comments in-line.

> 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.

It might be helpful to divide these into threats that are particularly 
serious with non-NSLP-aware nodes and others that affect all nodes equally.

Also, some of these attacks can effectively be prevented or limited by 
forcing a return-routability test, without a full crypto mechanism. I 
think it would be helpful to highlight those.

Finally, it would be helpful to classify the attacks by whether they can 
be perpetrated by a remote third party (without ability to listen) or 
whether they need the attacker to be able to intercept the messages. 
Some consider the ability of backbone snooping sufficiently unlikely 
that those risks may not warrant mitigation.

> Combining discovery together with signaling message delivery prevents 
> usage of security mechanisms (even at the NSLP layer). Furthermore it 

Depends. If NSLP messages are individually integrity-protected with the 
sender's private key, this may not be the case.

> number of NSIS nodes along the path. This might be seen as an 
> amplification attack.

Or an adversary might just do a state-exhaustion attack by creating NTLP 
state. Here, return routability can help some since one can then limit 
the number of states that each previous hop can establish.

> 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.

Assuming that NSLP services, such as QoS, cost money, I can then route 
the message to particularly expensive nodes, even though the data 
doesn't go there. A local reservation in Vienna can take a slight detour 
via New York, picking up reservation charges along the way. This is 
particularly helpful if one of the nodes can be located in a small 
Caribbean Island where the local telco has a cozy relationship with the 
attacker.

> 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
> 
> 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
> 
> 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 
> 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
> 
> Signaling" <draft-schulzrinne-nsis-ntlp-00.txt>, (work in progress), 
> June 2003.
> 
> MSN Hotmail  -  Absolut kostenfrei! Der weltweit größte E-Mail-Anbieter 
> im Netz:  http://www.msn.de/hotmail
> 
>