AW: [NSIS] comments on NSIS Security Threats ID

[Kappler Cornelia <[e-mail]>]

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:[e-mail]] 
> Gesendet: Samstag, 13. März 2004 17:14
> An: 'Kappler Cornelia'; Tschofenig Hannes; [e-mail]
> Betreff: RE: [NSIS] comments on NSIS Security Threats ID
> 
> 
> 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...)
> 
> -- 
> 
> 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.
> 

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