From owner-ip-dvb@erg.abdn.ac.uk Mon Jun 2 18:57:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h52HvCFL016715 for ; Mon, 2 Jun 2003 18:57:12 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h52HvBjo016713 for ip-dvb-subscribed-users; Mon, 2 Jun 2003 18:57:11 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from gateway.hns.com (gateway.hns.com [208.236.67.13]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h52HuoFM016701 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 2 Jun 2003 18:56:51 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by gateway.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h52HuleY007910 for ; Mon, 2 Jun 2003 13:56:48 -0400 (EDT) Received: from hns.com (altasun9.md.hnsnet [10.48.51.25]) by excore8.hns.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id h52HufCL020917 for ; Mon, 2 Jun 2003 13:56:41 -0400 (EDT) Message-ID: <3EDB8F6E.5256DF56@hns.com> Date: Mon, 02 Jun 2003 13:54:54 -0400 From: John Border X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re the encapsulation I-Ds... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-00.txt http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-01.txt A couple of comments which apply to both documents... ENH - Re Section 5.2, Last Paragraph In most cases, latency will be more important. But, in some cases, a trade-off for more efficiency might be desirable. So, how about having the encapsulator optionally support waiting N milliseconds for another SNDU, where N is configurable with a default value of 0? IMP - General As far as I can tell, there is no way a receiver can automatically detect which encapsulation method is being used by the encapsulator (between these two methods or between one of these methods and the DVB-S standard mechanism(s)). Therefore, I am assuming the receiver knows a priori via configuration (or some other means, independent from the encapsulation itself), probably associates with the PID being used. Of course, I may have just missed the subtleties which allow automatic detection of the method. My real point is that a sentence or two in the introductory material re how the receiver knows which encapsulation method is being used should be included in the documents. John Border Hughes Network Systems, Inc. From owner-ip-dvb@erg.abdn.ac.uk Mon Jun 9 17:26:05 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59GPUBk017487 for ; Mon, 9 Jun 2003 17:25:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h59GPUfe017486 for ip-dvb-subscribed-users; Mon, 9 Jun 2003 17:25:30 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59GP6Bk017472 for ; Mon, 9 Jun 2003 17:25:07 +0100 (BST) Message-ID: <3EE4B4E3.5B7679E5@erg.abdn.ac.uk> Date: Mon, 09 Jun 2003 17:25:08 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: "Flat Multicast Key Exchange (FMKE)"- Internet Draft References: <3ED74372.BA667A7D@eim.surrey.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thanks Haitham for your inputs! I was wondering whether anyone else had given thouughts as to whether there was a need for a specific key management protocol for MPEG-2 transmission? Various people have in the past commented on the current MPEG-2 encryption systems being inappropriate for IP data, but I don't see a clear consensus yet on exactly what needs to be fixed. Is this an Internet Protocol issue (e.g. IPSEC)? Is it a MPEG-2/DVB/ATSC issue? Please send comments and questions to this list. I'd like to get a feeling on how important this is to people, and what exactly people want to be done. Best wishes, Gorry Fairhurst > Laurence.Duquerroy@space.alcatel.fr wrote: > > > Hello, > > > > In the context of the SatIP6 IST project, Alcatel Space studies a multicast > > security scheme optimised to protect large multicast groups. Such a scheme is > > designed for IP over Satellite, Wifi or DVB systems; it is a security solution > > for the satellite segment. An implementation over DVB-S/RCS is planned in the > > SatIP6 demonstrator. > > We have presented this security solution (called SatIPSec) during the ESA > > workshop at ESTEC, 13-14 May on "IP networking over satellite". > > > > We have started to write an Internet Draft detailing our key exchange protocol > > (called "Flat Multicast Key Exchange (FMKE)"), and we think that it could be > > submitted to the "IP over DVB " group, as IP over DVB systems are targeted > > systems. We would be ready to present it to the next IETF meeting (in Vienna). > > As it is very security-oriented, it will probably also be submitted to an IETF > > security group (i.e. MSEC (Multicast Security) WG). > > > > You will find in attachment a draft of the ID. Your comments, opinion, and > > feedback on it are welcome. > > (See attached file: draft-duquer-fmke-00.doc) > > > > This solution is very flexible. It is able to configure any security dataplane > > at layer 2 or 3 ( IPv4/6 IPSec, L2 security dataplanes...). > > It is based on similar principles to the ones of the protocols currently defined > > in the IETF MSEC group. It uses also similar messages (based on the ISAKMP > > standard protocol). However it implements additional mechanisms and features in > > order to provide a security solution optimized for satellite systems: > > > > - It is defined to be low ressource consuming in bandwidth > > - It provides a reliable key distribution ( unlike the GDOI and GSAKMP > > protocols) > > - It can be used in one-to-many and many-to-many scenarios, and is > > scalable in these scenarios (MIKEY cannot be used in many-to-many scenarios in > > large groups) > > - It provides a multicast re-keying (mandatory in large groups) (unlike > > MIKEY) > > - etc > > > > We hope that you will find interest in it, and thank you in advance for your > > comments. > > > > Best regards, > > > > Laurence Duquerroy > > > > ALCATEL SPACE > > RT/ST > > Research Department / Advanced Telecom Satellite Systems > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > E-Mail : laurence.duquerroy@space.alcatel.fr > > > > ------------------------------------------------------------------------ > > Name: draft-duquer-fmke-00.doc > > draft-duquer-fmke-00.doc Type: WINWORD File (application/msword) > > Encoding: base64 > > Description: Mac Word 3.0 > > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in 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 owner-ip-dvb@erg.abdn.ac.uk Mon Jun 9 19:03:37 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59I3GBk018738 for ; Mon, 9 Jun 2003 19:03:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h59I3GKp018737 for ip-dvb-subscribed-users; Mon, 9 Jun 2003 19:03:16 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59I32Bk018725 for ; Mon, 9 Jun 2003 19:03:02 +0100 (BST) Message-ID: <3EE4CBD7.77D3586D@erg.abdn.ac.uk> Date: Mon, 09 Jun 2003 19:03:03 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Re the encapsulation I-Ds... References: <3EE4CA8D.910A959C@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Thanks John.... You could have mailed the list :-) John Border wrote: > > > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-00.txt > http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-01.txt > > A couple of comments which apply to both documents... > > ENH - Re Section 5.2, Last Paragraph > > In most cases, latency will be more important. But, in some cases, a > trade-off for more efficiency might be desirable. So, how about having the > encapsulator optionally support waiting N milliseconds for another SNDU, where > N is configurable with a default value of 0? > Yes, that seems OK. But does it *really* matter if N is some small value (e.g. value <30 ms or so ?). > IMP - General > > As far as I can tell, there is no way a receiver can automatically > detect which encapsulation method is being used by the encapsulator (between > these two methods or between one of these methods and the DVB-S standard > mechanism(s)). Therefore, I am assuming the receiver knows a priori via > configuration (or some other means, independent from the encapsulation > itself), probably associates with the PID being used. Of course, I may have > just missed the subtleties which allow automatic detection of the method. My > real point is that a sentence or two in the introductory material re how the > receiver knows which encapsulation method is being used should be included in > the documents. > I separated the two scehems to help the list think through things. Basically, the LE (draft-clausen-ipdvb-enc-01) scheme requires and uses the PES semantics for the MPEG-2 PUSI bit and requires the use of the MPEG-2 TS Adaption Field. This only happens for certain types of MPEG-2 Transport Streams. The ULE approach assumes you will not supply an Adaption Field, and that every time the PUSI is set, the first byte of the MPEG-2 TS Packet contains a 1 B pointer. I suggest if we need to differentiate the "modes" we could do that as a part of "address resolution" - i.e., when the receiver figures out the PID, it should also associate the PID with MPE, LE, or ULE! (or whatever subset survives the next round of debate). Gorry > John Border > Hughes Network Systems, Inc.. From owner-ip-dvb@erg.abdn.ac.uk Mon Jun 9 19:16:59 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59IGdBk018924 for ; Mon, 9 Jun 2003 19:16:39 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h59IGdmO018923 for ip-dvb-subscribed-users; Mon, 9 Jun 2003 19:16:39 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59IGPBk018908 for ; Mon, 9 Jun 2003 19:16:25 +0100 (BST) Message-ID: <3EE4CEFA.2510847E@erg.abdn.ac.uk> Date: Mon, 09 Jun 2003 19:16:26 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-fair-ipdvb-req-03.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for transmission of IP datagrams over MPEG-2 networks Author(s) : G. Fairhurst et al. Filename : draft-fair-ipdvb-req-03.txt Pages : 28 Date : 2003-6-6 This document contains requirements for a framework for transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. Examples include the Digital Video Broadcast (DVB), specified by standards published by the European Telecommunications Standards Institute (ETSI) and the ATSC Digital Television Standard specified by the Advanced Television Systems Committee (ATSC). It identifies the need for the definition of a set of network protocols to standardise the interface between the MPEG-2 Transport Stream and an IP subnetwork. It also suggests an optimised encapsulation method for IP datagrams. The requirements for these functions are described, and a framework proposed for their implementation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fair-ipdvb-req-03.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@ietf.org. In the body type: "FILE /internet-drafts/draft-fair-ipdvb-req-03.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. From owner-ip-dvb@erg.abdn.ac.uk Mon Jun 9 19:17:33 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59IHEBk018948 for ; Mon, 9 Jun 2003 19:17:14 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h59IHEOW018947 for ip-dvb-subscribed-users; Mon, 9 Jun 2003 19:17:14 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h59IGuBk018931 for ; Mon, 9 Jun 2003 19:16:56 +0100 (BST) Message-ID: <3EE4CF19.64E908AE@erg.abdn.ac.uk> Date: Mon, 09 Jun 2003 19:16:57 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 2003) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk NOTE: There are two (2) Internet-Draft Cutoff dates June 23rd: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, June 23rd, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, June 16th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of June 23rd will NOT be accepted. June 30st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, June 30st, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html From owner-ip-dvb@erg.abdn.ac.uk Tue Jun 10 06:34:27 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5A5YAvb026407 for ; Tue, 10 Jun 2003 06:34:10 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5A5YAEk026406 for ip-dvb-subscribed-users; Tue, 10 Jun 2003 06:34:10 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from olympos (star-100.rt.net.tr [212.65.137.100] (may be forged)) by erg.abdn.ac.uk (8.12.9/8.12.9) with SMTP id h5A5X1vb026387 for ; Tue, 10 Jun 2003 06:33:36 +0100 (BST) Subject: Re: Re the encapsulation I-Ds... To: ip-dvb@erg.abdn.ac.uk X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: OZGUR.AKSU@startv.com.tr Date: Tue, 10 Jun 2003 08:32:48 +0300 X-MIMETrack: Serialize by Router on TELEON/INTERSTAR(Release 5.0.3 (Intl)|21 March 2000) at 06/10/2003 08:32:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hello , I have been following you for a long time , I am prepairing a master thesis , but one point I could not understand that why we need to encapsulate IP packets with MPEG format, what are the advantages of doing that ? Is it also possible to transmit data in IP format via satellite , at this time, what types of problems we would encounter ? Thank you. Ozgur AKSU From owner-ip-dvb@erg.abdn.ac.uk Tue Jun 10 08:11:49 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5A7BVvb027372 for ; Tue, 10 Jun 2003 08:11:31 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5A7BUs1027371 for ip-dvb-subscribed-users; Tue, 10 Jun 2003 08:11:30 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from cpt077.canal-plus.fr (cpt077.canal-plus.fr [194.2.208.77]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5A7BAvb027357 for ; Tue, 10 Jun 2003 08:11:10 +0100 (BST) Received: from antivirus-gw.ctechno.net (servap08 [192.168.240.200]) by cpt077.canal-plus.fr (8.12.9/8.12.9) with ESMTP id h5A7B2fN026391 for ; Tue, 10 Jun 2003 09:11:03 +0200 (MEST) Content-Class: urn:content-classes:message Received: from mail2.ctechno.net ([192.168.253.29]) by antivirus-gw.ctechno.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Jun 2003 09:11:01 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Received: from intranet.canal-plus.fr ([172.20.11.68]) by mail2.ctechno.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 10 Jun 2003 09:11:01 +0200 Received: from canal-plus.fr ([192.168.243.239]) by intranet.canal-plus.fr (8.11.1/8.11.1) with ESMTP id h5A7B1x14759 for ; Tue, 10 Jun 2003 09:11:01 +0200 (MET DST) Message-ID: <3EE584AA.28F64CD3@canal-plus.fr> Date: Tue, 10 Jun 2003 09:11:38 +0200 From: "Bertrand WENDLING" Organization: CANAL+ Technologies X-Mailer: Mozilla 4.7 [en]C-CCK-MCD C+ (Win98; I) X-Accept-Language: fr,en MIME-Version: 1.0 To: Subject: Re: Re the encapsulation I-Ds... References: Content-Type: multipart/mixed; boundary="------------243D7499ACC1CB3A4580A953" X-OriginalArrivalTime: 10 Jun 2003 07:11:01.0431 (UTC) FILETIME=[72E07470:01C32F1F] X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------243D7499ACC1CB3A4580A953 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IP is not a transport protocol, MPEG yes, but you are free to use any = other transport format. The other reason is that millions of receiver are able = to receive data (video, audio, encapsulated data of various format) in MPEG format. Creating a new format would result in having to start from zero receiver to launch the service.... OZGUR.AKSU@startv.com.tr wrote: > Hello , > > I have been following you for a long time , I am prepairing a master > thesis , but one point I could not understand that why we need to > encapsulate IP packets with MPEG format, what are the advantages of = doing > that ? Is it also possible to transmit data in IP format via satellite = , at > this time, what types of problems we would encounter ? > > Thank you. > > Ozgur AKSU -- This message and any attachments (the "message") is intended solely for = the addressees and is confidential. If you receive this message in error, = please delete it and immediately notify the sender. Any use not in accordance with its purpose, any dissemination or = disclosure, either whole or partial, is prohibited except formal approval. The E-Mail transmission can not guarantee the integrity of this message. CANAL+TECHNOLOGIES will not therefore be liable for the message if = modified. --------------243D7499ACC1CB3A4580A953 Content-Type: text/x-vcard; charset="us-ascii"; name="wendling.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Bertrand WENDLING Content-Disposition: attachment; filename="wendling.vcf" begin:vcard n:Bertrand;WENDLING tel;cell:+33 6 03 45 86 54 tel;fax:+33 1 71 71 50 51 tel;work:+33 1 71 71 53 57 x-mozilla-html:TRUE url:www.canalplus-technologies.com org:CANAL+ Technologies;Advanced Project Department adr:;;34 place Raoul Dautry;75906 PARIS Cedex 15;;;France version:2.1 email;internet:wendling@canal-plus.fr title:Standards Officer fn:WENDLING Bertrand end:vcard --------------243D7499ACC1CB3A4580A953-- From owner-ip-dvb@erg.abdn.ac.uk Wed Jun 11 00:02:35 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5AN2Ivb011206 for ; Wed, 11 Jun 2003 00:02:18 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5AN2Hrn011205 for ip-dvb-subscribed-users; Wed, 11 Jun 2003 00:02:18 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from bonnie.ses-astra.com (bonnie.ses-astra.com [194.154.219.59]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5AN1mvb011185 for ; Wed, 11 Jun 2003 00:01:48 +0100 (BST) Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by bonnie.ses-astra.com (8.12.9/8.12.9) with ESMTP id h5AN1ilE002208 for ; Wed, 11 Jun 2003 01:01:44 +0200 (MET DST) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ip-dvb@erg.abdn.ac.uk Message-ID: Date: Wed, 11 Jun 2003 01:01:43 +0200 X-MIMETrack: Serialize by Router on marge/BTZ(Release 5.0.12 |February 13, 2003) at 11/06/2003 01:01:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk I will be out of the office starting 06/07/2003 and will not return until 06/12/2003. If required, I will respond to your message when I return. Best Regards, Joel Grotz -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. From owner-ip-dvb@erg.abdn.ac.uk Wed Jun 11 22:53:45 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5BLrOvb028234 for ; Wed, 11 Jun 2003 22:53:24 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5BLrOLL028233 for ip-dvb-subscribed-users; Wed, 11 Jun 2003 22:53:24 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [192.80.55.70]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5BLqpvb028216 for ; Wed, 11 Jun 2003 22:52:52 +0100 (BST) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.12.9/8.12.8) with ESMTP id h5BLqqAu017280 for ; Wed, 11 Jun 2003 17:52:52 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv2.mitre.org (8.12.9/8.12.8) with ESMTP id h5BLqswd007723 for ; Wed, 11 Jun 2003 17:52:55 -0400 (EDT) Received: from m07387-pc.mitre.org (128.29.25.72) by mailhub1.mitre.org with SMTP id 2973513; Wed, 11 Jun 2003 17:52:47 -0400 Message-ID: <3EE7A4AE.4F169193@mitre.org> Date: Wed, 11 Jun 2003 17:52:46 -0400 From: Richard Gibbons Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Re the encapsulation I-Ds... References: <3EE584AA.28F64CD3@canal-plus.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk The question is a good one. While IP is at layer 3 there is a HDLC router output that provides Sync Serial IP frames that could directly interface with a Modem. NASA's Space Network currently uses HDLC as the underlying satellite transport. ATM is also possible as the basic underlying satellite transport. The comparision between HDLC, DVB and ATM for satellite transport is not obvious in spite of the mass produced DVB IRDs. Richard Gibbons Bertrand WENDLING wrote: > > IP is not a transport protocol, MPEG yes, but you are free to use any other > transport format. The other reason is that millions of receiver are able to > receive data (video, audio, encapsulated data of various format) in MPEG > format. Creating a new format would result in having to start from zero > receiver to launch the service.... > > OZGUR.AKSU@startv.com.tr wrote: > > > Hello , > > > > I have been following you for a long time , I am prepairing a master > > thesis , but one point I could not understand that why we need to > > encapsulate IP packets with MPEG format, what are the advantages of doing > > that ? Is it also possible to transmit data in IP format via satellite , at > > this time, what types of problems we would encounter ? > > > > Thank you. > > > > Ozgur AKSU > > -- > This message and any attachments (the "message") is intended solely for the > addressees and is confidential. If you receive this message in error, please > delete it and immediately notify the sender. > Any use not in accordance with its purpose, any dissemination or disclosure, > either whole or partial, is prohibited except formal approval. > The E-Mail transmission can not guarantee the integrity of this message. > CANAL+TECHNOLOGIES will not therefore be liable for the message if modified. From owner-ip-dvb@erg.abdn.ac.uk Thu Jun 12 11:41:19 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5CAeZvb006784 for ; Thu, 12 Jun 2003 11:40:35 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5CAeZTW006783 for ip-dvb-subscribed-users; Thu, 12 Jun 2003 11:40:35 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5CAeEvb006765 for ; Thu, 12 Jun 2003 11:40:14 +0100 (BST) Message-ID: <3EE8588F.DFE13C6F@erg.abdn.ac.uk> Date: Thu, 12 Jun 2003 11:40:14 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Re the encapsulation I-Ds... References: <3EE584AA.28F64CD3@canal-plus.fr> <3EE7A4AE.4F169193@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Richard Gibbons wrote: > > The question is a good one. While IP is at layer 3 there is a HDLC > router output that provides Sync Serial IP frames that could directly > interface with a Modem. NASA's Space Network currently uses HDLC as the > underlying satellite transport. ATM is also possible as the basic > underlying satellite transport. The comparision between HDLC, DVB and > ATM for satellite transport is not obvious in spite of the mass produced > DVB IRDs. HDLC/PPP, ATM, SONET/SDH, MPEG-2/DVB/ATSC all provide ways of moving IP packets between interfaces ona router or end-host. That is they are all at L2. I'll follow the HDLC thread... HDLC/PPP uses flag bytes/sequences to delimit the edges of frames. In MPEG-2 transmission is synchronous, and each MPEG-2 TS frame (confusingly known as a TS Packet) contains a SYNC byte at the start in the header. The synchonisation has similarities to ATM. HDLC provides link addressing (if you want it, in the first byte). This is used by SDLC, NRM, LAP-D, etc. It identifies a level 2 flow to a particular destination (or group of destination addresses). MPEG-2 has a similar concept in the PID field which identifies a flow, flows can be (and often are) point-to-multipoint. A receiver can use a PID to slect an appropriate flow that it wishes to receive. Unlike ATM and HDLC, a wide cariety of commercial off-the-sheld components are available using MPEG-2 that combine both the physical radio / "modem" interface with this link level interface in the same board/box. The "DVB", "ATSC", etc standards add the physical layer to the MPEG-2 link layer. draft-fair-ipdvb-req-03.txt gives more details on how this relates to IP. Gorry > > Richard Gibbons > > Bertrand WENDLING wrote: > > > > IP is not a transport protocol, MPEG yes, but you are free to use any other > > transport format. The other reason is that millions of receiver are able to > > receive data (video, audio, encapsulated data of various format) in MPEG > > format. Creating a new format would result in having to start from zero > > receiver to launch the service.... > > > > OZGUR.AKSU@startv.com.tr wrote: > > > > > Hello , > > > > > > I have been following you for a long time , I am prepairing a master > > > thesis , but one point I could not understand that why we need to > > > encapsulate IP packets with MPEG format, what are the advantages of doing > > > that ? Is it also possible to transmit data in IP format via satellite , at > > > this time, what types of problems we would encounter ? > > > > > > Thank you. > > > > > > Ozgur AKSU > > > > -- > > This message and any attachments (the "message") is intended solely for the > > addressees and is confidential. If you receive this message in error, please > > delete it and immediately notify the sender. > > Any use not in accordance with its purpose, any dissemination or disclosure, > > either whole or partial, is prohibited except formal approval. > > The E-Mail transmission can not guarantee the integrity of this message. > > CANAL+TECHNOLOGIES will not therefore be liable for the message if modified. From owner-ip-dvb@erg.abdn.ac.uk Mon Jun 16 09:58:01 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5G8vhb1011936 for ; Mon, 16 Jun 2003 09:57:43 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5G8vgl1011935 for ip-dvb-subscribed-users; Mon, 16 Jun 2003 09:57:42 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5G8vLb1011922 for ; Mon, 16 Jun 2003 09:57:21 +0100 (BST) Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h5G8uTvu027400 for ; Mon, 16 Jun 2003 10:57:16 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D47.0030DC9C ; Mon, 16 Jun 2003 10:53:42 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: ip-dvb@erg.abdn.ac.uk cc: Sebastien.Josset@space.alcatel.fr, Isabelle.Buret@space.alcatel.fr, Stephane.Combes@space.alcatel.fr Message-ID: Date: Mon, 16 Jun 2003 10:54:28 +0200 Subject: =?iso-8859-1?Q?R=E9f._:_Re:_"Flat_Multicast_Key_Exchange_(FMKE)"-?= =?iso-8859-1?Q?_Internet_Draft?= Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new X-MailScanner: Found to be clean, Found to be clean X-MailScanner-SpamScore: s Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Dear Haitham, Thank you very much for your comments. They will help me to improve the draft. Please find in the following the answers to your questions. >Dear Laurence >Sorry for the delay in my reply. I read your proposed Internet Draft "Flat >Multicast Key Exchange (FMKE)" and I have the following comments: >1. Fundamental question: I remember your presentation at the ESTEC workshop "IP >networking over satellites" few weeks ago. I remember that you said that this >solution will be implemented in the link level (for example DVB-S link level). >That is something is not clear in my mind yet, because your proposal is IPSEC >based. In this solution, the control plane (i.e. the Flat Multicast Key Exchange) and the dataplane (functions encrypting and authenticating data) are separated. FMKE is indeed implemented in the layer 3 over IP, as it is based on ISAKMP, like IKE. In fact, this is the dataplane which can be implemented at link level (or in layer 3). My presentation at the ESTEC workshop dealed with a security dataplane implemented into the IP dedicated protocol. However, we envisage to define a security solution (control plane + dataplane) fully implemented at the link level, based on the DVB-RCS security messages (probably by re-using some of them and adding some messages based on the FMKE ones). > One more point, your Internet draft does not mention satellites. May be you can > clarify this. The draft is indeed very general. The objective of this security solution is to secure the satellite segment.The FMKE mechanims are implemented at the satellite terminal level. We can consider them as a module, which may be directly implemented inside the stack of each satellite terminal, or may be implemented in a separate box, located behind each ST. In the ID, a group member is therefore a satellite terminal (or the box behind), and the GCKS a server implemented for instance in a gateway. All FMKE messages are therefore exchanged on satellite links. This solution is able to establish in an optimized manner secure communication groups in Star and mesh architectures >By the way, ALCATEL ASP has a project with ESA on DVB-RCS security for >multicast and also University of Surrey and ALCATEL ASP have some documentation in >the GEOCAST project on how to modify DVB-RCS current security to cater for >multicast. The project that ALCATEL ASP has on DVB-RCS security, and security documentation of the GEOCAST project, define security mechanisms for star architectures. Some security features are missing to use them in MESH topology. With FMKE, we look at a more long-term solution, which would provide an optimized security in STAR systems and in MESH systems (for one-to-many and many-to-many communications). Moreover, we define some supplementary and useful mechanisms (like multicast configuration and re-keying ...) >2. As I understand that you will present your draft at the MSEC group at the IETF >meeting in Vienna. Your proposal looks fairly similar to The Group Domain of >Interpretation (GDOI) and latest draft is draft-ietf-msec-gdoi-08.txt (see: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-08.txt), which is well >established and going to be an RFC soon. Your work is duplicating GDOI and adding >phase 3 which does not exist in GDOI. In fact, GDOI has flat key and LKH (tree >architecture) distribution mechanisms. Can you clarify the differences between > FMKE and GDOI. FMKE and GDOI are based on similar principles. Both are based on a centralized management achieved by the GCKS, on 3 different exchanges or phases which have similar objectives, on similar security levels, on similar key system (KEKs and TEKs, and we intend to use LKH ). However FMKE is designed to provide a solution more adapted to our context. * First of all, the main difference between the GDOI "Group Key pull" exchange and the FMKE phase 2 concerns the initiator of the exchange. In GDOI, the phase is initiated by the potential Group Member (GM), and in FMKE by the GCKS. In the GDOI "Group key pull" exchange, the GM has to initiate the exchange in order to request the access to a particular group. It receives the SAs associated to this group if it is authorized. This exchange is realised several times, each time the GM decides to join another group. As the initiator is the GM, checking its liveliness is required. Indeed, as this exchange can be realised several times , a replay attack can easily be launched. This requirement implies that the exchange is composed of 4 messages ( the 3rd msg allows to prove the GM liveliness, and in the 4th message the group keys are transmitted). In FMKE the exchange is initiated by the GCKS. It transmits during this exchange all the SAs the member is authorized to get access to, belonging to one or several groups. The Client just has to send periodically acknowledgement messages in response. This phase is launched once; at the end of the first phase. Moreover,as only one phase 2 is realised and is initiated by the GCKS, verifying the client liveliness is not needed ( does not require the messages used in the Group key push) Therefore FMKE phase 2 is less resource consuming than GDOI "Group Key push", as it requires less messages for an equal number of SAs to transmit (for one group , GDOI requires 4 messages , whereas in FMKE the GCKS sends a message with the SAs, and waits for a periodic acknowledgement of the GM) * GDOI requires that group members know specific information and own specific functionality to be able to request the SAs of the groups they wish to join. On the contrary, in FMKE, they receive directly all the SAs they are authorized to get access to, belonging to one or several groups, without having to send a request. With the attributes contain in the SA payloads, they know which traffic flows they have to protect (for instance identified by a multicast destination address, a layer 2 label, a PID) . In the context considered by FMKE, satellite terminals have to protect traffic that they do not generate themselves. So they know very few information about it. Thus, it seems more adapted that they receive directly the data security configurations for the traffic they have to protect, instead of requesting them. * GDOI exchanges ("Group Key Pull" and "Group Key Push") are not reliable. Nothing guarantees that the GM(s) has(have) received the group keys transmitted by the GCKS. On the contrary, in FMKE, during the phase 2, each message from the GCKS has to be acknowledged by the GM, and is retransmitted if it is not acknowledged. In the phase 3, GMs can request the non received messages (this mechanism is optimized in order to avoid the congestion at the GCKS) >3. In section 8 (security consideration), you should state the remaining or >potential problems with your protocol. One example is Denial of Service (DoS) >attacks, where you should state how your protocol and your security server can >cope with thousands of forged messages coming from false IP addresses. One >common practice is to use stateless COOKIES in order to minimize the memory >and CPU burden on the security server which is experiencing the DoS attack >(for more details see: >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-07.txt). Thank you, I am going to check the remaining attacks and add the necessary information >Please consider these as constructive comments and I hope they will improve your >draft. >Regards >Haitham Best regards, Laurence Duquerroy ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr From owner-ip-dvb@erg.abdn.ac.uk Fri Jun 20 09:57:57 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5K8vehA006222 for ; Fri, 20 Jun 2003 09:57:40 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5K8veDK006221 for ip-dvb-subscribed-users; Fri, 20 Jun 2003 09:57:40 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.26] (maxp31.abdn.ac.uk [139.133.7.190]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5K8vKhA006202 for ; Fri, 20 Jun 2003 09:57:22 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 20 Jun 2003 10:00:52 +0100 Subject: Revised IP over mpeg-2/DVB charter From: gorry To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk A revised charter has been uploaded to the ip-dvb server at: http://www.erg.abdn.ac.uk/ip-dvb/charter.html Please do send corrections to me and comments to the ip-dvb list. Best wishes, Gorry P.S. The index page has also been updated (long overdue!) at: http://www.erg.abdn.ac.uk/ip-dvb/index.html From owner-ip-dvb@erg.abdn.ac.uk Fri Jun 20 16:59:24 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KFx4hA013266 for ; Fri, 20 Jun 2003 16:59:05 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5KFx4JD013265 for ip-dvb-subscribed-users; Fri, 20 Jun 2003 16:59:04 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from neko.cts.com (neko.cts.com [209.68.192.150]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KFwihA013252 for ; Fri, 20 Jun 2003 16:58:45 +0100 (BST) Received: from miked.tbt.com (vsat-148-63-99-97.c002.t7.mrt.starband.net [148.63.99.97]) by neko.cts.com (8.9.3p2/8.9.3) with ESMTP id IAA05646 for ; Fri, 20 Jun 2003 08:58:37 -0700 (PDT) Message-Id: <5.2.0.9.2.20030620084407.045eb470@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 20 Jun 2003 08:58:23 -0700 To: ip-dvb@erg.abdn.ac.uk From: "Michael A. Dolan" Subject: Re: Revised IP over mpeg-2/DVB charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi- I just joined this list, so am coming at this work entirely out of context. But I wanted to understand the scope and requirements as it moves to an IETF WG. Thanks in advance for your indulgence.... 1. The proposed working group name is "IP over DVB", yet the charter says it is intended for any MPEG-2 transport stream. Is it the intent of this group to develop documents relating to non-DVB transports (ATSC, ARIB, video servers, and others)? 2. The second paragraph says, "There is therefore a need to define an efficient standardised encapsulation for IPv4 and IPv6 datagrams...". This statement seems to presume that the ISO MPEG 13818-6 Amendment #1 (and the related ETSI 301192 and ATSC A/90 and ATSC A/92) that everyone uses today are somehow unsuitable for some reason. I think it would be helpful to add something between these paragraphs that supports the need for the development of a new encapsulation. Alternatively, one could soften the "therefore there is a need" to something like "investigate and recommend". Regards, Mike At 10:00 AM 6/20/2003 +0100, gorry wrote: >A revised charter has been uploaded to the ip-dvb server at: >http://www.erg.abdn.ac.uk/ip-dvb/charter.html > >Please do send corrections to me and comments to the ip-dvb list. > >Best wishes, > >Gorry > >P.S. The index page has also been updated (long overdue!) at: >http://www.erg.abdn.ac.uk/ip-dvb/index.html ----------------------------------------------------- Michael A. Dolan, President Television Broadcast Technology, Inc. (TBT) PO Box 1673 Alpine, CA 91903 USA 619-445-9070 FAX: 208-545-6564 URL:http://www.tbt.com From owner-ip-dvb@erg.abdn.ac.uk Fri Jun 20 18:25:36 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KHPIhA014445 for ; Fri, 20 Jun 2003 18:25:18 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5KHPHHo014444 for ip-dvb-subscribed-users; Fri, 20 Jun 2003 18:25:18 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from isis-08 (proqos.cosy.sbg.ac.at [141.201.2.218]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KHOuhA014428 for ; Fri, 20 Jun 2003 18:24:57 +0100 (BST) Received: from milbe ([141.201.2.21]) by isis-08 with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Jun 2003 19:24:57 +0200 From: "Bernhard Collini-Nocker" To: Subject: RE: Revised IP over mpeg-2/DVB charter Date: Fri, 20 Jun 2003 19:24:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.2.20030620084407.045eb470@cts.com> X-OriginalArrivalTime: 20 Jun 2003 17:24:57.0854 (UTC) FILETIME=[DF3A09E0:01C33750] X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi, ad 1. The name "IP Over DVB" is somehow historically and is clarified in draft-unisal-ipdvb-encaps-xxx (and also draft-fair-ipdvb-ule-xx): ------------------------ snip -------------------- This document describes an encapsulation for transport of IP datagrams or other network layer packets over ISO MPEG-2 Transport Streams [ISO-MPEG]. This is suited to services based on MPEG-2, for example the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC; ATSC-G], and other similar MPEG-2 based transmission systems. Such systems typically provide unidirectional (simplex) physical and link layer standards, and have been defined for a wide range of physical media (e.g. Terrestrial TV [ETSI-DVBT; ATSC-PSIP-TC], Satellite TV [ETSI-DVBS; ATSC-S],Cable Transmission [ETSI-DVBC; ATSC-PSIP-TC]). Bi-directional (duplex) links may also be established using these standards (e.g., DVB defines a range of return channel technologies, including the use of two-way satellite links [ETSI-RCS] and dial-up modem links [RFC3077]). ------------------------ snip -------------------- ad 2. We have tried to motivate the reason for the need of a lighter encapsulation in draft-fair-ipdvb-req-xxx in section 5: ------------------------ snip -------------------- 5. Motivation for a Lightwight Protocol Encapsulation To transmit packet data over an MPEG-2 transmission network requires that individual SNDUs (e.g. IPv4, IPv6 packets, or bridged Ethernet Frames) are encapsulated using a convergence protocol. The following encapsulations are currently standardised for MPEG-2 transmission networks: (i) Multi-Protocol Encapsulation (MPE). The Multi-Protocol Encapsulation, MPE, specification of DVB [ETSI-DAT] uses private Sections for the transport of IP packets and uses encapsulation that is similar to the IEEE LAN/MAN standards [LLC]. Data packets are encapsulated in datagram sections that are compliant with the DSMCC section format for private data. One advantage of this is that some receivers may exploit section-processing hardware to perform a first-level filter of the packets that arrive at the receiver. The section header also includes fields, which may be used by a receiver to filter datagrams assigned to the same TS logical channel. This feature allows several logical networks to be established without assigning PID values to each of the services. Section filtering is especially well suited for TV broadcast environments where remultiplexing comes into play. This encapsulation makes use of a MAC-level network point of attachment address. The address format conforms to the ISO/IEEE standards for LAN/MAN LLC]. The 48-bit MAC address field contains the MAC address of the destination; it is distributed over six 8-bit fields, labeled MAC_address_1 to MAC_address_6. The MAC_address_1 field contains the most significant byte of the MAC address, while MAC_address_6 contains the least significant byte. How many of these bytes are significant is optional and defined by the value of the broadcast descriptor table [SI-DAT] sent separately over another MPEG-2 TS within the TS multiplex. MPE is currently the most widely used scheme. Due to investments in existing equipment, usage is likely to continue in some applications in current and future networks. (ii) Data Piping. The DVB Data Piping profile [ETSI-DAT] is a minimum overhead, simple and flexible profile that makes no assumptions concerning the format of the data being sent. In this profile, the MPEG-2 receiver is intended to provide PID filtering, packet reassembly according to [DVB-SIDAT-368], error detection and optionally CA support. The specification allows the user data stream to be unstructured or organized into packets. The specific structure is transparent to the receiver. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc. (iii) Data Streaming. The data broadcast specification profile [ETSI-DAT] for PES tunnels (Data Streaming) supports unicast and multicast data services that require a stream-oriented delivery of data packets. This encapsulation maps an IP packet into a single PES Packet payload Data Streaming is intended to handle a single stream of data at a high data rate using standard demultiplexing ICs (e.g. developed for STBs) that have been designed for handling video streams. Transporting data packets using the PES level offers the benefits of PES layer functions integrated into the chip sets, e.g. handling of program specific information (tables), scrambling and synchronization with other TS. The standard PES Packet as defined in table 2-18 of [ISO-MPEG] can also be used as a container for data packets. The two values for the stream_id are "private_stream_1" and "private_stream_2". The private_stream_2 permits the use of the short PES header with limited overhead. This makes it attractive for publicly accessible multicast distribution services. The private_stream_1 makes available the scrambling control and the timing and clock reference features of the PES layer. The PES_data_packet_header_length will be used in this context to insert stuffing bytes. This is an important aspect since the payload can be aligned to 32-bit word boundaries. When the data_identifier field is used in conjunction with the first 4 bits of the sub_stream_id field it forms a 12 bit field. This carries a descriptor of the next level protocol. The list of protocol codes will be managed by [EUTELSAT], and the values of the part stored into the data_identifier field will be in the range 0x80-0xFF (assigned by DVB as user defined). The remaining 4 bits of the sub_stream_id field are used for storing the current version of the encapsulation format. Some or all of these proposals have been implemented and are used in current systems. ------------------------ snip -------------------- Best regards, Bernhard > -----Original Message----- > From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On > Behalf Of Michael A. Dolan > Sent: Freitag, 20. Juni 2003 17:58 > To: ip-dvb@erg.abdn.ac.uk > Subject: Re: Revised IP over mpeg-2/DVB charter > > > Hi- > > I just joined this list, so am coming at this work entirely out of > context. But I wanted to understand the scope and requirements > as it moves > to an IETF WG. Thanks in advance for your indulgence.... > > 1. The proposed working group name is "IP over DVB", yet the charter says > it is intended for any MPEG-2 transport stream. Is it the intent of this > group to develop documents relating to non-DVB transports (ATSC, ARIB, > video servers, and others)? > > 2. The second paragraph says, "There is therefore a need to define an > efficient standardised encapsulation for IPv4 and IPv6 > datagrams...". This > statement seems to presume that the ISO MPEG 13818-6 Amendment #1 > (and the > related ETSI 301192 and ATSC A/90 and ATSC A/92) that everyone uses today > are somehow unsuitable for some reason. I think it would be > helpful to add > something between these paragraphs that supports the need for the > development of a new encapsulation. Alternatively, one could soften the > "therefore there is a need" to something like "investigate and recommend". > > Regards, > > Mike > > > At 10:00 AM 6/20/2003 +0100, gorry wrote: > > >A revised charter has been uploaded to the ip-dvb server at: > >http://www.erg.abdn.ac.uk/ip-dvb/charter.html > > > >Please do send corrections to me and comments to the ip-dvb list. > > > >Best wishes, > > > >Gorry > > > >P.S. The index page has also been updated (long overdue!) at: > >http://www.erg.abdn.ac.uk/ip-dvb/index.html > > ----------------------------------------------------- > Michael A. Dolan, President > Television Broadcast Technology, Inc. (TBT) > PO Box 1673 Alpine, CA 91903 USA > 619-445-9070 FAX: 208-545-6564 > URL:http://www.tbt.com > From owner-ip-dvb@erg.abdn.ac.uk Fri Jun 20 18:34:37 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KHXghA014591 for ; Fri, 20 Jun 2003 18:33:42 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5KHXgDZ014590 for ip-dvb-subscribed-users; Fri, 20 Jun 2003 18:33:42 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KHXIhA014573 for ; Fri, 20 Jun 2003 18:33:18 +0100 (BST) Message-ID: <3EF34561.C6DB7D41@erg.abdn.ac.uk> Date: Fri, 20 Jun 2003 18:33:21 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Revised IP over mpeg-2/DVB charter References: <5.2.0.9.2.20030620084407.045eb470@cts.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Nice to hear from you, see below. "Michael A. Dolan" wrote: > > Hi- > > I just joined this list, so am coming at this work entirely out of > context. But I wanted to understand the scope and requirements as it moves > to an IETF WG. Well, to be technically correct, we are asking the IETF to consider the work. The BOF is a chance to exchange ideas, get feedback, set goals, and talk. It also helps the IESG work out how to support the work. A BOF doesn't imply an IETF WG will happen, and anyway a WG isn't needed neccessarily to do work. What is needed, is to understand the problem and to get IESG Review/approval for the work. We seem to be progressing. > Thanks in advance for your indulgence.... > > 1. The proposed working group name is "IP over DVB", yet the charter says > it is intended for any MPEG-2 transport stream. Is it the intent of this > group to develop documents relating to non-DVB transports (ATSC, ARIB, > video servers, and others)? > YES, please *DO* take this to mean DVB, DAB, ATSC, ARIB, whatever. The word "DVB" in the title really is a mixed blessing. On the one hand, it represents a large community of users, manufacturer and operators that are a major player in the MPEG-2 world. *HOWEVER* I believe we should ***TRY HARD*** to find solutions that work for all the MPEG-2 systems. This may be hard, or it may be easy, if you have opinions on this (or what might be needed) please do speak up. We need inputs from experts on all MPEG-2 Transport systems that do / may carry IP services. > 2. The second paragraph says, "There is therefore a need to define an > efficient standardised encapsulation for IPv4 and IPv6 datagrams...". This > statement seems to presume that the ISO MPEG 13818-6 Amendment #1 (and the > related ETSI 301192 and ATSC A/90 and ATSC A/92) that everyone uses today > are somehow unsuitable for some reason. MPE is fine, for some applications, and is likely to be long-lived, in those scenarios. It does however have some serious shortfalls for some applications, and these may be of significant concern especially in IP-only networks. > I think it would be helpful to add > something between these paragraphs that supports the need for the > development of a new encapsulation. Alternatively, one could soften the > "therefore there is a need" to something like "investigate and recommend". The "requirements" draft contains some of the rationale behind this conclusion. Do you think we need to say more? (have you suggestions?) Best wishes, Gorry Fairhurst > Regards, > > Mike > > At 10:00 AM 6/20/2003 +0100, gorry wrote: > > >A revised charter has been uploaded to the ip-dvb server at: > >http://www.erg.abdn.ac.uk/ip-dvb/charter.html > > > >Please do send corrections to me and comments to the ip-dvb list. > > > >Best wishes, > > > >Gorry > > > >P.S. The index page has also been updated (long overdue!) at: > >http://www.erg.abdn.ac.uk/ip-dvb/index.html > > ----------------------------------------------------- > Michael A. Dolan, President > Television Broadcast Technology, Inc. (TBT) > PO Box 1673 Alpine, CA 91903 USA > 619-445-9070 FAX: 208-545-6564 > URL:http://www.tbt.com From owner-ip-dvb@erg.abdn.ac.uk Fri Jun 20 19:28:21 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KIRvhA015432 for ; Fri, 20 Jun 2003 19:27:57 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5KIRvUj015431 for ip-dvb-subscribed-users; Fri, 20 Jun 2003 19:27:57 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from neko.cts.com (neko.cts.com [209.68.192.150]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5KIRZhA015417 for ; Fri, 20 Jun 2003 19:27:35 +0100 (BST) Received: from miked.tbt.com (vsat-148-63-99-97.c002.t7.mrt.starband.net [148.63.99.97]) by neko.cts.com (8.9.3p2/8.9.3) with ESMTP id LAA17320 for ; Fri, 20 Jun 2003 11:27:30 -0700 (PDT) Message-Id: <5.2.0.9.2.20030620110631.046a4dc8@cts.com> X-Sender: miked@cts.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 20 Jun 2003 11:24:20 -0700 To: ip-dvb@erg.abdn.ac.uk From: "Michael A. Dolan" Subject: Re: Revised IP over mpeg-2/DVB charter In-Reply-To: <3EF34561.C6DB7D41@erg.abdn.ac.uk> References: <5.2.0.9.2.20030620084407.045eb470@cts.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry- Thanks for your and Bernhard's prompt replies and background. It seems if the explicit intent is to be broader then DVB, then the name of the effort being "IP over DVB" may be misleading, over-constrained, and potentially alienate non-DVB participation regardless of what the fine print says. And, I was not suggesting this adhoc group here change its name. But going forward if you organize something new under IETF (in whatever form it takes, including a BOF), perhaps you should consider the new entity with a more generic title. Just a suggestion. I personally understand the scope to be broader. I wasn't trying to take a technical position one way or the other in regard use of addressable sections. I was merely pointing out that the statement about the need for a new encapsulation does not follow. One cannot conclude that a new encapsulation is needed from the sentences that precede it. It presumes a great deal of background not present in the charter. I'm just trying to help clarify the charter text at this point (both for myself and future parties), not put forth any specific technical position at this point. I'll jump in on the technical discussion later after I understand the charter and what problem is being solved, exactly. Best regards, Mike At 06:33 PM 6/20/2003 +0100, Dr G Fairhurst wrote: >Nice to hear from you, see below. > >"Michael A. Dolan" wrote: > > > > Hi- > > > > I just joined this list, so am coming at this work entirely out of > > context. But I wanted to understand the scope and requirements as it moves > > to an IETF WG. > >Well, to be technically correct, we are asking the IETF to consider the work. >The BOF is a chance to exchange ideas, get feedback, set goals, and >talk. >It also helps the IESG work out how to support the work. > >A BOF doesn't imply an IETF WG will happen, and anyway a WG isn't needed >neccessarily to do work. What is needed, is to understand the problem >and to get IESG Review/approval for the work. We seem to be progressing. > > > Thanks in advance for your indulgence.... > > > > 1. The proposed working group name is "IP over DVB", yet the charter says > > it is intended for any MPEG-2 transport stream. Is it the intent of this > > group to develop documents relating to non-DVB transports (ATSC, ARIB, > > video servers, and others)? > > > >YES, please *DO* take this to mean DVB, DAB, ATSC, ARIB, whatever. > >The word "DVB" in the title really is a mixed blessing. On the one >hand, it represents a large community of users, manufacturer and >operators that are a major player in the MPEG-2 world. > >*HOWEVER* I believe we should ***TRY HARD*** to find solutions that >work for all the MPEG-2 systems. This may be hard, or it may be easy, >if you have opinions on this (or what might be needed) please do speak >up. We need inputs from experts on all MPEG-2 Transport systems >that do / may carry IP services. > > > 2. The second paragraph says, "There is therefore a need to define an > > efficient standardised encapsulation for IPv4 and IPv6 datagrams...". This > > statement seems to presume that the ISO MPEG 13818-6 Amendment #1 (and the > > related ETSI 301192 and ATSC A/90 and ATSC A/92) that everyone uses today > > are somehow unsuitable for some reason. > >MPE is fine, for some applications, and is likely to be long-lived, >in those scenarios. > >It does however have some serious shortfalls for some applications, >and these may be of significant concern especially in IP-only networks. > > > I think it would be helpful to add > > something between these paragraphs that supports the need for the > > development of a new encapsulation. Alternatively, one could soften the > > "therefore there is a need" to something like "investigate and recommend". > >The "requirements" draft contains some of the rationale behind this >conclusion. Do you think we need to say more? (have you suggestions?) > >Best wishes, > >Gorry Fairhurst > > > Regards, > > > > Mike > > > > At 10:00 AM 6/20/2003 +0100, gorry wrote: > > > > >A revised charter has been uploaded to the ip-dvb server at: > > >http://www.erg.abdn.ac.uk/ip-dvb/charter.html > > > > > >Please do send corrections to me and comments to the ip-dvb list. > > > > > >Best wishes, > > > > > >Gorry > > > > > >P.S. The index page has also been updated (long overdue!) at: > > >http://www.erg.abdn.ac.uk/ip-dvb/index.html > > > > ----------------------------------------------------- > > Michael A. Dolan, President > > Television Broadcast Technology, Inc. (TBT) > > PO Box 1673 Alpine, CA 91903 USA > > 619-445-9070 FAX: 208-545-6564 > > URL:http://www.tbt.com ----------------------------------------------------- Michael A. Dolan, President Television Broadcast Technology, Inc. (TBT) PO Box 1673 Alpine, CA 91903 USA 619-445-9070 FAX: 208-545-6564 URL:http://www.tbt.com From owner-ip-dvb@erg.abdn.ac.uk Mon Jun 23 23:09:30 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5NM9D9l010208 for ; Mon, 23 Jun 2003 23:09:13 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5NM9DLY010207 for ip-dvb-subscribed-users; Mon, 23 Jun 2003 23:09:13 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5NM8u9l010193 for ; Mon, 23 Jun 2003 23:08:56 +0100 (BST) Message-ID: <3EF77A7B.12D6E902@erg.abdn.ac.uk> Date: Mon, 23 Jun 2003 23:08:58 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk A BOF will be held in Vienna on the subject of building standards for IP networks using MPEG-2 Transport Stream transmission. This is intended to cover issues common to implementors/operators wishing to build efficient IP transmission networks using DVB, ATSC, etc. Satellite systems are currently a major user of this technology. The description is below. For the current (as yet provisional scheduling see): http://www.ietf.org/meetings/ IP over MPEG-2/DVB Transport ============================ BoF Description --------------- The MPEG-2 Transport Stream provides a transmission network that has become widely use to support digital TV broadcast, including: DVB, DAB, ATSC, ISDB-T. These and related standards define a set of commercially available components that are increasingly being used to provide a general-purpose packet transmission network. MPEG-2 Transport networks are being used to build IP networks to supplement broadcast TV/audio services and also to provide one-way and two-way IP-only subnetworks. The BOF will explore how the IETF might work to define documents that describe the protocols required to build a complete IPv4/IPv6 unicast/multicast service, and the mappings that are needed to perform address resolution, etc. A set of Internet Drafts will be reviewed describing requirements, and some proposed protocols. DRAFT AGENDA ============ CHAIRS: Gorry Fairhurst Bernhard Collini-Nocker Agenda Bashing (5 minutes) - Election of scribes (jabber scribe?) What is MPEG-2? and Why is this an IETF activity? (10 minutes) draft-fair-ipdvb-req-03.txt Bernhard Collini-Nocker Lightweight Encapsulation (15 minutes) draft-clausen-ipdvb-enc-01.txt draft-fair-ipdvb-ule-00.txt Gorry Fairhurst Address Resolution for IPv4/IPv6 (10 minutes) draft-fair-ipdvb-ar-00.txt (tbc) Proposed Roadmap (15 minutes) Gorry Fairhurst - STANDARDS TRACK RFC on Encapsulation (review Oct 2003) (to IESG by Dec 2003) - INFO RFC on Address Resolution (review Mar 2004) (to IESG by June 2004) - INFO RFC on Architecture (review Mar 2004) (to IESG by Jun 2004) Open mic discussion - Protocol issues? - Deployment issues? - Does this need an IETF WG? References: http://www.erg.abdn.ac.uk/ip-dvb/ Requirements for transmission of IP datagrams over MPEG-2/DVB networks. http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-03.txt Simple Encapsulation for transmission of IP datagrams over MPEG-2/DVB networks. http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-01.txt Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams over MPEG-2/DVB networks. http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-00.txt Address Resolution for IP datagrams over MPEG-2 networks. http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt To subscribe to the mailing list: send "subscribe ip-dvb" in the BODY part of an email to "majordomo@erg.abdn.ac.uk" The mailing list archives are at: http://www.erg.abdn.ac.uk/ip-dvb/archive From owner-ip-dvb@erg.abdn.ac.uk Tue Jun 24 13:46:38 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5OCkG9l019932 for ; Tue, 24 Jun 2003 13:46:16 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5OCkGYi019931 for ip-dvb-subscribed-users; Tue, 24 Jun 2003 13:46:16 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [10.0.1.45] (maxp18.abdn.ac.uk [139.133.7.177]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5OCj79l019883; Tue, 24 Jun 2003 13:45:08 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 24 Jun 2003 13:48:40 +0100 Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) From: gorry To: CC: William StanisLaus Message-ID: In-Reply-To: <3EFC4703@mailandnews.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk > Hi Gorry, > Good Day... i was trying to get the document > >> Address Resolution for IP datagrams over MPEG-2 networks. >> http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt It was submitted to the ID editor, so it must still be in the queue, this is a very busy time for them. If you'd like to see the "unofficial" submitted copy then it's archived in the ip-dvb web-pages at: http://www.erg.abdn.ac.uk/ip-dvb/ids/ > > but it says "The page you are looking for cannot be found" > > Have a nice day. > Thanks and Best Regards, > William. > > <> Gorry P.S. The working group should be covering all MPEG-2 technologies. The address resolution ID would especially benefit from input from other MPEG-2 user communities, - is anyone willing to offer comments or, even better one or two paragraphs about ATSC, etc.????? From owner-ip-dvb@erg.abdn.ac.uk Tue Jun 24 14:22:29 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5ODLr9l020581 for ; Tue, 24 Jun 2003 14:21:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5ODLqDM020580 for ip-dvb-subscribed-users; Tue, 24 Jun 2003 14:21:52 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5ODLV9m020567 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 24 Jun 2003 14:21:32 +0100 (BST) Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Unjb-0005sV-00; Tue, 24 Jun 2003 14:21:19 +0100 Message-ID: <3EF8504F.DAC0B49A@eim.surrey.ac.uk> Date: Tue, 24 Jun 2003 14:21:19 +0100 From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk CC: Sebastien.Josset@space.alcatel.fr, Isabelle.Buret@space.alcatel.fr, Stephane.Combes@space.alcatel.fr Subject: Re: =?iso-8859-1?Q?R=E9f=2E?= : Re: "Flat Multicast Key Exchange (FMKE)" -Internet Draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-105.7 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM, USER_IN_WHITELIST version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Unjb-0005sV-00*od6pV58PdmI* (SECM, UniS) X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi again Luarence, Many thanks for your detailed reply. I am very pleased that you have produced such detailed work and most of your comments are OK. However to keep the discussions going in ip-dvb mailing list, see my comments inline: Laurence.Duquerroy@space.alcatel.fr wrote: > Dear Haitham, > > Thank you very much for your comments. They will help me to improve the draft. > Please find in the following the answers to your questions. > > >Dear Laurence > > >Sorry for the delay in my reply. I read your proposed Internet Draft "Flat > >Multicast Key Exchange (FMKE)" and I have the following comments: > > >1. Fundamental question: I remember your presentation at the ESTEC workshop > "IP > >networking over satellites" few weeks ago. I remember that you said that this > >solution will be implemented in the link level (for example DVB-S link level). > >That is something is not clear in my mind yet, because your proposal is IPSEC > >based. > > In this solution, the control plane (i.e. the Flat Multicast Key Exchange) and > the dataplane (functions encrypting and authenticating data) are separated. > FMKE is indeed implemented in the layer 3 over IP, as it is based on ISAKMP, > like IKE. > In fact, this is the dataplane which can be implemented at link level (or in > layer 3). My presentation at the ESTEC workshop dealed with a security dataplane > implemented into the IP dedicated protocol. It is very good to separate security control and data planes. Between University of Surrey and Logica (UK) in the ESA project, we have a full implementation GSAKMP which is another security framework for managing group communications. We think of GSAKMP as an application that produces keys that can be used in the data plane (network level: IPSEC ESP or AH modes ; or link level: such as DVB-S link level). So your idea is good to separate control and data planes. > > > However, we envisage to define a security solution (control plane + dataplane) > fully implemented at the link level, based on the DVB-RCS security messages > (probably by re-using some of them and adding some messages based on the FMKE > ones). > > > One more point, your Internet draft does not mention satellites. May be you > can > > clarify this. > > The draft is indeed very general. > > The objective of this security solution is to secure the satellite segment.The > FMKE mechanims are implemented at the satellite terminal level. We can consider > them as a module, which may be directly implemented inside the stack of each > satellite terminal, or may be implemented in a separate box, located behind > each ST. > > In the ID, a group member is therefore a satellite terminal (or the box behind), > and the GCKS a server implemented for instance in a gateway. > All FMKE messages are therefore exchanged on satellite links. > > This solution is able to establish in an optimized manner secure communication > groups in Star and mesh architectures > > >By the way, ALCATEL ASP has a project with ESA on DVB-RCS security for > >multicast and also University of Surrey and ALCATEL ASP have some documentation > in > >the GEOCAST project on how to modify DVB-RCS current security to cater for > >multicast. > > The project that ALCATEL ASP has on DVB-RCS security, and security documentation > of the GEOCAST project, define security mechanisms for star architectures. Some > security features are missing to use them in MESH topology. In my opinion, the MESH topology can only work effectively with satellite OBP. > > With FMKE, we look at a more long-term solution, which would provide an > optimized security in STAR systems and in MESH systems (for one-to-many and > many-to-many communications). > Moreover, we define some supplementary and useful mechanisms (like multicast > configuration and re-keying ...) > > >2. As I understand that you will present your draft at the MSEC group at the > IETF > >meeting in Vienna. Your proposal looks fairly similar to The Group Domain of > >Interpretation (GDOI) and latest draft is draft-ietf-msec-gdoi-08.txt (see: > >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-08.txt), which is well > >established and going to be an RFC soon. Your work is duplicating GDOI and > adding > >phase 3 which does not exist in GDOI. In fact, GDOI has flat key and LKH (tree > >architecture) distribution mechanisms. Can you clarify the differences between > > FMKE and GDOI. > > FMKE and GDOI are based on similar principles. Both are based on a centralized > management achieved by the GCKS, on 3 different exchanges or phases which have > similar objectives, on similar security levels, on similar key system (KEKs and > TEKs, and we intend to use LKH ). I disagree here with you, FMKE and LKH are two different things: Flay key and tree architecture (LKH) are not the same. Flat key system is good for groups with low volatility (groups with low rate of joins and leaves). LKH is more efficient for highly dynamic groups. > > However FMKE is designed to provide a solution more adapted to our context. > > * First of all, the main difference between the GDOI "Group Key pull" exchange > and the FMKE phase 2 concerns the initiator of the exchange. In GDOI, the phase > is initiated by the potential Group Member (GM), and in FMKE by the GCKS. > In the GDOI "Group key pull" exchange, the GM has to initiate the exchange in > order to request the access to a particular group. It receives the SAs > associated to this group if it is authorized. This exchange is realised several > times, each time the GM decides to join another group. > As the initiator is the GM, checking its liveliness is required. Indeed, as this > exchange can be realised several times , a replay attack can easily be launched. > This requirement implies that the exchange is composed of 4 messages ( the 3rd > msg allows to prove the GM liveliness, and in the 4th message the group keys are > transmitted). > > In FMKE the exchange is initiated by the GCKS. It transmits during this exchange > all the SAs the member is authorized to get access to, belonging to one or > several groups. The Client just has to send periodically acknowledgement > messages in response. > This phase is launched once; at the end of the first phase. > Moreover,as only one phase 2 is realised and is initiated by the GCKS, verifying > the client liveliness is not needed ( does not require the messages used in the > Group key push) > > Therefore FMKE phase 2 is less resource consuming than GDOI "Group Key push", as > it requires less messages for an equal number of SAs to transmit (for one group > , GDOI requires 4 messages , whereas in FMKE the GCKS sends a message with the > SAs, and waits for a periodic acknowledgement of the GM) > > * GDOI requires that group members know specific information and own specific > functionality to be able to request the SAs of the groups they wish to join. On > the contrary, in FMKE, they receive directly all the SAs they are authorized to > get access to, belonging to one or several groups, without having to send a > request. With the attributes contain in the SA payloads, they know which traffic > flows they have to protect (for instance identified by a multicast destination > address, a layer 2 label, a PID) . > In the context considered by FMKE, satellite terminals have to protect traffic > that they do not generate themselves. So they know very few information about > it. Thus, it seems more adapted that they receive directly the data security > configurations for the traffic they have to protect, instead of requesting them. > > * GDOI exchanges ("Group Key Pull" and "Group Key Push") are not reliable. > Nothing guarantees that the GM(s) has(have) received the group keys transmitted > by the GCKS. > On the contrary, in FMKE, during the phase 2, each message from the GCKS has to > be acknowledged by the GM, and is retransmitted if it is not acknowledged. In > the phase 3, GMs can request the non received messages (this mechanism is > optimized in order to avoid the congestion at the GCKS) I have one more question: How does the GCKS distribute new traffic keys (TEK) to existing members in cases such as period rekeying (to stop cryptoanalysts) or if the current data key is compromised (broken). Thanks. > > > >3. In section 8 (security consideration), you should state the remaining or > >potential problems with your protocol. One example is Denial of Service (DoS) > >attacks, where you should state how your protocol and your security server can > >cope with thousands of forged messages coming from false IP addresses. One > >common practice is to use stateless COOKIES in order to minimize the memory > >and CPU burden on the security server which is experiencing the DoS attack > >(for more details see: > >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-07.txt). > > Thank you, I am going to check the remaining attacks and add the necessary > information Especially DoS attacks. Thanks again Haitham > > > >Please consider these as constructive comments and I hope they will improve > your > >draft. > >Regards > >Haitham > > Best regards, > > Laurence Duquerroy > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr -- Dr. Haitham S. Cruickshank Senior Research Fellow in 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 owner-ip-dvb@erg.abdn.ac.uk Tue Jun 24 14:29:31 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5ODTE9l020763 for ; Tue, 24 Jun 2003 14:29:14 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5ODTEMm020762 for ip-dvb-subscribed-users; Tue, 24 Jun 2003 14:29:14 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from mailandnews.com (smw03.shanjemail.com [209.81.157.234]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5ODSt9l020745; Tue, 24 Jun 2003 14:28:56 +0100 (BST) X-WM-Posted-At: mailandnews.com; Tue, 24 Jun 03 09:26:12 -0400 X-WebMail-UserID: williams77 Date: Tue, 24 Jun 2003 09:26:12 -0400 From: William StanisLaus To: , gorry X-EXP32-SerialNo: 50000000 Subject: RE: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) Message-ID: <3EFAE75C@mailandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.62.01 X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry, Thanks for your reference, just i am curious to understand how PID is handled in ARP over DVB :) Sure i will get back if i have any strange thoughts :) Best Regards, William. >===== Original Message From gorry ===== >> Hi Gorry, >> Good Day... i was trying to get the document >> >>> Address Resolution for IP datagrams over MPEG-2 networks. >>> http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt > >It was submitted to the ID editor, so it must still be in the queue, this is >a very busy time for them. > >If you'd like to see the "unofficial" submitted copy then it's archived in >the ip-dvb web-pages at: > > >http://www.erg.abdn.ac.uk/ip-dvb/ids/ > >> >> but it says "The page you are looking for cannot be found" >> >> Have a nice day. >> Thanks and Best Regards, >> William. >> >> > ><> > >Gorry > >P.S. The working group should be covering all MPEG-2 technologies. The >address resolution ID would especially benefit from input from other MPEG-2 >user communities, - is anyone willing to offer comments or, even better one >or two paragraphs about ATSC, etc.????? From owner-ip-dvb@erg.abdn.ac.uk Tue Jun 24 14:50:09 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5ODnh9l021121 for ; Tue, 24 Jun 2003 14:49:43 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5ODnh3M021120 for ip-dvb-subscribed-users; Tue, 24 Jun 2003 14:49:43 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5ODnH9m021097 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 24 Jun 2003 14:49:19 +0100 (BST) Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19UoAY-000771-00 for ip-dvb@erg.abdn.ac.uk; Tue, 24 Jun 2003 14:49:10 +0100 Message-ID: <3EF856D5.18464446@eim.surrey.ac.uk> Date: Tue, 24 Jun 2003 14:49:10 +0100 From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: "Flat Multicast Key Exchange (FMKE)"- Internet Draft References: <3ED74372.BA667A7D@eim.surrey.ac.uk> <3EE4B4E3.5B7679E5@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-105.3 required=5.5 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM, USER_IN_WHITELIST version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19UoAY-000771-00*/bgVKdq.HIc* (SECM, UniS) X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Gorry and IP-DVB colleagues, Dr G Fairhurst wrote: > Thanks Haitham for your inputs! > > I was wondering whether anyone else had given thouughts as to whether there > was a need for a specific key management protocol for MPEG-2 transmission? I think the most well known security system is DVB-S CA (Conditional Access). The system was designed to be simple and fast to cope with DVB MPEG-TS payload encryption/decryption. As you know, it uses master/session key concept using EMM/ECM (Entitlement Management Message /Entitlement Checking Message) plus smartcard key. > > > Various people have in the past commented on the current MPEG-2 encryption > systems being inappropriate for IP data, Currently MPEG-TS payload encryption is used on TV broadcasts. I think on principle, MPEG-2 encryption can be used for IP data in the MPE level. Of course the question of efficiency is another matter. Also the MPEG-2 encryption is a proprietary system, so there is no way to fully test its security strengths and weakness. On the other hand, the use of DES or AES in IPSEC is good because these encryption algorithms had been well tested. > but I don't see a clear > consensus yet > on exactly what needs to be fixed. I can tell my opinion about what needs to be fixed. The MPEG-2 encryption is OK, but the key management is the problems, where the whole DVB-CA system relies on the smartcard in set top boxes being temper proof and relies on a permanent secret key stored in the smartcard. This must change and a new security management system should be used with NO NEED FOR PERMANENTLY STORED SECRET KEYS. Therefore security frameworks such as GDOI, GSAKMP or Alcatel's FMKE can used to replace the existing system > > > Is this an Internet Protocol issue (e.g. IPSEC)? The key management can be GDOI, GSAKMP/FMKE > > > Is it a MPEG-2/DVB/ATSC issue? Data encryption is MPEG-2/DVB/ATSC > > > Please send comments and questions to this list. I'd like to get a feeling > on how important this is to people, and what exactly people want to be done. I would like to hear other peoples opinions on this subject, please. Best wishes. Haitham > > > Best wishes, > > Gorry Fairhurst > > > Laurence.Duquerroy@space.alcatel.fr wrote: > > > > > Hello, > > > > > > In the context of the SatIP6 IST project, Alcatel Space studies a multicast > > > security scheme optimised to protect large multicast groups. Such a scheme is > > > designed for IP over Satellite, Wifi or DVB systems; it is a security solution > > > for the satellite segment. An implementation over DVB-S/RCS is planned in the > > > SatIP6 demonstrator. > > > We have presented this security solution (called SatIPSec) during the ESA > > > workshop at ESTEC, 13-14 May on "IP networking over satellite". > > > > > > We have started to write an Internet Draft detailing our key exchange protocol > > > (called "Flat Multicast Key Exchange (FMKE)"), and we think that it could be > > > submitted to the "IP over DVB " group, as IP over DVB systems are targeted > > > systems. We would be ready to present it to the next IETF meeting (in Vienna). > > > As it is very security-oriented, it will probably also be submitted to an IETF > > > security group (i.e. MSEC (Multicast Security) WG). > > > > > > You will find in attachment a draft of the ID. Your comments, opinion, and > > > feedback on it are welcome. > > > (See attached file: draft-duquer-fmke-00.doc) > > > > > > This solution is very flexible. It is able to configure any security dataplane > > > at layer 2 or 3 ( IPv4/6 IPSec, L2 security dataplanes...). > > > It is based on similar principles to the ones of the protocols currently defined > > > in the IETF MSEC group. It uses also similar messages (based on the ISAKMP > > > standard protocol). However it implements additional mechanisms and features in > > > order to provide a security solution optimized for satellite systems: > > > > > > - It is defined to be low ressource consuming in bandwidth > > > - It provides a reliable key distribution ( unlike the GDOI and GSAKMP > > > protocols) > > > - It can be used in one-to-many and many-to-many scenarios, and is > > > scalable in these scenarios (MIKEY cannot be used in many-to-many scenarios in > > > large groups) > > > - It provides a multicast re-keying (mandatory in large groups) (unlike > > > MIKEY) > > > - etc > > > > > > We hope that you will find interest in it, and thank you in advance for your > > > comments. > > > > > > Best regards, > > > > > > Laurence Duquerroy > > > > > > ALCATEL SPACE > > > RT/ST > > > Research Department / Advanced Telecom Satellite Systems > > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > > E-Mail : laurence.duquerroy@space.alcatel.fr > > > > > > ------------------------------------------------------------------------ > > > Name: draft-duquer-fmke-00.doc > > > draft-duquer-fmke-00.doc Type: WINWORD File (application/msword) > > > Encoding: base64 > > > Description: Mac Word 3.0 > > > > -- > > Dr. Haitham S. Cruickshank > > > > Senior Research Fellow in 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/ -- Dr. Haitham S. Cruickshank Senior Research Fellow in 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 owner-ip-dvb@erg.abdn.ac.uk Wed Jun 25 11:13:08 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5PACm9l006693 for ; Wed, 25 Jun 2003 11:12:48 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5PACmFS006692 for ip-dvb-subscribed-users; Wed, 25 Jun 2003 11:12:48 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5PACM9l006668 for ; Wed, 25 Jun 2003 11:12:22 +0100 (BST) Message-ID: <3EF97587.6229FAA@erg.abdn.ac.uk> Date: Wed, 25 Jun 2003 11:12:23 +0100 From: Dr G Fairhurst Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Good advice when preparing for the upcoming IETF meeting in Vienna Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk The IETF meeting is coming up fairly soon in Vienna, and I hope that many people on this mailing list are planning to attend the BOF meeting on "IP over MPEG-2/DVB Transport". Thismeeting aims to look at IP service provision over MPEG-2. Despite the word "DVB" in the BOF title, I would especially encourage input and comments from those using MPEG-2 beyond DVB, such as ATSC, DAB, etc. It may be the first time for some of you to attend an IETF. Here are some tips which may improve your experience, courtesy of Paul Hoffman: - Newcomers can learn a lot ahead of time by reading the Tao of the IETF [1]. The newcomer orientation on Sunday (this year, at 1PM) is useful, but it is even more useful if they have read the Tao first. - It is a good idea to at least skim the WG archives [2] for the past four months before the meeting to help prevent rehashing items that have already been decided and to help focus on items that need more review. - Similarly, it is a good idea to re-read the WG's charter [3] before the meeting. - Many IETF areas have area-wide meetings. People who are interested in more than just one WG can get a feel for what is happening in other areas by going to these meetings. The transport area has one of these meetings, tsvwg. - The "Note Well" notice [4] is serious. It will also be given on paper in the registration packets. --- [1] http://www.ietf.org/tao.html [2] http://www.erg.abdn.ac.uk/ip-dvb/archive [3] http://www.erg.abdn.ac.uk/ip-dvb/charter.html [4] http://www.ietf.org/overview.html --- Details of the Vienna meeting, including registration, hotels, and travel, can be found at: http://www.ietf.org/meetings/IETF-57.html A copy of current provisional BOF agenda (subject to approval by the AD) is at: http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00333.html and the current list of working group / BOF meetings is at: http://www.ietf.org/meetings/agenda_57.txt --- From owner-ip-dvb@erg.abdn.ac.uk Thu Jun 26 09:53:23 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5Q8r19l023873 for ; Thu, 26 Jun 2003 09:53:02 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5Q8r1Ca023872 for ip-dvb-subscribed-users; Thu, 26 Jun 2003 09:53:01 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from smail3.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5Q8qd9l023859 for ; Thu, 26 Jun 2003 09:52:39 +0100 (BST) Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h5Q8qSvl004107 for ; Thu, 26 Jun 2003 10:52:34 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D51.00307C87 ; Thu, 26 Jun 2003 10:49:36 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: ip-dvb@erg.abdn.ac.uk cc: Sebastien.Josset@space.alcatel.fr, Isabelle.Buret@space.alcatel.fr Message-ID: Date: Thu, 26 Jun 2003 10:51:28 +0200 Subject: =?iso-8859-1?Q?R=E9f._:_Re:_R=E9f._:_Re:_"Flat_Multicast_Key_Exch?= =?iso-8859-1?Q?ange_(FMKE)"?= -Internet Draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Hi Haitham , Thanks again for your comments. You will find below the answers to your questions. FYI, FMKE will be presented at the next IETF MSEC working group meeting in Vienna ( in July) (but the I-D is still an independent I-D) Best regards, Laurence >Hi again Laurence, >Many thanks for your detailed reply. I am very pleased that you have produced such >detailed work and most of your comments are OK. >However to keep the discussions going in ip-dvb mailing list, see my comments >inline: >Laurence.Duquerroy@space.alcatel.fr wrote: >> Dear Haitham, >> >> Thank you very much for your comments. They will help me to improve the draft. >> Please find in the following the answers to your questions. >> >> >Dear Laurence >> >> >Sorry for the delay in my reply. I read your proposed Internet Draft "Flat >> >Multicast Key Exchange (FMKE)" and I have the following comments: >> >> >1. Fundamental question: I remember your presentation at the ESTEC workshop >> "IP >> >networking over satellites" few weeks ago. I remember that you said that this >> >solution will be implemented in the link level (for example DVB-S link level). >> >That is something is not clear in my mind yet, because your proposal is IPSEC >> >based. >> >> In this solution, the control plane (i.e. the Flat Multicast Key Exchange) and >> the dataplane (functions encrypting and authenticating data) are separated. >> FMKE is indeed implemented in the layer 3 over IP, as it is based on ISAKMP, >> like IKE. >> In fact, this is the dataplane which can be implemented at link level (or in >> layer 3). My presentation at the ESTEC workshop dealed with a security dataplane >> implemented into the IP dedicated protocol. >It is very good to separate security control and data planes. Between University of >Surrey and Logica (UK) in the ESA project, we have a full implementation GSAKMP >which is another security framework for managing group communications. We think of >GSAKMP as an application that produces keys that can be used in the data plane >(network level: IPSEC ESP or AH modes ; or link level: such as DVB-S link level). >So your idea is good to separate control and data planes. >> However, we envisage to define a security solution (control plane + dataplane) >> fully implemented at the link level, based on the DVB-RCS security messages >> (probably by re-using some of them and adding some messages based on the FMKE >> ones). >> >> > One more point, your Internet draft does not mention satellites. May be you >> can >> > clarify this. >> >> The draft is indeed very general. >> >> The objective of this security solution is to secure the satellite segment.The >> FMKE mechanims are implemented at the satellite terminal level. We can consider >> them as a module, which may be directly implemented inside the stack of each >> satellite terminal, or may be implemented in a separate box, located behind >> each ST. >> >> In the ID, a group member is therefore a satellite terminal (or the box behind), >> and the GCKS a server implemented for instance in a gateway. >> All FMKE messages are therefore exchanged on satellite links. >> >> This solution is able to establish in an optimized manner secure communication >> groups in Star and mesh architectures >> >> >By the way, ALCATEL ASP has a project with ESA on DVB-RCS security for >> >multicast and also University of Surrey and ALCATEL ASP have some documentation >> in >> >the GEOCAST project on how to modify DVB-RCS current security to cater for >> >multicast. >> >> The project that ALCATEL ASP has on DVB-RCS security, and security documentation >> of the GEOCAST project, define security mechanisms for star architectures. Some >> security features are missing to use them in MESH topology. >In my opinion, the MESH topology can only work effectively with satellite OBP. Indeed, by MESH topology, we mean mesh satellite systems with satellite OBP. >> >> With FMKE, we look at a more long-term solution, which would provide an >> optimized security in STAR systems and in MESH systems (for one-to-many and >> many-to-many communications). >> Moreover, we define some supplementary and useful mechanisms (like multicast >> configuration and re-keying ...) >> >> >2. As I understand that you will present your draft at the MSEC group at the >> IETF >> >meeting in Vienna. Your proposal looks fairly similar to The Group Domain of >> >Interpretation (GDOI) and latest draft is draft-ietf-msec-gdoi-08.txt (see: >> >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-08.txt), which is well >> >established and going to be an RFC soon. Your work is duplicating GDOI and >> adding >> >phase 3 which does not exist in GDOI. In fact, GDOI has flat key and LKH (tree >> >architecture) distribution mechanisms. Can you clarify the differences between >> > FMKE and GDOI. >> >> FMKE and GDOI are based on similar principles. Both are based on a centralized >> management achieved by the GCKS, on 3 different exchanges or phases which have >> similar objectives, on similar security levels, on similar key system (KEKs and >> TEKs, and we intend to use LKH ). >I disagree here with you, FMKE and LKH are two different things: Flay key and tree >architecture (LKH) are not the same. Flat key system is good for groups with low >volatility (groups with low rate of joins and leaves). LKH is more efficient for >highly dynamic groups. Indeed FMKE an LKH are different things : * FMKE is a group key distribution protocol, which can be used to distribute any types of keys : - keys from a flat key system (i.e. 1 KEK and TEKs shared by all group members) - keys from a hierarchical key system (i.e. LKH) * LKH is an algorithm which defines how to build a key tree, which keys in the tree have to be renewed when a group member leaves the group, which the order of the distribution of these keys is and how they have to be renewed (keys to use to encrypt them, transmission in multicast or unicast ?...). This system is very useful for large and highly dynamic groups. Thus FMKE can be used to distribute keys from a key tree. We have for a group no more a single KEK, but a set of KEKs (KEK array) which is different for each Group member, and TEKs which are the root of the tree and which are shared by all group members. The name of the protocol "Flat multicast key exchange" is maybe confusing. It does not mean that we address flat key system, but that the protocol is destined to "Flat environment",that is to say that it allows to flexibly set up large secure multicast networks in flat environment (no intermediate routers between the GCKS and a large amount of group members). >> >> However FMKE is designed to provide a solution more adapted to our context. >> >> * First of all, the main difference between the GDOI "Group Key pull" exchange >> and the FMKE phase 2 concerns the initiator of the exchange. In GDOI, the phase >> is initiated by the potential Group Member (GM), and in FMKE by the GCKS. >> In the GDOI "Group key pull" exchange, the GM has to initiate the exchange in >> order to request the access to a particular group. It receives the SAs >> associated to this group if it is authorized. This exchange is realised several >> times, each time the GM decides to join another group. >> As the initiator is the GM, checking its liveliness is required. Indeed, as this >> exchange can be realised several times , a replay attack can easily be launched. >> This requirement implies that the exchange is composed of 4 messages ( the 3rd >> msg allows to prove the GM liveliness, and in the 4th message the group keys are >> transmitted). >> >> In FMKE the exchange is initiated by the GCKS. It transmits during this exchange >> all the SAs the member is authorized to get access to, belonging to one or >> several groups. The Client just has to send periodically acknowledgement >> messages in response. >> This phase is launched once; at the end of the first phase. >> Moreover,as only one phase 2 is realised and is initiated by the GCKS, verifying >> the client liveliness is not needed ( does not require the messages used in the >> Group key push) >> >> Therefore FMKE phase 2 is less resource consuming than GDOI "Group Key push", as >> it requires less messages for an equal number of SAs to transmit (for one group >> , GDOI requires 4 messages , whereas in FMKE the GCKS sends a message with the >> SAs, and waits for a periodic acknowledgement of the GM) >> >> * GDOI requires that group members know specific information and own specific >> functionality to be able to request the SAs of the groups they wish to join. On >> the contrary, in FMKE, they receive directly all the SAs they are authorized to >> get access to, belonging to one or several groups, without having to send a >> request. With the attributes contain in the SA payloads, they know which traffic >> flows they have to protect (for instance identified by a multicast destination >> address, a layer 2 label, a PID) . >> In the context considered by FMKE, satellite terminals have to protect traffic >> that they do not generate themselves. So they know very few information about >> it. Thus, it seems more adapted that they receive directly the data security >> configurations for the traffic they have to protect, instead of requesting them. >> >> * GDOI exchanges ("Group Key Pull" and "Group Key Push") are not reliable. >> Nothing guarantees that the GM(s) has(have) received the group keys transmitted >> by the GCKS. >> On the contrary, in FMKE, during the phase 2, each message from the GCKS has to >> the phase 3, GMs can request the non received messages (this mechanism is >> optimized in order to avoid the congestion at the GCKS) >I have one more question: How does the GCKS distribute new traffic keys (TEK) to >existing members in cases such as period rekeying (to stop cryptoanalysts) or if the >current data key is compromised (broken). Thanks. For a flat key system, if only TEKs have to be renewed, this can be done in multicast by using the FMKE Phase 3 messages (transmission is protected by the Re-key SA (KEK)). For a key tree architecture,we determine the KEKs of the KEK array to use ( I think they are the two keys which are just under the root) and we use them to send the TEKs in multicast( by using the FMKE phase 3). For a flat key system, if TEKs and the KEK are compromised or if a member leaves the group, we have to renew KEK and TEKs. A solution is to distribute the new KEK in unicast to all remaining group members by using the FMKE phase 2 exchange, and then to distribute the new TEKs in multicast by using Phase 3 messages (encrypted with the new KEK of the Re-key SA). For a key tree architecture, if a member leaves a group or if TEKs and some of the KEKs are compromised, we determine with the LKH algorithm which keys of the tree have to be changed, the order of the distribution of these keys, and how they have to be renewed (in multicast or in unicast? Encrypted with which other KEK?). We use then FMKE phase 2 and Phase 3 exchanges to achieve it. This solution needs less messages than the solution for the flat key system. >> >3. In section 8 (security consideration), you should state the remaining or >> >potential problems with your protocol. One example is Denial of Service (DoS) >> >attacks, where you should state how your protocol and your security server can >> >cope with thousands of forged messages coming from false IP addresses. One >>> >and CPU burden on the security server which is experiencing the DoS attack >> >(for more details see: >> >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-07.txt). >> >> Thank you, I am going to check the remaining attacks and add the necessary >> information >Especially DoS attacks. >Thanks again >Haitham >> >Please consider these as constructive comments and I hope they will improve >> your >> >draft. >> >Regards >> >Haitham >> >> Best regards, >> >> Laurence Duquerroy >> >> ALCATEL SPACE >> RT/ST >> Research Department / Advanced Telecom Satellite Systems >> Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 >> E-Mail : laurence.duquerroy@space.alcatel.fr -- >Dr. Haitham S. Cruickshank >Senior Research Fellow in 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/ ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr From owner-ip-dvb@erg.abdn.ac.uk Fri Jun 27 12:22:26 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5RBLwnL014741 for ; Fri, 27 Jun 2003 12:21:58 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5RBLwLI014740 for ip-dvb-subscribed-users; Fri, 27 Jun 2003 12:21:58 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from [139.133.207.88] (inspiration-mac.erg.abdn.ac.uk [139.133.207.88]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5RBLanM014723 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 27 Jun 2003 12:21:38 +0100 (BST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 27 Jun 2003 12:21:25 +0100 Subject: 57th IETF - Pre-Registration From: Alastair Matthews To: Message-ID: In-Reply-To: <200306261442.KAA28492@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk FYI A. ------ Forwarded Message > From: ietf-secretariat@ietf.org > Date: Thu, 26 Jun 2003 10:42:33 -0400 > To: IETF-Announce: ; > Subject: 57th IETF - Pre-Registration > > REMINDER - pre-registration and pre-payment for the upcoming > IETF meeting in Vienna, Austria will close on Monday, 30 June > at 12:00 noon ET. After this time you will have to register > on-site in Vienna. > > You can register at http://www.ietf.org/meetings/notewell.html > > ------ End of Forwarded Message From owner-ip-dvb@erg.abdn.ac.uk Sun Jun 29 14:03:27 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5TD2rnL014013 for ; Sun, 29 Jun 2003 14:02:53 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5TD2rsf014012 for ip-dvb-subscribed-users; Sun, 29 Jun 2003 14:02:53 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sh.csm.jcsat.co.jp (root@sh.csm.jcsat.co.jp [163.142.0.34]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5TD1xnL013969 for ; Sun, 29 Jun 2003 14:02:00 +0100 (BST) Received: from csm.jcsat.co.jp ([202.212.167.184]) by sh.csm.jcsat.co.jp (8.12.8/3.7W) with ESMTP id h5TCgK8R008193 for ; Sun, 29 Jun 2003 21:42:20 +0900 (JST) Message-ID: <3EFEE33E.5000506@csm.jcsat.co.jp> Date: Sun, 29 Jun 2003 22:01:50 +0900 From: TAKEI jun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) References: <3EF77A7B.12D6E902@erg.abdn.ac.uk> In-Reply-To: <3EF77A7B.12D6E902@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry, I believe this BOF is continuous work from the unofficial BOF in Salt lake city IETF and the situation has not been changed a lot. Based on the information which I have and the situation in Japan, urgent issue related on MPEG/DVB is IPv6 encapsulation. In terms of IPv4, there are existing standard even though it was not defined by IETF and it is not efficient ;-). If the WG try to define new encapsulation mechanism of IPv4, it needs strong merit ,reason and a time to make it be RFC. But IPv6, there are few mechanism which can handle on MPEG/DVB-TS(I am not saying no standard). So my comment is WG should focus on IPv6 encapsulation. Hopefully it should be better that current MPE mechanism by using lessons and learned from IPv4 experience. Second item which on the agenda, address resolution between MPEG PID and IP address. Those address space are totally different each other. And normally PID assignment has already done by service provider(TV broadcasting company, IP service provider, etc.) or satellite operator. So it is difficult to assign specific IP address to specific PID. Maybe it is better to define new service mapping table like NIT, PAT and PMT. Anyway this is the start point of the discussion. I hope we can define something from IETF. Best regards, Jun Takei Dr G Fairhurst wrote: > A BOF will be held in Vienna on the subject of building standards for IP > networks using MPEG-2 Transport Stream transmission. This is intended to > cover issues common to implementors/operators wishing to build efficient > IP transmission networks using DVB, ATSC, etc. Satellite systems are > currently a major user of this technology. The description is below. > > For the current (as yet provisional scheduling see): > > http://www.ietf.org/meetings/ > > IP over MPEG-2/DVB Transport > ============================ > > BoF Description > --------------- > > The MPEG-2 Transport Stream provides a transmission network that has > become widely use to support digital TV broadcast, including: DVB, DAB, > ATSC, ISDB-T. These and related standards define a set of commercially > available components that are increasingly being used to provide a > general-purpose packet transmission network. MPEG-2 Transport networks > are being used to build IP networks to supplement broadcast TV/audio > services and also to provide one-way and two-way IP-only subnetworks. > > The BOF will explore how the IETF might work to define documents that > describe the protocols required to build a complete IPv4/IPv6 > unicast/multicast service, and the mappings that are needed to perform > address resolution, etc. A set of Internet Drafts will be reviewed > describing requirements, and some proposed protocols. > > > DRAFT AGENDA > ============ > > CHAIRS: > Gorry Fairhurst > Bernhard Collini-Nocker > > Agenda Bashing (5 minutes) > - Election of scribes (jabber scribe?) > > > What is MPEG-2? and Why is this an IETF activity? (10 minutes) > draft-fair-ipdvb-req-03.txt > Bernhard Collini-Nocker > > Lightweight Encapsulation (15 minutes) > draft-clausen-ipdvb-enc-01.txt > draft-fair-ipdvb-ule-00.txt > Gorry Fairhurst > > Address Resolution for IPv4/IPv6 (10 minutes) > draft-fair-ipdvb-ar-00.txt > (tbc) > > Proposed Roadmap (15 minutes) > Gorry Fairhurst > - STANDARDS TRACK RFC on Encapsulation (review Oct 2003) (to > IESG by > Dec 2003) > - INFO RFC on Address Resolution (review Mar 2004) (to IESG by > June 2004) > - INFO RFC on Architecture (review Mar 2004) (to IESG by Jun 2004) > > Open mic discussion > - Protocol issues? > - Deployment issues? > - Does this need an IETF WG? > > > References: > > http://www.erg.abdn.ac.uk/ip-dvb/ > > Requirements for transmission of IP datagrams over MPEG-2/DVB networks. > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-03.txt > > Simple Encapsulation for transmission of IP datagrams over MPEG-2/DVB > networks. > http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-01.txt > > Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams > over MPEG-2/DVB networks. > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-00.txt > > Address Resolution for IP datagrams over MPEG-2 networks. > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt > > > > To subscribe to the mailing list: > > send "subscribe ip-dvb" in the BODY part of an email to "majordomo@erg.abdn.ac.uk" > > The mailing list archives are at: > http://www.erg.abdn.ac.uk/ip-dvb/archive > From owner-ip-dvb@erg.abdn.ac.uk Sun Jun 29 14:03:51 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5TD3UnL014038 for ; Sun, 29 Jun 2003 14:03:30 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h5TD3UBU014037 for ip-dvb-subscribed-users; Sun, 29 Jun 2003 14:03:30 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from sh.csm.jcsat.co.jp (root@sh.csm.jcsat.co.jp [163.142.0.34]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5TD2MnL013999 for ; Sun, 29 Jun 2003 14:02:23 +0100 (BST) Received: from csm.jcsat.co.jp ([202.212.167.184]) by sh.csm.jcsat.co.jp (8.12.8/3.7W) with ESMTP id h5TCgk8R008197 for ; Sun, 29 Jun 2003 21:42:46 +0900 (JST) Message-ID: <3EFEE357.3030409@csm.jcsat.co.jp> Date: Sun, 29 Jun 2003 22:02:15 +0900 From: TAKEI jun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: BoF Announcement for IETF-57, Vienna: (IP over MPEG-2) References: <3EF77A7B.12D6E902@erg.abdn.ac.uk> In-Reply-To: <3EF77A7B.12D6E902@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry, I believe this BOF is continuous work from the unofficial BOF in Salt lake city IETF and the situation has not been changed a lot. Based on the information which I have and the situation in Japan, urgent issue related on MPEG/DVB is IPv6 encapsulation. In terms of IPv4, there are existing standard even though it was not defined by IETF and it is not efficient ;-). If the WG try to define new encapsulation mechanism of IPv4, it needs strong merit ,reason and a time to make it be RFC. But IPv6, there are few mechanism which can handle on MPEG/DVB-TS(I am not saying no standard). So my comment is WG should focus on IPv6 encapsulation. Hopefully it should be better that current MPE mechanism by using lessons and learned from IPv4 experience. Second item which on the agenda, address resolution between MPEG PID and IP address. Those address space are totally different each other. And normally PID assignment has already done by service provider(TV broadcasting company, IP service provider, etc.) or satellite operator. So it is difficult to assign specific IP address to specific PID. Maybe it is better to define new service mapping table like NIT, PAT and PMT. Anyway this is the start point of the discussion. I hope we can define something from IETF. Best regards, Jun Takei Dr G Fairhurst wrote: > A BOF will be held in Vienna on the subject of building standards for IP > networks using MPEG-2 Transport Stream transmission. This is intended to > cover issues common to implementors/operators wishing to build efficient > IP transmission networks using DVB, ATSC, etc. Satellite systems are > currently a major user of this technology. The description is below. > > For the current (as yet provisional scheduling see): > > http://www.ietf.org/meetings/ > > IP over MPEG-2/DVB Transport > ============================ > > BoF Description > --------------- > > The MPEG-2 Transport Stream provides a transmission network that has > become widely use to support digital TV broadcast, including: DVB, DAB, > ATSC, ISDB-T. These and related standards define a set of commercially > available components that are increasingly being used to provide a > general-purpose packet transmission network. MPEG-2 Transport networks > are being used to build IP networks to supplement broadcast TV/audio > services and also to provide one-way and two-way IP-only subnetworks. > > The BOF will explore how the IETF might work to define documents that > describe the protocols required to build a complete IPv4/IPv6 > unicast/multicast service, and the mappings that are needed to perform > address resolution, etc. A set of Internet Drafts will be reviewed > describing requirements, and some proposed protocols. > > > DRAFT AGENDA > ============ > > CHAIRS: > Gorry Fairhurst > Bernhard Collini-Nocker > > Agenda Bashing (5 minutes) > - Election of scribes (jabber scribe?) > > > What is MPEG-2? and Why is this an IETF activity? (10 minutes) > draft-fair-ipdvb-req-03.txt > Bernhard Collini-Nocker > > Lightweight Encapsulation (15 minutes) > draft-clausen-ipdvb-enc-01.txt > draft-fair-ipdvb-ule-00.txt > Gorry Fairhurst > > Address Resolution for IPv4/IPv6 (10 minutes) > draft-fair-ipdvb-ar-00.txt > (tbc) > > Proposed Roadmap (15 minutes) > Gorry Fairhurst > - STANDARDS TRACK RFC on Encapsulation (review Oct 2003) (to > IESG by > Dec 2003) > - INFO RFC on Address Resolution (review Mar 2004) (to IESG by > June 2004) > - INFO RFC on Architecture (review Mar 2004) (to IESG by Jun 2004) > > Open mic discussion > - Protocol issues? > - Deployment issues? > - Does this need an IETF WG? > > > References: > > http://www.erg.abdn.ac.uk/ip-dvb/ > > Requirements for transmission of IP datagrams over MPEG-2/DVB networks. > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-03.txt > > Simple Encapsulation for transmission of IP datagrams over MPEG-2/DVB > networks. > http://www.ietf.org/internet-drafts/draft-clausen-ipdvb-enc-01.txt > > Ultra Lightweight Encapsulation (ULE) for transmission of IP datagrams > over MPEG-2/DVB networks. > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ule-00.txt > > Address Resolution for IP datagrams over MPEG-2 networks. > http://www.ietf.org/internet-drafts/draft-fair-ipdvb-ar-00.txt > > > > To subscribe to the mailing list: > > send "subscribe ip-dvb" in the BODY part of an email to "majordomo@erg.abdn.ac.uk" > > The mailing list archives are at: > http://www.erg.abdn.ac.uk/ip-dvb/archive >