Subject: Re: [NSIS] ntlp security thoughts

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 13 Jul 2003 16:18:11 +0200

hi henning,

thanks for your quick response.

please find my comments inline:

>From: Henning Schulzrinne <[email-masked]>
>To: Hannes Tschofenig <[email-masked]>
>CC: [email-masked]
>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/nsis
>
>
>
>_______________________________________________
>nsis mailing list
>[email-masked]
>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

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

> (e.g. would you delete nslp state if you receive an ntlp "teardown" 

I can't see how you can have free-floating NSLP state. This may be 
proposal-specific, but my assumption was that NTLP state is necessary 
for NSLP state. I can't see any disadvantages of this approach, but 
others will likely differ (but I would appreciate concrete benefits of 
allowing this, as it makes a lot of things far more complicated, in my 
view).

> e.g. is flooding (dos) more serious than transmitting a bogus terminate 

I would only suggest classifying this on a per-attack basis, not 
generically.

> i can, however, try it.

Clearly, in some cases the answer is going to be "it depends".

> possible solution: do not support such a message (use soft-state timeout 

This is not a viable option, I'm afraid. If we can't agree on that 
within the working group, we have far bigger problems than worrying 
about DOS attacks, since there won't be any service to deny.

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

Unless this has changed, I thought there was some agreement that we will 
need CMS-style PK at NSLP layer since none of the other solutions scale 
cross-domain. Is there another proposal, leaving optimizations for 
specific scenarios aside? I don't think we can make progress if we don't 
admit to certain realities, even if we disagree how often they are 
needed. Maybe we need to hum on such a list such as:

- some applications will need PK crypto at NSLP layer
- some applications will need reliable message delivery
- some messages are going to exceed 500 bytes
etc.

> 
> what prevents an adversary from flooding an nsis node with bogus 
> (randomly generated) messages?

Nothing. But that's where, say, return-routability allows me to throttle 
a particular host (attacker) and limit the ability of one attacker to 
cause damage. You just stick each peer into its own queue and serve them 
round-robin. That way, an attacker has to compromise lots of hosts to be 
effective.

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

Yes, about 5 KB, at minimum, to be precise. Such is life :-)

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

You are assuming that the wireless link is unprotected. One would hope 
that this is a temporary condition that only afflicts certain current 
implementations. I believe that 3G networks, for example, don't suffer 
from this problem.

>> small Caribbean Island where the local telco has a cozy relationship 
>> with the attacker.
> 
> 

Can one file a business method patent on how to defraud people?

Henning