From owner-ipdvb@erg.abdn.ac.uk Wed Oct 05 06:12:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6Fz-0005rl-Ln for ipdvb-archive@megatron.ietf.org; Wed, 05 Oct 2005 06:12:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11451 for ; Wed, 5 Oct 2005 06:12:13 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6Oq-0006LK-7I for ipdvb-archive@ietf.org; Wed, 05 Oct 2005 06:21:25 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j959q09x026674 for ; Wed, 5 Oct 2005 10:52:00 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j959q0MC026672 for ipdvb-subscribed-users; Wed, 5 Oct 2005 10:52:00 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp.e7even.com (smtp.e7even.com [83.151.192.5]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j959pjHn026654 for ; Wed, 5 Oct 2005 10:51:46 +0100 (BST) Received: (qmail 12419 invoked from network); 5 Oct 2005 09:51:39 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost with SMTP; 5 Oct 2005 09:51:39 -0000 Received: from smtp.e7even.com ([127.0.0.1]) by localhost (gateway [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09540-09 for ; Wed, 5 Oct 2005 10:51:38 +0100 (BST) Received: (qmail 12393 invoked from network); 5 Oct 2005 09:51:38 -0000 Received: from unknown (HELO desktopmort) (83.151.198.217) by smtp.e7even.com with SMTP; 5 Oct 2005 09:51:38 -0000 Message-ID: <004701c5c992$60b7e5c0$0700000a@desktopmort> From: "Robert Mort" To: Cc: References: <3FE10A5C09BEE173EDC46BFA@[10.0.1.2]> Subject: ETSI BSM drafts on QoS and Security Date: Wed, 5 Oct 2005 10:51:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at e7even.com X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Dear All, The ETSI BSM group is active in several aspects of standardisation and, through its STF task force, has produced two new draft specifications on QoS Functional Architecture and Security Architecture. These are available at http://portal.etsi.org/STFs/SES/STF283.asp. Whilst these documents are considered 70-80% complete, your comments, especially on their overall approach, will be much appreciated in order to refine these documents before the final draft stage foreseen in several weeks. Best Regards Robert Mort BSM/STF283 From owner-ipdvb@erg.abdn.ac.uk Fri Oct 07 18:20:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0a3-0007a1-UV for ipdvb-archive@megatron.ietf.org; Fri, 07 Oct 2005 18:20:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29342 for ; Fri, 7 Oct 2005 18:20:40 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO0jQ-0007Mf-27 for ipdvb-archive@ietf.org; Fri, 07 Oct 2005 18:30:25 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j97MDglF011941 for ; Fri, 7 Oct 2005 23:13:42 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j97MDgYE011940 for ipdvb-subscribed-users; Fri, 7 Oct 2005 23:13:42 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j97MDYLv011922 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 Oct 2005 23:13:34 +0100 (BST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j97MAga9023831 for ; Sat, 8 Oct 2005 01:10:45 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Oct 2005 01:13:32 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Oct 2005 01:13:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IP over DVB-S2 requirements draft Date: Sat, 8 Oct 2005 01:13:30 +0300 Message-ID: <7222D14EF47E0840AD88EC7BCBAD8513011D6302@trebe101.NOE.Nokia.com> Thread-Topic: IP over DVB-S2 requirements draft Thread-Index: AcXFwdlSFxGCHwBuRreo1J4CMM+xlQFyaBXw From: To: X-OriginalArrivalTime: 07 Oct 2005 22:13:31.0755 (UTC) FILETIME=[5A1BABB0:01C5CB8C] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j97MDfes011937 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 8bit Hi Juan Has there been any follow up on the DVB-S2 liaisons following the action point in IETF63? If so, please keep the email list up to date with progress. If not, you'll keep banging against the same wall: "is this really of benefit to the internet community without DVB-S2 adoption?" (The answer being "no", unless there's some major innovation in standards procedures!) Sorry to be the wet blanket in this, just that it seems sensible only to employ your talent in the IETF on something which offers realistic chances of deployment. (BTW, this only applies to WG adoption of the draft, and I'm happy to see individual efforts for academic or any interest, though I got the impression you are aiming at WG adoption). Cheers, Rod. ________________________________ From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of ext Juan Cantillo Sent: 30 September, 2005 14:50 To: ipdvb@erg.abdn.ac.uk Subject: IP over DVB-S2 requirements draft Dear all, Following the 63th meeting discussions, we have produced a brand-new version of our document concerning the IP/DVB-S2 issues. The I-D "draft-cantillo-ipdvb-s2encaps-01.txt" si bnow available online at: http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-01.txt We look forward to discussing the draft together in Vancouver. Of course, we warmly encourage you to take a look at it from now; comments, questions and remarks are most welcome via @. Best regards, ----------------------------------------------------------------------- Juan CANTILLO - SatComs PhD. Researcher Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 ENST/TeSA/ENSICA/AAS, Toulouse, FR From owner-ipdvb@erg.abdn.ac.uk Mon Oct 10 13:37:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP1b3-0007eu-Vv for ipdvb-archive@megatron.ietf.org; Mon, 10 Oct 2005 13:37:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08159 for ; Mon, 10 Oct 2005 13:37:56 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP1ky-0002pv-FY for ipdvb-archive@ietf.org; Mon, 10 Oct 2005 13:48:14 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9AHLgt8014678 for ; Mon, 10 Oct 2005 18:21:42 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9AHLgrU014677 for ipdvb-subscribed-users; Mon, 10 Oct 2005 18:21:42 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9AHLNPG014660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Oct 2005 18:21:23 +0100 (BST) Message-ID: <434AA315.7010501@erg.abdn.ac.uk> Date: Mon, 10 Oct 2005 18:21:25 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernhard Collini-Nocker CC: Ang Way Chuang , ipdvb@erg.abdn.ac.uk Subject: Re: Typo errors in draft-ietf-ipdvb-ule-06.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 1.2 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit You are quite correct, thank you for your careful reading! However, Bernhard is also correct in that we have an Author's note to fix this before this is made an RFC (it managed to remain uncorrected in the last rev's of the I-D). If you (or any one else in the WG) do spot any more errors, or possible mistakes, do let us know! Best wishes, Gorry (ipdvb WG Chair) Bernhard Collini-Nocker wrote: > Dear Ang Way Chuang, > > many thanks for the notification. Actually we have been pointed on these > issues already earlier (some two month ago, should be in the ipdvb mailing > list archive) and the typos have been fixed. > > Kind regards, > Bernhard > > On Fri, 7 Oct 2005, Ang Way Chuang wrote: > > >>Dear Sir, >> I think I've found typo errors in the above mentioned document. In >>the diagram of example A.2, all of the SNDU length values are >>incorrect. 0x63, 0x62, 0x61 and 0x65 should be changed to 0xb3, 0xb2, >>0xb1 and 0xb5 respectively. 6 looks similar to b, I guess. >> >> >>Regards, >>Ang Way Chuang >> > > > From owner-ipdvb@erg.abdn.ac.uk Mon Oct 10 13:49:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP1mF-00029Z-0Z for ipdvb-archive@megatron.ietf.org; Mon, 10 Oct 2005 13:49:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08773 for ; Mon, 10 Oct 2005 13:49:29 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP1wB-0003AY-G4 for ipdvb-archive@ietf.org; Mon, 10 Oct 2005 13:59:48 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9AHYqxC015613 for ; Mon, 10 Oct 2005 18:34:52 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9AHYqTH015612 for ipdvb-subscribed-users; Mon, 10 Oct 2005 18:34:52 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9AHYkc0015594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Oct 2005 18:34:46 +0100 (BST) Message-ID: <434AA638.3010702@erg.abdn.ac.uk> Date: Mon, 10 Oct 2005 18:34:48 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: Axel.Jahn@triagnosys.com Subject: Re: IP over DVB-S2 requirements draft References: <7222D14EF47E0840AD88EC7BCBAD8513011D6302@trebe101.NOE.Nokia.com> In-Reply-To: <7222D14EF47E0840AD88EC7BCBAD8513011D6302@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit At the moment, the above I-D is an individual submission, and it is not chartered as a working group work item. I still do encourage discussion of this on the ipdvb WG list, not only because there may be opportunities for defining common methods (e.g. with ULE) for header compression, security, and other extensions; but because there is a body of expertise in this community that could usefully contribute thinking on this topic. As regards the DVB-S2 encapsulation study group of DVB-GS, activity has been slow over the summer months. The next event will be a document outlining requirements for evaluation of possible methods - which is currently a work in progress within the study group. This is expected soon, and then work on protocol detail may begin with the study group. The chair of the study group is on this email list (as are many members of the DVB study group and ETSI). Best wishes, Gorry (ipdvb WG Chair) Rod.Walsh@nokia.com wrote: > Hi Juan > > Has there been any follow up on the DVB-S2 liaisons following the action > point in IETF63? If so, please keep the email list up to date with > progress. > > If not, you'll keep banging against the same wall: "is this really of > benefit to the internet community without DVB-S2 adoption?" (The answer > being "no", unless there's some major innovation in standards > procedures!) > > Sorry to be the wet blanket in this, just that it seems sensible only to > employ your talent in the IETF on something which offers realistic > chances of deployment. > > (BTW, this only applies to WG adoption of the draft, and I'm happy to > see individual efforts for academic or any interest, though I got the > impression you are aiming at WG adoption). > > Cheers, Rod. > > > > > > ________________________________ > > From: owner-ipdvb@erg.abdn.ac.uk > [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of ext Juan Cantillo > Sent: 30 September, 2005 14:50 > To: ipdvb@erg.abdn.ac.uk > Subject: IP over DVB-S2 requirements draft > > > Dear all, > > Following the 63th meeting discussions, we have produced a > brand-new version of our document concerning the IP/DVB-S2 issues. The > I-D "draft-cantillo-ipdvb-s2encaps-01.txt" si bnow available online at: > > > http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-01.txt > t> > > We look forward to discussing the draft together in Vancouver. > Of course, we warmly encourage you to take a look at it from now; > comments, questions and remarks are most welcome via @. > > Best regards, > > > ----------------------------------------------------------------------- > Juan CANTILLO - SatComs PhD. Researcher > Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 > ENST/TeSA/ENSICA/AAS, Toulouse, FR > > > > > > From owner-ipdvb@erg.abdn.ac.uk Tue Oct 11 06:11:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPH6b-0005uy-Ho for ipdvb-archive@megatron.ietf.org; Tue, 11 Oct 2005 06:11:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11808 for ; Tue, 11 Oct 2005 06:11:30 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPHGf-0003DV-Tu for ipdvb-archive@ietf.org; Tue, 11 Oct 2005 06:21:59 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9BA466J021875 for ; Tue, 11 Oct 2005 11:04:06 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9BA46tb021874 for ipdvb-subscribed-users; Tue, 11 Oct 2005 11:04:06 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (loghost.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9BA40u9021846 for ; Tue, 11 Oct 2005 11:04:00 +0100 (BST) Received: from DrCerebro (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with SMTP id j9BA45W15874 for ; Tue, 11 Oct 2005 12:04:05 +0200 (MEST) Message-ID: <000801c5ce4b$0d439890$877a36c1@DrCerebro> From: "Juan Cantillo" To: "IPDVB" Subject: Correction to draft-cantillo-ipdvb-s2encaps-01.txt Date: Tue, 11 Oct 2005 12:03:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C5CE5B.D09A0DF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 1.0 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C5CE5B.D09A0DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I have just received a mail from a careful reader, pointing out a = correction to be done to our draft cantillo-ipdvb-s2encaps-01: >>Hi, >> >>I found an error in the document draft-cantillo-ipdvb-s2encaps-01.txt = on page 9: >>DFL in the figure 2 is described as being of length of 1 byte, where = actually it is 2 bytes (which are ofcourse needed >>to store the range of 0b-58112b. >> >>Ulrik De Bie Cheers, ----------------------------------------------------------------------- Juan CANTILLO - SatComs PhD. Researcher Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 ENST/TeSA/ENSICA/AAS, Toulouse, FR ------=_NextPart_000_0005_01C5CE5B.D09A0DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
I have just received a mail from a careful = reader,=20 pointing out a correction to be done to our draft=20 cantillo-ipdvb-s2encaps-01:
 
>>Hi,
>>
>>I = found an=20 error in the document draft-cantillo-ipdvb-s2encaps-01.txt on page=20 9:
>>DFL in the figure 2 is described as being of length of 1 = byte,=20 where actually it is 2 bytes (which are ofcourse needed
>>to = store the=20 range of 0b-58112b.
>>
>>Ulrik = De=20 Bie
 
Cheers,
---------------------------------------------------------= --------------
Juan=20 CANTILLO - SatComs PhD. Researcher
Tel +33 6 23 54 59 65- Fax  = +33 5 61=20 61 86 88
ENST/TeSA/ENSICA/AAS, Toulouse, = FR
------=_NextPart_000_0005_01C5CE5B.D09A0DF0-- From owner-ipdvb@erg.abdn.ac.uk Tue Oct 11 07:30:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIL1-0006zM-H7 for ipdvb-archive@megatron.ietf.org; Tue, 11 Oct 2005 07:30:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15606 for ; Tue, 11 Oct 2005 07:30:30 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIV5-0005HJ-DX for ipdvb-archive@ietf.org; Tue, 11 Oct 2005 07:40:57 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9BBOiTD027787 for ; Tue, 11 Oct 2005 12:24:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9BBOi4J027786 for ipdvb-subscribed-users; Tue, 11 Oct 2005 12:24:44 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (mermoz.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9BBOaTV027769 for ; Tue, 11 Oct 2005 12:24:36 +0100 (BST) Received: from DrCerebro (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with SMTP id j9BBObW01526 ; Tue, 11 Oct 2005 13:24:37 +0200 (MEST) Message-ID: <001101c5ce56$4cfa2b60$877a36c1@DrCerebro> From: "Juan Cantillo" To: , "IPDVB" Subject: Re: IP over DVB-S2 requirements draft Date: Tue, 11 Oct 2005 13:24:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C5CE67.0FEA3DD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.6 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C5CE67.0FEA3DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Rod, As Gorry pointed out, DVB is fully aware of our actions at IETF. = Furthermore, WE are ourselves involved in DVB through Alcatel Alenia = Space. From their side, the next step will be the release of a document = outlining requirements, much as we have just done. This will give the = basis for a new ID in which we will be able to integrate some concrete = propositions (as well as some numerical analysis to back our ideas), and = start make our views converge. WG adoption or not is not a primary = concern now :-) Cheers, ----------------------------------------------------------------------- Juan CANTILLO - SatComs PhD. Researcher Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 ENST/TeSA/ENSICA/AAS, Toulouse, FR ------=_NextPart_000_000E_01C5CE67.0FEA3DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Rod,
 
As Gorry pointed out, DVB is fully aware of = our actions=20 at IETF. Furthermore, WE are ourselves involved in DVB through Alcatel = Alenia=20 Space. From their side, the next step will be the release of a document=20 outlining requirements, much as we have just done. This will give the = basis for=20 a new ID in which we will be able to integrate some concrete = propositions (as=20 well as some numerical analysis to back our ideas), and start make our = views=20 converge. WG adoption or not is not a = primary=20 concern now :-)
 
Cheers,

---------------------------------------------------= --------------------
Juan=20 CANTILLO - SatComs PhD. Researcher
Tel +33 6 23 54 59 65- Fax  = +33 5 61=20 61 86 88
ENST/TeSA/ENSICA/AAS, Toulouse, = FR
------=_NextPart_000_000E_01C5CE67.0FEA3DD0-- From owner-ipdvb@erg.abdn.ac.uk Sun Oct 16 14:12:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERCzg-0007zI-3a for ipdvb-archive@megatron.ietf.org; Sun, 16 Oct 2005 14:12:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14020 for ; Sun, 16 Oct 2005 14:12:18 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERDAo-0001Cu-SS for ipdvb-archive@ietf.org; Sun, 16 Oct 2005 14:23:57 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9GHql8D015570 for ; Sun, 16 Oct 2005 18:52:47 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9GHqlT1015569 for ipdvb-subscribed-users; Sun, 16 Oct 2005 18:52:47 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.111] (maxp21.dialup.abdn.ac.uk [139.133.201.180]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9GHqHqj015532 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sun, 16 Oct 2005 18:52:34 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 16 Oct 2005 15:29:16 +0100 Subject: Re: IP over DVB-S2 - crc usage? From: Gorry Fairhurst To: CC: Message-ID: In-Reply-To: <42B83CAD.6010709@sunaut.uab.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.7 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Fausto, I'm trying to understand the main outstanding issues. I agree there are a set of DVB-S.2 BB header fields that may be re-used to carry the protocol control information for the encapsulation layer. This seems like the correct way to go. Many BB header fields are not defined/used for the Generic Mode, but I don't yet know (maybe others are wiser) exactly which fields may be safely (re)used and for a S.2 generic encapsulation and still remain compatible the DVB-S.2 spec. This is probably an area that needs to be cleared with the DVB S.2 group. My main query relates to your comment about the optional CRC fields. I'm puzzled by your suggestion that requirements for CRC usage may be related to the presence of padding in the BB frame. My thoughts were that the CRC requirement stemmed from: (i) The need to verify the integrity of the payload (PDU) before passing to the IP layer - to mitigate the impact of link errors and low level errors in data movement. (ii) To verify the framing (length) of PDUs - ensuring the next SNDU header was correctly located within the BB frame payload. (iii) To verify the integrity of reassembled SNDUs. (iv) To allow a receiver to monitor the quality of the received bitstream. - I can see how (i) relates to worst case expected link error characteristics, but don't see yet how this can be related to the presence or absence of padding bytes. Thoughts? Gorry From owner-ipdvb@erg.abdn.ac.uk Mon Oct 17 03:34:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERPVU-0004Df-TG for ipdvb-archive@megatron.ietf.org; Mon, 17 Oct 2005 03:34:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22402 for ; Mon, 17 Oct 2005 03:33:58 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERPgm-0003hm-Jl for ipdvb-archive@ietf.org; Mon, 17 Oct 2005 03:45:45 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9H7QVcj012655 for ; Mon, 17 Oct 2005 08:26:31 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9H7QVqO012654 for ipdvb-subscribed-users; Mon, 17 Oct 2005 08:26:31 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9H7QP9Q012637 for ; Mon, 17 Oct 2005 08:26:25 +0100 (BST) Received: from p5499283C.dip0.t-ipconnect.de [84.153.40.60] (helo=[192.168.10.3]) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1ERPO442SW-0007Dt; Mon, 17 Oct 2005 09:26:24 +0200 Message-ID: <4353522E.6060700@triagnosys.com> Date: Mon, 17 Oct 2005 09:26:38 +0200 From: "Axel Jahn, TriaGnoSys GmbH" Organization: TriaGnoSys GmbH User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: IP over DVB-S2 requirements draft References: <7222D14EF47E0840AD88EC7BCBAD8513011D6302@trebe101.NOE.Nokia.com> <434AA638.3010702@erg.abdn.ac.uk> In-Reply-To: <434AA638.3010702@erg.abdn.ac.uk> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:6e03a4d43a033f8425468b816f4854cd X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Dear colleagues, as Gorry pointed out, the TM-GBS working group of DVB is working on an encapsulation protocol for S2 Generic Streams as well. The group is now editing a requirement document (which includes as well simulation assumptions for performance evaluation). As it would definitely make sense to exchange this document, I will ask the GBS group to release the document to ipdvb. regards, Axel Gorry Fairhurst wrote: > > At the moment, the above I-D is an individual submission, and it is > not chartered as a working group work item. I still do encourage > discussion of this on the ipdvb WG list, not only because there may be > opportunities for defining common methods (e.g. with ULE) for header > compression, security, and other extensions; but because there is a > body of expertise in this community that could usefully contribute > thinking on this topic. > > As regards the DVB-S2 encapsulation study group of DVB-GS, activity > has been slow over the summer months. The next event will be a > document outlining requirements for evaluation of possible methods - > which is currently a work in progress within the study group. This is > expected soon, and then work on protocol detail may begin with the > study group. > > The chair of the study group is on this email list (as are many > members of the DVB study group and ETSI). > > Best wishes, > > Gorry > (ipdvb WG Chair) > > Rod.Walsh@nokia.com wrote: > >> Hi Juan >> >> Has there been any follow up on the DVB-S2 liaisons following the action >> point in IETF63? If so, please keep the email list up to date with >> progress. >> >> If not, you'll keep banging against the same wall: "is this really of >> benefit to the internet community without DVB-S2 adoption?" (The answer >> being "no", unless there's some major innovation in standards >> procedures!) >> >> Sorry to be the wet blanket in this, just that it seems sensible only to >> employ your talent in the IETF on something which offers realistic >> chances of deployment. >> >> (BTW, this only applies to WG adoption of the draft, and I'm happy to >> see individual efforts for academic or any interest, though I got the >> impression you are aiming at WG adoption). >> >> Cheers, Rod. >> >> >> >> >> >> ________________________________ >> >> From: owner-ipdvb@erg.abdn.ac.uk >> [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of ext Juan Cantillo >> Sent: 30 September, 2005 14:50 >> To: ipdvb@erg.abdn.ac.uk >> Subject: IP over DVB-S2 requirements draft >> >> >> Dear all, >> Following the 63th meeting discussions, we have produced a >> brand-new version of our document concerning the IP/DVB-S2 issues. The >> I-D "draft-cantillo-ipdvb-s2encaps-01.txt" si bnow available online >> at: >> http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-01.txt >> > t> We look forward to discussing the draft together in >> Vancouver. >> Of course, we warmly encourage you to take a look at it from now; >> comments, questions and remarks are most welcome via @. >> Best regards, >> >> >> ----------------------------------------------------------------------- >> Juan CANTILLO - SatComs PhD. Researcher >> Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 >> ENST/TeSA/ENSICA/AAS, Toulouse, FR >> >> >> > > From owner-ipdvb@erg.abdn.ac.uk Mon Oct 17 09:28:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERV2V-0007NQ-I7 for ipdvb-archive@megatron.ietf.org; Mon, 17 Oct 2005 09:28:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12084 for ; Mon, 17 Oct 2005 09:28:24 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVDl-0005ym-6A for ipdvb-archive@ietf.org; Mon, 17 Oct 2005 09:40:14 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9HDFhFE011804 for ; Mon, 17 Oct 2005 14:15:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9HDFhMc011803 for ipdvb-subscribed-users; Mon, 17 Oct 2005 14:15:43 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from istanbul.uab.es (istanbul.uab.es [158.109.168.138]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9HDFaLN011781 for ; Mon, 17 Oct 2005 14:15:37 +0100 (BST) Received: from istanbul.uab.es (localhost [127.0.0.1]) by istanbul.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0IOI003KCAB20U50@istanbul.uab.es> for ipdvb@erg.abdn.ac.uk; Mon, 17 Oct 2005 15:18:38 +0200 (CEST) Received: from [127.0.0.1] ([158.109.69.162]) by istanbul.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0IOI00FBCAB2LA20@istanbul.uab.es> for ipdvb@erg.abdn.ac.uk; Mon, 17 Oct 2005 15:18:38 +0200 (CEST) Date: Mon, 17 Oct 2005 15:20:35 +0200 From: Fausto Vieira Subject: Re: IP over DVB-S2 - crc usage? In-reply-to: To: ipdvb@erg.abdn.ac.uk Message-id: <4353A523.3020708@sunaut.uab.es> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed X-Accept-Language: en-us, en References: User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j9HDFhFE011804 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Well, my idea was that sometimes it is not possible to fill the entire=20 BB frame with packets, either because you want to expedite the=20 transmission of the frame or because you don't have enough bytes left to=20 start a new packet. In these cases, I imagine that some padding would be=20 required at the end of the BB frame. Instead of wasting these bytes, you=20 could insert a CRC that should decrease the number of errors at a frame=20 level. It is my understanding that the standard guarantees something=20 like 10^-7 BER. My question is in fact if you can live without a CRC, especially=20 considering the problem with transport layer retransmissions with high=20 round trip times. Maybe I'm seeing this with incorrect assumptions, especially on the=20 nature of errors. Well, this was my reasoning for the optional CRC. Regards Fausto Gorry Fairhurst wrote: >Fausto, > >I'm trying to understand the main outstanding issues. > >I agree there are a set of DVB-S.2 BB header fields that may be re-used = to >carry the protocol control information for the encapsulation layer. This >seems like the correct way to go. Many BB header fields are not defined/= used >for the Generic Mode, but I don't yet know (maybe others are wiser) exac= tly >which fields may be safely (re)used and for a S.2 generic encapsulation = and >still remain compatible the DVB-S.2 spec. This is probably an area that >needs to be cleared with the DVB S.2 group. > >My main query relates to your comment about the optional CRC fields. I'm >puzzled by your suggestion that requirements for CRC usage may be relate= d to >the presence of padding in the BB frame. My thoughts were that the CRC >requirement stemmed from: > > (i) The need to verify the integrity of the payload (PDU) before > passing to the IP layer - to mitigate the impact of link errors > and low level errors in data movement. > > (ii) To verify the framing (length) of PDUs - ensuring the next > SNDU header was correctly located within the BB frame payload. > > (iii) To verify the integrity of reassembled SNDUs. > > (iv) To allow a receiver to monitor the quality of the > received bitstream. > >- I can see how (i) relates to worst case expected link error >characteristics, but don't see yet how this can be related to the presen= ce >or absence of padding bytes. > >Thoughts? > >Gorry > > > =20 > --=20 Fausto Vieira Researcher Dpt. Telecomunicaci=F3 i d'Enginyeria de Sistemes ETSE - UNIVERSITAT AUT=D2NOMA DE BARCELONA Campus Universitari, s/n 08193 Bellatera Barcelona SPAIN Phone :(34) 935813843 Fax :(34) 935814031=20 From owner-ipdvb@erg.abdn.ac.uk Wed Oct 19 11:34:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESFxi-0005Mb-Pr for ipdvb-archive@megatron.ietf.org; Wed, 19 Oct 2005 11:34:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23323 for ; Wed, 19 Oct 2005 11:34:34 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESG9S-0006uW-UA for ipdvb-archive@ietf.org; Wed, 19 Oct 2005 11:46:52 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9JFF9bF025236 for ; Wed, 19 Oct 2005 16:15:09 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9JFF95D025233 for ipdvb-subscribed-users; Wed, 19 Oct 2005 16:15:09 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mailg.surrey.ac.uk (mailg.surrey.ac.uk [131.227.102.21]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j9JFF1Qb025023 for ; Wed, 19 Oct 2005 16:15:01 +0100 (BST) Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 19 Oct 2005 16:02:54 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Oct 2005 16:02:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt Date: Wed, 19 Oct 2005 16:02:52 +0100 Message-ID: Thread-Topic: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt Thread-Index: AcW90yV4NgaSX2mOTJqcyIjq4bY7QAW6WOWA From: "H.Cruickshank" To: ipdvb X-OriginalArrivalTime: 19 Oct 2005 15:02:53.0140 (UTC) FILETIME=[2E0CE940:01C5D4BE] X-ERG-MailScanner: Found to be clean, Found to be clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j9JFF8tR025222 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 8bit Hi IPDVB members, Few weeks ago, Gorry raise some interesting issues in his email regarding the draft above. I certainly agree with points 1 and 2 are good and should be included in the draft (in Gorry email below). Regarding points 3 (threats and relationship with IPDVB architecture scenarios, packet authentications etc..) and 4 (signalling security) are interesting and I really hope that people with practical and operational experience should try to comment on these issues. So that the IP-DVB security requirement draft can capture these issues correctly. Many thanks -- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: 20 September 2005 10:18 To: ipdvb@erg.abdn.ac.uk Cc: Haitham Cruickshank; Iyengar S Mr (CCSR); stephane.combes@space.alcatel.fr; Laurence.Duquerroy@space.alcatel.fr Subject: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt This draft raises several issues, and seems to me to be a good start, at a document that would be useful to this WG. I'd like to get more opinions on what the document does say, and what it does not, so that we can understand whether this fits the needs of this WG. Can I encourage people to read thsi and send comments to the list? I have some comments below, to start this process: Section 1.1: ----- 1) In 1.1 it is may also be worth stating that the service to be protected is the stream (TS Logical Channel) that is between the Encapsulation Gateway and Receiver. This stream is identified at the Gateway and Receiver by a unique PID value associated with the stream (although at the two ends of the link may have differing values, since this can be and is modified in the MPEG2 Transmission Network). ----- 2) It also could perhaps be staring that although a number of components operate within the network. For the IP network service, they do not modify the packet payload. ----- Section 2: Threats ----- 3) I wonder if there are any thoughts on the different "Access to the Channel" related to the set of scenarios in section 3.1 of draft-ietf-ipdvb-arch-xx.txt. - Specifically do people see different threats being important in TV-oriented networks that are contribution/broadcast carrying IP data and networks that are more IP-oriented (with smaller transmit hubs/power)? - I do. - In broadcast networks, it is probably hard to access the ground network at the transmitter (or the contribution feed, in a digital TV scenario). It is therefore hard to modify the traffic sent on the broadcast up-link (from the modulator to the headend/satellite/mast) which would impact all receivers - this typically requires access to facilities and/or a large transmit power (as in Captain Midnight [Ref]). - In contrast, access to the air-interface of specific receivers is much easier. The signal at a Receiver is often much weaker (due to path propagation loss). This could potentially be jammed/replayed/over-loaded with another signal (e.g. A transmitter injecting a signal into the side-lobe of a satellite receive antenna). - DoS, traffic analysis, and other networking threats are more significant for IP-data than TV services, where the potential damage from malicous manipulation is greater. ETC.... ----- 4) I would like to have seen some discussion of the impact of modified/corrupted/forged signalling information on the Receiver. It is usually hard to inject different traffic or modify existing TS Packets within a stream, but through configuration of the (re)multiplexor, access to the physical media (e.g. connections between components), etc it is possible to replace a Stream with a different stream. This could also arise on the broadcast physical link (e.g. An unauthorised high-power transmitter overriding the intended transmission). However, note that the transmissions are normally continuous (rather than the discrete bursts, e.g. Used in 802.11, WiMAX). To successfully inject new/replacement traffic requires the physical layer FEC/modulation to be acquired by the Receiver. L2 signalling (MPEG2 SI) also needs to be consistent with the TS packets being sent. However, the current specifications for MPEG-2 [....] do not specify a method for authentication (or encryption) of the L2 signalling information. - Could we try to define some security properties of the signalling plane (I'd be happy to contribute some starting text)? - Perhaps this should also be identified as an assumption/issue in the Security Considerations section? ----- Hope that helps, Gorry From owner-ipdvb@erg.abdn.ac.uk Fri Oct 21 11:41:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESz1P-0005oW-2m for ipdvb-archive@megatron.ietf.org; Fri, 21 Oct 2005 11:41:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12964 for ; Fri, 21 Oct 2005 11:41:19 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESzDY-0002Qg-Mz for ipdvb-archive@ietf.org; Fri, 21 Oct 2005 11:54:05 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9LFNsxO026924 for ; Fri, 21 Oct 2005 16:23:54 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9LFNsbo026923 for ipdvb-subscribed-users; Fri, 21 Oct 2005 16:23:54 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mailg.surrey.ac.uk (mailg.surrey.ac.uk [131.227.102.21]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j9LFNlcx026874 for ; Fri, 21 Oct 2005 16:23:47 +0100 (BST) Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Fri, 21 Oct 2005 16:18:00 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 16:17:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5D652.9E49A57C" Subject: RE: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt Date: Fri, 21 Oct 2005 16:17:58 +0100 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD20A@EVS-EC1-NODE1.surrey.ac.uk> X-MS-TNEF-Correlator: <018160DBE8D48349A0CABF4424C3DC21AAD20A@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt Thread-Index: AcW90yWOj6fJLfp9RNOXIoYhjv/8xQYfsGux From: "S.Iyengar" To: ipdvb , gorry Cc: "H.Cruickshank" , "stephane.combes" , "Laurence.Duquerroy" X-OriginalArrivalTime: 21 Oct 2005 15:17:59.0307 (UTC) FILETIME=[9EFE85B0:01C5D652] X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D652.9E49A57C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gorry and all, =20 Thanks for all the comments. Regarding section 4 here's some input: =20 Concerning signalling, this is definitely a threat in order to mount = active attacks. But as we understand SI signalling does not have any = authentication /encryption and also it is considered a different plane. = Moreover some SI tables are important to be initially in plaintext for = the proper configuration of the terminals. This is definitely a threat. = Maybe people involved with SI tables and so can provide more insight = into the severity of this threat. =20 =20 Regards =20 Sunil Iyengar, Centre For Communication And Systems Research(CCSR), School of Electronics, Computing & Mathematics, University Of Surrey, Guildford GU2 7XH, Surrey, England, United Kingdom. ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst Sent: Tue 20/09/2005 10:18 To: ipdvb@erg.abdn.ac.uk Cc: Haitham Cruickshank; Iyengar S Mr (CCSR); = stephane.combes@space.alcatel.fr; Laurence.Duquerroy@space.alcatel.fr Subject: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt This draft raises several issues, and seems to me to be a good start, at = a document that would be useful to this WG. I'd like to get more opinions = on what the document does say, and what it does not, so that we can = understand whether this fits the needs of this WG. Can I encourage people to read = thsi and send comments to the list? I have some comments below, to start this process: Section 1.1: ----- 1) In 1.1 it is may also be worth stating that the service to be = protected is the stream (TS Logical Channel) that is between the Encapsulation = Gateway and Receiver. This stream is identified at the Gateway and Receiver by a = unique PID value associated with the stream (although at the two ends of the = link may have differing values, since this can be and is modified in the MPEG2 Transmission Network). ----- 2) It also could perhaps be staring that although a number of components operate within the network. For the IP network service, they do not = modify the packet payload. ----- Section 2: Threats ----- 3) I wonder if there are any thoughts on the different "Access to the = Channel" related to the set of scenarios in section 3.1 of = draft-ietf-ipdvb-arch-xx.txt. - Specifically do people see different threats being important in = TV-oriented networks that are contribution/broadcast carrying IP data and networks = that are more IP-oriented (with smaller transmit hubs/power)? - I do. - In broadcast networks, it is probably hard to access the ground = network at the transmitter (or the contribution feed, in a digital TV scenario). It = is therefore hard to modify the traffic sent on the broadcast up-link (from = the modulator to the headend/satellite/mast) which would impact all = receivers - this typically requires access to facilities and/or a large transmit = power (as in Captain Midnight [Ref]). - In contrast, access to the air-interface of specific receivers is much easier. The signal at a Receiver is often much weaker (due to path propagation loss). This could potentially be jammed/replayed/over-loaded with another signal (e.g. A transmitter injecting a signal into the side-lobe of a satellite receive antenna). - DoS, traffic analysis, and other networking threats are more = significant for IP-data than TV services, where the potential damage from malicous manipulation is greater. ETC.... ----- 4) I would like to have seen some discussion of the impact of modified/corrupted/forged signalling information on the Receiver. It is usually hard to inject different traffic or modify existing TS = Packets within a stream, but through configuration of the (re)multiplexor, = access to the physical media (e.g. connections between components), etc it is = possible to replace a Stream with a different stream. This could also arise on the broadcast physical link (e.g. An = unauthorised high-power transmitter overriding the intended transmission). However, = note that the transmissions are normally continuous (rather than the discrete bursts, e.g. Used in 802.11, WiMAX). To successfully inject = new/replacement traffic requires the physical layer FEC/modulation to be acquired by the Receiver. L2 signalling (MPEG2 SI) also needs to be consistent with the = TS packets being sent. However, the current specifications for MPEG-2 = [....] do not specify a method for authentication (or encryption) of the L2 signalling information. - Could we try to define some security properties of the signalling = plane (I'd be happy to contribute some starting text)? - Perhaps this should also be identified as an assumption/issue in the Security Considerations section? ----- Hope that helps, Gorry ------_=_NextPart_001_01C5D652.9E49A57C Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjsPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEANwAAAFJFOiBUaG91Z2h0cyBvbiBk cmFmdC1jcnVpY2tzaGFuay1pcGR2Yi1zZWMtcmVxLTAwLnR4dAByEwEFgAMADgAAANUHCgAVABAA EQA6AAUAWwEBIIADAA4AAADVBwoAFQAQABEAOgAFAFsBAQmAAQAhAAAARjQ4MDVEMDBGRUM0RDg0 OTlFRkUzRTc0OEYzMDY1NTkATAcBA5AGAEgcAAA4AAAAAwA2AAAAAABAADkAfKVJnlLWxQEeAD0A AQAAAAUAAABSRTogAAAAAAIBRwABAAAAMwAAAGM9VVM7YT0gO3A9VU5JUztsPUVWUy1FQzEtTk9E RTEtMDUxMDIxMTUxNzU4Wi0xMDg4AAAeAEkAAQAAADMAAABUaG91Z2h0cyBvbiBkcmFmdC1jcnVp Y2tzaGFuay1pcGR2Yi1zZWMtcmVxLTAwLnR4dAAAQABOAAAbkzXEvcUBHgBaAAEAAAAbAAAAb3du ZXItaXBkdmJAZXJnLmFiZG4uYWMudWsAAAIBWwABAAAAUwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QC AAAAAG93bmVyLWlwZHZiQGVyZy5hYmRuLmFjLnVrAFNNVFAAb3duZXItaXBkdmJAZXJnLmFiZG4u YWMudWsAAAIBXAABAAAAIAAAAFNNVFA6T1dORVItSVBEVkJARVJHLkFCRE4uQUMuVUsAHgBdAAEA AAAQAAAAR29ycnkgRmFpcmh1cnN0AAIBXgABAAAAQgAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAA AEdvcnJ5IEZhaXJodXJzdABTTVRQAGdvcnJ5QGVyZy5hYmRuLmFjLnVrAAAAAgFfAAEAAAAaAAAA U01UUDpHT1JSWUBFUkcuQUJETi5BQy5VSwAAAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEAAAAb AAAAb3duZXItaXBkdmJAZXJnLmFiZG4uYWMudWsAAB4AaAABAAAABQAAAFNNVFAAAAAAHgBpAAEA AAAVAAAAZ29ycnlAZXJnLmFiZG4uYWMudWsAAAAAHgBwAAEAAAAzAAAAVGhvdWdodHMgb24gZHJh ZnQtY3J1aWNrc2hhbmstaXBkdmItc2VjLXJlcS0wMC50eHQAAAIBcQABAAAAGwAAAAHFvdMljo+n yS36fUTTlyKGIY7//MUGH7BrsQAeAHMAAQAAAHAAAABIYWl0aGFtIENydWlja3NoYW5rOyBJeWVu Z2FyIFMgTXIgKENDU1IpOyBzdGVwaGFuZS5jb21iZXNAc3BhY2UuYWxjYXRlbC5mcjsgTGF1cmVu Y2UuRHVxdWVycm95QHNwYWNlLmFsY2F0ZWwuZnIAHgB0AAEAAAAVAAAAaXBkdmJAZXJnLmFiZG4u YWMudWsAAAAAHgAaDAEAAAAUAAAASXllbmdhciBTIE1yIChDQ1NSKQAeAB0OAQAAADMAAABUaG91 Z2h0cyBvbiBkcmFmdC1jcnVpY2tzaGFuay1pcGR2Yi1zZWMtcmVxLTAwLnR4dAAAAgEJEAEAAACo FAAApBQAALhBAABMWkZ1rCvhEAMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jB CsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2VkS72Y0EG8RezUDxlR8 YWgDcQKAEeMI7wn3O3scHw4wNR0/HRER4QxgY2cAUAsJAWQzNhFgC6U0siAQAipcDrIBkGcU8BcK oxHjImg0FPA8IUQAT0NUWVBFIEgAVE1MIFBVQkwASUMgIi0vL1dEM0MmAERURCUUM4QuMiYARU4i PiNt8yMPKEExOCRwJSInjyifjSsQMyIAKfBFQUQqTS8O8StvLe8pdDYO8DxNKEVUQQewQTDgPSKm RwnwBJBhdAWwIhcQaE9OVCdQVDFwBeFFongY4W5nZQZSdhMxBzPBAJACICA2LjUudQHAMjSAMCd+ L08pgzeCNyRwVElUTEUqTso0DvBUGuB1Zw6wBCCtNFFkMdABgC0FAHUN4CRrczMxay0FIGR2JGIt GSBjLR6gcS2oMDAuDNB0KO41JHD+LzfPNf8qxTkRPYAszysfBUFUNRFgPEJPRFlHQM0hcUHvZzk2 JHBEQElWIGlkPUZATxBXQVJlC1B5VGUTPEAeYDY5PWBkaXK6PUFwckDAQTMAISAAAM9H8QqxSOIY 4FxxAyFIVf8RYEOvRL9Fxke/SM9J2kEJXDY0TbpKDyl0NCnRRkkyUSBmANBlPQcTIFkbkz0jPABU wiAAkHrdU9AyTasYMAMwYxPwA7JDAdBJ6UhpIEcFsHL0eSAAcGQiHFZxS5MHQPxsLCj8R2A9cVNS TalNt39P+wHATbcKolxoCoAo/DD/LJEmYEYQW79R70tfTG9Nf/9Oj1yfUK9hv1LPU9ZVP1ZEX1b9 Wk9bX2GPQUU4IgAmMG5ic3ACgGVnXCf+YQFAZy9dn16vX79gz3DP/2LvY/9lD2Yfc39oP3ifal// a29sf1cbOUA64QQgAhAFwLFaASB0aDNwBaBtB4DJAjBzLgfwZWcLEQuA7mdYr3ojO4F0NEIiAIZA dR6gJwQgcwNwM3ALgHD4dXQ6bl9vb1xvdG91f/92j3efgE95v3rPe998733//38PgB+BL4I/g09t b4rvi///nk9xr3K/jV+Ob49/kI+gj/+Sr5O/lM+V35bvl/+ZD6lv/5svnD+dT7DPWUqob6RfrNb/ pi+rT6xfrW+uf6+PsJmz77+0/7GPsp+zr8GfCFBuU8BnBKCHcgCQZ25aAYdxLD+GIQQARjAEIAEB C4BpdP5lRvBYYLW/qqOGMB6gMeD/ilE5wAsgEzEx8KGvor+jyv0EYHUCMMxfzW+jyp7fn+//qP/D D8QfxS9W/QDQiTAzwL/J31m0AkAA0DqwhvBCipC7WGAEIHczcM9QBIFzAZBZWIFTScfJOfBvB5Fu /m8FQBjw2fEAcFhRipCGQL8CMA3gMeA0QtovqrIvCfD9BQB5BTA0QlhyB0CKEEYw/cuBc8+P0J+j ygWgAIEEgb8JgMmxu8ABIImxAjAgC1HLMbCG8E0FsGVvM8KKE+/dUeBPyvMBoGwHkQrAikE8bXAb wQBwBUAx8CBi/4pCyWAHMcmRy6ELU8lwPEDrhaOGMnADYHATMeYRyTDuZwhw3+9ZaG+8wIYyyXD8 cm0LgOKRhvA5QMi/ycDzyzTn0WF569HuIO4Q6oD9ilF2BvAzwFiQA/CGMOjPv+neWIHisd/Q7LED YHbmUf/PIerSAIE5gYpR66GGMhkgfzPByWBYUPCT8dH1b8r4Lv/Sb9N/t6n+H7gvpW+6D6eP//+P qa+qv7tPvF+9b75/v4//wJ/Br+NP5F+j2QR/AG8Bf/8CjwOfEk8FvwbPB98I7wn//wsPDB8NLw4/ D08QXxFvEn//E48UnxWvFr8XzxjfGe8a/38cDx0fHi8fPyBPKpiHFHP/Kf8l7yb/KA8pHzVfKz8s T/8tXy5vL38wjzGfMq8g/yIP/yMfJC81jzafN684vznPOt+/O+88/z4PPx9ALE5LMtYSv/2lQQ9C H9U/1k+GcGyFwDg9IzBaA9dPQ6VjZuoyQ/9T3KBpQED6z09SrEl54aCHMSxXfDH9cdxCUlrZUoDx QGVOQMaJ+4ax6tFGhcHHIIaQXTHf1cpB3SJ53PBlbfcAhxAHiQBPUEAAKENDU1KuKV9PYF9hbVNA AG/0gPf6Ml2PT1JF6oCJIO4AY1G+c8hwYwGKgYd/RdJh6xDdRlkmVtjzcYYxbe7haxH3ZZ9mr2F8 VceA+dHmQPoRVk9R4F0gcucwechwR5p1XVBkhbHdMEdVXADjaT9PUjdYSG9fcG9nru1zVUWHgOeR ZMhwcmHJcO3dMEtrsd4wbfx9dx94L//8j/2fSH9Jj0qfS69Mv32//4P/hQ+GH4cviD9Or0+/UM// Ud9S73tqXAB8TYyhfX+L/1mNDkhS7aD2wEncsXioPS0xWtwxQCBjQCAoalx1c/BiXBB+IP5fmTKY 8X0jgmOTX5RuVV/nVm9Xf1iJVGFosG7wWm/9Q6I1XB9r/nxAWtuY4aKHskbuAG06lWySES+kKguA WcvAd+ewci1pcJBkdmJAx2BnLvbAhGRuqaBjLnVry8B34jDr0N7AbI9AaQ+U9UfP7YDh0GKw7PBy aO7A3PD/ez98T31fo0+kX1zF35GmDzOnH24XVHXe8KJALzA0OS+iQDCh8ImwOjF+OK1/ro+vn7Cv sb+59FT+b7NvtH9uF6s/lSKpH6ohv7dfuG+5f7qPu59h9WO9L3u+P24XSOzw7bBtAGJAcodz0Nux 3sBuazsgXtX/9SDzcO5AZSTMEL/flSJkQS5wy9HnwO5gbevQc0A3RjDWsamgbN/R8qAuZnZyzW+V BEzfUOcx0AFEzHVxtiBzYG95z8/Cb5/Df8SPxZ/Gr1zGYmpqoe/IP8lPtYhosHX44fcA7x/FlPVk 7tBmdC3hwMuHJakELfmwYy3nMHEt+VoALnTtQNR/1Y/Wn35v/39/5D/iT+NfgL+Bz4LfiW//5l+a /5UPjada2+8fka+Sv+/zT/BvnMXt4FD030dP8s+/ns+f0KC/Q7Ez3N1Aad2wvd9TIN9g/5DPoP1A ZXKR+1lh/5BztiBrIXnxAIFkYvB0byBttjACMaqQAYB8IGdowGQA3g/OlPWgdHsBcQAAYeeP6J9h fHrwY751AmCzQJaQqrAAAHfdYOtz8AKydWTAZpiwAiJuwNH/kVdHLswgJ2QAYVDSawJzZ2UAAG1i 0LYw8wNv95JvcOPAY6HdsgVv+wZ/YXx3CQJuwQhYevAAYj5heYEBkhFTemASZG5v/QTxcwpSCRK2 MNPw3e/3dP9jQJbwrUF58Q5fD28QfgvQ927Q8MAKc2Z6YAIREbHPMC96gN2xj0AKd0MVMUkgj9KB 3WDfYAvAIHBlDaDfapACIhVv95LhEGFkAG7A/3LAF18Yb2F8AZRj8c9hCKLvAhMRomFQZEA/IF8h b+Pf/yVvJn9hqR0QqrBykBRhAmH3I+eqkFmwd2swHn/3kgIx+wSzCmRw0zCgEAEg2pwpDz8qHygv MK9nrmqhY6IxLu4xL58zrzG9LTliNm83f/lhfDEpzCA2AxOS/5Fu8P+swNPQFHEs//eSAsEJQOuw PmguYmujCPMRomTAcnb/Y2ACdi8hZFBqsHqB/5A5v586z2F8QPNigcsxKFTMsLhMb2djYV1v93RD y9G9zzBsPMAI8/+RqpB0FPDvzFARk3mw0/BwATB54GOT+kfQYXc9whc/Q89hXmSg/6AQcoIK4P9z RhVHT8Dj3bD2aZbws0BpGyB6gRF1S0n/TueqgD3RCcB6UNLxS/9ND8FhfFBJRCB209C2IXZhASAI cGnQYQNP93R3/8sBRcvT0G7A3WJSdknAAkD/I6Eb9STCy/A9olT/Vg9hfPMrU45AZmZyoGu/dXZY M/9rIXLA0pEKZBUiAsIjsT2CDwMwUiQxsBGTTVBFR24yXi9fPypcVN9gDgBtbwERSwJiH/eSTkmx dCBrfil7L2fPOH85j21fbm8y/zzBBTE+Ah1RCXEd0K0QSpH/ArIEskBnW6gUEAiQqpDwwO9qnw1j j0DPYXAOMCwyb8//cN8qXA2gAMHO4AkwWqFmBTfPMGwDCuBGDBARk0lQ/3y2QSYs0BqBrMAIYHZv 94P/FCFlZKzAGoF4n3mvKlzTgfcLYAAA94B5LKAf4Gxvgs//bo9vn4afh6+JD4ofiy+MP+eNTzT/ qnAyOn+P94PdQH8fwXh/j/+Hv4jPlU+WXyD+MzzBCTEWwgEAXUMMIfWg/2TigXLdaBGjYYMIspK/ 95K4IkFjL1IkZkiVIpfP/5jfKlzhEErRWREkdeDQAADVqwFzU9BudKFvUbGqcPvg0UrzMz0hqw/e 61JA68CD4GX1oGNoLXh44XL/ha+h/44fql+rb5a7zKAd0PdY0BsgRwFsf0Md1QHRnY/vLV6UFCxx YdJpeBHrsM8g4xOBpgBUVi0MEFJAUgD/WRCtP65PKlx+BRtSBSIML0/3Zc9gUgBhwGJ1SvIvfmLT MB/g0/DO0BUR0yB5+2HSfdFkSuBUcAGSuVu2X/+3byJ9ukEMD0gHfdC1x8zwv1qTagCw0RqiadQA AGjaMIxzL3ggFPByKT+wIf8dEH9gqi/AX6xPx8/I3698/zzhvJjC74CjuWUs0D1ULyHYYmFisPHg IHKkU4TQ+5+0EbFnQiAWsX33vz/Ln79E31xyxeVLYHZf93QofWX/u8obEBvB0GGmAFRwYXBG4P/3 IADwtaClR2xQcuJCv9Sv+9W/m8JmwqLRdte/95KBKH/FwmGQQXAjgqUBSgS8mHXkcC1doyhmQiBG YIGf/92f3q9lcUrCfWIkhODf95L3GpAf4COhLxLAS2Cw4Fqg/GUvxWBP4DzAEVBBcEAA/wlEtNGE 0HMCAPDCsFPUnQDPl7/mz97P/5F0eQ2wsMT36d8fhFTAacKwnQDR9gJA+maE0Gnr8VJA9HHrcX1h +1RwStByHaHF18az7s/v3+8qXFuQpdMc0HD4UGYB8r+dn0JNUdAN0JzRIFtO8PxmXWxf+K/Jr/4P /x/M39/ZdLzxEvGfq/tgcqiwthH+cvUxoFClIrBl+58fde42/T2CdamQAP8CDypcH9AgMP9PVCuB 2xClgO3wdSJTqBrx36bgS2CmAAmCFOFhhPCfUP4o6ODpvy3nhMDFIAnPCt/3g+1CIITAZ0rkLKDS MNwx/0+Tc3VCMVIBsNNk0RB/n0L+akZQK8DrgMKwsYCFQBmR/m/uYeTQhXG2PxMv//5akw+gkEIw m8ENdihlLmft3EBB1usAAGo1smHvnxX/VHANhQYB6XMbDxwfKlwM4P9R4BqRZNGm4SJx67buBvXR /w8hpYD93yR///8pPypPr234RG9T2pAhL7Oz4uWgkP1HEHkM4NBRU3IedH4FQGT/tBTCVw2CsJNS ACwvLT9XHP/gAS+Pw+a9878RtYJBJtBR/+ygm9LSYhcXveHFYPah5UP/OF/h40cQQXCcsNyvNh/n 3n+gkKkQSsZRodKglDFPUkX4VEMuQ9E/H0AvK09ET99FX5bPRy9IP0ZLNJrU7SL/RhCE8OCf6qdh MrHBpgF4AP9hUtuwPvBqQ1017WWm4Epv90t/5+9loy938L1Q5LCkMf4v4AH2oFkvnyQNhEYRtLH+ buABxWDaA50lDkZED1OPP0YvWw9cH10q3GPkoHN1/7DT0XYghFcfqBSyF+LWfWEZgSVleNyQINNU UyD+UITTPw9e7x0ffDMicdmw/eswbdqQvCEzQnWTYr+7hVlVwGd1e8FRSSjCsCnvCYA44KkQxZB4 wqAEyWb/92gP3t+EsGgxofJRVXBW8P8XcB81a8+7hV0AkiO0UtMw/1BCbRC04V0AIxAWINqQpPD/ B0DQhRYBvBDFkHAPcR9yLe+xMBnDBnG+IFNqkx30dJ//IjSyCGqEWt96H1z/gE+BX/+CahZpHxBQ gJwB3JAnAeO+f3NH5ON9r9jDH1SmANLQYf/Z8JyghzIa/4Qvgj3x0JzQ/i3Gs9brGlLZwFWgMyNR 0X8oohrRiW8wlsYCUSPcMUj/xsHuYdqQHmF5D40fch+6Af/WuVEjM7QeYFlhsOK7woIw/nU+4ZH/ 2LRtgR6SOiPSYv9Q0sKwlP+WD4IuvCDugGbQG3fRH2JVi+Gl4jgwMgWmsDHakFdpTUFY3xYyTn9Y FQmQBQJmQmCw8ftiRYJAdxm0DmBQoDT/nt9/lx8w9fQHcwsZ8jg/imRG/EVD7DDo1NoSTmEm8WaQ +/Qj7UBi4nOm76f/gkxaVxggTDINdVjTKE1Q5EVHs2BTSeyAhtOsL//PpJHQBTMm8W0RMbEXMh30 /9JiZlCvv7DPFF1mlHaRIOJL41KAHDiKQCZuxoBw4ju5+SdhMIKIlDjpn/9sl21wf2QG5UKDeHA4 ErRC6i2zYFtD0l24r7m/gkz+ZHwgHmEGxRewfvBQoIuR/+1AOB9+d4uBPBLC1OUgyPH/42CdkPIg 2gLsgFGFs1DEb//FfyWuWJ/aEYAfzf+CP9GP79KfAzzJL4qCQ4aDD7Diwf/icXwg61BVwNOAUHSL 4MHh//WAF7AVMjqw9ZNRhc/5GeHn2hHXj4qDSSeMD9Vvn/7zWjBhwHBw2YMEQ3jQaxC/2ibfgNtx MyJlwOxwP97v39//04/kz+XfA0tQOrDiEfuq0oZBc4ug7SLdX36zhuL/JvEmkRdRVcL2QPXC7mFh UPtSAEKSL5OxEEH7ca+P6H/96Y9T2qbY0LdhGtBthJrv/1gVdiTkj/FPSS9KP/d/+I//+e/6//wP /R/+L4V5lEAG4N+YBPTPT6MnoOsALP/vAP+v/w8FbwZ/hXlHViF5CD//CU8HXwu/DM8N3w7vD/8R Dy8SHxMvFD8VQDUVcS9G+E9OVBXJFdcUYBXmimLfGagWyD4jFs84pjezYBiQNlAVwBSMMIpAGJBE SfZWGP8dH2caMYpzIX8ij4Q1OBiBQk9EWR6dF7NgI78mQTcYgUhUTQpMFcB9KHAeADUQAQAAAEQA AAA8MDE4MTYwREJFOEQ0ODM0OUEwQ0FCRjQ0MjRDM0RDMjFBQUQyMEFARVZTLUVDMS1OT0RFMS5z dXJyZXkuYWMudWs+AB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAA egAAAFIARQAlADMAQQAgAFQAaABvAHUAZwBoAHQAcwAgAG8AbgAgAGQAcgBhAGYAdAAtAGMAcgB1 AGkAYwBrAHMAaABhAG4AawAtAGkAcABkAHYAYgAtAHMAZQBjAC0AcgBlAHEALQAwADAALgB0AHgA dAAuAEUATQBMAAAAAAALAPYQAAAAAEAABzCE/TrnUdbFAUAACDCG81eeUtbFAQMA3j+vbwAAAwDx PwkIAAAeAPg/AQAAAB4AAABJeWVuZ2FyIFMgTXIgKEVsZWN0cm9uaWMgRW5nKQAAAAIB+T8BAAAA SAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1VTklTL09VPUlTQlNTSVRFL0NOPVJF Q0lQSUVOVFMvQ049RUVTMVNJAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB +z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAA AAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABwAAAEVFUzFTSQAAHgAxQAEAAAAHAAAA RUVTMVNJAAAeADJAAQAAABsAAABvd25lci1pcGR2YkBlcmcuYWJkbi5hYy51awAAHgAzQAEAAAAV AAAAZ29ycnlAZXJnLmFiZG4uYWMudWsAAAAAHgA4QAEAAAAHAAAARUVTMVNJAAAeADlAAQAAAAIA AAAuAAAAAwB2QP////8LACkAAAAAAAsAIwAAAAAAAwAGEGdoyfIDAAcQ+A4AAAMAEBAAAAAAAwAR EAAAAAAeAAgQAQAAAGUAAABISUdPUlJZQU5EQUxMLFRIQU5LU0ZPUkFMTFRIRUNPTU1FTlRTUkVH QVJESU5HU0VDVElPTjRIRVJFU1NPTUVJTlBVVDpDT05DRVJOSU5HU0lHTkFMTElORyxUSElTSVNE RUZJAAAAAAIBfwABAAAARAAAADwwMTgxNjBEQkU4RDQ4MzQ5QTBDQUJGNDQyNEMzREMyMUFBRDIw QUBFVlMtRUMxLU5PREUxLnN1cnJleS5hYy51az4Avl0= ------_=_NextPart_001_01C5D652.9E49A57C-- From owner-ipdvb@erg.abdn.ac.uk Mon Oct 24 09:35:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2U1-0004JZ-UD for ipdvb-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:35:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10008 for ; Mon, 24 Oct 2005 09:35:11 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU2gm-0003tf-5Y for ipdvb-archive@ietf.org; Mon, 24 Oct 2005 09:48:37 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9ODJR2n019498 for ; Mon, 24 Oct 2005 14:19:27 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9ODJR7n019497 for ipdvb-subscribed-users; Mon, 24 Oct 2005 14:19:27 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9ODJMQH019480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2005 14:19:22 +0100 (BST) Message-ID: <435CDF59.7030800@erg.abdn.ac.uk> Date: Mon, 24 Oct 2005 14:19:21 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: IP over DVB-S2 - crc usage? References: <4353A523.3020708@sunaut.uab.es> In-Reply-To: <4353A523.3020708@sunaut.uab.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Fausto Vieira wrote: > Well, my idea was that sometimes it is not possible to fill the entire > BB frame with packets, either because you want to expedite the > transmission of the frame or because you don't have enough bytes left to > start a new packet. Agreed. > In these cases, I imagine that some padding would be > required at the end of the BB frame. OK. > Instead of wasting these bytes, you > could insert a CRC that should decrease the number of errors at a frame > level. First: Can we use padding to save overhead for CRC transmission? That was the part I did not understand, you seem to suggest the CRC's would be inserted conditionally on the padding being present - but the requirement is the same whether padding is used or not - so I'd say if the analysis shows a CRC is needed, it will be needed in all cases, and the padding is irrelevent. > It is my understanding that the standard guarantees something > like 10^-7 BER. On the second question : How much of a CRC is needed? BER performance is often hard to quantify. Does that mean that WHATEVER distorted waveform is presented at the input to the receiver, the output of the link FEC processing will result in either a BBframe being marked as invalid, or one that has up to 10-7 errors in the forwarded frames? Even this is not exact, a single BBframe could (with small probability) contain many errors - and somehow this has to be detected. IMHO, this means we need to consider the worst-case lvele of residual (undetected) errors that can be presented in any single BB frame. > My question is in fact if you can live without a CRC, especially > considering the problem with transport layer retransmissions with high > round trip times. The question of retransmissions is irrelevent. The issue here is data integrity - the probability that a corrupted block is (mis)delivered to and accepted by an application. Best wishes, Gorry > > Maybe I'm seeing this with incorrect assumptions, especially on the > nature of errors. > Well, this was my reasoning for the optional CRC. > > Regards > > Fausto > > Gorry Fairhurst wrote: > >> Fausto, >> >> I'm trying to understand the main outstanding issues. >> >> I agree there are a set of DVB-S.2 BB header fields that may be >> re-used to >> carry the protocol control information for the encapsulation layer. This >> seems like the correct way to go. Many BB header fields are not >> defined/used >> for the Generic Mode, but I don't yet know (maybe others are wiser) >> exactly >> which fields may be safely (re)used and for a S.2 generic >> encapsulation and >> still remain compatible the DVB-S.2 spec. This is probably an area that >> needs to be cleared with the DVB S.2 group. >> >> My main query relates to your comment about the optional CRC fields. I'm >> puzzled by your suggestion that requirements for CRC usage may be >> related to >> the presence of padding in the BB frame. My thoughts were that the CRC >> requirement stemmed from: >> >> (i) The need to verify the integrity of the payload (PDU) before >> passing to the IP layer - to mitigate the impact of link errors >> and low level errors in data movement. >> >> (ii) To verify the framing (length) of PDUs - ensuring the next >> SNDU header was correctly located within the BB frame payload. >> >> (iii) To verify the integrity of reassembled SNDUs. >> >> (iv) To allow a receiver to monitor the quality of the >> received bitstream. >> >> - I can see how (i) relates to worst case expected link error >> characteristics, but don't see yet how this can be related to the >> presence >> or absence of padding bytes. >> >> Thoughts? >> >> Gorry >> >> >> >> > > From owner-ipdvb@erg.abdn.ac.uk Mon Oct 24 13:20:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU607-0000E6-LM for ipdvb-archive@megatron.ietf.org; Mon, 24 Oct 2005 13:20:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21613 for ; Mon, 24 Oct 2005 13:20:34 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU6Cr-0002pT-P2 for ipdvb-archive@ietf.org; Mon, 24 Oct 2005 13:34:01 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9OHEYEg007534 for ; Mon, 24 Oct 2005 18:14:34 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9OHEYS6007533 for ipdvb-subscribed-users; Mon, 24 Oct 2005 18:14:34 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9OHEQd3007517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2005 18:14:27 +0100 (BST) Message-ID: <435D1673.1060001@erg.abdn.ac.uk> Date: Mon, 24 Oct 2005 18:14:27 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Update on WG Status page Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Many of you will have noticed that the ipdvb web site at: http://www.erg.abdn.ac.uk/ip-dvb/ Now has a link to the IETF-maintained ipdvb wg status page (see top of the banner to the web site). This page is still evolving, but has recently been significantly updated. The features in the current version have been put in place gradually since IETF-63, but an announcement seems appropriate to point out the changes and improvements which are now in place. From the changelog: wg-pages (0.60) * Added WG Agendas back to IETF-59 (earlier agendas are not easily available without manual handling). * Added WG Minutes back to IETF-50. Minutes which weren't natively in HTML format, but had some HTML added later, have been stripped to text format and run through fmt. * Agendas and minutes will now be automatically updated also during coming IETFs, requiring no manual intervention. * Added a list of 'related drafts' at the bottom of the WG drafts page, based on the drafts being named with -- in the name. * Added updating of closed WGs. Closed WGs will remain available with no change of URL, but will not be listed in the WG list on the left-hand side of the status pages. * Added pages for ietf and iab, under /group/iab and /group/ietf. * Added listing of published RFCs on the draft pages, with diff against the last draft version. * Added version indication on the WG status pages, with a link to tool information. Access to other IETF WG archives is available using: http://tools.ietf.org/wg/name/ where name is the IETF accronym for the working group. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue Oct 25 11:45:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQzW-0008CI-GG for ipdvb-archive@megatron.ietf.org; Tue, 25 Oct 2005 11:45:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00811 for ; Tue, 25 Oct 2005 11:45:19 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURCT-0000Cs-7s for ipdvb-archive@ietf.org; Tue, 25 Oct 2005 11:58:59 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9PFfEsp015991 for ; Tue, 25 Oct 2005 16:41:14 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9PFfEK3015990 for ipdvb-subscribed-users; Tue, 25 Oct 2005 16:41:14 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9PFf6So015973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Oct 2005 16:41:06 +0100 (BST) Message-ID: <435E5213.8050007@erg.abdn.ac.uk> Date: Tue, 25 Oct 2005 16:41:07 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "S.Iyengar" CC: ipdvb , "H.Cruickshank" , "stephane.combes" , "Laurence.Duquerroy" Subject: Re: Thoughts on the impact of Signalling security on IP traffic References: <018160DBE8D48349A0CABF4424C3DC21AAD20A@EVS-EC1-NODE1.surrey.ac.uk> In-Reply-To: <018160DBE8D48349A0CABF4424C3DC21AAD20A@EVS-EC1-NODE1.surrey.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Here are some thoughts... Comments welcome! Gorry --- Some of the L2 signalling security properties include: - No authentication of the signalling source. The layer-2 signalling entity is often not be the encapsulation gateway itself. - No encryption (but sometimes this is needed to bootstrap terminals). - Integrity check is a CRC-32. This is relatively weak compared to a cryptographic hash. (Should the forging of table contents needs to be considered?) - (re)multiplexors do modify (or insert new SI tables), but there is no security association with these devices within an MPEG-2 Transmission network. - Modification/Denial of the SI information could result in association of a different stream with the service, or an inability to identify the TS Logical Channel (PID) that is used for a service. Threats from interception of Forward link signalling. In current MPEG-TS networks, the forward link signalling is not encrypted. Eavesdropping of the signalling information does not reveal any information which is not available to all receivers. In the case of two-way networks, forward link signalling can reveal traffic parameters of the return links from specific users. This information can also reveal the status of specific terminals (logon/logoff, etc) and the timing and transmission parameters used by these terminals. Some of these threats could be reduced by using IP-based signalling [ref] and appropriate IP-level security mechanisms (e.g. IPsec). Replay/Jamming - SI information is required to associate PID values with Streams and therefore to demultiplex the data at the Receiver. - In two-way systems, denial of forward signalling may also prevent link transmission in the return direction. - Jamming/interception may also occur in the return link direction. In this case, forged return link signalling could acquire return link bandwidth, or modify the state of a terminal as perceived at the network control centre. These threats can be exploited as a DoS attack. - SI information may be sent periodically. If the time of transmission is predictable, this could be "jammed" resulting in loss of signalling at the receiver, which is a DoS vulnerability. It requires access to the stream - either on the air interface (e.g. A different transmitter injecting a signal that is Received (e.g. On an antenna side-lobe). - Modification of SI can also be a DoS attack, this requires access to the network components (multiplexors, etc) and/or connecting physical media - a man-in-the-middle attack. From owner-ipdvb@erg.abdn.ac.uk Tue Oct 25 11:45:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQzZ-0008G2-P2 for ipdvb-archive@megatron.ietf.org; Tue, 25 Oct 2005 11:45:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00814 for ; Tue, 25 Oct 2005 11:45:22 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURCT-0000Cr-9k for ipdvb-archive@ietf.org; Tue, 25 Oct 2005 11:59:00 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9PFaw76015641 for ; Tue, 25 Oct 2005 16:36:59 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9PFaww1015640 for ipdvb-subscribed-users; Tue, 25 Oct 2005 16:36:58 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9PFagku015623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Oct 2005 16:36:43 +0100 (BST) Message-ID: <435E510B.2040008@erg.abdn.ac.uk> Date: Tue, 25 Oct 2005 16:36:43 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "S.Iyengar" CC: ipdvb , "H.Cruickshank" , "stephane.combes" , "Laurence.Duquerroy" Subject: Re: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt References: <018160DBE8D48349A0CABF4424C3DC21AAD20A@EVS-EC1-NODE1.surrey.ac.uk> In-Reply-To: <018160DBE8D48349A0CABF4424C3DC21AAD20A@EVS-EC1-NODE1.surrey.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit I think it would be good to understand these issues, and if you can draw any wisdom, then I encourage you to distill this into the draft - even if the end result is that we are unable to change anything in the signalliung plane, it seems wise to document that vulnerabilities as seen from the IP viewpoint. I'll send some thoughts to the list... Gorry S.Iyengar wrote: > Hi Gorry and all, > > Thanks for all the comments. Regarding section 4 here's some input: > > Concerning signalling, this is definitely a threat in order > to mount active attacks. But as we understand SI signalling does not > have any authentication /encryption and also it is considered a > different plane. Moreover some SI tables are important to be initially > in plaintext for the proper configuration of the terminals. This is > definitely a threat. Maybe people involved with SI tables and so can > provide more insight into the severity of this threat. > > > Regards > > Sunil Iyengar, > Centre For Communication And Systems Research(CCSR), > School of Electronics, Computing & Mathematics, > University Of Surrey, Guildford GU2 7XH, > Surrey, England, United Kingdom. > > ------------------------------------------------------------------------ > From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst > Sent: Tue 20/09/2005 10:18 > To: ipdvb@erg.abdn.ac.uk > Cc: Haitham Cruickshank; Iyengar S Mr (CCSR); > stephane.combes@space.alcatel.fr; Laurence.Duquerroy@space.alcatel.fr > Subject: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt > > > This draft raises several issues, and seems to me to be a good start, at a > document that would be useful to this WG. I'd like to get more opinions on > what the document does say, and what it does not, so that we can understand > whether this fits the needs of this WG. Can I encourage people to read thsi > and send comments to the list? > > I have some comments below, to start this process: > > Section 1.1: > ----- > 1) In 1.1 it is may also be worth stating that the service to be > protected is > the stream (TS Logical Channel) that is between the Encapsulation > Gateway and > Receiver. This stream is identified at the Gateway and Receiver by a unique > PID value associated with the stream (although at the two ends of the > link may > have differing values, since this can be and is modified in the MPEG2 > Transmission Network). > ----- > 2) It also could perhaps be staring that although a number of components > operate within the network. For the IP network service, they do not > modify the > packet payload. > ----- > > > Section 2: Threats > ----- > 3) I wonder if there are any thoughts on the different "Access to the > Channel" > related to the set of scenarios in section 3.1 of > draft-ietf-ipdvb-arch-xx.txt. > > - Specifically do people see different threats being important in > TV-oriented > networks that are contribution/broadcast carrying IP data and networks that > are more IP-oriented (with smaller transmit hubs/power)? - I do. > > - In broadcast networks, it is probably hard to access the ground network at > the transmitter (or the contribution feed, in a digital TV scenario). It is > therefore hard to modify the traffic sent on the broadcast up-link (from the > modulator to the headend/satellite/mast) which would impact all receivers - > this typically requires access to facilities and/or a large transmit power > (as in Captain Midnight [Ref]). > > - In contrast, access to the air-interface of specific receivers is much > easier. The signal at a Receiver is often much weaker (due to path > propagation loss). This could potentially be jammed/replayed/over-loaded > with another signal (e.g. A transmitter injecting a signal into the > side-lobe of a satellite receive antenna). > > - DoS, traffic analysis, and other networking threats are more significant > for IP-data than TV services, where the potential damage from malicous > manipulation is greater. ETC.... > > ----- > 4) I would like to have seen some discussion of the impact of > modified/corrupted/forged signalling information on the Receiver. > > It is usually hard to inject different traffic or modify existing TS Packets > within a stream, but through configuration of the (re)multiplexor, access to > the physical media (e.g. connections between components), etc it is possible > to replace a Stream with a different stream. > > This could also arise on the broadcast physical link (e.g. An unauthorised > high-power transmitter overriding the intended transmission). However, note > that the transmissions are normally continuous (rather than the discrete > bursts, e.g. Used in 802.11, WiMAX). To successfully inject new/replacement > traffic requires the physical layer FEC/modulation to be acquired by the > Receiver. L2 signalling (MPEG2 SI) also needs to be consistent with the TS > packets being sent. However, the current specifications for MPEG-2 [....] > do not specify a method for authentication (or encryption) of the L2 > signalling information. > > - Could we try to define some security properties of the signalling > plane (I'd > be happy to contribute some starting text)? > > - Perhaps this should also be identified as an assumption/issue in the > Security Considerations section? > ----- > > > Hope that helps, > > Gorry > > > From owner-ipdvb@erg.abdn.ac.uk Tue Oct 25 16:00:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUyX-0003NB-Ko for ipdvb-archive@megatron.ietf.org; Tue, 25 Oct 2005 16:00:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18573 for ; Tue, 25 Oct 2005 16:00:34 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUVBR-0000WL-VQ for ipdvb-archive@ietf.org; Tue, 25 Oct 2005 16:14:15 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9PJrRmO005191 for ; Tue, 25 Oct 2005 20:53:27 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9PJrROS005190 for ipdvb-subscribed-users; Tue, 25 Oct 2005 20:53:27 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout04-03.prod.mesa1.secureserver.net (smtpout04-03.prod.mesa1.secureserver.net [64.202.165.198]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j9PJrF7k005168 for ; Tue, 25 Oct 2005 20:53:16 +0100 (BST) Received: (qmail 3363 invoked from network); 25 Oct 2005 19:53:09 -0000 Received: from unknown (HELO webmail14.mesa1.secureserver.net) (64.202.189.55) by smtpout04-03.prod.mesa1.secureserver.net with SMTP; 25 Oct 2005 19:53:09 -0000 Received: (qmail 17356 invoked by uid 99); 25 Oct 2005 19:53:09 -0000 Date: Tue, 25 Oct 2005 12:53:09 -0700 From: Marie-Jose Montpetit Subject: RE: Thoughts on the impact of Signalling security on IP traffic To: ipdvb@erg.abdn.ac.uk cc: ipdvb , "H.Cruickshank" , "stephane.combes" , "Laurence.Duquerroy" , "S.Iyengar" Message-ID: <20051025125309.ca5566c7162b3cfcb6c200079b757bd6.c3d4d92a47.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 I ping'ed one of our security people here at Motorola and please find below what he had as a comment: "In the case of DOCSIS, we had the debate a few years ago on whether or not it is easy to impersonate the headend and modify the contents of a DOCSIS downstream, which is just an MPEG-2 multiplex. It was decided by the working group that such an attack would be too costly and impractical - for HFC cable networks at least. The same probably applies for satellite networks. This email suggests that the return channel could be monitored to determine if an STB is logged in or not. As the email suggests, IP traffic can be protected with IPsec - but generally any IP stack including the one over DVB can be modified to include IPsec." I think the group should look a bit more at what was done on the cable side? /mjm > -------- Original Message -------- > Subject: Re: Thoughts on the impact of Signalling security on IP > traffic > From: Gorry Fairhurst > Date: Tue, October 25, 2005 11:41 am > To: "S.Iyengar" > Cc: ipdvb , "H.Cruickshank" > , "stephane.combes" > , "Laurence.Duquerroy" > > > Here are some thoughts... Comments welcome! > > Gorry > > --- > > > Some of the L2 signalling security properties include: > > - No authentication of the signalling source. The layer-2 signalling > entity is often not be the encapsulation gateway itself. > - No encryption (but sometimes this is needed to bootstrap terminals). > - Integrity check is a CRC-32. This is relatively weak compared to a > cryptographic hash. (Should the forging of table contents needs to be > considered?) > - (re)multiplexors do modify (or insert new SI tables), but there is no > security association with these devices within an MPEG-2 Transmission > network. > - Modification/Denial of the SI information could result in association of a > different stream with the service, or an inability to identify the TS > Logical Channel (PID) that is used for a service. > > Threats from interception of Forward link signalling. > > In current MPEG-TS networks, the forward link signalling is not encrypted. > Eavesdropping of the signalling information does not reveal any information > which is not available to all receivers. > > In the case of two-way networks, forward link signalling can reveal traffic > parameters of the return links from specific users. This information can > also reveal the status of specific terminals (logon/logoff, etc) and the > timing and transmission parameters used by these terminals. > > Some of these threats could be reduced by using IP-based signalling [ref] > and appropriate IP-level security mechanisms (e.g. IPsec). > > Replay/Jamming > > - SI information is required to associate PID values with Streams and > therefore to demultiplex the data at the Receiver. > - In two-way systems, denial of forward signalling may also prevent link > transmission in the return direction. > - Jamming/interception may also occur in the return link direction. In this > case, forged return link signalling could acquire return link bandwidth, or > modify the state of a terminal as perceived at the network control centre. > These threats can be exploited as a DoS attack. > > - SI information may be sent periodically. If the time of transmission is > predictable, this could be "jammed" resulting in loss of signalling at the > receiver, which is a DoS vulnerability. It requires access to the stream - > either on the air interface (e.g. A different transmitter injecting a signal > that is Received (e.g. On an antenna side-lobe). > - Modification of SI can also be a DoS attack, this requires access to the > network components (multiplexors, etc) and/or connecting physical media - a > man-in-the-middle attack. From owner-ipdvb@erg.abdn.ac.uk Wed Oct 26 08:09:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUk62-0004Cp-Ri for ipdvb-archive@megatron.ietf.org; Wed, 26 Oct 2005 08:09:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14731 for ; Wed, 26 Oct 2005 08:09:20 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUkJA-0007V2-9x for ipdvb-archive@ietf.org; Wed, 26 Oct 2005 08:23:11 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QC0g6I021260 for ; Wed, 26 Oct 2005 13:00:42 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9QC0grt021259 for ipdvb-subscribed-users; Wed, 26 Oct 2005 13:00:42 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout04-03.prod.mesa1.secureserver.net (smtpout04-03.prod.mesa1.secureserver.net [64.202.165.198]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j9QC0Rbn021226 for ; Wed, 26 Oct 2005 13:00:28 +0100 (BST) Received: (qmail 11618 invoked from network); 26 Oct 2005 12:00:22 -0000 Received: from unknown (HELO webmail13.mesa1.secureserver.net) (64.202.189.54) by smtpout04-03.prod.mesa1.secureserver.net with SMTP; 26 Oct 2005 12:00:22 -0000 Received: (qmail 1459 invoked by uid 99); 26 Oct 2005 12:00:22 -0000 Date: Wed, 26 Oct 2005 05:00:22 -0700 From: Marie-Jose Montpetit Subject: RE: Réf. : RE: Thoughts on the impact of Signalling security on IP traffic To: Stephane.Combes@alcatelaleniaspace.com cc: ipdvb@erg.abdn.ac.uk Message-ID: <20051026050021.ca5566c7162b3cfcb6c200079b757bd6.a998566be6.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j9QC0g6I021260 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: quoted-printable Should Amerhis drive all the requirements for MPEG/ULE security? We should make sure that IP over DVB does not become another IP over satellite - that too many people think it is BTW. And yes: we should do ULE and leave DVB (and other groups) to address the big picture. /mjm > -------- Original Message -------- > Subject: R=E9f. : RE: Thoughts on the impact of Signalling security on > IP traffic > From: Stephane.Combes@alcatelaleniaspace.com > Date: Wed, October 26, 2005 5:57 am > To: Marie-Jose Montpetit > Cc: ipdvb@erg.abdn.ac.uk > > Hi Marie-Jos=E9, > > I admit that a conventional hub-and-spoke DVB network will not have mor= e > stringent requirements than a DOCSIS network. But this is not the case = of > mesh DVB-RCS networks (eg Amerhis system). Here the MPEG-2 mux is on-bo= ard > the satellite and the signalling is generated by a Network Control Cent= er > (NCC) which is just like any other sender/receiver. Therefore this NCC = is > probably easier to impersonate than a cable headend. > > Regarding preventing the return channel to be monitored, this is a very > important issue for the most "sensible" networks. And IPSec cannot help > here... > > As a general comment on the current discussion thread, my feeling is: > - Securing DVB and MPEG-2 signalling seems a bit out-of-scope to me. Th= e > current I-D mostly concentrate on securing ULE (and ULE signalling). It= is > true that "the integrity of control and management message in MPEG-2 > networks" appears as an optional requirement in the I-D. But perhaps th= is > is too vague and we should first concentrate on ULE and not go down to > MPEG. > - We can discuss DVB and MPEG signalling security but this issue should > probably be owned by the DVB Forum or by groups which have developed so= me > specific additional signalling protocols (e.g. SatLabs for RCS protocol= s) > > cheers, > > St=E9phane > > > > > Marie-Jose > Montpetit Pour : ipdvb@erg.abdn.= ac.uk > > it.com> "H.Cruickshank" > Stephane Combes/ALCATEL-= SPACE@ALCATEL-SPACE > 25/10/2005 21:53 Laurence Duquerroy/ALCAT= EL-SPACE@ALCATEL-SPACE > Veuillez "S.Iyengar" > r=E9pondre =E0 Objet : RE: Thought= s on the impact of Signalling security on IP traffic > Marie-Jose > Montpetit > > > > > > I ping'ed one of our security people here at Motorola and please find > below what he had as a comment: > > "In the case of DOCSIS, we had the debate a few years ago on whether or > not it is easy to impersonate the headend and modify the contents of a > DOCSIS downstream, which is just an MPEG-2 multiplex. It was decided > by the working group that such an attack would be too costly and > impractical - for HFC cable networks at least. The same probably > applies for satellite networks. > > This email suggests that the return channel could be monitored to > determine if an STB is logged in or not. As the email suggests, IP > traffic can be protected with IPsec - but generally any IP stack > including the one over DVB can be modified to include IPsec." > > I think the group should look a bit more at what was done on the cable > side? > > /mjm > > > > > -------- Original Message -------- > > Subject: Re: Thoughts on the impact of Signalling security on IP > > traffic > > From: Gorry Fairhurst > > Date: Tue, October 25, 2005 11:41 am > > To: "S.Iyengar" > > Cc: ipdvb , "H.Cruickshank" > > , "stephane.combes" > > , "Laurence.Duquerroy" > > > > > > Here are some thoughts... Comments welcome! > > > > Gorry > > > > --- > > > > > > Some of the L2 signalling security properties include: > > > > - No authentication of the signalling source. The layer-2 signalling > > entity is often not be the encapsulation gateway itself. > > - No encryption (but sometimes this is needed to bootstrap terminals). > > - Integrity check is a CRC-32. This is relatively weak compared to a > > cryptographic hash. (Should the forging of table contents needs to be > > considered?) > > - (re)multiplexors do modify (or insert new SI tables), but there is = no > > security association with these devices within an MPEG-2 Transmission > > network. > > - Modification/Denial of the SI information could result in associati= on > of a > > different stream with the service, or an inability to identify the TS > > Logical Channel (PID) that is used for a service. > > > > Threats from interception of Forward link signalling. > > > > In current MPEG-TS networks, the forward link signalling is not > encrypted. > > Eavesdropping of the signalling information does not reveal any > information > > which is not available to all receivers. > > > > In the case of two-way networks, forward link signalling can reveal > traffic > > parameters of the return links from specific users. This information = can > > also reveal the status of specific terminals (logon/logoff, etc) and = the > > timing and transmission parameters used by these terminals. > > > > Some of these threats could be reduced by using IP-based signalling [= ref] > > and appropriate IP-level security mechanisms (e.g. IPsec). > > > > Replay/Jamming > > > > - SI information is required to associate PID values with Streams and > > therefore to demultiplex the data at the Receiver. > > - In two-way systems, denial of forward signalling may also prevent = link > > transmission in the return direction. > > - Jamming/interception may also occur in the return link direction. I= n > this > > case, forged return link signalling could acquire return link bandwid= th, > or > > modify the state of a terminal as perceived at the network control > centre. > > These threats can be exploited as a DoS attack. > > > > - SI information may be sent periodically. If the time of transmissio= n is > > predictable, this could be "jammed" resulting in loss of signalling a= t > the > > receiver, which is a DoS vulnerability. It requires access to the str= eam > - > > either on the air interface (e.g. A different transmitter injecting a > signal > > that is Received (e.g. On an antenna side-lobe). > > - Modification of SI can also be a DoS attack, this requires access t= o > the > > network components (multiplexors, etc) and/or connecting physical med= ia - > a > > man-in-the-middle attack. > > > > > > Research Department/Advanced Telecom Systems -- R&D Engineer > Tel : +33 53435 6938 / Fax : +33 53435 5560 > Porte : W219 / E-Mail : stephane.combes@alcatelaleniaspace.com > > 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 acco= rd > with its purpose, any dissemination or disclosure, either whole or part= ial, > is prohibited except formal approval. The internet can not guarantee th= e > integrity of this message. ALCATEL ALENIA SPACE (and its subsidiaries) > shall (will) not therefore be liable for the message if modified. > > Ce message et toutes les pieces jointes (ci-apres le "message") sont > etablis a l'intention exclusive de ses destinataires et sont confidenti= els. > Si vous recevez ce message par erreur, merci de le detruire et d'en ave= rtir > immediatement l'expediteur. Toute utilisation de ce message non conform= e a > sa destination, toute diffusion ou toute publication, totale ou partiel= le, > est interdite, sauf autorisation expresse. L'internet ne permettant pas > d'assurer l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filia= les) > decline(nt) toute responsabilite au titre de ce message, dans l'hypothe= se > ou il aurait ete modifie. From owner-ipdvb@erg.abdn.ac.uk Wed Oct 26 09:30:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlLw-0001jh-UA for ipdvb-archive@megatron.ietf.org; Wed, 26 Oct 2005 09:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19532 for ; Wed, 26 Oct 2005 09:29:50 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUlZ7-0001d8-1g for ipdvb-archive@ietf.org; Wed, 26 Oct 2005 09:43:41 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QA2OTi012215 for ; Wed, 26 Oct 2005 11:02:24 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9QA2O0Z012214 for ipdvb-subscribed-users; Wed, 26 Oct 2005 11:02:24 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (mermoz.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QA2H0I012197 for ; Wed, 26 Oct 2005 11:02:17 +0100 (BST) Received: from DrCerebro (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with SMTP id j9QA2V211799 for ; Wed, 26 Oct 2005 12:02:31 +0200 (MEST) Message-ID: <000d01c5da14$494dbe40$877a36c1@DrCerebro> From: "Juan Cantillo" To: "IPDVB" Subject: Thoughts on CRC usage Date: Wed, 26 Oct 2005 12:01:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C5DA25.0C905D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.6 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C5DA25.0C905D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (This mail might appear twice in the list, since I sent it from another mai= l address... it looks like majordomo filters the senders it doesn't know, r= ight?) Dear Gorry and Fausto,=20 =20 Gorry said:=20 >>>BER performance is often hard to quantify. Does that mean that WHATEVER >>>distorted waveform is presented at the input to the receiver, the output= of=20 >>>the link FEC processing will result in either a BBframe being marked as= =20 >>>invalid, or one that has up to 10-7 errors in the forwarded frames?"=20 >>>Even this is not exact, a single BBframe could (with small probability)= =20 >>>contain many errors - and somehow this has to be detected. >>>IMHO, this means we need to consider the worst-case lvele of residual >>>(undetected) errors that can be presented in any single BB frame.=20 1e-7 is the Packet Error Rate (PER). This is the probability that the FEC u= sed to protect the BBFrame cannot *correct* all the erroneous bits in a BBF= RAME. Say that 1 packet out of 10 000 000 cannot be corrected. One importan= t strength of the BCH used is that he can also *detect* very accurately tha= t this packet was indeed erroneous after decoding; theoretical estimates sh= ow that he will prove wrong only 1e-8 of the time.=20 So if you ask your BCH to do error *correction + detection*, at the encapsu= lation layer, only 1e-15 of your packets will be wrong (this is the "small = probability" Gorry refers to)!!! At 15 Mbits/s, for frames of length 384 By= te, this means one uncorrected packet every 6000 years more or less :-) Tha= t means that if you If you intend to use a CRC to correct link errors, it w= ill only be activated once every 6000 years.=20 To verify these estimations, we have been running some simulations under va= rious link conditions here in Toulouse since July, full time, and as expect= ed, we still have not detected a single erroneous BBFRAME on our platform a= fter FEC correction + detection :-)=20 >>>The question of retransmissions is irrelevent. The issue here is data >>>integrity - the probability that a corrupted block is (mis)delivered to = and=20 >>>accepted by an application.=20 =20 I agree with Gorry. Protecting data is the most important issue, and it sho= uld not depend on padding presence/absence. IMHO, the key point is analysin= g where the threats to data integrity come from: if we suppose that an erro= r event is due *only* to the AWGN link, Maths and simulations clearly prove= that CRCs could be removed. If on the other hand you suppose that there mi= ght be errors *other* than link ones (say, bit offsets due to bugs in the s= ofware/hardware), then making a CRC check can be the only way to spot them.= =20 Unfortunately, no figures nor precise measurements/litterature are availabl= e on that at our knowledge! If anyone has data on this particular issue we = would gratefully appreciate it. If those became available you could then sc= ale properly the length of the CRC you need, if that threat proves worth it= .=20 =20 Any thoughts on this? =20 Juan ----------------------------------------------------------------------- Juan CANTILLO - SatComs PhD. Researcher Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 ENST/TeSA/ENSICA/AAS, Toulouse, FR= ------=_NextPart_000_000A_01C5DA25.0C905D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(This mail might appear twice in the list, since I sent it from another = mail=20 address... it looks like majordomo filters the senders it doesn't know,=20 right?)

Dear Gorry and Fausto,
 
Gorry said:=20
>>>BER performance is often hard to quantify. Does that mean t= hat=20 WHATEVER
>>>distorted waveform is presented at the input to the= =20 receiver, the output of
>>>the link FEC processing will result= in=20 either a BBframe being marked as
>>>invalid, or one that has u= p to=20 10-7 errors in the forwarded frames?"
>>>Even this is not exac= t, a=20 single BBframe could (with small probability)
>>>contain many= =20 errors - and somehow this has to be detected.
>>>IMHO, this mea= ns we=20 need to consider the worst-case lvele of residual
>>>(undetecte= d)=20 errors that can be presented in any single BB frame.

1e-7 is the Packet Error Rate (PER). This is the probability that the FE= C=20 used to protect the BBFrame cannot *correct* all the erroneous bits in a=20 BBFRAME. Say that 1 packet out of 10 000 000 cannot be corrected. One impor= tant=20 strength of the BCH used is that he can also *detect* very accurately that = this=20 packet was indeed erroneous after decoding; theoretical estimates show that= he=20 will prove wrong only 1e-8 of the time.
So if you ask your BCH to do er= ror=20 *correction + detection*, at the encapsulation layer, only 1e-15 of your pa= ckets=20 will be wrong (this is the "small probability" Gorry refers to)!!! At 15=20 Mbits/s, for frames of length 384 Byte, this means one uncorrected packet e= very=20 6000 years more or less :-) That means that if you If you in= tend=20 to use a CRC to correct link errors, it will only be activated once ev= ery=20 6000 years.

To verify these estimations, we have been running some simulations under= =20 various link conditions here in Toulouse since July, full time, and as=20 expected, we still have not detected a single erroneous BBFRAME on our= =20 platform after FEC correction + detection :-)

>>>The question of retransmissions is irrelevent. The iss= ue=20 here is data
>>>integrity - the probability that a corrupted bl= ock=20 is (mis)delivered to and
>>>accepted by an application.
 
I=20 agree with Gorry. Protecting data is the most important issue, and it shoul= d not=20 depend on padding presence/absence. IMHO, the key point is analysing where = the=20 threats to data integrity come from: if we suppose that an error event is d= ue=20 *only* to the AWGN link, Maths and simulations clearly prove that CRCs coul= d be=20 removed. If on the other hand you suppose that there might be errors *other= *=20 than link ones (say, bit offsets due to bugs in the sofware/hardware), then= =20 making a CRC check can be the only way to spot them.

Unfortunately, no figures nor precise measurements/litterature are avail= able=20 on that at our knowledge! If anyone has data on this particular issue we wo= uld=20 gratefully appreciate it. If those became available you could then scale=20 properly the length of the CRC you need, if that threat proves worth it.=20
 
Any thoughts on this?
 
Juan

<= /DIV>

-------------------------------------------------------= ----------------
Juan=20 CANTILLO - SatComs PhD. Researcher
Tel +33 6 23 54 59 65- Fax  +33 = 5 61=20 61 86 88
ENST/TeSA/ENSICA/AAS, Toulouse, FR
------=_NextPart_000_000A_01C5DA25.0C905D80-- From owner-ipdvb@erg.abdn.ac.uk Wed Oct 26 10:38:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmPt-0004G2-Qv for ipdvb-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:38:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23886 for ; Wed, 26 Oct 2005 10:37:58 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmd3-0003wO-Fi for ipdvb-archive@ietf.org; Wed, 26 Oct 2005 10:51:51 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QERgrn002031 for ; Wed, 26 Oct 2005 15:27:42 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9QERglY002030 for ipdvb-subscribed-users; Wed, 26 Oct 2005 15:27:42 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout01-03.mesa1.secureserver.net (smtpout01-03.mesa1.secureserver.net [64.202.165.78]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j9QERUOq002013 for ; Wed, 26 Oct 2005 15:27:31 +0100 (BST) Received: (qmail 17543 invoked from network); 26 Oct 2005 14:27:24 -0000 Received: from unknown (HELO gem-wbe04) (64.202.189.36) by smtpout01-03.mesa1.secureserver.net with SMTP; 26 Oct 2005 14:27:24 -0000 Received: (qmail 18443 invoked by uid 99); 26 Oct 2005 14:27:24 -0000 Date: Wed, 26 Oct 2005 07:27:24 -0700 From: Marie-Jose Montpetit Subject: RE: Thoughts on CRC usage To: ipdvb@erg.abdn.ac.uk, juan.cantillo@ensica.fr cc: IPDVB Message-ID: <20051026072724.ca5566c7162b3cfcb6c200079b757bd6.139961a59d.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is all interesting but for me the fundamental issue is that as far as I know, unless all your packets are fixed length (ATM cell? VOIP? Ethernet Frames) and you are not trying some app level queue management to increase throughput (like packing packets until a timer is set which may or may not mean a constant number of packets) resulting in a fixed padding at the end of each MPEG frame then, in general, padding will be variable. How do you signal which CRC was used? And yes AWGN may not be the right model for all DVB networks: 3G or HFC etc. could have very different characteristics. Maybe I'm missing something? /mjm > -------- Original Message -------- > Subject: Thoughts on CRC usage > From: "Juan Cantillo" > Date: Wed, October 26, 2005 6:01 am > To: "IPDVB" > > > > > > (This mail might appear twice in the list, since I sent it from another mail address... it looks like majordomo filters the senders it doesn't know, right?) > > Dear Gorry and Fausto, > > Gorry said: > >>>BER performance is often hard to quantify. Does that mean that WHATEVER > >>>distorted waveform is presented at the input to the receiver, the output of > >>>the link FEC processing will result in either a BBframe being marked as > >>>invalid, or one that has up to 10-7 errors in the forwarded frames?" > >>>Even this is not exact, a single BBframe could (with small probability) > >>>contain many errors - and somehow this has to be detected. > >>>IMHO, this means we need to consider the worst-case lvele of residual > >>>(undetected) errors that can be presented in any single BB frame. > > 1e-7 is the Packet Error Rate (PER). This is the probability that the FEC used to protect the BBFrame cannot *correct* all the erroneous bits in a BBFRAME. Say that 1 packet out of 10 000 000 cannot be corrected. One important strength of the BCH used is that he can also *detect* very accurately that this packet was indeed erroneous after decoding; theoretical estimates show that he will prove wrong only 1e-8 of the time. > So if you ask your BCH to do error *correction + detection*, at the encapsulation layer, only 1e-15 of your packets will be wrong (this is the "small probability" Gorry refers to)!!! At 15 Mbits/s, for frames of length 384 Byte, this means one uncorrected packet every 6000 years more or less :-) That means that if you If you intend to use a CRC to correct link errors, it will only be activated once every 6000 years. > > To verify these estimations, we have been running some simulations under various link conditions here in Toulouse since July, full time, and as expected, we still have not detected a single erroneous BBFRAME on our platform after FEC correction + detection :-) > > >>>The question of retransmissions is irrelevent. The issue here is data > >>>integrity - the probability that a corrupted block is (mis)delivered to and > >>>accepted by an application. > > I agree with Gorry. Protecting data is the most important issue, and it should not depend on padding presence/absence. IMHO, the key point is analysing where the threats to data integrity come from: if we suppose that an error event is due *only* to the AWGN link, Maths and simulations clearly prove that CRCs could be removed. If on the other hand you suppose that there might be errors *other* than link ones (say, bit offsets due to bugs in the sofware/hardware), then making a CRC check can be the only way to spot them. > > Unfortunately, no figures nor precise measurements/litterature are available on that at our knowledge! If anyone has data on this particular issue we would gratefully appreciate it. If those became available you could then scale properly the length of the CRC you need, if that threat proves worth it. > > Any thoughts on this? > > Juan > > > ----------------------------------------------------------------------- > Juan CANTILLO - SatComs PhD. Researcher > Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 > ENST/TeSA/ENSICA/AAS, Toulouse, FR From owner-ipdvb@erg.abdn.ac.uk Wed Oct 26 11:19:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUn3q-0005x1-Vw for ipdvb-archive@megatron.ietf.org; Wed, 26 Oct 2005 11:19:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00509 for ; Wed, 26 Oct 2005 11:19:15 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnH0-0006jY-0s for ipdvb-archive@ietf.org; Wed, 26 Oct 2005 11:33:08 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QF8ndK005639 for ; Wed, 26 Oct 2005 16:08:49 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9QF8n1u005638 for ipdvb-subscribed-users; Wed, 26 Oct 2005 16:08:49 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QF8f6O005621 for ; Wed, 26 Oct 2005 16:08:42 +0100 (BST) Received: by zproxy.gmail.com with SMTP id s1so128393nze for ; Wed, 26 Oct 2005 08:08:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fEQMVMUPm2lX4GZDbjQGHZBd6rZsX4m49JhJ16lQvKQrzRLJ/Ern1n1OI1uEdDqzdadVpZyWRa2a3c2/oZYnHIw6ZoRy9TtbxnOX5uXDF3vd2N/toPv/57hE/cdIn8q2H9jy+ZsJIU4996nCbnsHM1voGrpTOXFtcz2qAv8uSGw= Received: by 10.36.108.10 with SMTP id g10mr1083690nzc; Wed, 26 Oct 2005 08:08:41 -0700 (PDT) Received: by 10.37.21.80 with HTTP; Wed, 26 Oct 2005 08:08:41 -0700 (PDT) Message-ID: <7935e2f10510260808m1084ebc0i@mail.gmail.com> Date: Wed, 26 Oct 2005 17:08:41 +0200 From: Juan Cantillo To: Marie-Jose Montpetit Subject: Re: Thoughts on CRC usage Cc: ipdvb@erg.abdn.ac.uk In-Reply-To: <20051026072724.ca5566c7162b3cfcb6c200079b757bd6.139961a59d.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4394_21563697.1130339321446" References: <20051026072724.ca5566c7162b3cfcb6c200079b757bd6.139961a59d.wbe@email.email.secureserver.net> X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 ------=_Part_4394_21563697.1130339321446 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear MJ, Indeed,our approach is not concerned with Fausto's proposal of a variable length of an optional CRC, that would be inserted according to padding absence/presence :-) Our approach concerns a "classical" and fixed-length CRC as we have in the encapsulation layer, that we suppose implemented and running. We are concerned about the number of times it is activated in real life. Our results suggest that it could be removed *totally* under some error-pattern hypothesis, that are those of the AWGN channel. 3G or other systems may not be AWGN, but a forward link under DVBS2 is AWGN as far as we know at bit level. Bets regards, Juan 2005/10/26, Marie-Jose Montpetit : > > This is all interesting but for me the fundamental issue is that as far > as I know, unless all your packets are fixed length (ATM cell? VOIP? > Ethernet Frames) and you are not trying some app level queue management > to increase throughput (like packing packets until a timer is set which > may or may not mean a constant number of packets) resulting in a fixed > padding at the end of each MPEG frame then, in general, padding will be > variable. How do you signal which CRC was used? And yes AWGN may not be > the right model for all DVB networks: 3G or HFC etc. could have very > different characteristics. > > Maybe I'm missing something? > > /mjm > > > -------- Original Message -------- > > Subject: Thoughts on CRC usage > > From: "Juan Cantillo" > > Date: Wed, October 26, 2005 6:01 am > > To: "IPDVB" > > > > > > > > > > > > (This mail might appear twice in the list, since I sent it from another > mail address... it looks like majordomo filters the senders it doesn't kn= ow, > right?) > > > > Dear Gorry and Fausto, > > > > Gorry said: > > >>>BER performance is often hard to quantify. Does that mean that > WHATEVER > > >>>distorted waveform is presented at the input to the receiver, the > output of > > >>>the link FEC processing will result in either a BBframe being marked > as > > >>>invalid, or one that has up to 10-7 errors in the forwarded frames?" > > >>>Even this is not exact, a single BBframe could (with small > probability) > > >>>contain many errors - and somehow this has to be detected. > > >>>IMHO, this means we need to consider the worst-case lvele of residua= l > > >>>(undetected) errors that can be presented in any single BB frame. > > > > 1e-7 is the Packet Error Rate (PER). This is the probability that the > FEC used to protect the BBFrame cannot *correct* all the erroneous bits i= n a > BBFRAME. Say that 1 packet out of 10 000 000 cannot be corrected. One > important strength of the BCH used is that he can also *detect* very > accurately that this packet was indeed erroneous after decoding; theoreti= cal > estimates show that he will prove wrong only 1e-8 of the time. > > So if you ask your BCH to do error *correction + detection*, at the > encapsulation layer, only 1e-15 of your packets will be wrong (this is th= e > "small probability" Gorry refers to)!!! At 15 Mbits/s, for frames of leng= th > 384 Byte, this means one uncorrected packet every 6000 years more or less > :-) That means that if you If you intend to use a CRC to correct link > errors, it will only be activated once every 6000 years. > > > > To verify these estimations, we have been running some simulations unde= r > various link conditions here in Toulouse since July, full time, and as > expected, we still have not detected a single erroneous BBFRAME on our > platform after FEC correction + detection :-) > > > > >>>The question of retransmissions is irrelevent. The issue here is dat= a > > >>>integrity - the probability that a corrupted block is (mis)delivered > to and > > >>>accepted by an application. > > > > I agree with Gorry. Protecting data is the most important issue, and it > should not depend on padding presence/absence. IMHO, the key point is > analysing where the threats to data integrity come from: if we suppose th= at > an error event is due *only* to the AWGN link, Maths and simulations clea= rly > prove that CRCs could be removed. If on the other hand you suppose that > there might be errors *other* than link ones (say, bit offsets due to bug= s > in the sofware/hardware), then making a CRC check can be the only way to > spot them. > > > > Unfortunately, no figures nor precise measurements/litterature are > available on that at our knowledge! If anyone has data on this particular > issue we would gratefully appreciate it. If those became available you co= uld > then scale properly the length of the CRC you need, if that threat proves > worth it. > > > > Any thoughts on this? > > > > Juan > > > > > > ----------------------------------------------------------------------- > > Juan CANTILLO - SatComs PhD. Researcher > > Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 > > ENST/TeSA/ENSICA/AAS, Toulouse, FR > > ------=_Part_4394_21563697.1130339321446 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Dear MJ,
 
Indeed,our approach is not concerned with Fausto's proposal&= nbsp;of a variable length of an optional CRC, that would be inser= ted according to padding absence/presence :-)
 
Our approach concerns a "classical" and fixed-length&nb= sp;CRC as we have in the encapsulation layer, that we suppose imp= lemented and running. We are concerned about the number of times it is acti= vated in real life. Our results suggest that it could be removed *tota= lly* under some error-pattern hypothesis, that are those of the AWGN channe= l. 3G or other systems may not be AWGN, but a forward link under DVBS2 is A= WGN as far as we know at bit level.
 
Bets regards,
 
Juan


 
2005/10/26, Marie-Jose Montpetit <marie@mjmontpetit.com>:
This is all interesting but for = me the fundamental issue is that as far
as I know, unless all your packe= ts are fixed length (ATM cell? VOIP?
Ethernet Frames) and you are not trying some app level queue management=
to increase throughput (like packing packets until a timer is set which=
may or may not mean a constant number of packets) resulting in a fixed
padding at the end of each MPEG frame then, in general, padding will be=
variable. How do you signal which CRC was used? And yes AWGN may not be=
the right model for all DVB networks: 3G or HFC etc. could have very
different characteristics.

Maybe I'm missing something?

/= mjm

> -------- Original Message --------
> Subject: Thought= s on CRC usage
> From: "Juan Cantillo" < juan.cantillo@ensica.fr>
> Date: Wed, October 26, 2005 6:01 am=
> To: "IPDVB" <= ipdvb@erg.abdn.ac.uk>
>
>
>
>
>
>= ; (This mail might appear twice in the list, since I sent it from another m= ail address... it looks like majordomo filters the senders it doesn't know,= right?)
>
> Dear Gorry and Fausto,
>
> Gorry said:
>= >>>BER performance is often hard to quantify. Does that mean that= WHATEVER
> >>>distorted waveform is presented at the input = to the receiver, the output of
> >>>the link FEC processing will result in either a BBfram= e being marked as
> >>>invalid, or one that has up to 10-7 e= rrors in the forwarded frames?"
> >>>Even this is not e= xact, a single BBframe could (with small probability)
> >>>contain many errors - and somehow this has to be detec= ted.
> >>>IMHO, this means we need to consider the worst-cas= e lvele of residual
> >>>(undetected) errors that can be pre= sented in any single BB frame.
>
> 1e-7 is the Packet Error Rate (PER). This is the probabili= ty that the FEC used to protect the BBFrame cannot *correct* all the errone= ous bits in a BBFRAME. Say that 1 packet out of 10 000 000 cannot be correc= ted. One important strength of the BCH used is that he can also *detect* ve= ry accurately that this packet was indeed erroneous after decoding; theoret= ical estimates show that he will prove wrong only 1e-8 of the time.
> So if you ask your BCH to do error *correction + detection*, at th= e encapsulation layer, only 1e-15 of your packets will be wrong (this is th= e "small probability" Gorry refers to)!!! At 15 Mbits/s, for fram= es of length 384 Byte, this means one uncorrected packet every 6000 years m= ore or less :-) That means that if you If you intend to use a CRC to correc= t link errors, it will only be activated once every 6000 years.
>
> To verify these estimations, we have been running some sim= ulations under various link conditions here in Toulouse since July, full ti= me, and as expected, we still have not detected a single erroneous BBFRAME = on our platform after FEC correction + detection :-)
>
> >>>The question of retransmissions is irrelevent.= The issue here is data
> >>>integrity - the probability tha= t a corrupted block is (mis)delivered to and <!-- D(["mb",&quo= t;
> >>>accepted by an application. \r\n
>
> I agr= ee with Gorry. Protecting data is the most important issue, and it should n= ot depend on padding presence/absence. IMHO, the key point is analysing whe= re the threats to data integrity come from: if we suppose that an error eve= nt is due *only* to the AWGN link, Maths and simulations clearly prove that= CRCs could be removed. If on the other hand you suppose that there might b= e errors *other* than link ones (say, bit offsets due to bugs in the sofwar= e/hardware), then making a CRC check can be the only way to spot them. \r\n= \r\n
>
> Unfortunately, no figures nor precise measurements/littera= ture are available on that at our knowledge! If anyone has data on this par= ticular issue we would gratefully appreciate it. If those became available = you could then scale properly the length of the CRC you need, if that threa= t proves worth it. \r\n
>
> Any thoughts on this?
>
> Juan
> \r\n\r\= n",0] ); D(["ce"]); D(["ms","221"] ); //= -->
> >>>accepted by an application.
>
> I ag= ree with Gorry. Protecting data is the most important issue, and it should = not depend on padding presence/absence. IMHO, the key point is analysing wh= ere the threats to data integrity come from: if we suppose that an error ev= ent is due *only* to the AWGN link, Maths and simulations clearly prove tha= t CRCs could be removed. If on the other hand you suppose that there might = be errors *other* than link ones (say, bit offsets due to bugs in the sofwa= re/hardware), then making a CRC check can be the only way to spot them.
>
> Unfortunately, no figures nor precise measurements/littera= ture are available on that at our knowledge! If anyone has data on this par= ticular issue we would gratefully appreciate it. If those became available = you could then scale properly the length of the CRC you need, if that threa= t proves worth it.
>
> Any thoughts on this?
>
> Juan
>
>=
> ------------------------------------------------------------------= -----
> Juan CANTILLO - SatComs PhD. Researcher
> Tel +33 6 23 = 54 59 65- Fax  +33 5 61 61 86 88
> ENST/TeSA/ENSICA/AAS, Toulouse, FR


------=_Part_4394_21563697.1130339321446-- From owner-ipdvb@erg.abdn.ac.uk Wed Oct 26 17:19:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsfz-0004tu-W4 for ipdvb-archive@megatron.ietf.org; Wed, 26 Oct 2005 17:19:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27335 for ; Wed, 26 Oct 2005 17:19:00 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUstE-0005fU-7X for ipdvb-archive@ietf.org; Wed, 26 Oct 2005 17:32:56 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QKvjEB003218 for ; Wed, 26 Oct 2005 21:57:45 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9QKvjJN003217 for ipdvb-subscribed-users; Wed, 26 Oct 2005 21:57:45 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9QKvaki003200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 26 Oct 2005 21:57:37 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.7048739; Wed, 26 Oct 2005 16:41:18 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_RE=3A_Thoughts_on_the_impact_of_Sig?= =?iso-8859-1?Q?nalling_security__on_IP_traffic?= Date: Wed, 26 Oct 2005 16:41:18 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C17458D03@morse.NAB.ORG> Thread-Topic: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_Thoughts_on_the_impact_of_Signalling_se?= =?iso-8859-1?Q?curity__on_IP_traffic?= Thread-Index: AcXaMA748GajW/xDSqK6oto5y7bMuwAPCbQg From: "Allison, Art" To: X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j9QKvifj003214 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j9QKvjEB003218 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Just a toe back into the security discussion - even though US terrestrial= broadcasters (my interest group) won't be using ULE anyway. I posted som= e thoughts a while back- they still seem consistent with all data availab= le to me. The transport of ULE packets in MPEG-2 TS is the responsibility= of someone else. If you don't trust the t= ransport security provisions, either don't use it or convince the provide= r to improve them. Or add a layer that reduces your payload and increase= s your complexity. Attempting to define how a transport shall be constructed when there are = other standards that already do that just adds to the list of voluntary s= tandards one must decide among when selecting what to support. Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N St. NW Washington DC 20036 202 429 5418 -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On B= ehalf Of Marie-Jose Montpetit Sent: Wednesday, October 26, 2005 8:00 AM To: Stephane.Combes@alcatelaleniaspace.com Cc: ipdvb@erg.abdn.ac.uk Subject: RE: R=E9f. : RE: Thoughts on the impact of Signalling security o= n IP traffic Should Amerhis drive all the requirements for MPEG/ULE security? We shoul= d make sure that IP over DVB does not become another IP over satellite - = that too many people think it is BTW. And yes: we should do ULE and leave DVB (and other groups) to address the= big picture. /mjm > -------- Original Message -------- > Subject: R=E9f. : RE: Thoughts on the impact of Signalling security on= =20 > IP traffic > From: Stephane.Combes@alcatelaleniaspace.com > Date: Wed, October 26, 2005 5:57 am > To: Marie-Jose Montpetit > Cc: ipdvb@erg.abdn.ac.uk > > Hi Marie-Jos=E9, > > I admit that a conventional hub-and-spoke DVB network will not have=20 > more stringent requirements than a DOCSIS network. But this is not the=20 > case of mesh DVB-RCS networks (eg Amerhis system). Here the MPEG-2 mux=20 > is on-board the satellite and the signalling is generated by a Network=20 > Control Center > (NCC) which is just like any other sender/receiver. Therefore this NCC=20 > is probably easier to impersonate than a cable headend. > > Regarding preventing the return channel to be monitored, this is a=20 > very important issue for the most "sensible" networks. And IPSec=20 > cannot help here... > > As a general comment on the current discussion thread, my feeling is: > - Securing DVB and MPEG-2 signalling seems a bit out-of-scope to me.=20 > The current I-D mostly concentrate on securing ULE (and ULE=20 > signalling). It is true that "the integrity of control and management=20 > message in MPEG-2 networks" appears as an optional requirement in the=20 > I-D. But perhaps this is too vague and we should first concentrate on=20 > ULE and not go down to MPEG. > - We can discuss DVB and MPEG signalling security but this issue=20 > should probably be owned by the DVB Forum or by groups which have=20 > developed some specific additional signalling protocols (e.g. SatLabs=20 > for RCS protocols) > > cheers, > > St=E9phane > > > > > Marie-Jose > Montpetit Pour : ipdvb@erg.abdn.= ac.uk > > it.com> "H.Cruickshank" > Stephane Combes/ALCATEL-= SPACE@ALCATEL-SPACE > 25/10/2005 21:53 Laurence Duquerroy/ALCAT= EL-SPACE@ALCATEL-SPACE > Veuillez "S.Iyengar" > r=E9pondre =E0 Objet : RE: Thought= s on the impact of Signalling security on IP traffic > Marie-Jose > Montpetit > > > > > > I ping'ed one of our security people here at Motorola and please find=20 > below what he had as a comment: > > "In the case of DOCSIS, we had the debate a few years ago on whether=20 > or not it is easy to impersonate the headend and modify the contents=20 > of a DOCSIS downstream, which is just an MPEG-2 multiplex. It was=20 > decided by the working group that such an attack would be too costly=20 > and impractical - for HFC cable networks at least. The same probably=20 > applies for satellite networks. > > This email suggests that the return channel could be monitored to=20 > determine if an STB is logged in or not. As the email suggests, IP=20 > traffic can be protected with IPsec - but generally any IP stack=20 > including the one over DVB can be modified to include IPsec." > > I think the group should look a bit more at what was done on the cable=20 > side? > > /mjm > > > > > -------- Original Message -------- > > Subject: Re: Thoughts on the impact of Signalling security on IP=20 > > traffic > > From: Gorry Fairhurst > > Date: Tue, October 25, 2005 11:41 am > > To: "S.Iyengar" > > Cc: ipdvb , "H.Cruickshank" > > , "stephane.combes" > > , "Laurence.Duquerroy" > > > > > > Here are some thoughts... Comments welcome! > > > > Gorry > > > > --- > > > > > > Some of the L2 signalling security properties include: > > > > - No authentication of the signalling source. The layer-2 signalling=20 > > entity is often not be the encapsulation gateway itself. > > - No encryption (but sometimes this is needed to bootstrap terminals). > > - Integrity check is a CRC-32. This is relatively weak compared to a=20 > > cryptographic hash. (Should the forging of table contents needs to=20 > > be > > considered?) > > - (re)multiplexors do modify (or insert new SI tables), but there is=20 > > no security association with these devices within an MPEG-2=20 > > Transmission network. > > - Modification/Denial of the SI information could result in=20 > > association > of a > > different stream with the service, or an inability to identify the=20 > > TS Logical Channel (PID) that is used for a service. > > > > Threats from interception of Forward link signalling. > > > > In current MPEG-TS networks, the forward link signalling is not > encrypted. > > Eavesdropping of the signalling information does not reveal any > information > > which is not available to all receivers. > > > > In the case of two-way networks, forward link signalling can reveal > traffic > > parameters of the return links from specific users. This information=20 > > can also reveal the status of specific terminals (logon/logoff, etc)=20 > > and the timing and transmission parameters used by these terminals. > > > > Some of these threats could be reduced by using IP-based signalling=20 > > [ref] and appropriate IP-level security mechanisms (e.g. IPsec). > > > > Replay/Jamming > > > > - SI information is required to associate PID values with Streams=20 > > and therefore to demultiplex the data at the Receiver. > > - In two-way systems, denial of forward signalling may also prevent=20 > > link transmission in the return direction. > > - Jamming/interception may also occur in the return link direction.=20 > > In > this > > case, forged return link signalling could acquire return link=20 > > bandwidth, > or > > modify the state of a terminal as perceived at the network control > centre. > > These threats can be exploited as a DoS attack. > > > > - SI information may be sent periodically. If the time of=20 > > transmission is predictable, this could be "jammed" resulting in=20 > > loss of signalling at > the > > receiver, which is a DoS vulnerability. It requires access to the=20 > > stream > - > > either on the air interface (e.g. A different transmitter injecting=20 > > a > signal > > that is Received (e.g. On an antenna side-lobe). > > - Modification of SI can also be a DoS attack, this requires access=20 > > to > the > > network components (multiplexors, etc) and/or connecting physical=20 > > media - > a > > man-in-the-middle attack. > > > > > > Research Department/Advanced Telecom Systems -- R&D Engineer Tel :=20 > +33 53435 6938 / Fax : +33 53435 5560 Porte : W219 / E-Mail :=20 > stephane.combes@alcatelaleniaspace.com > > This message and any attachments (the "message") is intended solely=20 > for the addressees and is confidential. If you receive this message in=20 > error, please delete it and immediately notify the sender. Any use not=20 > in accord with its purpose, any dissemination or disclosure, either=20 > whole or partial, is prohibited except formal approval. The internet=20 > can not guarantee the integrity of this message. ALCATEL ALENIA SPACE=20 > (and its subsidiaries) shall (will) not therefore be liable for the mes= sage if modified. > > Ce message et toutes les pieces jointes (ci-apres le "message") sont=20 > etablis a l'intention exclusive de ses destinataires et sont confidenti= els. > Si vous recevez ce message par erreur, merci de le detruire et d'en=20 > avertir immediatement l'expediteur. Toute utilisation de ce message=20 > non conforme a sa destination, toute diffusion ou toute publication,=20 > totale ou partielle, est interdite, sauf autorisation expresse.=20 > L'internet ne permettant pas d'assurer l'integrite de ce message,=20 > ALCATEL ALENIA SPACE (et ses filiales) > decline(nt) toute responsabilite au titre de ce message, dans=20 > l'hypothese ou il aurait ete modifie. From owner-ipdvb@erg.abdn.ac.uk Thu Oct 27 13:07:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBDt-0005rQ-Jj for ipdvb-archive@megatron.ietf.org; Thu, 27 Oct 2005 13:07:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16017 for ; Thu, 27 Oct 2005 13:07:12 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBRH-00044n-Ua for ipdvb-archive@ietf.org; Thu, 27 Oct 2005 13:21:20 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9RGipie026095 for ; Thu, 27 Oct 2005 17:44:51 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9RGip5i026094 for ipdvb-subscribed-users; Thu, 27 Oct 2005 17:44:51 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9RGilk8026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 27 Oct 2005 17:44:47 +0100 (BST) Message-ID: <436103FE.3040606@erg.abdn.ac.uk> Date: Thu, 27 Oct 2005 17:44:46 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: =?ISO-8859-1?Q?R=E9f=2E_=3A_RE=3A_Thoughts_on_the_?= =?ISO-8859-1?Q?impact_of_Signalling_security__on_IP_traffi?= =?ISO-8859-1?Q?c?= References: <33CB4DEADE8C734CAF59FA0B47E14C17458D03@morse.NAB.ORG> In-Reply-To: <33CB4DEADE8C734CAF59FA0B47E14C17458D03@morse.NAB.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j9RGipie026095 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: quoted-printable When I started the thread, my comment was related to: draft-cruickshank-ipdvb-sec-req-00.txt Which includes a draft of an analysis of potential threats to the IP serv= ice=20 when used over this type of network. To me this still seems a valid quest= ion... MPEG-2 signalling is a part of the system - and control-plane attacks are= not=20 unheard of in IP networks. (In many other networks the L2 control plane i= s=20 also visibile). One conclusion may be that despite a lack of security mechanisms, such at= tacks=20 are hard in most practical networks, because the physical infrastructure = is=20 itself secured (i.e. they require access to the multiplexor,modulator, et= c),=20 in contrast to WiFi networks were this is easy - to me, this seems to be = the=20 case put forward for DOCSIS. It was also put forward as a case for satell= ite=20 TV broadcast networks. Although it seems the next generation of satellite= =20 on-board multiplexors could require some thought? I was primarilly thinking about terrestrial receivers - where a follow-on= =20 attack could be possible by receiving the bit-stream and then regeneratin= g a=20 different bitstream that was transmitted locally towards a receiver to=20 manipulate the IP packet flow (e.g. inject data). Gorry Allison, Art wrote: > Just a toe back into the security discussion - even though US terrestri= al broadcasters (my interest group) won't be using ULE anyway. I posted s= ome thoughts a while back- they still seem consistent with all data avail= able to me. The transport of ULE packets in MPEG-2 TS is the responsibili= ty of someone else. If you don't trust the= transport security provisions, either don't use it or convince the provi= der to improve them. Or add a layer that reduces your payload and increa= ses your complexity. >=20 > Attempting to define how a transport shall be constructed when there ar= e other standards that already do that just adds to the list of voluntary= standards one must decide among when selecting what to support. >=20 > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N St. NW > Washington DC 20036 > 202 429 5418 >=20 >=20 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On= Behalf Of Marie-Jose Montpetit > Sent: Wednesday, October 26, 2005 8:00 AM > To: Stephane.Combes@alcatelaleniaspace.com > Cc: ipdvb@erg.abdn.ac.uk > Subject: RE: R=E9f. : RE: Thoughts on the impact of Signalling security= on IP traffic >=20 > Should Amerhis drive all the requirements for MPEG/ULE security? We sho= uld make sure that IP over DVB does not become another IP over satellite = - that too many people think it is BTW. >=20 > And yes: we should do ULE and leave DVB (and other groups) to address t= he big picture. >=20 > /mjm >=20 >=20 >>-------- Original Message -------- >>Subject: R=E9f. : RE: Thoughts on the impact of Signalling security on= =20 >>IP traffic >>From: Stephane.Combes@alcatelaleniaspace.com >>Date: Wed, October 26, 2005 5:57 am >>To: Marie-Jose Montpetit >>Cc: ipdvb@erg.abdn.ac.uk >> >>Hi Marie-Jos=E9, >> >>I admit that a conventional hub-and-spoke DVB network will not have=20 >>more stringent requirements than a DOCSIS network. But this is not the=20 >>case of mesh DVB-RCS networks (eg Amerhis system). Here the MPEG-2 mux=20 >>is on-board the satellite and the signalling is generated by a Network=20 >>Control Center >>(NCC) which is just like any other sender/receiver. Therefore this NCC=20 >>is probably easier to impersonate than a cable headend. >> >>Regarding preventing the return channel to be monitored, this is a=20 >>very important issue for the most "sensible" networks. And IPSec=20 >>cannot help here... >> >>As a general comment on the current discussion thread, my feeling is: >>- Securing DVB and MPEG-2 signalling seems a bit out-of-scope to me.=20 >>The current I-D mostly concentrate on securing ULE (and ULE=20 >>signalling). It is true that "the integrity of control and management=20 >>message in MPEG-2 networks" appears as an optional requirement in the=20 >>I-D. But perhaps this is too vague and we should first concentrate on=20 >>ULE and not go down to MPEG. >>- We can discuss DVB and MPEG signalling security but this issue=20 >>should probably be owned by the DVB Forum or by groups which have=20 >>developed some specific additional signalling protocols (e.g. SatLabs=20 >>for RCS protocols) >> >>cheers, >> >>St=E9phane >> >> >> >> >> Marie-Jose >> Montpetit Pour : ipdvb@erg.abdn.= ac.uk >> >> it.com> "H.Cruickshank" >> Stephane Combes/ALCATEL-= SPACE@ALCATEL-SPACE >> 25/10/2005 21:53 Laurence Duquerroy/ALCAT= EL-SPACE@ALCATEL-SPACE >> Veuillez "S.Iyengar" >> r=E9pondre =E0 Objet : RE: Thought= s on the impact of Signalling security on IP traffic >> Marie-Jose >> Montpetit >> >> >> >> >> >>I ping'ed one of our security people here at Motorola and please find=20 >>below what he had as a comment: >> >>"In the case of DOCSIS, we had the debate a few years ago on whether=20 >>or not it is easy to impersonate the headend and modify the contents=20 >>of a DOCSIS downstream, which is just an MPEG-2 multiplex. It was=20 >>decided by the working group that such an attack would be too costly=20 >>and impractical - for HFC cable networks at least. The same probably=20 >>applies for satellite networks. >> >>This email suggests that the return channel could be monitored to=20 >>determine if an STB is logged in or not. As the email suggests, IP=20 >>traffic can be protected with IPsec - but generally any IP stack=20 >>including the one over DVB can be modified to include IPsec." >> >>I think the group should look a bit more at what was done on the cable=20 >>side? >> >>/mjm >> >> >> >> >>>-------- Original Message -------- >>>Subject: Re: Thoughts on the impact of Signalling security on IP=20 >>>traffic >>>From: Gorry Fairhurst >>>Date: Tue, October 25, 2005 11:41 am >>>To: "S.Iyengar" >>>Cc: ipdvb , "H.Cruickshank" >>>, "stephane.combes" >>>, "Laurence.Duquerroy" >>> >>> >>>Here are some thoughts... Comments welcome! >>> >>>Gorry >>> >>>--- >>> >>> >>>Some of the L2 signalling security properties include: >>> >>>- No authentication of the signalling source. The layer-2 signalling=20 >>>entity is often not be the encapsulation gateway itself. >>>- No encryption (but sometimes this is needed to bootstrap terminals). >>>- Integrity check is a CRC-32. This is relatively weak compared to a=20 >>>cryptographic hash. (Should the forging of table contents needs to=20 >>>be >>>considered?) >>>- (re)multiplexors do modify (or insert new SI tables), but there is=20 >>>no security association with these devices within an MPEG-2=20 >>>Transmission network. >>>- Modification/Denial of the SI information could result in=20 >>>association >> >>of a >> >>>different stream with the service, or an inability to identify the=20 >>>TS Logical Channel (PID) that is used for a service. >>> >>>Threats from interception of Forward link signalling. >>> >>>In current MPEG-TS networks, the forward link signalling is not >> >>encrypted. >> >>>Eavesdropping of the signalling information does not reveal any >> >>information >> >>>which is not available to all receivers. >>> >>>In the case of two-way networks, forward link signalling can reveal >> >>traffic >> >>>parameters of the return links from specific users. This information=20 >>>can also reveal the status of specific terminals (logon/logoff, etc)=20 >>>and the timing and transmission parameters used by these terminals. >>> >>>Some of these threats could be reduced by using IP-based signalling=20 >>>[ref] and appropriate IP-level security mechanisms (e.g. IPsec). >>> >>>Replay/Jamming >>> >>>- SI information is required to associate PID values with Streams=20 >>>and therefore to demultiplex the data at the Receiver. >>>- In two-way systems, denial of forward signalling may also prevent=20 >>>link transmission in the return direction. >>>- Jamming/interception may also occur in the return link direction.=20 >>>In >> >>this >> >>>case, forged return link signalling could acquire return link=20 >>>bandwidth, >> >>or >> >>>modify the state of a terminal as perceived at the network control >> >>centre. >> >>>These threats can be exploited as a DoS attack. >>> >>>- SI information may be sent periodically. If the time of=20 >>>transmission is predictable, this could be "jammed" resulting in=20 >>>loss of signalling at >> >>the >> >>>receiver, which is a DoS vulnerability. It requires access to the=20 >>>stream >> >>- >> >>>either on the air interface (e.g. A different transmitter injecting=20 >>>a >> >>signal >> >>>that is Received (e.g. On an antenna side-lobe). >>>- Modification of SI can also be a DoS attack, this requires access=20 >>>to >> >>the >> >>>network components (multiplexors, etc) and/or connecting physical=20 >>>media - >> >>a >> >>>man-in-the-middle attack. >> >> >> >> >> >>Research Department/Advanced Telecom Systems -- R&D Engineer Tel :=20 >>+33 53435 6938 / Fax : +33 53435 5560 Porte : W219 / E-Mail :=20 >>stephane.combes@alcatelaleniaspace.com >> >>This message and any attachments (the "message") is intended solely=20 >>for the addressees and is confidential. If you receive this message in=20 >>error, please delete it and immediately notify the sender. Any use not=20 >>in accord with its purpose, any dissemination or disclosure, either=20 >>whole or partial, is prohibited except formal approval. The internet=20 >>can not guarantee the integrity of this message. ALCATEL ALENIA SPACE=20 >>(and its subsidiaries) shall (will) not therefore be liable for the mes= sage if modified. >> >>Ce message et toutes les pieces jointes (ci-apres le "message") sont=20 >>etablis a l'intention exclusive de ses destinataires et sont confidenti= els. >>Si vous recevez ce message par erreur, merci de le detruire et d'en=20 >>avertir immediatement l'expediteur. Toute utilisation de ce message=20 >>non conforme a sa destination, toute diffusion ou toute publication,=20 >>totale ou partielle, est interdite, sauf autorisation expresse.=20 >>L'internet ne permettant pas d'assurer l'integrite de ce message,=20 >>ALCATEL ALENIA SPACE (et ses filiales) >>decline(nt) toute responsabilite au titre de ce message, dans=20 >>l'hypothese ou il aurait ete modifie. >=20 >=20 >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Thu Oct 27 15:07:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVD5c-00041F-OA for ipdvb-archive@megatron.ietf.org; Thu, 27 Oct 2005 15:07:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23048 for ; Thu, 27 Oct 2005 15:06:46 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDIz-0007l7-MG for ipdvb-archive@ietf.org; Thu, 27 Oct 2005 15:20:56 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9RJ2KMo007141 for ; Thu, 27 Oct 2005 20:02:20 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9RJ2KhY007140 for ipdvb-subscribed-users; Thu, 27 Oct 2005 20:02:20 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9RJ27TP007120 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 27 Oct 2005 20:02:08 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.7062091; Thu, 27 Oct 2005 14:45:43 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: =?iso-8859-1?Q?RE=3A_R=E9f=2E_=3A_RE=3A_Thoughts_on_the_impact_of_Sig?= =?iso-8859-1?Q?nalling_security__on_IP_traffic?= Date: Thu, 27 Oct 2005 14:45:39 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C17458D0A@morse.NAB.ORG> Thread-Topic: =?iso-8859-1?Q?R=E9f=2E_=3A_RE=3A_Thoughts_on_the_impact_of_Signalling_se?= =?iso-8859-1?Q?curity__on_IP_traffic?= Thread-Index: AcXbIvksY5nKAIYdR2CyPhvn371aUAAASmcw From: "Allison, Art" To: X-ERG-MailScanner: Found to be clean, Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id j9RJ2KZf007137 Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j9RJ2KMo007141 X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Content-Transfer-Encoding: quoted-printable Right... It is possible that someone could suitably equip a truck, drive it into a= neighborhood and overpower the RF that arrives at the nearby homes. Int= erception and retransmission for replacement requires very low processing= delay such that the real signal appears as reflection (pre-ghost) that = the receiver can cancel/ignore. (If those technical constraints are not m= et, nothing is received - that is it effectively is simply a RF jammer - = no standard can stop that. While I don't have quotes, certainly it would = cost several 10s of thousands US dollars for the equipment; and for the h= omes in the next torus where it did not swamp the receivers it would seri= ously interfere with reception (jammer again). While determination of in= terference sources can be hard, the large panel truck with antennas on mi= ght help in this case. If the attacker were an apartment dweller, he per= haps could impact neighbors in a similar manner and be more difficult to = detect. But it is not clear what benefit could be obtained from this lo= calized denial of service attack that many nearby would detect as lost of= regular TV programming. =20 After all the potential attacker can directly obtain all of the data stre= am and process it without interfering with anyone. I fail to see that discussion of a terrestrial spoofing attack is worthy = of further time or IP packets. But have it... ______________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N St. NW Washington DC 20036 202 429 5418 -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On B= ehalf Of Gorry Fairhurst Sent: Thursday, October 27, 2005 12:45 PM To: ipdvb@erg.abdn.ac.uk Subject: Re: R=E9f. : RE: Thoughts on the impact of Signalling security o= n IP traffic When I started the thread, my comment was related to: draft-cruickshank-ipdvb-sec-req-00.txt Which includes a draft of an analysis of potential threats to the IP serv= ice when used over this type of network. To me this still seems a valid q= uestion... MPEG-2 signalling is a part of the system - and control-plane attacks are= not unheard of in IP networks. (In many other networks the L2 control pl= ane is also visibile). One conclusion may be that despite a lack of security mechanisms, such at= tacks are hard in most practical networks, because the physical infrastru= cture is itself secured (i.e. they require access to the multiplexor,modu= lator, etc), in contrast to WiFi networks were this is easy - to me, this= seems to be the case put forward for DOCSIS. It was also put forward as = a case for satellite TV broadcast networks. Although it seems the next ge= neration of satellite on-board multiplexors could require some thought? I was primarilly thinking about terrestrial receivers - where a follow-on= attack could be possible by receiving the bit-stream and then regenerati= ng a different bitstream that was transmitted locally towards a receiver = to manipulate the IP packet flow (e.g. inject data). Gorry Allison, Art wrote: > Just a toe back into the security discussion - even though US terrestri= al broadcasters (my interest group) won't be using ULE anyway. I posted s= ome thoughts a while back- they still seem consistent with all data avail= able to me. The transport of ULE packets in MPEG-2 TS is the responsibili= ty of someone else. If you don't trust the= transport security provisions, either don't use it or convince the provi= der to improve them. Or add a layer that reduces your payload and increa= ses your complexity. >=20 > Attempting to define how a transport shall be constructed when there ar= e other standards that already do that just adds to the list of voluntary= standards one must decide among when selecting what to support. >=20 > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N St. NW > Washington DC 20036 > 202 429 5418 >=20 >=20 > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]=20 > On Behalf Of Marie-Jose Montpetit > Sent: Wednesday, October 26, 2005 8:00 AM > To: Stephane.Combes@alcatelaleniaspace.com > Cc: ipdvb@erg.abdn.ac.uk > Subject: RE: R=E9f. : RE: Thoughts on the impact of Signalling security= =20 > on IP traffic >=20 > Should Amerhis drive all the requirements for MPEG/ULE security? We sho= uld make sure that IP over DVB does not become another IP over satellite = - that too many people think it is BTW. >=20 > And yes: we should do ULE and leave DVB (and other groups) to address t= he big picture. >=20 > /mjm >=20 >=20 >>-------- Original Message -------- >>Subject: R=E9f. : RE: Thoughts on the impact of Signalling security on= =20 >>IP traffic >>From: Stephane.Combes@alcatelaleniaspace.com >>Date: Wed, October 26, 2005 5:57 am >>To: Marie-Jose Montpetit >>Cc: ipdvb@erg.abdn.ac.uk >> >>Hi Marie-Jos=E9, >> >>I admit that a conventional hub-and-spoke DVB network will not have=20 >>more stringent requirements than a DOCSIS network. But this is not the=20 >>case of mesh DVB-RCS networks (eg Amerhis system). Here the MPEG-2 mux=20 >>is on-board the satellite and the signalling is generated by a Network=20 >>Control Center >>(NCC) which is just like any other sender/receiver. Therefore this NCC=20 >>is probably easier to impersonate than a cable headend. >> >>Regarding preventing the return channel to be monitored, this is a=20 >>very important issue for the most "sensible" networks. And IPSec=20 >>cannot help here... >> >>As a general comment on the current discussion thread, my feeling is: >>- Securing DVB and MPEG-2 signalling seems a bit out-of-scope to me.=20 >>The current I-D mostly concentrate on securing ULE (and ULE=20 >>signalling). It is true that "the integrity of control and management=20 >>message in MPEG-2 networks" appears as an optional requirement in the=20 >>I-D. But perhaps this is too vague and we should first concentrate on=20 >>ULE and not go down to MPEG. >>- We can discuss DVB and MPEG signalling security but this issue=20 >>should probably be owned by the DVB Forum or by groups which have=20 >>developed some specific additional signalling protocols (e.g. SatLabs=20 >>for RCS protocols) >> >>cheers, >> >>St=E9phane >> >> >> >> >> Marie-Jose >> Montpetit Pour : ipdvb@erg.abdn.= ac.uk >> >> it.com> "H.Cruickshank" >> Stephane Combes/ALCATEL-= SPACE@ALCATEL-SPACE >> 25/10/2005 21:53 Laurence Duquerroy/ALCAT= EL-SPACE@ALCATEL-SPACE >> Veuillez "S.Iyengar" >> r=E9pondre =E0 Objet : RE: Thought= s on the impact of Signalling security on IP traffic >> Marie-Jose >> Montpetit >> >> >> >> >> >>I ping'ed one of our security people here at Motorola and please find=20 >>below what he had as a comment: >> >>"In the case of DOCSIS, we had the debate a few years ago on whether=20 >>or not it is easy to impersonate the headend and modify the contents=20 >>of a DOCSIS downstream, which is just an MPEG-2 multiplex. It was=20 >>decided by the working group that such an attack would be too costly=20 >>and impractical - for HFC cable networks at least. The same probably=20 >>applies for satellite networks. >> >>This email suggests that the return channel could be monitored to=20 >>determine if an STB is logged in or not. As the email suggests, IP=20 >>traffic can be protected with IPsec - but generally any IP stack=20 >>including the one over DVB can be modified to include IPsec." >> >>I think the group should look a bit more at what was done on the cable=20 >>side? >> >>/mjm >> >> >> >> >>>-------- Original Message -------- >>>Subject: Re: Thoughts on the impact of Signalling security on IP=20 >>>traffic >>>From: Gorry Fairhurst >>>Date: Tue, October 25, 2005 11:41 am >>>To: "S.Iyengar" >>>Cc: ipdvb , "H.Cruickshank" >>>, "stephane.combes" >>>, "Laurence.Duquerroy" >>> >>> >>>Here are some thoughts... Comments welcome! >>> >>>Gorry >>> >>>--- >>> >>> >>>Some of the L2 signalling security properties include: >>> >>>- No authentication of the signalling source. The layer-2 signalling=20 >>>entity is often not be the encapsulation gateway itself. >>>- No encryption (but sometimes this is needed to bootstrap terminals). >>>- Integrity check is a CRC-32. This is relatively weak compared to a=20 >>>cryptographic hash. (Should the forging of table contents needs to be >>>considered?) >>>- (re)multiplexors do modify (or insert new SI tables), but there is=20 >>>no security association with these devices within an MPEG-2=20 >>>Transmission network. >>>- Modification/Denial of the SI information could result in=20 >>>association >> >>of a >> >>>different stream with the service, or an inability to identify the TS=20 >>>Logical Channel (PID) that is used for a service. >>> >>>Threats from interception of Forward link signalling. >>> >>>In current MPEG-TS networks, the forward link signalling is not >> >>encrypted. >> >>>Eavesdropping of the signalling information does not reveal any >> >>information >> >>>which is not available to all receivers. >>> >>>In the case of two-way networks, forward link signalling can reveal >> >>traffic >> >>>parameters of the return links from specific users. This information=20 >>>can also reveal the status of specific terminals (logon/logoff, etc)=20 >>>and the timing and transmission parameters used by these terminals. >>> >>>Some of these threats could be reduced by using IP-based signalling=20 >>>[ref] and appropriate IP-level security mechanisms (e.g. IPsec). >>> >>>Replay/Jamming >>> >>>- SI information is required to associate PID values with Streams and=20 >>>therefore to demultiplex the data at the Receiver. >>>- In two-way systems, denial of forward signalling may also prevent=20 >>>link transmission in the return direction. >>>- Jamming/interception may also occur in the return link direction.=20 >>>In >> >>this >> >>>case, forged return link signalling could acquire return link=20 >>>bandwidth, >> >>or >> >>>modify the state of a terminal as perceived at the network control >> >>centre. >> >>>These threats can be exploited as a DoS attack. >>> >>>- SI information may be sent periodically. If the time of=20 >>>transmission is predictable, this could be "jammed" resulting in loss=20 >>>of signalling at >> >>the >> >>>receiver, which is a DoS vulnerability. It requires access to the=20 >>>stream >> >>- >> >>>either on the air interface (e.g. A different transmitter injecting a >> >>signal >> >>>that is Received (e.g. On an antenna side-lobe). >>>- Modification of SI can also be a DoS attack, this requires access=20 >>>to >> >>the >> >>>network components (multiplexors, etc) and/or connecting physical=20 >>>media - >> >>a >> >>>man-in-the-middle attack. >> >> >> >> >> >>Research Department/Advanced Telecom Systems -- R&D Engineer Tel :=20 >>+33 53435 6938 / Fax : +33 53435 5560 Porte : W219 / E-Mail :=20 >>stephane.combes@alcatelaleniaspace.com >> >>This message and any attachments (the "message") is intended solely=20 >>for the addressees and is confidential. If you receive this message in=20 >>error, please delete it and immediately notify the sender. Any use not=20 >>in accord with its purpose, any dissemination or disclosure, either=20 >>whole or partial, is prohibited except formal approval. The internet=20 >>can not guarantee the integrity of this message. ALCATEL ALENIA SPACE=20 >>(and its subsidiaries) shall (will) not therefore be liable for the mes= sage if modified. >> >>Ce message et toutes les pieces jointes (ci-apres le "message") sont=20 >>etablis a l'intention exclusive de ses destinataires et sont confidenti= els. >>Si vous recevez ce message par erreur, merci de le detruire et d'en=20 >>avertir immediatement l'expediteur. Toute utilisation de ce message=20 >>non conforme a sa destination, toute diffusion ou toute publication,=20 >>totale ou partielle, est interdite, sauf autorisation expresse. >>L'internet ne permettant pas d'assurer l'integrite de ce message,=20 >>ALCATEL ALENIA SPACE (et ses filiales) >>decline(nt) toute responsabilite au titre de ce message, dans=20 >>l'hypothese ou il aurait ete modifie. >=20 >=20 >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Thu Oct 27 16:48:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEgC-0005QN-Vg for ipdvb-archive@megatron.ietf.org; Thu, 27 Oct 2005 16:48:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16327 for ; Thu, 27 Oct 2005 16:48:40 -0400 (EDT) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVEtY-0000EF-69 for ipdvb-archive@ietf.org; Thu, 27 Oct 2005 17:02:47 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9RKh5kg014621 for ; Thu, 27 Oct 2005 21:43:05 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9RKh59c014620 for ipdvb-subscribed-users; Thu, 27 Oct 2005 21:43:05 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id j9RKgsDD014602 for ; Thu, 27 Oct 2005 21:42:55 +0100 (BST) Received: (qmail 22743 invoked from network); 27 Oct 2005 20:42:49 -0000 Received: from unknown (HELO gem-wbe13.mesa1.secureserver.net) (64.202.189.100) by smtpout03-03.mesa1.secureserver.net with SMTP; 27 Oct 2005 20:42:49 -0000 Received: (qmail 19162 invoked by uid 99); 27 Oct 2005 20:42:49 -0000 Date: Thu, 27 Oct 2005 13:42:48 -0700 From: Marie-Jose Montpetit Subject: RE: Réf. : RE: Thoughts on the impact of Signalling security on IP traffic To: ipdvb@erg.abdn.ac.uk cc: ipdvb@erg.abdn.ac.uk Message-ID: <20051027134248.ca5566c7162b3cfcb6c200079b757bd6.31e3d0f9c6.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id j9RKh5kg014621 X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: quoted-printable I smiled reading this, I hope it was the intention ;-) From my recent experience with vulnerabilities it seems it's not the big things that are the main issues but interesting software, firmware and IP level threats which cost nothing but can create havoc. Use a truck to take over a receivers is hard. To use a non secure port in the firmware to download some harmful code to and then interfere with eveyone is probably way easier. And BTW that could be the issue with that satellite... /mjm > -------- Original Message -------- > Subject: RE: R=E9f. : RE: Thoughts on the impact of Signalling security > on IP traffic > From: "Allison, Art" > Date: Thu, October 27, 2005 2:45 pm > To: > > Right... > It is possible that someone could suitably equip a truck, drive it into= a neighborhood and overpower the RF that arrives at the nearby homes. I= nterception and retransmission for replacement requires very low processi= ng delay such that the real signal appears as reflection (pre-ghost) tha= t the receiver can cancel/ignore. (If those technical constraints are not= met, nothing is received - that is it effectively is simply a RF jammer = - no standard can stop that. While I don't have quotes, certainly it woul= d cost several 10s of thousands US dollars for the equipment; and for the= homes in the next torus where it did not swamp the receivers it would se= riously interfere with reception (jammer again). While determination of = interference sources can be hard, the large panel truck with antennas on = might help in this case. If the attacker were an apartment dweller, he p= erhaps could impact neighbors in a similar manner and be more difficult t= o detect. But it is not clear what benef! > it could be obtained from this localized denial of service attack that= many nearby would detect as lost of regular TV programming. > > After all the potential attacker can directly obtain all of the data st= ream and process it without interfering with anyone. > I fail to see that discussion of a terrestrial spoofing attack is worth= y of further time or IP packets. But have it... > > ______________ > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N St. NW > Washington DC 20036 > 202 429 5418 > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On= Behalf Of Gorry Fairhurst > Sent: Thursday, October 27, 2005 12:45 PM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: R=E9f. : RE: Thoughts on the impact of Signalling security= on IP traffic > > When I started the thread, my comment was related to: > > draft-cruickshank-ipdvb-sec-req-00.txt > > Which includes a draft of an analysis of potential threats to the IP se= rvice when used over this type of network. To me this still seems a valid= question... > > MPEG-2 signalling is a part of the system - and control-plane attacks a= re not unheard of in IP networks. (In many other networks the L2 control = plane is also visibile). > > One conclusion may be that despite a lack of security mechanisms, such = attacks are hard in most practical networks, because the physical infrast= ructure is itself secured (i.e. they require access to the multiplexor,mo= dulator, etc), in contrast to WiFi networks were this is easy - to me, th= is seems to be the case put forward for DOCSIS. It was also put forward a= s a case for satellite TV broadcast networks. Although it seems the next = generation of satellite on-board multiplexors could require some thought? > > I was primarilly thinking about terrestrial receivers - where a follow-= on attack could be possible by receiving the bit-stream and then regenera= ting a different bitstream that was transmitted locally towards a receive= r to manipulate the IP packet flow (e.g. inject data). > > Gorry > > > Allison, Art wrote: > > > Just a toe back into the security discussion - even though US terrest= rial broadcasters (my interest group) won't be using ULE anyway. I posted= some thoughts a while back- they still seem consistent with all data ava= ilable to me. The transport of ULE packets in MPEG-2 TS is the responsibi= lity of someone else. If you don't trust t= he transport security provisions, either don't use it or convince the pro= vider to improve them. Or add a layer that reduces your payload and incr= eases your complexity. > > > > Attempting to define how a transport shall be constructed when there = are other standards that already do that just adds to the list of volunta= ry standards one must decide among when selecting what to support. > > > > Art Allison > > Director, Advanced Engineering > > Science & Technology > > National Association of Broadcasters > > 1771 N St. NW > > Washington DC 20036 > > 202 429 5418 > > > > > > -----Original Message----- > > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] > > On Behalf Of Marie-Jose Montpetit > > Sent: Wednesday, October 26, 2005 8:00 AM > > To: Stephane.Combes@alcatelaleniaspace.com > > Cc: ipdvb@erg.abdn.ac.uk > > Subject: RE: R=E9f. : RE: Thoughts on the impact of Signalling securi= ty > > on IP traffic > > > > Should Amerhis drive all the requirements for MPEG/ULE security? We s= hould make sure that IP over DVB does not become another IP over satellit= e - that too many people think it is BTW. > > > > And yes: we should do ULE and leave DVB (and other groups) to address= the big picture. > > > > /mjm > > > > > >>-------- Original Message -------- > >>Subject: R=E9f. : RE: Thoughts on the impact of Signalling security = on > >>IP traffic > >>From: Stephane.Combes@alcatelaleniaspace.com > >>Date: Wed, October 26, 2005 5:57 am > >>To: Marie-Jose Montpetit > >>Cc: ipdvb@erg.abdn.ac.uk > >> > >>Hi Marie-Jos=E9, > >> > >>I admit that a conventional hub-and-spoke DVB network will not have > >>more stringent requirements than a DOCSIS network. But this is not th= e > >>case of mesh DVB-RCS networks (eg Amerhis system). Here the MPEG-2 mu= x > >>is on-board the satellite and the signalling is generated by a Networ= k > >>Control Center > >>(NCC) which is just like any other sender/receiver. Therefore this NC= C > >>is probably easier to impersonate than a cable headend. > >> > >>Regarding preventing the return channel to be monitored, this is a > >>very important issue for the most "sensible" networks. And IPSec > >>cannot help here... > >> > >>As a general comment on the current discussion thread, my feeling is: > >>- Securing DVB and MPEG-2 signalling seems a bit out-of-scope to me. > >>The current I-D mostly concentrate on securing ULE (and ULE > >>signalling). It is true that "the integrity of control and management > >>message in MPEG-2 networks" appears as an optional requirement in the > >>I-D. But perhaps this is too vague and we should first concentrate on > >>ULE and not go down to MPEG. > >>- We can discuss DVB and MPEG signalling security but this issue > >>should probably be owned by the DVB Forum or by groups which have > >>developed some specific additional signalling protocols (e.g. SatLabs > >>for RCS protocols) > >> > >>cheers, > >> > >>St=E9phane > >> > >> > >> > >> > >> Marie-Jose > >> Montpetit Pour : ipdvb@erg.abd= n.ac.uk > >> > >> it.com> "H.Cruickshank" > >> Stephane Combes/ALCATE= L-SPACE@ALCATEL-SPACE > >> 25/10/2005 21:53 Laurence Duquerroy/ALC= ATEL-SPACE@ALCATEL-SPACE > >> Veuillez "S.Iyengar" > >> r=E9pondre =E0 Objet : RE: Thoug= hts on the impact of Signalling security on IP traffic > >> Marie-Jose > >> Montpetit > >> > >> > >> > >> > >> > >>I ping'ed one of our security people here at Motorola and please find > >>below what he had as a comment: > >> > >>"In the case of DOCSIS, we had the debate a few years ago on whether > >>or not it is easy to impersonate the headend and modify the contents > >>of a DOCSIS downstream, which is just an MPEG-2 multiplex. It was > >>decided by the working group that such an attack would be too costly > >>and impractical - for HFC cable networks at least. The same probably > >>applies for satellite networks. > >> > >>This email suggests that the return channel could be monitored to > >>determine if an STB is logged in or not. As the email suggests, IP > >>traffic can be protected with IPsec - but generally any IP stack > >>including the one over DVB can be modified to include IPsec." > >> > >>I think the group should look a bit more at what was done on the cabl= e > >>side? > >> > >>/mjm > >> > >> > >> > >> > >>>-------- Original Message -------- > >>>Subject: Re: Thoughts on the impact of Signalling security on IP > >>>traffic > >>>From: Gorry Fairhurst > >>>Date: Tue, October 25, 2005 11:41 am > >>>To: "S.Iyengar" > >>>Cc: ipdvb , "H.Cruickshank" > >>>, "stephane.combes" > >>>, "Laurence.Duquerroy" > >>> > >>> > >>>Here are some thoughts... Comments welcome! > >>> > >>>Gorry > >>> > >>>--- > >>> > >>> > >>>Some of the L2 signalling security properties include: > >>> > >>>- No authentication of the signalling source. The layer-2 signalling > >>>entity is often not be the encapsulation gateway itself. > >>>- No encryption (but sometimes this is needed to bootstrap terminals= ). > >>>- Integrity check is a CRC-32. This is relatively weak compared to a > >>>cryptographic hash. (Should the forging of table contents needs to b= e > >>>considered?) > >>>- (re)multiplexors do modify (or insert new SI tables), but there is > >>>no security association with these devices within an MPEG-2 > >>>Transmission network. > >>>- Modification/Denial of the SI information could result in > >>>association > >> > >>of a > >> > >>>different stream with the service, or an inability to identify the T= S > >>>Logical Channel (PID) that is used for a service. > >>> > >>>Threats from interception of Forward link signalling. > >>> > >>>In current MPEG-TS networks, the forward link signalling is not > >> > >>encrypted. > >> > >>>Eavesdropping of the signalling information does not reveal any > >> > >>information > >> > >>>which is not available to all receivers. > >>> > >>>In the case of two-way networks, forward link signalling can reveal > >> > >>traffic > >> > >>>parameters of the return links from specific users. This information > >>>can also reveal the status of specific terminals (logon/logoff, etc) > >>>and the timing and transmission parameters used by these terminals. > >>> > >>>Some of these threats could be reduced by using IP-based signalling > >>>[ref] and appropriate IP-level security mechanisms (e.g. IPsec). > >>> > >>>Replay/Jamming > >>> > >>>- SI information is required to associate PID values with Streams an= d > >>>therefore to demultiplex the data at the Receiver. > >>>- In two-way systems, denial of forward signalling may also prevent > >>>link transmission in the return direction. > >>>- Jamming/interception may also occur in the return link direction. > >>>In > >> > >>this > >> > >>>case, forged return link signalling could acquire return link > >>>bandwidth, > >> > >>or > >> > >>>modify the state of a terminal as perceived at the network control > >> > >>centre. > >> > >>>These threats can be exploited as a DoS attack. > >>> > >>>- SI information may be sent periodically. If the time of > >>>transmission is predictable, this could be "jammed" resulting in los= s > >>>of signalling at > >> > >>the > >> > >>>receiver, which is a DoS vulnerability. It requires access to the > >>>stream > >> > >>- > >> > >>>either on the air interface (e.g. A different transmitter injecting = a > >> > >>signal > >> > >>>that is Received (e.g. On an antenna side-lobe). > >>>- Modification of SI can also be a DoS attack, this requires access > >>>to > >> > >>the > >> > >>>network components (multiplexors, etc) and/or connecting physical > >>>media - > >> > >>a > >> > >>>man-in-the-middle attack. > >> > >> > >> > >> > >> > >>Research Department/Advanced Telecom Systems -- R&D Engineer Tel : > >>+33 53435 6938 / Fax : +33 53435 5560 Porte : W219 / E-Mail : > >>stephane.combes@alcatelaleniaspace.com > >> > >>This message and any attachments (the "message") is intended solely > >>for the addressees and is confidential. If you receive this message i= n > >>error, please delete it and immediately notify the sender. Any use no= t > >>in accord with its purpose, any dissemination or disclosure, either > >>whole or partial, is prohibited except formal approval. The internet > >>can not guarantee the integrity of this message. ALCATEL ALENIA SPACE > >>(and its subsidiaries) shall (will) not therefore be liable for the m= essage if modified. > >> > >>Ce message et toutes les pieces jointes (ci-apres le "message") sont > >>etablis a l'intention exclusive de ses destinataires et sont confiden= tiels. > >>Si vous recevez ce message par erreur, merci de le detruire et d'en > >>avertir immediatement l'expediteur. Toute utilisation de ce message > >>non conforme a sa destination, toute diffusion ou toute publication, > >>totale ou partielle, est interdite, sauf autorisation expresse. > >>L'internet ne permettant pas d'assurer l'integrite de ce message, > >>ALCATEL ALENIA SPACE (et ses filiales) > >>decline(nt) toute responsabilite au titre de ce message, dans > >>l'hypothese ou il aurait ete modifie. > > > > > > > > From owner-ipdvb@erg.abdn.ac.uk Mon Oct 31 16:43:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhRM-0002Dq-N0 for ipdvb-archive@megatron.ietf.org; Mon, 31 Oct 2005 16:43:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12564 for ; Mon, 31 Oct 2005 16:43:20 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWhfc-0000YJ-FA for ipdvb-archive@ietf.org; Mon, 31 Oct 2005 16:58:24 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9VLSdNE026425 for ; Mon, 31 Oct 2005 21:28:39 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9VLScjI026424 for ipdvb-subscribed-users; Mon, 31 Oct 2005 21:28:39 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9VLSYfv026408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 31 Oct 2005 21:28:34 GMT Message-ID: <43668C81.2020502@erg.abdn.ac.uk> Date: Mon, 31 Oct 2005 21:28:33 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Thoughts on CRC usage References: <000d01c5da14$494dbe40$877a36c1@DrCerebro> In-Reply-To: <000d01c5da14$494dbe40$877a36c1@DrCerebro> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Let me pick-up this thread again - Do you have any published (or technical data) to support your observations about the S.2 link error properties? Can I also make a plea for anyone else with understanding of this particular physical layer to also come forward and comment on this topic... Gorry Juan Cantillo wrote: > (This mail might appear twice in the list, since I sent it from another > mail address... it looks like majordomo filters the senders it doesn't > know, right?) > > Dear Gorry and Fausto, > > Gorry said: >> >>BER performance is often hard to quantify. Does that mean that WHATEVER >> >>distorted waveform is presented at the input to the receiver, the > output of >> >>the link FEC processing will result in either a BBframe being marked as >> >>invalid, or one that has up to 10-7 errors in the forwarded frames?" >> >>Even this is not exact, a single BBframe could (with small probability) >> >>contain many errors - and somehow this has to be detected. >> >>IMHO, this means we need to consider the worst-case lvele of residual >> >>(undetected) errors that can be presented in any single BB frame. > > 1e-7 is the Packet Error Rate (PER). This is the probability that the > FEC used to protect the BBFrame cannot *correct* all the erroneous bits > in a BBFRAME. Say that 1 packet out of 10 000 000 cannot be corrected. > One important strength of the BCH used is that he can also *detect* very > accurately that this packet was indeed erroneous after decoding; > theoretical estimates show that he will prove wrong only 1e-8 of the time. > So if you ask your BCH to do error *correction + detection*, at the > encapsulation layer, only 1e-15 of your packets will be wrong (this is > the "small probability" Gorry refers to)!!! At 15 Mbits/s, for frames of > length 384 Byte, this means one uncorrected packet every 6000 years more > or less :-) That means that if you If you intend to use a CRC to correct > link errors, it will only be activated once every 6000 years. > > To verify these estimations, we have been running some simulations under > various link conditions here in Toulouse since July, full time, and as > expected, we still have not detected a single erroneous BBFRAME on our > platform after FEC correction + detection :-) > >> >>The question of retransmissions is irrelevent. The issue here is data >> >>integrity - the probability that a corrupted block is (mis)delivered > to and >> >>accepted by an application. > > I agree with Gorry. Protecting data is the most important issue, and it > should not depend on padding presence/absence. IMHO, the key point is > analysing where the threats to data integrity come from: if we suppose > that an error event is due *only* to the AWGN link, Maths and > simulations clearly prove that CRCs could be removed. If on the other > hand you suppose that there might be errors *other* than link ones (say, > bit offsets due to bugs in the sofware/hardware), then making a CRC > check can be the only way to spot them. > > Unfortunately, no figures nor precise measurements/litterature are > available on that at our knowledge! If anyone has data on this > particular issue we would gratefully appreciate it. If those became > available you could then scale properly the length of the CRC you need, > if that threat proves worth it. > > Any thoughts on this? > > Juan > > > ----------------------------------------------------------------------- > Juan CANTILLO - SatComs PhD. Researcher > Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88 > ENST/TeSA/ENSICA/AAS, Toulouse, FR From owner-ipdvb@erg.abdn.ac.uk Mon Oct 31 17:55:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWiYk-0001On-Je for ipdvb-archive@megatron.ietf.org; Mon, 31 Oct 2005 17:55:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17434 for ; Mon, 31 Oct 2005 17:55:02 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWin1-0000Z2-8Y for ipdvb-archive@ietf.org; Mon, 31 Oct 2005 18:10:07 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9VMihCs001971 for ; Mon, 31 Oct 2005 22:44:43 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9VMihwI001970 for ipdvb-subscribed-users; Mon, 31 Oct 2005 22:44:43 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.23] (maxp28.dialup.abdn.ac.uk [139.133.201.187]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9VMiNv8001906 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 31 Oct 2005 22:44:35 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 31 Oct 2005 22:42:25 +0100 Subject: Re: RE: R=?ISO-8859-1?B?6Q==?=f. : RE: Thoughts on the impact of Signalling security on IP traffic From: Gorry Fairhurst To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit If the cost is indeed 10's of thousands of dollars for an MPEG-Mux and terrestrial Modulator/Amp, - then this clearly makes this an expensive attack for an individual to mount. Maybe though if the signal disappears, I should still look out for a truck outside? :-). In an IP network, my concerns would likely be orientated towards the possible injection of data that modifies the flow of IP packets that are forwarded to a Receiver network, particularly if modifications may go undetected. It may be that there is an implicit reliance on the validity of the MPEG-2 signalling data ... (and hence the identity of the equipment multiplexing the data)..., and that for most applications, the physical security of the equipment means this is valid assumption? Gorry --- Right... It is possible that someone could suitably equip a truck, drive it into a neighborhood and overpower the RF that arrives at the nearby homes. Interception and retransmission for replacement requires very low processing delay such that the real signal appears as reflection (pre-ghost) that the receiver can cancel/ignore. (If those technical constraints are not met, nothing is received - that is it effectively is simply a RF jammer - no standard can stop that. While I don't have quotes, certainly it would cost several 10s of thousands US dollars for the equipment; and for the homes in the next torus where it did not swamp the receivers it would seriously interfere with reception (jammer again). While determination of interference sources can be hard, the large panel truck with antennas on might help in this case. If the attacker were an apartment dweller, he perhaps could impact neighbors in a similar manner and be more difficult to detect. But it is not clear what benefit could be obtained from this localized denial of service attack that many nearby would detect as lost of regular TV programming. After all the potential attacker can directly obtain all of the data stream and process it without interfering with anyone. I fail to see that discussion of a terrestrial spoofing attack is worthy of further time or IP packets. But have it... ______________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N St. NW Washington DC 20036 202 429 5418 From owner-ipdvb@erg.abdn.ac.uk Mon Oct 31 17:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWiYl-0001Oz-J7 for ipdvb-archive@megatron.ietf.org; Mon, 31 Oct 2005 17:55:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17438 for ; Mon, 31 Oct 2005 17:55:03 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWin1-0000Z1-7r for ipdvb-archive@ietf.org; Mon, 31 Oct 2005 18:10:08 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9VMibPB001935 for ; Mon, 31 Oct 2005 22:44:37 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id j9VMib1j001934 for ipdvb-subscribed-users; Mon, 31 Oct 2005 22:44:37 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.23] (maxp28.dialup.abdn.ac.uk [139.133.201.187]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id j9VMiNv5001906 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 31 Oct 2005 22:44:28 GMT User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 30 Oct 2005 15:06:30 +0100 Subject: Security Requirements Thread From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit I'd like to encourage the authors to think through the recent Security Requirements discussion thread. The focus needs to be on the use of the technology to receive the Internet service. We have a face-to-face ipdvb WG meeting (for those who can make it to Vancouver) next week - and one of things on the Agenda that we need to talk about are the set of potential threats, the vulnerabilities to the IP service related to specific scenarios, and whether the group is yet ready to define exact requirements for securing the IP service (specifically for ULE). Authors, can you try to summarise things to the list before the meeting? Best wishes, Gorry Fairhurst