Subject: [NSIS] comments on NSIS Security Threats ID

From: Kappler Cornelia <[email-masked]>
Date: Fri, 12 Mar 2004 20:35:26 +0100

Hi Hannes, 

my comments mostly relate to the structure of Sec 4 (along similar lines as Robert was suggesting), and to problems I have understanding identity spoofing of flow identifieres. See below. 

Cornelia
----------------------

*4. NSIS Specific Threat Scenarios

This Section describes "threat scenarios in terms of attacks on and security deficiencies in the NSIS signaling protocol". I find it hard sometimes in subsequent subsections to pick out what the attack is, and (particularly) what the security deficiencies allowing the attack are. May be you could add sentences clearly stating this, rather than mentioning it in passing. 

In addition to Theats and Security Deficiencies may be you should add (in a structured fashion) what possible remedies are. In most subsections this is mentioned but not everywhere. Also I think the fact that you also discuss remedies should be mentioned in the intro to Sec 4.

Subsection headings sometimes contain possible security deficiencies ("Combined Signaling and SA Establishment") and sometimes threats ("Eavesdropping and Traffic Analysis"). Could you streamline this (i.e. either one or the other)

* 4.2 "Combined Signaling and SA Establishment"

It took me some time to understand the problem. To my current understanding it is the assumption that one doesnt want to introduce extra roundtrip times to establish SAs. I.e. somehow the SA needs to be established as soon as an NSIS message arrives from an unknown NE, without further interaction wiht this NE. But is this assumption valid? Do we expect the number of possible peer-NEs is so large that the costs for an additional roundtrip to establish the SA is too big?

I dont understand the sentence "For this to work, specific classes of cryptographic mechanisms supporting this type of behaviour are needed". What is "this to work"? Do you mean (previous sentence) "allow refresh messages to create new state along a new path" to work _in a secure way_? Furthermore  what specifically is "this type of behaviour"? In the text above no "behaviour" was described.

* 4.3 "Eavesdropping and Traffic Analysis"

I cant find what the security deficiencies are that allow this kind of threat. It only says integrity protection does NOT help against it. But why would anybody think it does??? Adding a kind of secured checksum (that is what integrity protection does, doesnt it?) of course doesnt help.

The 3rd paragraph introduces exploitation of the spoofing of flow identifiers. The remaining paragraphs of 4.3 all seem to discuss this problem in more detail. It took me some time to realize this, may be you could add an explaining sentence.

2nd last paragraph of 4.3: "The ability...to inject data atraffic..requires the ability to also receive the data traffic. This is, however, true only if the flow identifier consists of a value that contains addresses used for routing." Doesnt seem to make sense. I can picture various scenarios where I am able to receive data traffic not really destined to me, independent of the structure of the flow identifier...!?

The same paragraph continues: "If ... using...a flow identifier that do not require such a property (CK: i.e. addresses used for routing I assume?? Or ability to receive data traffic? But this I think is independent of the structure of the flow identifier) then ...injecting traffic are much easier." Doesnt make sense to me either (I may just have problems catching on...)

The final paragraph contains the DiffServ example but I dont see how it relates to the rest. Where is the spoofed flow identifier in the example? May be you could be more explicit...

* 4.6 Missing Non-Repudiation
last paragraph "because it public-key" -> "because public-key"

* 4.8 Denial of Service Attacks
In the "path-finding" scenario, what is a possible remedy?

---

From: "Hancock, Robert" <[email-masked]>
Date: Sat, 13 Mar 2004 16:13:52 -0000

hi,

a comment on cornelia's comment (which in her email is
targeted at 4.3 but which i think is actually about 4.4):

> -----Original Message-----
> From: Kappler Cornelia [mailto:[email-masked]]
> Sent: Saturday, March 13, 2004 04:35
> To: Tschofenig Hannes; [email-masked]
> Subject: [NSIS] comments on NSIS Security Threats ID
> 
> 
> Hi Hannes, 
> my comments mostly relate to the structure of Sec 4 (along 
> similar lines as Robert was suggesting), and to problems I 
> have understanding identity spoofing of flow identifieres. See below. 
[snip]

