Security Considerations section for draft-fair-ipdvb-req-04.txt

[Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>]

Hi All,

I have been discussing with Gorry the security requirements for IP over
DVB.  Here is some text that I prepared and borrowed some material from
the PILC draft on Advice to Link Designers. I also include Laurent
Claverotte recent ideas (email) as well, any comments are welcome:

***********************************
x. SECURITY REQUIREMENTS FOR IPDVB

End-to-end security (including confidentiality, authentication,
integrity and access control) are closely associated with the end-user
assets they protect. This close association cannot be ensured when
providing subnetwork security mechanisms, such as those for MPEG-2
transmission networks.  Several security mechanisms that can be used
end-to-end have already been deployed in the general Internet and are
enjoying increasing use. The most important are:

* The Secure Sockets Layer (SSL) and Transport Layer Security, TLS,
which is primarily used to protect web commerce;
* Pretty Good Privacy (PGP) and S/MIME, primarily used to protect and
authenticate email and software distributions;
* The Secure Shell (SSH), used to secure remote access and file
transfer;
* IPsec, a general purpose encryption and authentication mechanism above

IP that can be used by any IP application.

However, subnetwork security is important [LINK] and should be
encouraged, on the principle that it is better than the default
situation, which all too often is no security at all.  Users of
especially vulnerable subnets (such as radio/broadcast networks and /or
shared media Internet access) often have control over at most one
endpoint - usually a client and therefore cannot enforce the use of
end-to-end mechanisms.

A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties and
determining their communication patterns and volumes even when their
actual contents are protected by strong end-to-end security mechanisms
(this is important for networks such broadacst/radio, were
eaves-dropping is easy).  Finally an important role for subnetwork
security is the protection of the subnetwork itself.  Possible threats
to subnetwork assets include theft of service and denial of service;
shared media subnets tend to be especially vulnerable to such attacks
[LINK].

Security concerns not just the packet data being communicated, but also
the control protocols.  Appropriate security functions must therefore be

provided for ipdvb support protocols [LINK].

x.1 SECURITY REQUIREMENTS FOR ULE

Link layer encryption

ULE level encryption is commonly used in broadcast/radio links.  The
encryption and key exchange methods vary significantly, depending on the

intended application. For example, DVB-S/DVB-RCS operated by Access
Network Operators (ANO) may wish to provide their customers (Internet
Service Providers, ISP) with security services. Common targeted security

services are: terminal authentication and data confidentiality (for the
unicast and multicast streams) between the gateway and the terminals
(also limited to the satcom system). A common objective is to provide
the same level of privacy as the terrestrial links. Moreover, in the
same time, the ISP may want to provide end-to-end security services to
the end-users (based on the well known mechanisms such as IPSec).
Therefore it is important to understand that both security solutions
((ANO-to-ISP) and (ISP-to-end users)) can co-exist and are economically
viable.

It is therefore recommended that ULE supports optional encryption of the

SNDU payload. Furthermore, it may be desirable to encrypt/authenticate
some/all ULE headers.  The method of encryption and the way in which
keys are exchanged is beyond the scope of the ULE Specification.
However, the specification MUST provide a method to allow such
encryption to be implemented at the link layer.

[LINK] = Advice to Link Designers, IETF PILC WG, BCP (with RFC-Ed).


***********************************

FINALLY, here are some thoughts about the TYPE field for security:

Some options that may be used include:
A type field in the ULE header (16 bits) can be used to indicate that
some part of the ULE PDU is encrypted.  There are two solutions for the
use of the type field:
1. Define a range of types X-to-Y for security.  These types will act as

security key ID to enable the decryption of the incoming ULE PDUs.
2. A single type value may be defined for encryption (say X) followed by

any required Security Association (SA) parameters.  The definition of
this SA and the related encryption keys are out of the scope for ULE
draft.

The second solution is more generic and decouples ULE document from any
future security extensions, and resembles the IPSEC operations. The
former provides functions that resemble
those currently used for MPE encapsulation (odd and even keys).


Haitham
--
Dr. Haitham S. Cruickshank

Senior Research Fellow
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/