[NSIS] Security Threats for NSIS : Relevant Communications Models

[Tschofenig Hannes <[e-mail]>]

hi all, 

i got a number of comments with regard to section 2 (Relevant Communications
Models). fixing this section is a bit more complex than specific security
threats:

i went through some ietf drafts which consider security threats, trust
models and related issues. after this list you will find my conclusion. here
is a brief overview:

------------

IPv6 Neighbor Discovery trust models and threats
draft-ietf-send-psreq-04

- an informal definition of trust is given
- three threat model are presented. 

------------

Security Considerations for 6to4
draft-ietf-v6ops-6to4-security-01.txt

- no trust model provided. 
- detailed threat descriptions provided

------------

Threats Introduced by Rserpool and Requirements for Security
in response to Threats
<draft-ietf-rserpool-threats-02.txt>

- no trust model provided. 
- each section is divided into Threat, Effect and Requirement

------------

Generic Threats to Routing Protocols
draft-ietf-rpsec-routing-threats-04

- no trust model provided. 
- threat definition and different threat sources provided. 

------------

DDP/RDMAP Security 
draft-ietf-rddp-security-01.txt 

- definition of Partial Trust Taxonomy given. 
- Attacks and Countermeasures provided. 
- resources and architecture defined 

------------            
                   
PANA Threat Analysis and Security Requirements

draft-ietf-pana-threats-eval-04.txt

- trust relationships described but term trust not defined. 
- security requirements are attached to each threat

------------

Security Threats and Risks for OPES
draft-ietf-opes-threats-03

- discusses threats 
- no trust, no requirements and no countermeasures. 

------------

Mobility Support in IPv6
draft-ietf-mobileip-ipv6-24.txt

- attached to the main protocol as part of the security consideration
section 
- discusses threats and their countermeasures
- very specific and was (as we all know) provided after the protocol was
nearly finished. 

------------

Security Framework for Provider Provisioned Virtual Private 
Networks 
draft-ietf-l3vpn-security-framework-00.txt

- a trust model is not mentioned although a Security Reference Model is
provided
- discusses threats and Countermeasures
- detailed security requirements (for user and for provider) 

------------

Securing Block Storage Protocols over IP
draft-ietf-ips-security-19.txt

- describes security requirements and security protection in detail 
- security threats are briefly mentioned as part of the security
requirements

------------

Threat Analysis of the Domain Name System
draft-ietf-dnsext-dns-threats-06.txt 

- lists known threats against the dns directory. 
- threats are detailed since they are described on a known protocol 

------------

Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis
draft-ietf-dhc-v4-threat-analysis-00

- threats are detailed since they are described on a known protocol 
- security Requirements are discussed. 

------------

Security Threat for Content Internetworking
draft-ietf-cdi-threat-00.txt

- trust model included
- threats distinguish between insider and outsider threats

------------

here is my conclusion from browsing through various security drafts: 

- only a few drafts describe a trust model
- the term trust is almost never defined; if it is defined then there is a
rather informal non-technical definition of it. 
- i could not find a place which made a difference between threats and
attacks 
- some drafts are very specific about their threats (since they point to
existing protocols; which are already in use for a long time)

what can we learn for our work: 

- we started with our security efforts very early. this has some benefits
but also some drawbacks:
advantage: we start with security discussions quite early and considered
various issues quite early
disadvantage: since the focus of our work shifted a bit over the last few
years it was difficult to keep the work synchronized. the security threats
work is always something behind. we could possibly keep it ongoing until the
last protocol is finished

- the threats document address the nsis protocol suite. it is generic and
cannot cover current activities in the qos nslp, nat/fw nslp and also in the
ntlp. these document must provide some additional information about their
threats and particuarly about the countermeasures. regarding some issues of
these protocols the work is not finished (and hence it would be difficult to
have all these issues covered in the threats document already). 

- it is hard to discuss trust models since they are highly application
specific. therefore, they are included in the nat/fw nslp and in the qos
nslp. the work there is still ongoing since they are not trivial. the ntlp
does not make sense without the nslps (at least from the current gimps
draft). hence it is useful to consider the relationship between the ntlp and
the nslps together with respect to their trust model and their security
properties. 

i know that the definition of trust raises long philosophical discussions. i
have attended several projects which came across this issue. typically the
outcome of these discussions is rather disappointing. hence, i would suggest
that we do not work on our flavor of trust definition. 

- we decided not to include 
  * security requirements (since they can be found in the security
requirements document)
  * solution specific aspects (such as countermeasures)
  in the threats document 

the main intention with section 2 was to provide an overview of the security
work in nsis, to provide some convient names for some communication pattern
which are typical (intra-domain, inter-domain, etc.) and to provide the
possible trust relationships in a high-level fashion (end-to-middle,
middle-to-middle, etc.). it seems that people did not like this approach
with regard to section 2. are there some proposals what we could do? 

i think we should do the following: 
 - we should polish the individual threats (see other mails)
 - we should not include security requirements
 - we should not include solutions aspects
 - we should clearly point the main intention of the document and that
additional information is found in the related documents
 - we should do something with section 2 (i hope to receive some comments)

ciao
hannes

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