Subject: RE: [NSIS] Security Threats for NSIS : Combining Signaling and SA Establishm ent

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Apr 2004 16:33:18 +0100

i think the new text is much better.

teeny comments:

the paragraph at the start:

> - Processing of Router Alert Options 
> 
> The processing of Router Alert Option requires a router to do some
> additional processing by receiving packets with IP options, 
> which might lead
> to additional delay for legitimate requests, or even to 
> reject of them. A
        ^
[nit] insert "some"?

> router being flooded with a large number of bogus messages requires
> resources (e.g., CPU processing due to the context switching) 

i would remove the () part

> before finding
> out that these messages have to be dropped. 

and then add something like "If the protocol is based on using 
interception for message delivery this threat cannot be completely
eliminated, but the protocol design should attempt to limit the
processing that has to be done on the RAO-bearing packet so it
is at most comparable to that for an arbitrary packet addressed
directly to one of the router interfaces." (or something.)

[The point I think was not so much that the interception, whether
done by RAO insertion or any other method like protocol filtering, 
was expensive, but more that it provided a mechanism to allow
arbitrary people to get the router to process the rest of the message
as well. At least, that is the impression I got from the discussion
during the meeting. To some extent this is also covered in your NTLP 
paragraph, the specific point here is the "require routers to process
intercepted messages" aspect.]

i would keep this separate from the DoS section (both are long enough).

r.

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]]
> Sent: Thursday, April 15, 2004 14:45
> To: [email-masked]'
> Subject: [NSIS] Security Threats for NSIS : Combining Signaling and SA
> Establishm ent
> 
> 
> hi all, 
> 
> a comment with regard to section 4.2:
> 
> > 4. NSIS-Specific Threat Scenarios 
> 
> > 4.2 Combining Signaling and SA Establishment 
> >     
> >    When a signaling message arrives at an NSIS-aware 
> network element,
> ...
> >    protection are described in [AN97] and in [ALN00]. 
> 
> > I found this paragraph quite hard to follow (even though I think
> > I know what you are trying to say). Part of the problem is that
> > you are talking about the *threat* of flooding but the section
> > title is referring to imperfections in a particular class of 
> > solution. 
> 
> > There is room for a more structured analysis of the flooding problem
> > (especially in the light of concerns about RAO handling expressed on
> > Monday). Flooding needs a layered defence and protection happens at
> > several levels.
> 
> 
> based on the received comment i have changed the original text from:
> 
> "
> 4.2 Combining Signaling and SA Establishment 
>     
>    This scenario describes attacks that allow an adversary to 
> flood an 
>    NSIS node with bogus signaling messages to cause a denial 
> of service 
>    attack.  
>     
>    When a signaling message arrives at an NSIS-aware network element, 
>    certain processing is required. If this message contains security 
>    objects such as digital signatures, and no security association is 
>    already available, then some additional processing is required for 
>    the cryptographic verification. Because NSIS signaling should not 
>    require extra roundtrips between two NSIS peers, it is 
> difficult to 
>    provide the DoS protection mechanisms commonly found in 
>    authentication and key agreement protocols. Signaling messages can 
>    be idempotent, which means that they contain the same amount of 
>    information as the original message. An example would be a refresh 
>    message that is equivalent to a create message. This 
> property allows 
>    a refresh message to create new state along a new path, 
> although no 
>    previous state is available. For this to work, specific classes of 
>    cryptographic mechanisms supporting this behavior are needed. An 
>    example is a scheme based on digital signatures, which, however, 
>    should be used with care due to possible denial of service 
> attacks. 
>    Problems with using these types of exchanges with public key based 
>    protection are described in [AN97] and in [ALN00]. 
>     
>    In addition to the threat scenario described above, an incoming 
>    signaling message might require time consuming processing 
>    (computations, state maintenance, timer setting, etc.) and 
>    communication with third-party nodes such as policy servers, LDAP 
>    servers, etc. If an adversary is able to transmit a large 
> number of 
>    signaling messages (for example, with QoS reservation 
> requests) with 
>    invalid credentials, then the verifying node may not be able to 
>    process other reservation messages from legitimate users.  
>     
>    Further attacks may be enabled by injecting error messages or 
>    forcing the creation of error messages to extract additional 
>    information.  
> 
> 
> " 
> 
> to: 
> 
> "
> 4.2 Flooding
> 
> This section describes attacks that allow an adversary to 
> flood an NSIS node
> with bogus signaling messages to cause a denial of service attack. 
> 
> We will discuss this threat a different layers in the NSIS 
> protocol suite: 
> 
> - Processing of Router Alert Options 
> 
> The processing of Router Alert Option requires a router to do some
> additional processing by receiving packets with IP options, 
> which might lead
> to additional delay for legitimate requests, or even to 
> reject of them. A
> router being flooded with a large number of bogus messages requires
> resources (e.g., CPU processing due to the context switching) 
> before finding
> out that these messages have to be dropped. 
> 
> - Force NTLP to-do more processing
> 
> Some protocol fields might allow an adversary to force an NTLP node to
> execute more processing. Additionally it might be possible to 
> interfere with
> the flow control or congestion control procedure. 
> 
> Certain attacks can be mounted against transport layer 
> protocols by flooding
> a node with bogus requests or even to finish the handshake phase to
> establish a transport layer association. These types of 
> threats are also
> addressed in Section 4.11. 
> 
> Furthermore, it might be possible to force the NTLP node to 
> perform some
> computations or signaling message exchanges by injecting 
> "trigger" events
> (which are unprotected).
> 
> - Force NSLP to-do more processing
> 
> An adversary might benefit from flooding an NSLP node with 
> messages which
> must be stored (e.g., due to fragmentation handling) before 
> verifying the
> correctness of signaling messages. 
> 
> Furthermore, causing memory allocation and computational 
> efforts might allow
> an adversary to do harm to NSIS entities. If a signaling 
> message contains,
> for example, a digital signature then some additional 
> processing is required
> for the cryptographic verification. An adversary can easily 
> create a random
> bit sequence instead of a digital signature to force an NSIS 
> node into heavy
> computation. 
> 
> Idempotent signaling messages are particularly vulnerable 
> against this type
> of attack. Idempotent refers to messages which contain the 
> same amount of
> information as the original message. An example would be a 
> refresh message
> that is equivalent to a create message. This property allows a refresh
> message to create new state along a new path, although no 
> previous state is
> available. For this to work, specific classes of 
> cryptographic mechanisms
> supporting this behavior are needed. An example is a scheme 
> based on digital
> signatures, which, however, should be used with care due to 
> possible denial
> of service attacks. 
> 
> Problems with the usage of public key based cryptosystems in 
> protocols are
> described in [AN97] and in [ALN00].
> 
> In addition to the threat scenario described above, an 
> incoming signaling
> message might trigger communication with third-party nodes 
> such as policy
> servers, LDAP servers or AAA servers. If an adversary is able 
> to transmit a
> large number of signaling messages (for example, with QoS reservation
> requests) with invalid credentials, then the verifying node 
> may not be able
> to process other reservation messages from legitimate users. 
> 
> "
> 
> 
> do you think that this text is more useful now? 
> should i move this section to the denial of service section? 
> 
> 
> ciao
> hannes
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 17 Apr 2004 14:33:29 +0200

