RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt

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

 Hi George,

Many thanks for your comments and they are much appreciated since you
are an active member of MSEC group.  See responses in-line:


----

Dr. Haitham S. Cruickshank

Lecturer 
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/



-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of George Gross
Sent: 30 June 2006 18:37
To: ipdvb@erg.abdn.ac.uk
Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt

Hi Haitham and co-authors,

since your ULE security requirements draft cites both GSAKMP and IPsec,
I thought it merited a closer look. In parallel, I've also been looking
at the ULE security extension header draft too, but I will comment on
that in a separate e-mail.

First off, let me qualify what I'm about to say, as my understanding of
the IPDVB architecture is still imperfect. I'm coming from a MSEC
perspective, and I'll need to verify some of my assumptions along the
way, so please let know if I'm off the mark...

ASSUMPTIONS:

Viewed from 10,000 feet (or perhaps even better from a geosynchronous
orbit ;o) the IPDVB network can be characterized a point to multi-point
layer-2 network topology, which may or may not be capable of satellite
based bi-directional Internet communication. In any case, terrestrial
Internet UDLR communications will be available when the satellite link
is one-way.  
Haitham :  That is Correct

Peer-to-peer communications between the subscribers is possible only via
the MPEG Transmission Stream Multiplexor acting a layer-2 relay (or
layer-3 router).

The service model presented to each subscriber is effectively a private
Layer-2 virtual Ethernet LAN. In the simplest topology, the VLAN has
only two MAC station addresses: a Service Provider's edge router
interface and the individual subscriber's DVB terminal. In a corporate
setting, the VLAN would have a closed group of MAC station addresses, at
least one of which would be an IP router. In this VLAN configuration, it
is possible to send a layer-2 frame multicast from a MAC station to all
other MAC stations on the same VLAN (i.e. MPEG-TS-Mux duplicates and
issues the multicast on behalf of the subscriber terminal). It is also
possible to send a unicast
layer-2 frame between any two subscriber MAC stations belonging to the
VLAN via the MPEG-TS-Mux. In other words, the VLAN maps into a secure
group.
Haitham:  Correct

QUESTIONS:

If the above set of assumptions are accurate, then I have the following
comments and questions about the IPDVB security requirements.

1) The IPDVB security requirements talk about "address hiding", but
really that security service is better described as "identity protection
using a pseudonym MAC address". Please add some words to that effect. I
agree that this is a valuable service to provide for IPDVB. 

Haitham:  Yes, that is a good suggestion. We will do that.
However, it does raise some questions in my mind:

a. what conditions would trigger the pseudonym MAC address to change?
policy defined lifetime? or is it quasi-permanent (i.e. changes only at
node reboot)? if the TS-Mux reboots, do the pseudonym MAC addresses
change?
Haitham:  Policy defined lifetime.

b. when a node's pseudonym MAC address changes, do all parties
communicating with that node's MAC station have to go through address
resolution again? how do they detect this event?

c. doesn't this problem suggest the requirement that the pseudonym MAC
address transitions be made transparent to all of the in the progress
communications?
Haitham:  We agree and we will add this requirement.

2) no where in the document is there a requirement expressed for group
SA re-keying (e.g. LKH). I would expect that policy would be set to
periodically change the VLAN's SA keys (or after X kilo-bytes sent per
key). also, VLAN membership changes would imply a requirement for
forward/backward secrecy.
Haitham:  We assume that this is part of the key management system,
which is independent of the ULE security extensions .  For example, if
GSAKMP is used, then rekey messages are transmitted as IP traffic over
ULE.

3) the requierements were not precise about the definition of source
authentication. Clearly for pair-wise SA then a MAC is sufficient. For
groups, you would need to say whether group authentication or individual
source authentication is required. if the answer is both mechanisms,
would the requirements ask for per packet choice of that mechanism?
Haitham: pair-wise SA and group SA are enough for MPEG transmission
systems.