> The 3rd paragraph introduces exploitation of the spoofing of 
> flow identifiers. The remaining paragraphs of 4.3 all seem to 
> discuss this problem in more detail. It took me some time to 
> realize this, may be you could add an explaining sentence.
> 2nd last paragraph of 4.3: "The ability...to inject data 
> atraffic..requires the ability to also receive the data 
> traffic. This is, however, true only if the flow identifier 
> consists of a value that contains addresses used for 
> routing." 

the real point is more subtle. compared to the original
"The ability for an adversary to inject data traffic that matches a 
   certain flow identifier established by a legitimate user often 
   requires the ability also to receive the data traffic. "

one might emphasise 
"The ability for an adversary to inject data traffic that matches a 
   certain flow identifier established by a legitimate user 
and to get some benefit from injecting that traffic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
often 
   requires the ability also to receive the data traffic. 
or to have one's correspondent receive it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"

> Doesnt seem to make sense. I can picture various 
> scenarios where I am able to receive data traffic not really 
> destined to me, independent of the structure of the flow 
> identifier...!?

you can always try to receive on-link traffic for one of
your neighbours, but that is not really the issue. the
point is:
a) a 'reservation' has an associated filter specification
b) it also has an intended beneficiary
c) all traffic that matches (a) will get the benefit, but
d) that traffic may not be associated with the beneficiary (b)

now, it is possible to write filter specifications which are
similarly fine-grained, but which are very different in the 
possibilities they allow other users to generate traffic which
is useful to them but not what the original user intended. 
hence the threat.

apart from per-packet cryptographic authentication at each
router, it's difficult to counter this type of threat. the
approach being discussed here is to say that if you specify
traffic some ways, the forwarding system itself (i.e. the most 
fundamental part of the network layer) will provide some
protection. the arguments are similar to what was done for
mip6 (see draft-nikander-mobileip-v6-ro-sec-02).

some examples may be needed.

*) reserve class X for traffic with SPI=fred
==> anyone can set SPI=fred in their own packets and get
class X for them.

*) reserve class X for traffic with proto/port=TCP/80 and
source=myself
==> all my outgoing web traffic will get class X; but so
will that from anyone else who spoofs my source address.
(it's hard but not impossible for the spoofer to benefit 
from this.) if applied, ingress filtering on the traffic
will make it harder.

*) reserve class X for traffic with proto/port=TCP/80 and
destination=myself
==> all my incoming traffic will get class X; if we assume
destination address spoofing is impossible, we are just 
about done.

[all these examples are slightly artificial, since the NTLP
would have difficulty in routing messages about such vaguely
specified flows, but they make the general point.]

some master wordsmithing may be required.

r.

> The same paragraph continues: "If ... using...a flow 
> identifier that do not require such a property (CK: i.e. 
> addresses used for routing I assume?? Or ability to receive 
> data traffic? But this I think is independent of the 
> structure of the flow identifier) then ...injecting traffic 
> are much easier." Doesnt make sense to me either (I may just 
> have problems catching on...)

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

---

From: Kappler Cornelia <[email-masked]>
Date: Tue, 16 Mar 2004 12:02:32 +0100

Hi Robert, 

thanks for the enlightening clarification. I understand the threat and the possible solution path now, however the current text IMHO just does not at all explain it. It is just too short. 

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Hancock, Robert [mailto:[email-masked]] 
> Gesendet: Samstag, 13. März 2004 17:14
> An: 'Kappler Cornelia'; Tschofenig Hannes; [email-masked]
> Betreff: RE: [NSIS] comments on NSIS Security Threats ID
> 
> 
> hi,
> 
> -- 
> Visit our website at www.roke.co.uk
> 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>