hi robert, 

i also got the impression during the last ietf meeting that people worry
about the fact that an arbitrary person can cause a router todo some
processing. 

i have fixed the typos and added the other sentence. 

ciao
hannes

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Donnerstag, 15. April 2004 17:33
> To: Tschofenig Hannes; [email-masked]'
> Subject: RE: [NSIS] Security Threats for NSIS : Combining 
> Signaling and SA Establishm ent
> 
> > additional processing by receiving packets with IP options, which 
> > might lead to additional delay for legitimate requests, or even to 
> > reject of them. A
>         ^
> [nit] insert "some"?
> 
> and then add something like "If the protocol is based on 
> using interception for message delivery this threat cannot be 
> completely eliminated, but the protocol design should attempt 
> to limit the processing that has to be done on the 
> RAO-bearing packet so it is at most comparable to that for an 
> arbitrary packet addressed directly to one of the router 
> interfaces." (or something.)
> 
> [The point I think was not so much that the interception, 
> whether done by RAO insertion or any other method like 
> protocol filtering, was expensive, but more that it provided 
> a mechanism to allow arbitrary people to get the router to 
> process the rest of the message as well. At least, that is 
> the impression I got from the discussion during the meeting. 
> To some extent this is also covered in your NTLP paragraph, 
> the specific point here is the "require routers to process 
> > > I found this paragraph quite hard to follow (even though 
> I think I 
> > > know what you are trying to say). Part of the problem is that you 
> > > are talking about the *threat* of flooding but the 
> section title is 
> > > referring to imperfections in a particular class of solution.
> > 
> >    This scenario describes attacks that allow an adversary 
> to flood an
> >    NSIS node with bogus signaling messages to cause a denial of 
> > service
> >    attack.  
> >     
> >    message that is equivalent to a create message. This property 
> > allows
> >    should be used with care due to possible denial of 
> service attacks.
> >    servers, etc. If an adversary is able to transmit a 
> large number of
> > This section describes attacks that allow an adversary to flood an 
> > We will discuss this threat a different layers in the NSIS protocol 
> > suite:
> > 
> > additional processing by receiving packets with IP options, which 
> > might lead to additional delay for legitimate requests, or even to 
> > reject of them. A router being flooded with a large number of bogus 
> > messages requires resources (e.g., CPU processing due to 
> the context 
> > switching) before finding out that these messages have to 
> be dropped.
> > 
> > interfere with the flow control or congestion control procedure.
> > 
> > Certain attacks can be mounted against transport layer protocols by 
> > flooding a node with bogus requests or even to finish the handshake 
> > phase to establish a transport layer association. These types of 
> > threats are also addressed in Section 4.11.
> > 
> > Furthermore, it might be possible to force the NTLP node to perform 
> > some computations or signaling message exchanges by injecting 
> > "trigger" events (which are unprotected).
> > 
> > An adversary might benefit from flooding an NSLP node with messages 
> > which must be stored (e.g., due to fragmentation handling) before 
> > verifying the correctness of signaling messages.
> > 
> efforts might 
> > allow an adversary to do harm to NSIS entities. If a 
> signaling message 
> > contains, for example, a digital signature then some additional 
> > processing is required for the cryptographic verification. An 
> > adversary can easily create a random bit sequence instead 
> of a digital 
> > signature to force an NSIS node into heavy computation.
> > 
> against this 
> > type of attack. Idempotent refers to messages which contain 
> the same 
> > amount of information as the original message. An example 
> would be a 
> > refresh message that is equivalent to a create message. 
> This property 
> > allows a refresh message to create new state along a new path, 
> > although no previous state is available. For this to work, specific 
> > classes of cryptographic mechanisms supporting this behavior are 
> > needed. An example is a scheme based on digital signatures, which, 
> > however, should be used with care due to possible denial of service 
> > attacks.
> > 
> > Problems with the usage of public key based cryptosystems 
> in protocols 
> > are described in [AN97] and in [ALN00].
> > 
> > signaling message might trigger communication with 
> third-party nodes 
> > such as policy servers, LDAP servers or AAA servers. If an 
> adversary 
> > is able to transmit a large number of signaling messages 
> (for example, 
> > with QoS reservation
> may not be 
> > able to process other reservation messages from legitimate users.
> > 
> > "
> > 
> > 
> -- 
> 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.
>