From owner-ipdvb@erg.abdn.ac.uk Mon Jul 03 11:14:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ83-0005sD-N0 for ipdvb-archive@ietf.org; Mon, 03 Jul 2006 11:14:27 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQ82-00053Z-8D for ipdvb-archive@ietf.org; Mon, 03 Jul 2006 11:14:27 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k63F4wXC006587 for ; Mon, 3 Jul 2006 16:04:58 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k63F4wcx006586 for ipdvb-subscribed-users; Mon, 3 Jul 2006 16:04:58 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.153] (dhcp-207-153.erg.abdn.ac.uk [139.133.207.153]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k63F4jr4006541 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 3 Jul 2006 16:04:50 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 03 Jul 2006 16:04:31 +0100 Subject: Agenda for meeting on MONDAY, July 10, 2006 . From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: Agenda for meeting on MONDAY, July 10, 2006 . Thread-Index: AcaesfyKOvQUgAqlEduHmAAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.4 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 The ipdvb WG will meet next week at 1520-1720 (Afternoon Session II) on MONDAY, July 10, 2006 at IETF-66: http://www.ietf.org/meetings/IETF-66.html The agenda for the ipdvb meeting is at: http://www3.ietf.org/proceedings/06jul/agenda/ipdvb.txt * IMPLEMENTORS of ULE please note that time has been allocated to report on the current status of implementation of the ULE Encapsulator or Receiver. If you would like to present (or wish the Chair to present for you) 1 or 2 slides on this topic (especially on implementation experience and the currently implemented Spec), please send these to the WG Chair in advance of the meeting. * All other presenters please send me copies of your slides to upload by Thursday this week - ahead of the meeting, to allow remote participants to be able to read and follow them. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Mon Jul 03 11:14:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQ85-0005sS-3K for ipdvb-archive@ietf.org; Mon, 03 Jul 2006 11:14:29 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQ82-00053Y-7q for ipdvb-archive@ietf.org; Mon, 03 Jul 2006 11:14:29 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k63F2hlv006446 for ; Mon, 3 Jul 2006 16:02:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k63F2gSH006445 for ipdvb-subscribed-users; Mon, 3 Jul 2006 16:02:42 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from ads40.surrey.ac.uk (ads40.surrey.ac.uk [131.227.102.140]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k63F2XSC006428 for ; Mon, 3 Jul 2006 16:02:33 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 16:02:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Date: Mon, 3 Jul 2006 16:02:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Thread-Index: AcackJuhrZQ6GalAQNar+96cym5SxgCFQuZA From: To: , X-OriginalArrivalTime: 03 Jul 2006 15:02:29.0093 (UTC) FILETIME=[B3E16150:01C69EB1] X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id k63F2gco006442 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 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. > .txt> > > From owner-ipdvb@erg.abdn.ac.uk Mon Jul 03 11:50:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQgs-00064U-Ms for ipdvb-archive@ietf.org; Mon, 03 Jul 2006 11:50:26 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQgp-00076p-86 for ipdvb-archive@ietf.org; Mon, 03 Jul 2006 11:50:26 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k63Fh50Q009550 for ; Mon, 3 Jul 2006 16:43:05 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k63Fh5xo009549 for ipdvb-subscribed-users; Mon, 3 Jul 2006 16:43:05 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout14-02.prod.mesa1.secureserver.net (smtpout14-02.prod.mesa1.secureserver.net [68.178.232.8]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k63Fgt9T009532 for ; Mon, 3 Jul 2006 16:42:55 +0100 (BST) Received: (qmail 31866 invoked from network); 3 Jul 2006 15:42:54 -0000 Received: from unknown (HELO gem-wbe23.prod.mesa1.secureserver.net) (64.202.189.214) by smtpout14-02.prod.mesa1.secureserver.net with SMTP; 3 Jul 2006 15:42:54 -0000 Received: (qmail 9524 invoked by uid 99); 3 Jul 2006 15:42:54 -0000 Date: Mon, 03 Jul 2006 08:42:54 -0700 From: Marie-Jose Montpetit Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt To: ipdvb@erg.abdn.ac.uk cc: gmgross@nac.net Message-ID: <20060703084254.ca5566c7162b3cfcb6c200079b757bd6.297b9211d4.wbe@email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII User-Agent: Web-Based Email 4.3.13 X-Originating-IP: 144.189.40.221 X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 1.8 (+) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a 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: , > > 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. > > > .txt> > > > > From owner-ipdvb@erg.abdn.ac.uk Tue Jul 04 05:14:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxgzE-0008D0-IW for ipdvb-archive@ietf.org; Tue, 04 Jul 2006 05:14:28 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxgzB-0006HW-Qz for ipdvb-archive@ietf.org; Tue, 04 Jul 2006 05:14:28 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6498cFa029726 for ; Tue, 4 Jul 2006 10:08:38 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6498c0t029725 for ipdvb-subscribed-users; Tue, 4 Jul 2006 10:08:38 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.152] (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6498S1f029709; Tue, 4 Jul 2006 10:08:28 +0100 (BST) Message-ID: <44AA300C.3010907@erg.abdn.ac.uk> Date: Tue, 04 Jul 2006 10:08:28 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: gmgross@nac.net, "H.Cruickshank" Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt References: <20060703084254.ca5566c7162b3cfcb6c200079b757bd6.297b9211d4.wbe@email.secureserver.net> In-Reply-To: <20060703084254.ca5566c7162b3cfcb6c200079b757bd6.297b9211d4.wbe@email.secureserver.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 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: , >> >>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. >>>>>.txt> >>> >>> > > From owner-ipdvb@erg.abdn.ac.uk Tue Jul 04 11:50:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxnAg-0000yb-15 for ipdvb-archive@ietf.org; Tue, 04 Jul 2006 11:50:42 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxnAd-0006jv-Sl for ipdvb-archive@ietf.org; Tue, 04 Jul 2006 11:50:42 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k64FiZan001803 for ; Tue, 4 Jul 2006 16:44:35 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k64FiZCK001802 for ipdvb-subscribed-users; Tue, 4 Jul 2006 16:44:35 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from ads40.surrey.ac.uk (ads40.surrey.ac.uk [131.227.102.140]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k64FiPWT001779; Tue, 4 Jul 2006 16:44:25 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 16:44:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Date: Tue, 4 Jul 2006 16:44:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Thread-Index: AcafSXCBTF9Qjmm1R4eNv5db28vMjQANw6hg From: To: , Cc: X-OriginalArrivalTime: 04 Jul 2006 15:44:20.0588 (UTC) FILETIME=[B742DAC0:01C69F80] X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id k64FiXet001797 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be 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: , >> >>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. >>>>>2 >>>.txt> >>> >>> > > From owner-ipdvb@erg.abdn.ac.uk Thu Jul 06 12:05:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWMM-0006CT-0w for ipdvb-archive@ietf.org; Thu, 06 Jul 2006 12:05:46 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWMJ-0002Se-GN for ipdvb-archive@ietf.org; Thu, 06 Jul 2006 12:05:46 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k66FqJa5007479 for ; Thu, 6 Jul 2006 16:52:19 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k66FqJxu007478 for ipdvb-subscribed-users; Thu, 6 Jul 2006 16:52:19 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k66Fq9K6007460 for ; Thu, 6 Jul 2006 16:52:10 +0100 (BST) Received: (qmail 95211 invoked by uid 0); 6 Jul 2006 11:52:08 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 6 Jul 2006 11:52:08 -0400 Received: (qmail 37464 invoked from network); 6 Jul 2006 11:52:08 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 6 Jul 2006 11:52:08 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k66C9pC15803; Thu, 6 Jul 2006 08:09:51 -0400 Date: Thu, 6 Jul 2006 08:09:51 -0400 (EDT) From: George Gross To: Subject: Re: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt In-Reply-To: <44A27543.3080504@erg.abdn.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi Gorry, first off, a question about this draft: I'm assuming it is planned for "informational RFC" status, correct? just checking, since there are no MUST/SHOULD ;o) in section 8, the "Security Considerations" should mention that when the optional IPDVB SNDU security mechanisms are present, ARP and ND security becomes nearly at rough parity with a private wireless LAN. The ARP or ND multicast transmissions will be accepted only from those peer DVB terminals that share a common group encryption and common group authentication key provided by SNDU key management. Whereas, without that optional ULE security extension, security is dependent on the Adversary not cracking into the DVB satellite receiver terminal to eavesdrop on the ARP or ND packets addressed to any other DVB terminal in the satellite network. If a DVB terminal is cracked open, then the Adversary could then issue bogus ARP or ND packets, masquerading as a legitimate peer in the ARP or ND protocols. there would also need to be an informational reference added to point at the IPDVB ULE security extension draft (which I'm assuming will become a proposed standard RFC someday). hth, George On Wed, 28 Jun 2006, Gorry Fairhurst wrote: > This note starts the ipdvb WG Last Call for comments for the WG document > named below: > > draft-ietf-ipdvb-ar-04.txt > http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > > This last call will end on 18th July 2006. > > The period of this last call has been extended because it also includes > the week of the IETF meeting. > > You are asked to read the draft and send any issues, comments, or > corrections to this mailing list. The WGLC procedure is the last chance > for this working group to modify/correct this. > > Please do forward any comments to the ipdvb list. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > From owner-ipdvb@erg.abdn.ac.uk Fri Jul 07 11:13:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fys1N-0002kC-7u for ipdvb-archive@ietf.org; Fri, 07 Jul 2006 11:13:33 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fys1K-0004Br-6G for ipdvb-archive@ietf.org; Fri, 07 Jul 2006 11:13:33 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k67ExwiU022521 for ; Fri, 7 Jul 2006 15:59:58 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k67ExwvY022520 for ipdvb-subscribed-users; Fri, 7 Jul 2006 15:59:58 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from ads40.surrey.ac.uk (ads40.surrey.ac.uk [131.227.102.140]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k67ExoU6022502 for ; Fri, 7 Jul 2006 15:59:50 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 15:59:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6A1D5.FBDF26E2" Subject: RE: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) Date: Fri, 7 Jul 2006 15:59:45 +0100 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD3BC@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: <018160DBE8D48349A0CABF4424C3DC21AAD3BC@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) Thread-Index: AcacxRVLBq29TXKXRHCJySspLQEZbgFDoZHl From: To: Cc: X-OriginalArrivalTime: 07 Jul 2006 14:59:45.0912 (UTC) FILETIME=[FC44EF80:01C6A1D5] X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A1D5.FBDF26E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi George,=0A= Thanks for the comments and suggestions. Please find our response to them i= nline:=0A= =20=0A= =20=0A= =0A= ________________________________=0A= =0A= From: owner-ipdvb@erg.abdn.ac.uk on behalf of George Gross=0A= Sent: Sat 01/07/2006 01:04=0A= To: ipdvb@erg.abdn.ac.uk=0A= Subject: Re: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt= (enclosed)=0A= =0A= =0A= =0A= Hi Haitham and co-authors,=0A= =0A= I reviewed your draft, and from what I can tell, the proposed ULE security= =0A= extension header fits the requirements in many regards. I do have a few=0A= comments and clarifications:=0A= =0A= 1) the sequence number processing steps described in section 2.3 omits=0A= mention of updating of the transmitter's ULE-SA sequence number state=0A= variable.=0A= =0A= //Sunny=0A= =0A= You are right and will update it.=0A= =0A= 2) section 2.4 omits mention of updating the receiver's sequence number=0A= state variable's update procedure. your procedure implicitly assumes in=0A= order delivery of the SNDUs, which is different than IPsec. as you may=0A= recall, IPsec defines an algorithm with a sliding window for acceptable=0A= sequence numbers that handles out of order delivery. I would suggest=0A= should pointing out the ULE dependency on the FIFO delivery order.=0A= =0A= //Sunny=0A= =0A= You are right and will update it. Regarding the order delivery, unlike IPSe= c, MPEG2 networks do not need sliding window for acceptable seq. numbers an= d hence will point of dependency of ULE on FIFO order.=0A= =0A= =0A= =0A= =0A= 3) In reading over your description of the ULE-SPD, it seemed to me that=0A= it really augments the RFC4301 SPD with at least a traffic selector for=0A= the NPA address, and also temporary NPA. you may wish to consider whether= =0A= other ULE header fields (e.g. the type field) can also participate in the= =0A= ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate=0A= IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct?= =0A= this would be helpful to highlight in your intro about the ULE-SPD.=0A= =0A= //Sunny=0A= =0A= Because the security is between the encapsulators and receievers, only the = NPA address along with the ULE-SID should be enough as selectors for the da= tabases. Dont intend to evaluate the IP v46 header fields. Will try to clar= ify this.=0A= =0A= 4) the focus of the document seems to be on the SNDU flow from the TS-Mux= =0A= to the receiver(s). yet would not DVB-RCS require comparable security=0A= protections for the inverse SNDU traffic flow?=0A= =0A= =0A= //Sunny=0A= =0A= For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS secur= ity on the key management and the DVB-RCS specs.=0A= =0A= =0A= in that case, does the inbound ULE-SPD within the TS-Mux need to know the= =0A= source NPA address when decrypting a non-IP layer-3 PDU since it can't=0A= de-mux using the source IP address?=0A= =0A= //Sunny=0A= =0A= Not an Issue. Will be communicated by the Key Management if present.=0A= =0A= 5) assuming there is a VLAN group within a DVB-RCS network, is there a=0A= distinct ULE SA with anti-replay state maintained by the TS-Mux SAD for=0A= each subscriber terminal within that VLAN? in other words, is there a=0A= ULE-SA per VLAN Group Speaker?=0A= =0A= =0A= // This is the same issue as in IPSec. Will follow the same solution as pro= posed in the MSec group.=20=0A= =0A= =20=0A= 6) as mentioned in my earlier e-mail, I'm concerned about the 32-bit=0A= authenticator field length not being strong enough. BTW, in my earlier=0A= e-mail's list item #6, I mistakenly mixed up "TS packets" with SNDUs. plz= =0A= disregard that statement. Clearly, there isn't a MAC computed per TS=0A= packet.=0A= =0A= //I agree with that and it should at least be 16 bytes. Wll change that. Di= sregarded your previous statement :)=0A= =0A= =0A= =0A= 7) how would this S-ULE extension header encode a digital signature's data= =0A= or handle TESLA for a multicast SNDU source authentication? I haven't=0A= thought this through entirely, but at first glance this seems like a=0A= possible feature for securing ARP or ND multicasts. A ULE-SA using this=0A= feature would have its own distinct ULE-SID allocated to it. It would be=0A= an example of when you might want more than one S-ULE extension header=0A= before the SNDU payload.=0A= =0A= //Sunny=0A= =0A= We thought of the same thing i.e. use an source authentication protocol lik= e tesla applied over many packets as oppposed to per packet as an example. = I havent thought this through ourself but at first glance looks like it mig= ht need a separate ULE-SID.=20=0A= =0A= =20=0A= =0A= Hope that helps and will incorporate all the suggestions in the next revisi= on.=0A= =0A= Thanks for your detailed comments=0A= =0A= =20=0A= =0A= BR=0A= =0A= Sunny and Haitham=0A= =0A= =0A= =0A= br,=0A= George=0A= =0A= On Sat, 24 Jun 2006 H.Cruickshank@surrey.ac.uk wrote:=0A= =0A= > Dear ipdvb WG,=0A= >=0A= > Gorry has kindly submitted for our the Internet draft on security extensi= ons to ULE(version 2) .=0A= >=0A= > This draft complements the ULE security requirements that was posted rece= ntly. The main focus of the security extension is defining the header form= at to carry secure data over ULE.=0A= >=0A= > We (the authors) feel this work fits well to the ipdvb current activity. = Many security related issues such as key management and security algorithm= are borrowed from existing work in IPsec and MSEC groups. The main focus = of this draft is the ULE header format for security.=0A= >=0A= > Haitham=0A= >=0A= > ----=0A= > Dr. Haitham S. Cruickshank=0A= > Lecturer=0A= > Communications Centre for Communication Systems Research (CCSR)=0A= > School of Electronics, Computing and Mathematics=0A= > University of Surrey, Guildford, Surrey GU2 7XH, UK=0A= >=0A= > Tel: +44 1483 686007 (indirect 689844)=0A= > Fax: +44 1483 686011=0A= > e-mail: H.Cruickshank@surrey.ac.uk=0A= > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=0A= >=0A= > ________________________________=0A= >=0A= > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]=0A= > Sent: Fri 23/06/2006 09:11=0A= > To: Internet-Drafts Administrator=0A= > Cc: Cruickshank HS Dr (CCSR)=0A= > Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (encl= osed)=0A= >=0A= >=0A= >=0A= >=0A= > On behalf of the authors, I wish to submit the enclosed draft:=0A= >=0A= > Security Extension for Unidirectional Lightweight Encapsulation=0A= > Protocol =0A= >=0A= > Best wishes,=0A= >=0A= > Gorry=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C6A1D5.FBDF26E2 Content-Type: text/plain; name="msg-4233-341.txt" Content-Disposition: attachment; filename="msg-4233-341.txt" Content-Transfer-Encoding: 8bit Hi George, Thanks for the comments and suggestions. Please find our response to them inline: ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of George Gross Sent: Sat 01/07/2006 01:04 To: ipdvb@erg.abdn.ac.uk Subject: Re: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) Hi Haitham and co-authors, I reviewed your draft, and from what I can tell, the proposed ULE security extension header fits the requirements in many regards. I do have a few comments and clarifications: 1) the sequence number processing steps described in section 2.3 omits mention of updating of the transmitter's ULE-SA sequence number state variable. //Sunny You are right and will update it. 2) section 2.4 omits mention of updating the receiver's sequence number state variable's update procedure. your procedure implicitly assumes in order delivery of the SNDUs, which is different than IPsec. as you may recall, IPsec defines an algorithm with a sliding window for acceptable sequence numbers that handles out of order delivery. I would suggest should pointing out the ULE dependency on the FIFO delivery order. //Sunny You are right and will update it. Regarding the order delivery, unlike IPSec, MPEG2 networks do not need sliding window for acceptable seq. numbers and hence will point of dependency of ULE on FIFO order. 3) In reading over your description of the ULE-SPD, it seemed to me that it really augments the RFC4301 SPD with at least a traffic selector for the NPA address, and also temporary NPA. you may wish to consider whether other ULE header fields (e.g. the type field) can also participate in the ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? this would be helpful to highlight in your intro about the ULE-SPD. //Sunny Because the security is between the encapsulators and receievers, only the NPA address along with the ULE-SID should be enough as selectors for the databases. Dont intend to evaluate the IP v46 header fields. Will try to clarify this. 4) the focus of the document seems to be on the SNDU flow from the TS-Mux to the receiver(s). yet would not DVB-RCS require comparable security protections for the inverse SNDU traffic flow? //Sunny For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS security on the key management and the DVB-RCS specs. in that case, does the inbound ULE-SPD within the TS-Mux need to know the source NPA address when decrypting a non-IP layer-3 PDU since it can't de-mux using the source IP address? //Sunny Not an Issue. Will be communicated by the Key Management if present. 5) assuming there is a VLAN group within a DVB-RCS network, is there a distinct ULE SA with anti-replay state maintained by the TS-Mux SAD for each subscriber terminal within that VLAN? in other words, is there a ULE-SA per VLAN Group Speaker? // This is the same issue as in IPSec. Will follow the same solution as proposed in the MSec group. 6) as mentioned in my earlier e-mail, I'm concerned about the 32-bit authenticator field length not being strong enough. BTW, in my earlier e-mail's list item #6, I mistakenly mixed up "TS packets" with SNDUs. plz disregard that statement. Clearly, there isn't a MAC computed per TS packet. //I agree with that and it should at least be 16 bytes. Wll change that. Disregarded your previous statement :) 7) how would this S-ULE extension header encode a digital signature's data or handle TESLA for a multicast SNDU source authentication? I haven't thought this through entirely, but at first glance this seems like a possible feature for securing ARP or ND multicasts. A ULE-SA using this feature would have its own distinct ULE-SID allocated to it. It would be an example of when you might want more than one S-ULE extension header before the SNDU payload. //Sunny We thought of the same thing i.e. use an source authentication protocol like tesla applied over many packets as oppposed to per packet as an example. I havent thought this through ourself but at first glance looks like it might need a separate ULE-SID. Hope that helps and will incorporate all the suggestions in the next revision. Thanks for your detailed comments BR Sunny and Haitham br, George On Sat, 24 Jun 2006 H.Cruickshank@surrey.ac.uk wrote: > Dear ipdvb WG, > > Gorry has kindly submitted for our the Internet draft on security extensions to ULE(version 2) . > > This draft complements the ULE security requirements that was posted recently. The main focus of the security extension is defining the header format to carry secure data over ULE. > > We (the authors) feel this work fits well to the ipdvb current activity. Many security related issues such as key management and security algorithm are borrowed from existing work in IPsec and MSEC groups. The main focus of this draft is the ULE header format for security. > > 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/ > > ________________________________ > > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Fri 23/06/2006 09:11 > To: Internet-Drafts Administrator > Cc: Cruickshank HS Dr (CCSR) > Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) > > > > > On behalf of the authors, I wish to submit the enclosed draft: > > Security Extension for Unidirectional Lightweight Encapsulation > Protocol > > Best wishes, > > Gorry > > > > > > ------_=_NextPart_001_01C6A1D5.FBDF26E2-- From owner-ipdvb@erg.abdn.ac.uk Fri Jul 07 15:34:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyw69-0004HV-Ey for ipdvb-archive@ietf.org; Fri, 07 Jul 2006 15:34:45 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyw66-0004vK-L7 for ipdvb-archive@ietf.org; Fri, 07 Jul 2006 15:34:45 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k67J6Vnb010832 for ; Fri, 7 Jul 2006 20:06:31 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k67J6Vk7010831 for ipdvb-subscribed-users; Fri, 7 Jul 2006 20:06:31 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k67J6JmJ010814 for ; Fri, 7 Jul 2006 20:06:20 +0100 (BST) Received: (qmail 57766 invoked by uid 0); 7 Jul 2006 15:06:19 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 7 Jul 2006 15:06:19 -0400 Received: (qmail 23714 invoked from network); 7 Jul 2006 15:06:18 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 7 Jul 2006 15:06:18 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k67FNnf17576; Fri, 7 Jul 2006 11:23:49 -0400 Date: Fri, 7 Jul 2006 11:23:49 -0400 (EDT) From: George Gross To: cc: , Subject: RE: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) In-Reply-To: <018160DBE8D48349A0CABF4424C3DC21AAD3BC@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Hi Sunny, On Fri, 7 Jul 2006 S.Iyengar@surrey.ac.uk wrote: > 3) In reading over your description of the ULE-SPD, it seemed to me that > it really augments the RFC4301 SPD with at least a traffic selector for > the NPA address, and also temporary NPA. you may wish to consider whether > other ULE header fields (e.g. the type field) can also participate in the > ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate > IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? > this would be helpful to highlight in your intro about the ULE-SPD. > > //Sunny > > Because the security is between the encapsulators and receievers, only > the NPA address along with the ULE-SID should be enough as selectors > for the databases. Dont intend to evaluate the IP v46 header fields. > Will try to clarify this. Q: so what you are saying is that ULE can not select its encryption policy on the basis of per IP source/destination traffic flow? Q: for that matter, what about SPD selecting policy on the basis of source MAC/destination MAC traffic flows? Q: does the TS-Mux have the ability to enforce DISCARD or BYPASS policy on specified SNDU flows? Also, I'd especially recommend that you clarify the SPD interaction with the "D" bit set to '1' as described in RFC 4326 section 4.1. In that case, there is implicit SNDU fragmentation re-assembly state maintained by the SPD/SAD receiver, correct? After the SAD processing decrypts the payload, the IPsec model does policy checking against the inbound SPD-S to confirm compliance (see RFC4301 section 4.4.1 top of page 25). When the "D" flag is '1', there is no NPA present, so this special handling by the ULE SPD must be documented. some other IPsec SPD/SAD model related things you'll need to consider: a. need to talk about how is the ULE PAD used? b. do you support Populate From Packet (PFP) processing? c. do you qualify inbound SAD multicast packet processing by the 2-tuple {destination NPA, ULE SA-ID} ? d. TS maximum transmission unit size impact on PDU processing by SPD (i.e. fragmentation interactions). As a general guideline, I'd recommend that you examine RFC 4301 section by section, and decide what the ULE SPD/SAD/PAD interpretation is, then add that text to the ULE security extension document. in most cases I'd expect you'll describe a subset of IPsec processing, but in any case that subset needs to be said. > > 4) the focus of the document seems to be on the SNDU flow from the TS-Mux > to the receiver(s). yet would not DVB-RCS require comparable security > protections for the inverse SNDU traffic flow? > > > //Sunny > > For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS > security on the key management and the DVB-RCS specs. Not sure I understand, are you saying that the ULE receiver terminal's SPD/SAD/PAD does not participate in its uplink security management? > > > in that case, does the inbound ULE-SPD within the TS-Mux need to know the > source NPA address when decrypting a non-IP layer-3 PDU since it can't > de-mux using the source IP address? > > //Sunny > > Not an Issue. Will be communicated by the Key Management if present. > > 5) assuming there is a VLAN group within a DVB-RCS network, is there a > distinct ULE SA with anti-replay state maintained by the TS-Mux SAD for > each subscriber terminal within that VLAN? in other words, is there a > ULE-SA per VLAN Group Speaker? > > > // This is the same issue as in IPSec. Will follow the same solution as proposed in the MSec group. At this point in time, the MSEC IPsec extensions draft has not put a stake in the ground on this topic. It is recognized that maintaining state at each Group Receiver for each Group Speaker does not scale. But what is the minimum number that a group MUST suport? 1? 16? more than that? in the context of the IPDVB work, I'd suggest nominating a number, and see what folks say... > 7) how would this S-ULE extension header encode a digital signature's data > or handle TESLA for a multicast SNDU source authentication? I haven't > thought this through entirely, but at first glance this seems like a > possible feature for securing ARP or ND multicasts. A ULE-SA using this > feature would have its own distinct ULE-SID allocated to it. It would be > an example of when you might want more than one S-ULE extension header > before the SNDU payload. > > //Sunny > > We thought of the same thing i.e. use an source authentication > protocol like tesla applied over many packets as oppposed to per > packet as an example. I havent thought this through ourself but at > first glance looks like it might need a separate ULE-SID. Makes sense. Probably need to find a few use cases that could benefit from this feature as a way of deciding how it works. e.g. sending any of the MPEG control table contents comes to mind. > > > > Hope that helps and will incorporate all the suggestions in the next revision. > > Thanks for your detailed comments u-r-welcome ;o) I'll be off-net until Sunday, C-U@Montreal br, George > > > > BR > > Sunny and Haitham > > > > br, > George > > On Sat, 24 Jun 2006 H.Cruickshank@surrey.ac.uk wrote: > > > Dear ipdvb WG, > > > > Gorry has kindly submitted for our the Internet draft on security extensions to ULE(version 2) . > > > > This draft complements the ULE security requirements that was posted recently. The main focus of the security extension is defining the header format to carry secure data over ULE. > > > > We (the authors) feel this work fits well to the ipdvb current activity. Many security related issues such as key management and security algorithm are borrowed from existing work in IPsec and MSEC groups. The main focus of this draft is the ULE header format for security. > > > > 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/ > > > > ________________________________ > > > > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > > Sent: Fri 23/06/2006 09:11 > > To: Internet-Drafts Administrator > > Cc: Cruickshank HS Dr (CCSR) > > Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) > > > > > > > > > > On behalf of the authors, I wish to submit the enclosed draft: > > > > Security Extension for Unidirectional Lightweight Encapsulation > > Protocol > > > > Best wishes, > > > > Gorry > > > > > > > > > > > > > > > > From owner-ipdvb@erg.abdn.ac.uk Fri Jul 07 20:09:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz0O4-0007n8-0q for ipdvb-archive@ietf.org; Fri, 07 Jul 2006 20:09:32 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz0O3-000312-EJ for ipdvb-archive@ietf.org; Fri, 07 Jul 2006 20:09:32 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k67NcbfX029138 for ; Sat, 8 Jul 2006 00:38:37 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k67NcbdV029137 for ipdvb-subscribed-users; Sat, 8 Jul 2006 00:38:37 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k67NcF9r029099 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sat, 8 Jul 2006 00:38:22 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 07 Jul 2006 11:38:24 -0400 Subject: Re: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt From: Gorry Fairhurst To: CC: Montpetit Marie-Jose-MGIF0300 Message-ID: Thread-Topic: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt Thread-Index: AcahsXkft45KSw2kEduJxAAKlc/qXg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 On 6/7/06 13:09, "George Gross" wrote: > Hi Gorry, > > first off, a question about this draft: I'm assuming it is planned for > "informational RFC" status, correct? > Yes. > just checking, since there are no MUST/SHOULD ;o) > Good question, let's discuss this in the ipdvb WG meeting: I can see there are places were more formal language could be used, even in an Informational document. > > in section 8, the "Security Considerations" should mention that when the > optional IPDVB SNDU security mechanisms are present, ARP and ND security > becomes nearly at rough parity with a private wireless LAN. The ARP or ND > multicast transmissions will be accepted only from those peer DVB > terminals that share a common group encryption and common group > authentication key provided by SNDU key management. > > Whereas, without that optional ULE security extension, security is > dependent on the Adversary not cracking into the DVB satellite receiver > terminal to eavesdrop on the ARP or ND packets addressed to any other DVB > terminal in the satellite network. If a DVB terminal is cracked open, then > the Adversary could then issue bogus ARP or ND packets, masquerading as a > legitimate peer in the ARP or ND protocols. > OK, that seems a reasonable addition. The current text says: There are known security issues relating to the use of unsecured address resolution [RFC3756]. Readers are also referred to the known security issues when mapping IP addresses to MAC/NPA addresses using ARP [RFC826] and ND [RFC2461]. It is recommended that AR protocols support authentication of the source of AR messages and the integrity of the AR information, this avoids known security vulnerabilities resulting from insertion of unauthorised AR messages within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] may be used in place of ND. This defines security mechanisms that can protect AR. Does the following additional paragraph capture this?: AR protocols can also be protected by the use of L2 security methods (e.g. Encryption of the ULE SNDU [ID-IPDVB-SEC]). When these methods are used, the security of ARP and ND can be comparable to that of a private LAN: A Receiver will only accept ARP or ND transmissions from the set of peer senders that share a common group encryption and common group authentication key provided by the L2 key management. Add Informative Reference: [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, draft-cruickshank-ipdvb-sec-req-xx.txt. > there would also need to be an informational reference added to point at > the IPDVB ULE security extension draft (which I'm assuming will become a > proposed standard RFC someday). > Would the requirements (INFO) be sufficient (this one is a milestone listed on the Charter page)? > hth, > George > > On Wed, 28 Jun 2006, Gorry Fairhurst wrote: > >> This note starts the ipdvb WG Last Call for comments for the WG document >> named below: >> >> draft-ietf-ipdvb-ar-04.txt >> http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ >> >> This last call will end on 18th July 2006. >> >> The period of this last call has been extended because it also includes >> the week of the IETF meeting. >> >> You are asked to read the draft and send any issues, comments, or >> corrections to this mailing list. The WGLC procedure is the last chance >> for this working group to modify/correct this. >> >> Please do forward any comments to the ipdvb list. >> >> Best wishes, >> >> Gorry Fairhurst >> (ipdvb WG Chair) >> > From owner-ipdvb@erg.abdn.ac.uk Sun Jul 09 09:15:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzZ8D-0000EF-RC for ipdvb-archive@ietf.org; Sun, 09 Jul 2006 09:15:29 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzZ8D-0002Zn-AR for ipdvb-archive@ietf.org; Sun, 09 Jul 2006 09:15:29 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k69Cs7b9002909 for ; Sun, 9 Jul 2006 13:54:07 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k69Cs7m0002908 for ipdvb-subscribed-users; Sun, 9 Jul 2006 13:54:07 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k69CreCg002872 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sun, 9 Jul 2006 13:53:53 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Sat, 08 Jul 2006 05:36:36 -0400 Subject: Re: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (a few comments) From: Gorry Fairhurst To: , CC: Message-ID: Thread-Topic: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (a few comments) Thread-Index: AcaicgFkQAdJzg5lEduMBAAKlc/qXg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.5 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab I have a few specific comments... On 7/7/06 11:23, "George Gross" wrote: > Hi Sunny, > > On Fri, 7 Jul 2006 S.Iyengar@surrey.ac.uk wrote: > > >> 3) In reading over your description of the ULE-SPD, it seemed to me that >> it really augments the RFC4301 SPD with at least a traffic selector for >> the NPA address, and also temporary NPA. you may wish to consider whether >> other ULE header fields (e.g. the type field) can also participate in the >> ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate >> IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? >> this would be helpful to highlight in your intro about the ULE-SPD. >> >> //Sunny >> >> Because the security is between the encapsulators and receievers, only >> the NPA address along with the ULE-SID should be enough as selectors >> for the databases. Dont intend to evaluate the IP v46 header fields. >> Will try to clarify this. > > Q: so what you are saying is that ULE can not select its encryption policy > on the basis of per IP source/destination traffic flow? > > Q: for that matter, what about SPD selecting policy on the basis of source > MAC/destination MAC traffic flows? > If you have bridging mode, you also have the possibility of using the MAC source and destination (assuming the bridging extension header is placed before the ULE security header). If the Type field in the ULE security header is not encrypted (should it be?) then you could also use this in policy selection? >> 4) the focus of the document seems to be on the SNDU flow from the TS-Mux >> to the receiver(s). yet would not DVB-RCS require comparable security >> protections for the inverse SNDU traffic flow? >> >> >> //Sunny >> >> For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS >> security on the key management and the DVB-RCS specs. > > Not sure I understand, are you saying that the ULE receiver terminal's > SPD/SAD/PAD does not participate in its uplink security management? > If you have bi-directional connectivity (i.e. ULE were to be used in both directions, then it would seem sensible to allow ULE security in both directions). From affiliates@queenschiropractor.com Thu Jul 13 12:22:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13xK-0001S6-T6 for ipdvb-archive@megatron.ietf.org; Thu, 13 Jul 2006 12:22:26 -0400 Received: from [201.15.75.117] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G13xI-00053H-RO for ipdvb-archive@megatron.ietf.org; Thu, 13 Jul 2006 12:22:26 -0400 Message-ID: <000001c6a696$594a8900$0100007f@localhost> From: "Jackson Mitchell" To: Subject: Re: Hi Date: Thu, 13 Jul 2006 12:22:08 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6A696.594A8900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6A696.594A8900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offers Adobe Full Suite: Adobe Video Collection + Adobe Premiere 1.5 Professional + Adobe After Effects 6.5 Professional + Adobe Audition 1.5 + Adobe Encore DVD 1.5 $149.95 Microsoft 2 in 1: MS Windows XP Pro + MS Office 2003 Pro $99.95 Microsoft + Adobe 3 in 1: MS Windows XP Pro + MS Office 2003 Pro + Adobe Acrobat 7.0 Professional $149.95 Bestsellers Microsoft Office Professional Edition 2003 Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 Microsoft Windows XP Professional Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 Adobe Photoshop CS2 V 9.0 Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 value(url)%} ------=_NextPart_000_0001_01C6A696.594A8900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pay attention
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6A696.594A8900-- From owner-ipdvb@erg.abdn.ac.uk Mon Jul 17 22:51:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2fg6-0007CT-R8 for ipdvb-archive@ietf.org; Mon, 17 Jul 2006 22:51:18 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2fg5-00012c-9s for ipdvb-archive@ietf.org; Mon, 17 Jul 2006 22:51:18 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6I2Vo2g019380 for ; Tue, 18 Jul 2006 03:31:50 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6I2VokQ019379 for ipdvb-subscribed-users; Tue, 18 Jul 2006 03:31:50 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k6I2Vecr019363 for ; Tue, 18 Jul 2006 03:31:40 +0100 (BST) Received: (qmail 42737 invoked by uid 0); 17 Jul 2006 22:31:36 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 17 Jul 2006 22:31:36 -0400 Received: (qmail 99451 invoked from network); 17 Jul 2006 22:31:36 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 17 Jul 2006 22:31:36 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6HMlMJ17484; Mon, 17 Jul 2006 18:47:22 -0400 Date: Mon, 17 Jul 2006 18:47:22 -0400 (EDT) From: George Gross To: cc: Montpetit Marie-Jose-MGIF0300 Subject: Re: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Hi Gorry, your proposed change to the security considerations text (see below) would do just fine.... hth, George On Fri, 7 Jul 2006, Gorry Fairhurst wrote: > On 6/7/06 13:09, "George Gross" wrote: > > > Hi Gorry, > > > > first off, a question about this draft: I'm assuming it is planned for > > "informational RFC" status, correct? > > > Yes. > > > just checking, since there are no MUST/SHOULD ;o) > > > Good question, let's discuss this in the ipdvb WG meeting: I can see there > are places were more formal language could be used, even in an Informational > document. > > > > in section 8, the "Security Considerations" should mention that when the > > optional IPDVB SNDU security mechanisms are present, ARP and ND security > > becomes nearly at rough parity with a private wireless LAN. The ARP or ND > > multicast transmissions will be accepted only from those peer DVB > > terminals that share a common group encryption and common group > > authentication key provided by SNDU key management. > > > > Whereas, without that optional ULE security extension, security is > > dependent on the Adversary not cracking into the DVB satellite receiver > > terminal to eavesdrop on the ARP or ND packets addressed to any other DVB > > terminal in the satellite network. If a DVB terminal is cracked open, then > > the Adversary could then issue bogus ARP or ND packets, masquerading as a > > legitimate peer in the ARP or ND protocols. > > > OK, that seems a reasonable addition. The current text says: > > There are known security issues relating to the use of unsecured > address resolution [RFC3756]. Readers are also referred to the > known security issues when mapping IP addresses to MAC/NPA addresses > using ARP [RFC826] and ND [RFC2461]. It is recommended that AR > protocols support authentication of the source of AR messages and > the integrity of the AR information, this avoids known security > vulnerabilities resulting from insertion of unauthorised AR messages > within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] > may be used in place of ND. This defines security mechanisms that > can protect AR. > > Does the following additional paragraph capture this?: > > AR protocols can also be protected by the use of L2 security methods > (e.g. Encryption of the ULE SNDU [ID-IPDVB-SEC]). When these methods > are used, the security of ARP and ND can be comparable to that of > a private LAN: A Receiver will only accept ARP or ND transmissions from > the set of peer senders that share a common group encryption and > common group authentication key provided by the L2 key management. > > Add Informative Reference: > > [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security > requirements for the Unidirectional Lightweight Encapsulation (ULE) > protocol", Work in Progress, draft-cruickshank-ipdvb-sec-req-xx.txt. > > > there would also need to be an informational reference added to point at > > the IPDVB ULE security extension draft (which I'm assuming will become a > > proposed standard RFC someday). > > > Would the requirements (INFO) be sufficient (this one is a milestone listed > on the Charter page)? > > > hth, > > George > > > > On Wed, 28 Jun 2006, Gorry Fairhurst wrote: > > > >> This note starts the ipdvb WG Last Call for comments for the WG document > >> named below: > >> > >> draft-ietf-ipdvb-ar-04.txt > >> http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > >> > >> This last call will end on 18th July 2006. > >> > >> The period of this last call has been extended because it also includes > >> the week of the IETF meeting. > >> > >> You are asked to read the draft and send any issues, comments, or > >> corrections to this mailing list. The WGLC procedure is the last chance > >> for this working group to modify/correct this. > >> > >> Please do forward any comments to the ipdvb list. > >> > >> Best wishes, > >> > >> Gorry Fairhurst > >> (ipdvb WG Chair) > >> > > > > From owner-ipdvb@erg.abdn.ac.uk Tue Jul 18 05:39:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2m3K-0007IS-TR for ipdvb-archive@ietf.org; Tue, 18 Jul 2006 05:39:42 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2m3K-0002At-H3 for ipdvb-archive@ietf.org; Tue, 18 Jul 2006 05:39:42 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6I9LDqK018575 for ; Tue, 18 Jul 2006 10:21:13 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6I9LCc8018574 for ipdvb-subscribed-users; Tue, 18 Jul 2006 10:21:12 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6I9L6UB018559 for ; Tue, 18 Jul 2006 10:21:06 +0100 (BST) Message-ID: <44BCA802.6030409@erg.abdn.ac.uk> Date: Tue, 18 Jul 2006 10:21:06 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 As WG Chair: draft-ietf-ipdvb-ar-04.txt http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ The WGLC for the above ID is due to end. Please ensure that you send an email to the ipdvb list if there are ANY issues which you think may require further discussion or any comments/corrections. It would also be most useful to email, if you have read the document and have no comments (or just minor corrections). Gorry Fairhurst (IPDVB WG CHAIR) From owner-ipdvb@erg.abdn.ac.uk Tue Jul 18 05:59:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2mMR-0007Zi-Pu for ipdvb-archive@ietf.org; Tue, 18 Jul 2006 05:59:27 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2mMQ-0002wF-CP for ipdvb-archive@ietf.org; Tue, 18 Jul 2006 05:59:27 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6I9mPFQ020672 for ; Tue, 18 Jul 2006 10:48:25 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6I9mPhY020671 for ipdvb-subscribed-users; Tue, 18 Jul 2006 10:48:25 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6I9mJ9X020656 for ; Tue, 18 Jul 2006 10:48:19 +0100 (BST) Message-ID: <44BCAE63.3050102@erg.abdn.ac.uk> Date: Tue, 18 Jul 2006 10:48:19 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Updated text for draft-ietf-ipdvb-ar-04.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 After discussion with an author of [ID-ND-PROXY], the following changes are requested... In section 5.4, draft -04 says: "Equivalent methods could provide IPv6 AR. Procedures for intercepting ND messages are defined in [ID-ND-PROXY]. To perform an AR Server function, the AR information must also be cached. Interactions with SEND are described in [ID-SP-ND]." 1) Add text following this on consistency issue: "The consistency of the cache also needs to be considered when the network topology changes (e.g. IP mobility) or there is intermittent connectivity. In these cases old (stale) information can result in IP packets being directed to an invalid L2 address. Methods also need to provided purge stale AR data from the cache." 2) Replace [ID-ND-PROXY] with citation to [RFC4389] Gorry Fairhurst (as Author) ipdvb From owner-ipdvb@erg.abdn.ac.uk Wed Jul 19 10:14:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CoL-0000zX-5U for ipdvb-archive@ietf.org; Wed, 19 Jul 2006 10:14:01 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3CoK-0005As-Cl for ipdvb-archive@ietf.org; Wed, 19 Jul 2006 10:14:01 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6JDfFgp028478 for ; Wed, 19 Jul 2006 14:41:15 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6JDfFgY028477 for ipdvb-subscribed-users; Wed, 19 Jul 2006 14:41:15 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6JDf7du028451; Wed, 19 Jul 2006 14:41:07 +0100 (BST) Message-ID: <44BE3674.60208@erg.abdn.ac.uk> Date: Wed, 19 Jul 2006 14:41:08 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rupert@ecotel.demon.co.uk CC: ipdvb@erg.abdn.ac.uk Subject: Re: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt References: <44BDFE2F.28009.16EE09F3@rupert.ecotel.demon.co.uk> In-Reply-To: <44BDFE2F.28009.16EE09F3@rupert.ecotel.demon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Thanks Rupert, That was very useful to have your comments. You spotted several thing athat I've now fixed in the new version of the document, which we'll submit next week, after any further comments. Detailed edits in-line. Gorry (as author) Rupert Goodings wrote: > Gorry and all, > > Sorry for late reply. Usual excuses apply(^2) ;-) > > As requested some comments on draft-ietf-ipdvb-ar-04.txt. > > > Generally I think the document is in good shape and provides > a useful introduction to the problems. My earlier major comments > about being clearer on the purpose of the document seem to have been > resolved. > > I have spotted a few editorial nits on rereading. Mostly minor (see below for > details) but I did notice several <> (suggesting more > inputs wanted) in Section 5. I think these can be deleted...but it does > suggest that a V05 would be useful mainly to clean up that section. > > best regards > > Rupert Goodings > Ecotel Ltd/ ETSI WG-BSM Chairman > > ==DETAILED EDITORIALS > > Section 2 and general > Sections 3 &4 use of "MAC Address" which is not defined in Section 2; in > preference to "NPA" which is defined. > Suggest adding MAC Address to Section 2 OK, defined this as: MAC Address: A 6 byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA). > Also suggest using "NPA/MAC Address" in sections 3 and 4. > To be consistent with RFC4326, NPA = ULA address indicated by the D-bit, whereas MAC means IEEE-style address. I've reworked the text to make this clearer. Also made all "NPA/MAC" into "MAC/NPA". Also note a mistake to section (iii) which was confusing about L2 multicast addressess, thsi now reads: " (iii) IP and other protocols may view sets of L3 multicast addresses as link-local. This may produce unexpected results if frames with the corresponding multicast L2 addresses are distributed to systems in a different L3 network or multicast scope (see sections 3.2 and 5.6)" > > Section 2&3 (nit) > All ULE to section 2 > Correct ULE longhand in section 3. > Can you explain which line this problem occurs in? > > Section 3: > (Nit+) The wording of the first requirement could be improved: > replace "A scalable and efficient transmission" > with two points: > "A scalable architecture" > "Efficient use of messages to minimise transmission overheads" > [assuming that is what you mean :-)] > Proposed new text: A scalable architecture that may support large numbers of systems within the MPEG-2 network [RFC4259]. A method for transmission of AR information from an AR Server to clients that minimise the transmission cost (link local multicast, is preferable to subnet broadcast). > > Section 3: > (Nit) Use "context/scope" terminology consistently. Reqs uses "scope"; > following para uses "context" [both words are OK for me]. > Done, scope now used in section 3. > Section 4.1.1; 3rd para > Is this para really discussing AR? The phrase "receive L2 information and > allocate an IP address" seems to be implying RAR instead? > Yes, I think the focus is DHCP as a method to populate the AR cache. > Some rewording may be needed. > [For info, ETSI BSM propose to avoid RAR in satellite context]. > DHCP is at least used in some cable systems and systems using UDLR. > > Section 4.2.4 > (nit) StrengthS /each has their strength/ > > Section 4.3. > Inconsistent use of language: > Title uses "resolution of TS Logical Channels" > body uses "address resolution for TS streams" OK, adjusted text. > [I prefer a hybrid "address resolution for TS Logical Channels"] > Agreed, changed title. > > Section 5: > I assume the <> lines will be deleted? > Also incomplete section xx reference. > I can not find these in rev -04, if you know where theyt are, let me know. > > Section 5.4. 2nd para > Might be better to add a few words as indicated by <<>> below > "follows normal practice for <> IEEE <<802>> > MAC Addresses. > Added: (mapping the IP address to the L2 address) > > ==END > > > Date sent: Tue, 18 Jul 2006 10:21:06 +0100 > From: Gorry Fairhurst > Organization: University of Aberdeen, UK > To: ipdvb@erg.abdn.ac.uk > Subject: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt > Send reply to: ipdvb@erg.abdn.ac.uk > > >>As WG Chair: >> >>draft-ietf-ipdvb-ar-04.txt >>http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ >> >>The WGLC for the above ID is due to end. Please ensure that you send an >>email to the ipdvb list if there are ANY issues which you think may >>require further discussion or any comments/corrections. >> >>It would also be most useful to email, if you have read the document and >>have no comments (or just minor corrections). >> >>Gorry Fairhurst >>(IPDVB WG CHAIR) >> >> >> >> >> >> >> >> > > > > > From owner-ipdvb@erg.abdn.ac.uk Tue Jul 25 04:09:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5HyO-000368-OI for ipdvb-archive@ietf.org; Tue, 25 Jul 2006 04:09:00 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5HyN-0000cN-6m for ipdvb-archive@ietf.org; Tue, 25 Jul 2006 04:09:00 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6P7nNaP014717 for ; Tue, 25 Jul 2006 08:49:23 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6P7nNe2014716 for ipdvb-subscribed-users; Tue, 25 Jul 2006 08:49:23 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6P7nE5n014692 for ; Tue, 25 Jul 2006 08:49:15 +0100 (BST) Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 65E701BAC4D for ; Tue, 25 Jul 2006 09:33:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <44A27543.3080504@erg.abdn.ac.uk> References: <44A27543.3080504@erg.abdn.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E832950-2E98-42DF-93DD-DA8D99A02299@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt Date: Tue, 25 Jul 2006 09:49:05 +0200 To: ipdvb@erg.abdn.ac.uk X-Mailer: Apple Mail (2.752.2) X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi all, The draft is fine with me. My comments from -03 have been fixed. Thanks Martin Am 28.06.2006 um 14:25 schrieb Gorry Fairhurst: > This note starts the ipdvb WG Last Call for comments for the WG > document > named below: > > draft-ietf-ipdvb-ar-04.txt > http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > > This last call will end on 18th July 2006. > > The period of this last call has been extended because it also > includes the week of the IETF meeting. > > You are asked to read the draft and send any issues, comments, or > corrections to this mailing list. The WGLC procedure is the last > chance for this working group to modify/correct this. > > Please do forward any comments to the ipdvb list. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue Jul 25 05:16:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5J1i-00048o-TU for ipdvb-archive@ietf.org; Tue, 25 Jul 2006 05:16:30 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5J1g-0000U8-DT for ipdvb-archive@ietf.org; Tue, 25 Jul 2006 05:16:30 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6P8qNaJ019950 for ; Tue, 25 Jul 2006 09:52:23 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k6P8qN1V019949 for ipdvb-subscribed-users; Tue, 25 Jul 2006 09:52:23 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6P8qFAk019929 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 25 Jul 2006 09:52:15 +0100 (BST) Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k6P8pEq8024015; Tue, 25 Jul 2006 09:51:14 +0100 (BST) Received: from bradford.ac.uk (thallium.cen.brad.ac.uk [143.53.238.78]) by radon.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k6P8pEwZ013029; Tue, 25 Jul 2006 09:51:14 +0100 (BST) Received: from d50201.inf.brad.ac.uk (d50201.inf.brad.ac.uk [143.53.20.37]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Tue, 25 Jul 2006 09:51:13 +0100 Message-ID: <1153817473.44c5db820007a@webmail6.brad.ac.uk> Date: Tue, 25 Jul 2006 09:51:14 +0100 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk, Gorry Fairhurst Subject: Re: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt In-Reply-To: <44BCA802.6030409@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.20.37 X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi, The document seems to be in good shape. It is fine with me. Regards Prashant Pillai Quoting Gorry Fairhurst : > > As WG Chair: > > draft-ietf-ipdvb-ar-04.txt > http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > > The WGLC for the above ID is due to end. Please ensure that you send an > email to the ipdvb list if there are ANY issues which you think may > require further discussion or any comments/corrections. > > It would also be most useful to email, if you have read the document and > have no comments (or just minor corrections). > > Gorry Fairhurst > (IPDVB WG CHAIR) > > > > > > > > > -- Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------