[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt
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: H.Cruickshank@surrey.ac.uk
> Date: Mon, July 03, 2006 11:02 am
> To: <ipdvb@erg.abdn.ac.uk>, <gmgross@nac.net>
>
> 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>
> >
> >