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

[George Gross <gmgross@nac.net>]

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.  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.

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. 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?

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?

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.

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?

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?

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".

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?

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.

8) the requirements should indicate whether 64-bit sequence numbers are to
be supported (or not) as RFC4301 does define this capability.

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)?

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.

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.

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