Some comments to draft-cruickshank-ipdvb-sec-req-00.txt

["Gessler Gerhard" <Gessler@iabg.de>]

Dear all,

please find bellow some comments from Wolfgang and myself to the current
version of draft-cruickshank-ipdvb-sec-req-00.txt:

- The draft document tries to strongly sell ULE encryption while it
first states to only look at the security requirements for ULE. I think
we should look in this document only generally on the requirements that
ULE and its users could have, and should either produce documents
describing the usage of IPsec over ULE (and what it provides / not
provides), the usage of encryption on ULE level (and what it provides /
not provides), and the usage of encryption below ULE, or describe in an
impartial way pros and cons of the three possibilities.

- In general, based on IETF tradition it is never a good idea to mix
requirements / problem statements and partial solution in a single doc.
E.g. we can say we need terminal authentication, but shouldn't say on
which layer nor during which phase (these are questions to be answered
later in a security solution design process)

- The draft says repudiation is an application layer issue, however,
means for non-repudiation (at least for non-repudiation of origin) can
also be done on the network layer (digital signature of single packets)
 
- Rather than saying "The ULE security solution should be compatible
with functions such as NAT/NAPT, IPsec, TLS, ..." it should be "The ULE
security solution should be compatible with functions such as NAT/NAPT."

 
- The comparison of the different security approaches IPsec, L2security
below ULE, L2 security as part of ULE is incomplete and misleading. E.g.
all three will have no problems with NAT and PEP if only used between
encapsulator and receiver and - as usual - the NAT and PEP functionality
is outside this link
 
- What means "Protection of the management system and the infrastructure
from unauthorised people"? Management systems use like data the same
transmission techniques, so there shouldn't be a difference for them. 
 
- The doc could say more about key management (especially for multicast
key management), e.g. which type of multicast key management will be
required (static, automatic), will key-revocation be needed for
multicast, ...
 
- Is network access control an issue?
 
- The large transmission range of satellite technology is in no case an
argument to consider legal issue. The whole Internet has a global
coverage, so what is good for the Internet from a legal point of view,
should also be good for ipdvb specifically.
 
- It is not clear to us if the MAC / NPA protection is a big
requirement, as also on other foo networks these are unprotected. The
only argument here could be that they need to be protected as satellite
links have a large reachability to other foo networks, so the visibility
of the L2 identifiers and consequently their traceability is larger.
Still I'm not sure if this is a major requirement.

- It is good to just define the usage of e.g. IPsec or L2-Security with
ULE and leaving out the details of how the keys are managed. This allows
the WG to re-use already existing key management approaches (IKE, IKEv2,
GSAKMP, etc) and the adoption of the used cryptographic methods to local
legislation.

- The often cited drawback of IPsec in tunnel mode (large overhead due
to 2 IP headers) could be quickly reduced if e.g. ROHC within the IPsec
tunnels is used. AFAIK, the MOBIKE WG is looking into this (Goals &
Milestones: Jan 06  Submit Reduced Tunnel Overhead Mode for IPsec to
IESG for Informational RFC). It is not yet clear if they really will
meet the milestone in time and how fast implementations will pick this
up, but the work of this WG could invalidate some of the arguments put
forward in favour of ULE encryption.

Best Regards,

	Gerhard

--------------------------------------------
Gerhard Gessler

Communication Networks, IABG mbH
Einsteinstr. 20
85521 Ottobrunn, Germany

Telefon: +49 89 6088 - 2021
Fax: +49 89 6088 - 2845

E-Mail: gessler at iabg dot de