Re: [NSIS] ntlp security thoughts

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.

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

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

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

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.

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

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.

> 
> - 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
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis