RE: [NSIS] comments on NSIS Security Threats ID

["Hancock, Robert" <[e-mail]>]

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:[e-mail]]
> Sent: Saturday, March 13, 2004 04:35
> To: Tschofenig Hannes; [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis