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

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

OK Gorry,

I agree with your comments and we will include your suggestions in the
next version.  Thanks.

Haitham  


----

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: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] 
Sent: 04 July 2006 10:08
To: ipdvb@erg.abdn.ac.uk
Cc: gmgross@nac.net; Cruickshank HS Dr (CCSR)
Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt


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

Marie-Jose Montpetit wrote:

> 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-0
>>>2
>>>.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-0
>>>2
>>>.txt>
>>>
>>>
> 
>