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

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 03 Jul 2006 08:42:54 -0700

Do we want to limit the assumptions to the satellite link? In my opinion
it limits the scope of the work even if essentially ULE is for
satellites.

/mjm

> -------- Original Message --------
> Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt
> From: [email-masked]
> Date: Mon, July 03, 2006 11:02 am
> To: <[email-masked]>, <[email-masked]>
>
> 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: [email-masked]
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of George Gross
> Sent: 30 June 2006 18:37
> To: [email-masked]
> 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>
> >
> >

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 04 Jul 2006 10:08:28 +0100

Indeed Marie-Jose,

Satellite links are important and good examples of usage (given that 
this is one of very few standards that are applicable to 
point-to-point/wide-area satellite networking).

HOWEVER, I agree that the scope MUST be applicable to all transmission 
media where IP services can be provided - terrestrial, cable, mobile 
broadcast, etc.

I think it would be good to be clear where specific requirement comes 
from, and identify whether each requirement results from:

	Wireless transmission (e.g. ease of intercept);
	Satellite (e.g. additional delay);
	Asymmetry (e.g. uni-directional routing)
	Flat/broadcast toplogy (e.g. large number of systems)
	etc

Gorry