Subject: RE: [NSIS] Security Threats for NSIS : Attacks against the Transp ort Mechani sm

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

i like the new text. some minor points in line:

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]]
> Sent: Thursday, April 15, 2004 14:45
> To: [email-masked]'
> Subject: [NSIS] Security Threats for NSIS : Attacks against the
> Transport Mechani sm
> 
> 
> hi all, 
> 
> a comment regarding section 4.11:
> 
> > 4.11 Attacks against the Transport Mechanism 
> >     
> > I think we can now refer to the split layer architecture as a 
> > decision within the group (after all, it's in the charter) and is
> > as defined in the framework.
> 
> > A reference to RFC2385 might be helpful background.
> 
> regarding the reference RFC2385 ( Protection of BGP Sessions 
> via the TCP MD5
> Signature Option). i guess we should not introduce new 
> pointers to certain
> solutions. rfc2385 is one particular solution approach.

again, i think it is interesting because of the threat description
that it contains (rather than the particular solution it describes).

> 
> regarding the overall comment i have changed the text from:
[snip]
> to 
> 
> "
> 
> 4.11 Attacks against the NTLP
> 
> In [BL01] a two-level architecture is proposed, which 
> suggests splitting an
> NSIS protocol into layers: a signaling message 
> transport-specific layer and
> an application-specific layer. More details can be found in the NSIS
> framework [HF+03]. Most of the threats described in this document are
> applicable to the NSLP application-specific part (e.g., QoS 
> NSLP). There
> are, however, some threats that are applicable to the NTLP. 
> 
> Network and transport layer protocols lacking protection 
> mechanisms are
> vulnerable to certain attacks such as header manipulation, 
> DoS, spoofing of
> identities, session hijacking, unexpected aborts, etc. 
> Malicious nodes can
> attack the congestion control mechanism to force NSIS nodes into a
> congestion avoidance state.
> 
> Threats which address parts of the NTLP which are not related 
> to attacks
> against the usage transport layer protocols are covered in 
              ^^^^^
              use of (?)
> various sections
> throughout this document, such as in Section 4.2. 
> 
> In the case in which existing transport layer protocols are used for
> exchanging NSIS signaling messages, security vulnerabilities 
> know to these
  ^^^^^^^
  known for?
> protocols need to be considered. A detailed threat 
> description of these
> protocols is outside the scope of this document. 
> " 
> 
> do you think that this is more appropriate?
> 
> 
> 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:16 +0200

hi robert, 

fixed the text. i will think about including a reference to RFC 2385 (or
something similar).

has someone else an opinion on this issue?

ciao
hannes

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Donnerstag, 15. April 2004 17:39
> To: Tschofenig Hannes; [email-masked]'
> Subject: RE: [NSIS] Security Threats for NSIS : Attacks 
> against the Transp ort Mechani sm
> 
> > > decision within the group (after all, it's in the 
> charter) and is as 
> > > defined in the framework.
> > 
> > regarding the reference RFC2385 ( Protection of BGP 
> Sessions via the 
> > TCP MD5 Signature Option). i guess we should not introduce new 
> > pointers to certain solutions. rfc2385 is one particular solution 
> > approach.
> 
> again, i think it is interesting because of the threat 
> description that it contains (rather than the particular 
> solution it describes).
> 
> > 
> > In [BL01] a two-level architecture is proposed, which suggests 
> > splitting an NSIS protocol into layers: a signaling message 
> > transport-specific layer and an application-specific layer. More 
> > details can be found in the NSIS framework [HF+03]. Most of the 
> > threats described in this document are applicable to the NSLP 
> > application-specific part (e.g., QoS NSLP). There are, 
> however, some 
> > threats that are applicable to the NTLP.
> > 
> > Network and transport layer protocols lacking protection mechanisms 
> > are vulnerable to certain attacks such as header manipulation, DoS, 
> > spoofing of identities, session hijacking, unexpected aborts, etc.
> > Malicious nodes can
> > Threats which address parts of the NTLP which are not related to 
> > attacks against the usage transport layer protocols are covered in
>               ^^^^^
>               use of (?)
> > various sections
> > exchanging NSIS signaling messages, security 
> vulnerabilities know to 
> > these
>   ^^^^^^^
>   known for?
> > protocols need to be considered. A detailed threat description of 
> > these protocols is outside the scope of this document.
> > " 
> > 
> -- 
> 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.
>