Re: [NSIS] ntlp security thoughts

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

hi henning,

thanks for your quick response.

please find my comments inline:

>From: Henning Schulzrinne <[e-mail]>
>To: Hannes Tschofenig <[e-mail]>
>CC: [e-mail]
>Subject: Re: [NSIS] ntlp security thoughts
>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.

that's certainly true although it is not simple for the following reasons:
a) i would need more information on the ntlp behavior with regard to the 
nslp.
(e.g. would you delete nslp state if you receive an ntlp "teardown" message)
b) it might depend on certain nslps (and on the security of them)
c) i would have to rate how harmful certain attacks are
e.g. is flooding (dos) more serious than transmitting a bogus terminate 
signaling message?

i thought about it for the "security threats for nsis" draft. unfortunately 
it is not as easy as it sounds.

i can, however, try it.

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

certainly. there are some non-crypto mechanisms that prevent certain 
attacks. i haven't listed possible countermeasures

e.g. deleting state information based on a bogus "teardown" message is 
problematic.
possible solution: do not support such a message (use soft-state timeout 
only)

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

true - separating adversaries into off-path an on-path makes sense.
i will add some text.

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

that is certainly possible but the usage of public key cryptography creates 
dos attack vulnerabilities.

what prevents an adversary from flooding an nsis node with bogus (randomly 
generated) messages?
they cause the nsis node to verify the digital signature.

additionally messages get large (certificates, digital signature etc.).

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

yes. i will add it.

>Here, return routability can help some since one can then limit the number 
>of states that each previous hop can establish.
>
return routability can help to limit some problems. unfortunately not 
entirely.

a mobile node at the wireless link can create messages (and he would see the 
response). the return-routability makes it more difficult to mount the 
attacks (since the adversary has to wait for the response) but does not 
prevent it.

for an offpath adversary return routability certainly helps.

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

good idea - sounds like a interesting application :-)

>
>
>>
>>- 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
>
>
>
>_______________________________________________
>nsis mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/nsis

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


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