Subject: Re: [NSIS] ntlp security thoughts

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 14 Jul 2003 12:03:47 +0200

hi henning,

>From: Henning Schulzrinne <[email-masked]>
>To: Hannes Tschofenig <[email-masked]>
>CC: [email-masked]
>Subject: Re: [NSIS] ntlp security thoughts
>Date: Sun, 13 Jul 2003 10:34:53 -0400
>
>Hannes Tschofenig wrote:
>
>
>>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)
>
>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).
>

ok. an unprotected ntlp signaling message would then destroy nslp state 
although you have protection at the nslp layer.

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

sounds good to me. that's a "solution" discussion.

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

that's true. however, this type of protection was in addition to the used 
peer-to-peer protection. hence the dos protection is already there.

in addition you might want to establish symmetric keys based on an initial 
pk-based roundtrip for usage with cms as proposed for diameter.

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.

sounds ok to me.

>
>>
>>what prevents an adversary from flooding an nsis node with bogus (randomly 
>>generated) messages?
>>they cause the nsis node to verify the digital signature.
>
>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.

to prevent dos attacks you commonly add an additional roundtrip. however, 
certain message handling in, for example, rsvp does not allow this 
procedure. you need to tailor your proposal to support this functionality.

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

hopefully it will be protected in the near future. it is, however, difficult 
to make some assumptions here which are based on architectural decisions.
i mentioned that there are some possible interactions with network access 
authentication.

>
>>>small Caribbean Island where the local telco has a cozy relationship with 
>>>the attacker.
>>
>>
>>good idea - sounds like a interesting application :-)
>
>Can one file a business method patent on how to defraud people?
>
...already writing....

ciao
hannes

>Henning
>
>
>
>_______________________________________________
>nsis mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/nsis

_________________________________________________________________
Mit dem MSN Messenger eine Reise für 4 Personen nach Barcelona gewinnen – 
jetzt mitmachen! http://www.sweepstakes2003.com/entry.aspx?locationid=15

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Jul 2003 08:11:22 -0400

> although you have protection at the nslp layer.

The only alternative I can see that NTLP state isn't removed until NSLP 
state is, but this doesn't work for the case of NTLP-only nodes.

> sounds good to me. that's a "solution" discussion.

We need to constrain the problem space - it's big enough as is solving 
"real" problems.

> that's true. however, this type of protection was in addition to the 
> used peer-to-peer protection. hence the dos protection is already there.

Peer-to-peer at NTLP or NSLP layer?

> 
> in addition you might want to establish symmetric keys based on an 
> initial pk-based roundtrip for usage with cms as proposed for diameter.

Yes, for state updates (and teardowns) this makes sense. However, I 
think peer-to-peer node (rather than session) tends to scale better, 
given that many signaling sessions may well be relatively short and the 
initial denial-of-service problem.

> to prevent dos attacks you commonly add an additional roundtrip. 
> however, certain message handling in, for example, rsvp does not allow 
> this procedure. you need to tailor your proposal to support this 
> functionality.

Indeed; this seems to be one of the fundamental trade-offs.