4) section 3 does not use the MUST and SHOULD keywords as often as I
would have expected. then again, as a requierements document I don't
know if that kind of normative language is necessary. what do people in
the IPFVB WG think?
Haitham:  I will leave this to somebody else.

5) Scenario 1 on page 8 says "ULE MAC address hiding should be
provided...". Does that mean that a solution that didn't offer that
feature would still be compliant? i.e. "should" is not the same as
"must"
or "MUST".
Haitham:  I agree.  Thanks.

6) Authentication costs bandwidth, which is at a premium on the
satellite link. Would it not be more bandwidth efficient to do
authentication at each layer-2 frame PDU boundary rather than for each
184 byte long SNDU unit within that frame?
?Haitham:  I agree about the cost bandwidth. Our target for
authentications is ULE source (encapsulator).

7) I noticed that the authentication MAC field in your proposed security
extension header is 32 bits long, whereas the minimum used with
HMAC-SHA1 in the IPsec suite is 96 bits. In terms of cryptographic
strength, 32 bits is weak. So I think a rationale for the 32-bit MAC
would in order somewhere in this document.
Haitham:  I agree about the 32-MAC.  We will change it.

8) the requirements should indicate whether 64-bit sequence numbers are
to be supported (or not) as RFC4301 does define this capability.
Haitham:  OK we will add that.

9) it was not clear to me (being an IPDVB newbie) at what granularity
does the Packet Identifier (PID) get assigned? is there one allocated to
each Service Provider? BTW, that acronym is very loaded, usually in
other circles it is interpreted to mean "protocol identifier". I would
suggest a new acronym. how about "Transport Stream Logical Channel"
(TSLC)?
Haitham:  PID stands for Packet ID.  It is a well known term in the MPEG
transmission networks.  Regarding IP packet, one PID can be used to
transport one or several IP flows. for example you can use a single PID
to form a VPN over MPEG transmission network.

10) ESP allows padding to deliberately lengthen the payload, with the
intent of protecting against traffic analysis. IPDVB may not want to
provide that service, but since this document refers to IPsec as its
model, in general it would useful to systematically say what subset is
being required for this feature or any other that IPsec offers.
Haitham:  OK we will analyse this.  Again bandwidth has a price here.

11) it would be useful to enumerate what pre-configured or out of band
installed parameters are assumed to be known to the subscriber terminal
about its layer-2 environment, versus what parameters are discovered or
setup by protocols. for example, I would expect certain trust anchor
public keys would have to be pre-placed on the subscriber terminal.
Haitham:  OK, will do.



hth,

	George

 On Wed, 21 Jun 2006, Gorry Fairhurst wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
>     Title        : Security requirements for the Unidirectional
Lightweight
> Encapsulation (ULE) protocol
>     Author(s)    : H. Cruickshank, et al.
>     Filename    : draft-cruickshank-ipdvb-sec-req-02.txt
>     Pages        : 16
>     Date        : 2006-6-20
>
> This document provides a threat analysis and derives security 
> requirements for MPEG-2 transmission links using the Unidirectional 
> Lightweight Encapsulation (ULE). It also provides the motivation for 
> ULE link-level security. This work is intended as a work item of the 
> ipdvb WG, and contributions are sought from the IETF on this topic.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-02
> .txt
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
>     "get draft-cruickshank-ipdvb-sec-req-02.txt".
>
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>     mailserv at ietf.org.
> In the body type:
>     "FILE /internet-drafts/draft-cruickshank-ipdvb-sec-req-02.txt".
>
> NOTE:    The mail server at ietf.org can return the document in
>     MIME-encoded form by using the "mpack" utility.  To use this
>     feature, insert the command "ENCODING mime" before the "FILE"
>     command.  To decode the response(s), you will need "munpack" or
>     a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>     exhibit different behavior, especially when dealing with
>     "multipart" MIME messages (i.e. documents which have been split
>     up into multiple messages), so check your local documentation on
>     how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> <ftp://ftp.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-02
> .txt>
>
>