From owner-ipdvb@erg.abdn.ac.uk Wed Aug 02 12:29:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Jb8-0003p0-Qn for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 12:29:30 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Jb7-0003NF-DE for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 12:29:30 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k72GEG2o015554 for ; Wed, 2 Aug 2006 17:14:16 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k72GEG0v015553 for ipdvb-subscribed-users; Wed, 2 Aug 2006 17:14:16 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k72GDx2B015533; Wed, 2 Aug 2006 17:13:59 +0100 (BST) Message-ID: <44D0CF48.7070102@erg.abdn.ac.uk> Date: Wed, 02 Aug 2006 17:14:00 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: rfc-editor@rfc-editor.org Subject: Re: RFC 4326 errata (ULE) References: <44B41E1F.1060003@cs.ucla.edu> In-Reply-To: <44B41E1F.1060003@cs.ucla.edu> Content-Type: text/plain; charset=windows-1252; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k72GEG2o015554 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hello RFC Editor! I have some errata to report for RFC 4326. See below. Thanks very much for your work! Gorry Fairhurst ------------------------------------------------------------------------ Several errors have been reported to the authors in RFC 4326. Page 10: Section 4.1 - Length field description refers to a 16-bit value. Source: Bernhard Collini-Nocker, 15th February 2006 OLD: "The most significant bit of the Length field carries the value of the=20 Destination Address Absent Field, the D-bit" NEW: "The most significant bit of the first byte of the SNDU base header=20 carries the value of the Destination Address Absent Field, the D-bit" Example A.2 Page 26: Section 7.2. Processing of a Received SNDU - Usage of last byte in a TS-Packet. Source: Bernhard Collini-Nocker & Gorry Fairhurst, 15th February 2006 OLD: =93When in the Reassembly State, the Receiver reads a 2-byte SNDU Length=20 field from the TS Packet payload. If the value is less than or equal to=20 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and=94 NEW: =93When in the Reassembly State, the Receiver reads the first two bytes=20 from the TS Packet payload. This value forms the first 2 bytes of the=20 SNDU base header, which is a combination of the D-bit and the=20 SNDU-Length. If the combined value is less than or equal to 4, or equal=20 to 0xFFFF (i.e. D=3D1 and SNDU Length =3D 32768), the Receiver MUST disca= rd=20 the Current SNDU and=94 Page 36: Example A.2 - Misrepresentation of hex byte in example, Change /0x65/0xB5/ Source: Karsten Siebert, 26th February 2006 OLD: | HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 | NEW: | HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0xB5 | From owner-ipdvb@erg.abdn.ac.uk Wed Aug 02 12:57:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8K2g-0001YD-S4 for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 12:57:58 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8K2g-000055-FS for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 12:57:58 -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 k72GlHDs018203 for ; Wed, 2 Aug 2006 17:47:17 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k72GlHOU018202 for ipdvb-subscribed-users; Wed, 2 Aug 2006 17:47:17 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k72GlBfB018187 for ; Wed, 2 Aug 2006 17:47:11 +0100 (BST) Message-ID: <44D0D70F.8030607@erg.abdn.ac.uk> Date: Wed, 02 Aug 2006 17:47:11 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: IETF66: A draft copies of the minutes are now available for comment Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The "minutes" for the meeting in Montreal are at the proceedings web site. This may be reached at the URL below. Thanks to Martin for taking notes (which have been cross-checked with the audio archive). Please send any corrections to this list. Best wishes, Gorry Fairhurst (ipdvb WG Chair) http://www3.ietf.org/proceedings/06jul/minutes/ipdvb.txt From owner-ipdvb@erg.abdn.ac.uk Wed Aug 02 14:18:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8LI9-0007PV-N7 for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 14:18:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8KCH-0001hp-K2 for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 13:07:53 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8K7r-0005Vm-5G for ipdvb-archive@ietf.org; Wed, 02 Aug 2006 13:03:21 -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 k72GpQAH018561 for ; Wed, 2 Aug 2006 17:51:26 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k72GpQlJ018560 for ipdvb-subscribed-users; Wed, 2 Aug 2006 17:51:26 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.154] (dhcp-207-154.erg.abdn.ac.uk [139.133.207.154]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k72GpJ7O018543 for ; Wed, 2 Aug 2006 17:51:19 +0100 (BST) Message-ID: <44D0D807.3080506@erg.abdn.ac.uk> Date: Wed, 02 Aug 2006 17:51:19 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: End of WGLC for draft-ietf-ipdvb-ar-04.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.5 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f This note marks the end of the WG Last-Call for comments for the WG document named below: draft-ietf-ipdvb-ar-04.txt Members of the IETF ipdvb WG may continue comment on the above draft, and note any corrections. A new version of the draft is now being prepared to correct the issues raised during WGLC. The document will then be sent to the IESG with a request for publication. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Thu Aug 03 03:46:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8XuI-0000zb-86 for ipdvb-archive@ietf.org; Thu, 03 Aug 2006 03:46:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8VjA-0003bj-Mg for ipdvb-archive@ietf.org; Thu, 03 Aug 2006 01:26:36 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8VWx-00036s-GN for ipdvb-archive@ietf.org; Thu, 03 Aug 2006 01:14:01 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7350wXl015665 for ; Thu, 3 Aug 2006 06:00:58 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7350w9V015664 for ipdvb-subscribed-users; Thu, 3 Aug 2006 06:00: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 hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7350kQi015611 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 3 Aug 2006 06:00:47 +0100 (BST) Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by hnse2.hns.com (Switch-3.1.9/Switch-3.1.9) with ESMTP id k7350axq020562 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 3 Aug 2006 01:00:37 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.9/Switch-3.1.9) with ESMTP id k7350Jaa000599 for ; Thu, 3 Aug 2006 01:00:35 -0400 (EDT) Subject: Roderick Ragland/HNS is out of the office. From: Roderick Ragland To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Thu, 3 Aug 2006 01:00:20 -0400 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 6.5.1|January 21, 2004) at 08/03/2006 00:58:34 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I will be out of the office starting 08/02/2006 and will not return until 08/04/2006. I will respond to your message when I return. From borderland@mc-blossom.com Mon Aug 07 01:16:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9xTn-0006Jy-Rj for ipdvb-archive@ietf.org; Mon, 07 Aug 2006 01:16:43 -0400 Received: from zaq3d2eb606.zaq.ne.jp ([61.46.182.6] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G9xTl-0000p4-6X for ipdvb-archive@ietf.org; Mon, 07 Aug 2006 01:16:43 -0400 Message-ID: <000001c6b9df$c0323800$0100007f@localhost> From: "Valina Lopez" To: Subject: August Payment Summary, Invoice #64046 Date: Mon, 07 Aug 2006 14:16:49 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C6B9DF.C0323800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 2.9 (++) X-Scan-Signature: 8949cc4fd406a34204d26327803246d1 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6B9DF.C0323800 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000E_01C6B9DF.C0323800" ------=_NextPart_001_000E_01C6B9DF.C0323800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forward original invoice with attached invoice transmittal sheet to the contracting officer ------=_NextPart_000_0001_01C6B9DF.C0323800 Content-Type: application/msword; name="invoice.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="invoice.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANwAAAAAA AAAAEAAANQAAAAEAAAD+////AAAAADgAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcWAJBAAA+BK/AAAAAAAAEAAAAAAABgAA 0goAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAAAAAJBBYALhwAABM6AQATOgEA0gIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAJIEAAAAAAAAkgQAAJIEAAAAAAAAkgQAAAAAAACSBAAA AAAAAJIEAAAAAAAAkgQAABQAAAAAAAAAAAAAAMwEAAAkAgAA2AsAAAAAAADYCwAAAAAAANgL AAAAAAAA2AsAABwAAAD0CwAAJAAAAPAGAAAAAAAACREAAFoBAAAkDAAAKAAAAEwMAAAAAAAA TAwAAAAAAABMDAAAAAAAAEwMAAAAAAAAJw0AAAAAAAAnDQAAAAAAACcNAAAAAAAAiBAAAAIA AACKEAAAAAAAAIoQAAAAAAAAihAAAAAAAACKEAAAAAAAAIoQAAAAAAAAihAAACQAAABjEgAA aAIAAMsUAACGAAAArhAAABUAAAAAAAAAAAAAAAAAAAAAAAAAkgQAAAAAAAA6DwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAnDQAAAAAAACcNAAAAAAAAOg8AAAAAAAA6DwAAAAAAAK4QAAAAAAAA AAAAAAAAAACSBAAAAAAAAJIEAAAAAAAATAwAAAAAAAAAAAAAAAAAAEwMAADbAAAAwxAAABYA AAC8DwAAAAAAALwPAAAAAAAAvA8AAAAAAAA6DwAAFgAAAJIEAAAAAAAATAwAAAAAAACSBAAA AAAAAEwMAAAAAAAAiBAAAAAAAAAAAAAAAAAAALwPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOg8AAAAAAACIEAAAAAAAAAAAAAAAAAAA vA8AAAAAAAAAAAAAAAAAALwPAAAAAAAAkgQAAAAAAACSBAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvA8AAAAAAABMDAAA AAAAABgMAAAMAAAAIJOI8uu4xgEAAAAAAAAAANgLAAAAAAAAUA8AAAoAAAC8DwAAAAAAAAAA AAAAAAAALBAAAFwAAADZEAAAMAAAAAkRAAAAAAAAvA8AAAAAAABRFQAAAAAAAFoPAABYAAAA URUAAAAAAAC8DwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFEVAAAAAAAAAAAAAAAAAACSBAAA AAAAALwPAABwAAAAJw0AAJIAAAC5DQAAaAAAALwPAAAAAAAAIQ4AAFQAAAB1DgAAxQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJw0AAAAAAAAnDQAAAAAAACcNAAAAAAAA rhAAAAAAAACuEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsg8AAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcNAAAAAAAAJw0AAAAAAAAnDQAA AAAAAAkRAAAAAAAAOg8AAAAAAAA6DwAAAAAAADoPAAAAAAAAOg8AAAAAAAAAAAAAAAAAAPAG AAAAAAAA8AYAAAAAAADwBgAAZAQAAFQLAACEAAAA8AYAAAAAAADwBgAAAAAAAPAGAAAAAAAA VAsAAAAAAACmBAAAFAAAALoEAAAOAAAAyAQAAAQAAACSBAAAAAAAAJIEAAAAAAAAkgQAAAAA AACSBAAAAAAAAJIEAAAAAAAAkgQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJhY2syU2Nob29sIFNvZnR3YXJlIEJsb3dvdXQgU2Fs ZSEHBw1TdG9wIG92ZXJwYXlpbmcgZm9yIHNvZnR3YXJlLg1CdXkgT0VNIFNvZnR3YXJlIHRv ZGF5LCBEb3dubG9hZCBJTlNUQU5UTFkgJg0TIEhZUEVSTElOSyAiaHR0cDovL3RlbW5pZXBy b2dpLmNvbSIgARRTYXZlIE92ZXIgODUlIRUNTWljcm9zb2Z0IE9mZmljZSAyMDAzIFByb2Zl c3Npb25hbA13L0NvbnRhY3QgTWFuYWdlcg0NV2luZG93cyBYUCBQcm9mZXNzaW9uYWwNSW5j bHVkZXMgU2VydmljZSBQYWNrIDENDUFkb2JlIFBob3Rvc2hvcCBDUzIgdiA5LjANIzEgUmF0 ZWQgUGhvdG8gRWRpdGluZyBzb2Z0d2FyZQ0NQWRvYmUgQWNyb2JhdCBQcm9mZXNzaW9uYWwg diA3LjANRXNzZW50aWFsIGZvciBXZWIgRG9jdW1lbnRzDQ1SZXRhaWwgUHJpY2UgQCBTdGFw bGVzOiAkNTQ5Ljk1DUV4Y2x1c2l2ZSBTYWxlIFByaWNlOiAkNjkuOTUNDVJldGFpbCBQcmlj ZSBAIFN0YXBsZXM6ICQyNDkuOTUNRXhjbHVzaXZlIFNhbGUgUHJpY2U6ICQ0OS45NQ0NUmV0 YWlsIFByaWNlIEAgU3RhcGxlczogJDU5OS45NQ1FeGNsdXNpdmUgU2FsZSBQcmljZTogJDY5 Ljk1DQ1SZXRhaWwgUHJpY2UgQCBTdGFwbGVzOiAkNDQ5Ljk1DUV4Y2x1c2l2ZSBTYWxlIFBy aWNlOiAkNjkuOTUNDQcHEyBIWVBFUkxJTksgImh0dHA6Ly90ZW1uaWVwcm9naS5jb20iIAEU VmlzaXQgb3VyIFdlYnNpdGUgYW5kIGdldCB5b3VycyB0b2RheSEVBwcNAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAIggAACMIAAAkCAAAJQgAAHAIAABxCAAAlQgAAJYI AACXCAAApQgAAKYIAACnCAAAhgkAAPHi3tHBppByplumRTIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAJBVogBWBABZogBWBADUIgUIqAU9KAgBRSgIAXkoCAHBoMzMzAAArFWjB W24AFmjeNz8ANQiBPioBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAACwVaMFbbgAWaN43PwAw ShEANQiBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAAAA6AgiBA2p1AAAABggBFWjBW24AFmjB W24ANQiBPioBQioBQ0o8AE9KBABRSgQAVQgBYUo8AHBoAAAAAAArFWjBW24AFmiAFYEANQiB PioBQioBQ0o8AE9KBABRSgQAYUo8AHBoAAAAADQDagAAAAAVaMFbbgAWaIAVgQA1CIE+KgFC KgFDSjwAT0oEAFFKBABVCAFhSjwAcGgAAAAAAB8VaMFR+gAWaN43PwA1CIFDSjAAT0oEAFFK BABhSjAAGRZoHhvgADUIgUNKEABPSgQAUUoEAGFKEAAGFmjeNz8AABwVaH0TcgAWaFk2AABD SkgAT0oDAFFKAwBhSkgAABwVaH0TcgAWaFJ5OgBDSkgAT0oDAFFKAwBhSkgADQAGAAAjCAAA JAgAACUIAABDCAAAcAgAAKcIAADKCAAA3AgAAN0IAAD1CAAADQkAAPMAAAAAAAAAAAAAAAB1 AAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAA AAAAAAAAAAAAAGAAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAGAAAAAA AAAAAAAAAABgAAAAAAAAAAAAAAAAAAkAABYkAUlmAgAAAGdkwVtuAAwAAAMkARYkAUlmAQAA AGEkAWdk3jc/AAB9AABrZAAAAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNYaAAGU/ywiAAaYIgAAAAAAAAAAAAAAAAAAAAAJ1gIgAAp0AADgARLWCgAA AP8AAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABU2ARf2AwAAGPYDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/NNYG AAEFAwAANNYGAAEKA2wAYNYKAAAA/wAAAAAAAGH2AwAAcNYKAAAA/wAAAAAAAAwAAAMkARYk AUlmAQAAAGEkAWdkfRNyAAALAAYAANIKAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQENCQAADgkAACgJ AABICQAASQkAAGoJAACGCQAAhwkAAKcJAADECQAAxQkAAOUJAAACCgAAAwoAACMKAABACgAA QQoAAGEKAAB+CgAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA AAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAPYAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAWJAFJZgIAAABnZMFbbgBLJAEJAAAW JAFJZgIAAABnZMFbbgAAEoYJAACHCQAApwkAAMQJAADFCQAA5QkAAAIKAAADCgAAIwoAAEAK AABBCgAAYQoAAH0KAAB+CgAAfwoAAIAKAACBCgAAggoAAKYKAADx4My84My84My84Mypno5/ YkoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAvFWiAFYEAFmiAFYEANQiBPioBQioGQ0ooAE9KAgBRSgIAXkoCAGFKKABwaP8AAAA4A2oA AAAAFWiAFYEAFmiAFYEANQiBPioBQioGQ0ooAE9KAgBRSgIAVQgBXkoCAGFKKABwaP8AAAAA HBVo3jc/ABZo3jc/AENKMABPSgQAUUoEAGFKMAAAHxVo0V48ABZogBWBAD4qAUNKPABPSgQA UUoEAGFKPAAVFmiAFYEANQiBT0oCAFFKAgBeSgIAJBVogBWBABZogBWBADUIgUIqBk9KAgBR SgIAXkoCAHBo/wAAAAAeFWiAFYEAFmiAFYEANQiBNgiBT0oCAFFKAgBeSgIAACcVaIAVgQAW aIAVgQA1CIE2CIFCKgZPSgIAUUoCAF5KAgBwaP8AAAAhFWjBW24AFmiAFYEAQioBT0oCAFFK AgBeSgIAcGgzMzMAGxVogBWBABZogBWBADUIgU9KAgBRSgIAXkoCAAASfgoAAH8KAACACgAA gQoAANAKAACfAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAAAFMAAAAAAAAAAAAAAABHAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAMkARYkAUlmAQAAAGEkAWdkgBWBAABCAABrZMEB AAAWJAEXJAFJZgEAAAAClmwAB5RVCgjWGgABlP8sIgAGmCIAAAAAAAAAAAAAAAAAAAAACnQA AOABFPYBAAAVNgEX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgAB BQMAADTWBgABCgNsAGH2AwAACQAAFiQBSWYBAAAAZ2SAFYEAYAAAa2QWAQAAFiQBSWYCAAAA SyQBTCQBApZsAAeUvQsI1jAAAgAA/BKxIQAG/BIAAAAAAAAAAAAAAAAAAAAAAAa1DgAAAAAA AAAAAAAAAAAAAAAKdAAA4AENNmAPlGIBEJS0ABT2A7EhFTYBF/YDAAAY9gMAABrWCAAAAP8A AAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/HpS0ADTWBgABBQMAADTWBgAB CgNsAGH2AwAAZTQBAASmCgAApwoAAKgKAADOCgAAzwoAANAKAADRCgAA0goAAODDqsOXk48A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZoCCCoAAAGFmhZNgAAACUVaIAVgQAW aIAVgQBCKgZDSigAT0oEAFFKBABhSigAcGj/AAAAMBVogBWBABZogBWBADBKEQA1CIFCKgZD SigAT0oCAFFKAgBeSgIAYUooAHBo/wAAAAA4A2oAAAAAFWiAFYEAFmiAFYEANQiBPioBQioG Q0ooAE9KAgBRSgIAVQgBXkoCAGFKKABwaP8AAAAAPgIIgQNqQQIAAAYIARVogBWBABZowVtu ADUIgT4qAUIqBkNKKABPSgIAUUoCAFUIAV5KAgBhSigAcGj/AAAAB9AKAADRCgAA0goAAL4A AAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2TBW24AAEAAAGtk4gIAABYk ARckAUlmAQAAAAKWbAAI1hoAAZT/LCIABpgiAAAAAAAAAAAAAAAAAAAAAAp0AADgART2AQAA FTYBF/YDAAAY9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP801gYAAQUDAAA01gYA AQoDbABh9gMAAAACLAAxkGgBH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAABew0AIYsNAC DJDQAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzABYkARckAUlmAQAAAAGW AAAhdgABaAE11gUAAQOYIiN2AAGYIjpWDwAClmwACdYCIAAKdAAA4AES1goAAAD/AAAAAAAA FPYBAAAVNgEY9gMAADXWBQABA5giYNYKAAAA/wAAAAAAAHDWCgAAAP8AAAAAAAChAAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLMAAAAGgA dAB0AHAAOgAvAC8AdABlAG0AbgBpAGUAcAByAG8AZwBpAC4AYwBvAG0ALwAAAKkAFiQBSWYC AAAASyQBTCQBAZZsACF2AAJoATXWBQABA/wSNdYFAQIDtQ4jdgAB/BIjdgECtQ46Vg8AApZs AAeUvQsKdAAA4AENNmAPlGIBEJS0ABPWMAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8A AAAAAAAA/wAAAAAAAAD/AAAAABT2A7EhFTYBGPYDAAAelLQANdYFAAED/BI11gUBAgO1DmU0 AX4AFiQBFyQBSWYBAAAAAZYAACF2AAFoATXWBQABA5giI3YAAZgiOlYPAAKWbAAHlFUKCnQA AOABE9YwAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAA FPYBAAAVNgEY9gMAADXWBQABA5gioQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIA AAADAAAA4Mnqefm6zhGMggCqAEupCzAAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAA cgBvAGcAaQAuAGMAbwBtAC8AAAB6ABYkARckAUlmAQAAAAGWAAAhdgABaAE11gUAAQOYIiN2 AAGYIjpWDwAClmwACnQAAOABE9YwAAAA/wAAAAAAAAD/AAAAAAAAAP8AAAAAAAAA/wAAAAAA AAD/AAAAAAAAAP8AAAAAFPYBAAAVNgEY9gMAADXWBQABA5giAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgISABIAAQCcAA8ABAAAAAAAAAAAAAQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwEAAAAAAAAAAAGAE4A bwByAG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAAAAAAAAAAAA AAAAAAAARABBQPL/oQBEAAwFAAAAAAAAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcA cgBhAHAAaAAgAEYAbwBuAHQAAAAAAFIAaUDz/7MAUgAMBQAAAAAAAAAADABUAGEAYgBsAGUA IABOAG8AcgBtAGEAbAAAABwAF/YDAAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAACgA a0D0/8EAKAAABQAAAAAAAAAABwBOAG8AIABMAGkAcwB0AAAAAgAAAAAAAABqAJpAswDzAGoA DAQAAN43PwAAAAoAVABhAGIAbABlACAARwByAGkAZAAAADcAOlYPABPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAACAA8AAABIAJkAAQACAUgA DAUAAAAzjQAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABAAFABDShAAT0oFAFFK BQBeSgUAYUoQADYAVUCiABEBNgAMBAAAgBWBAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAwA PioBQioCcGgAAP8AAAAAANICAAALAAAcAAAHAP////8BAAAABCEAAP//AQCgepkAAAAAAAAA AADSAgAAAAAAAAAAAAAAAAAAAAAjAAAAJAAAACUAAABDAAAAcAAAAKcAAADKAAAA3AAAAN0A AAD1AAAADQEAAA4BAAAoAQAASAEAAEkBAABqAQAAhgEAAIcBAACnAQAAxAEAAMUBAADlAQAA AgIAAAMCAAAjAgAAQAIAAEECAABhAgAAfgIAAIACAACBAgAA0AIAANECAADUAgAAEAIAAMAh AABbgggAAAAAAAAAAAC1BBEAAAEAAMAhAAAX7QEAAAEAAMAhAADBlAUAAAIAAMAhAADBlAUA AAEAAMAhAADw+QYAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQS AACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIA AAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAACQSAACNrAIAAAEAAN0N AACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIA AAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0NAACNrAIAAAEAAN0N AACNrAIAAAEAAN0NAACNrAIAAAAAAAAAAACdFiAAAAAAAAAAAACBKj0AAAEAAMAhAADrdAQA AAAAAAAAAADrdAQAAAEAAMAhAACNrAIAAAAAACMAAAAkAAAAJQAAAEMAAABwAAAApwAAAMoA AADcAAAA3QAAAPUAAAANAQAADgEAACgBAABIAQAASQEAAGoBAACGAQAAhwEAAKcBAADEAQAA xQEAAOUBAAACAgAAAwIAACMCAABAAgAAQQIAAGECAAB+AgAAfwIAAIACAACBAgAA0AIAANEC AADUAgAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA ANQAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACA AQAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAEAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAA AIABAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACA AAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAA AIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAA AAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAA AAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAw AAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAA ADAAAAAAAAAAgAAAAIACAACYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkA AAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAA qQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAA AACpAAAAADAAAAAAAAAAgAAAAIACAACYAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAA AAAAAKkAAAAAMAAAAAAAAACAAAAAgAIAAJgAAAAAAACpAAAAADAAAAAAAAAAgAAAAIACAACY AAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAgAAmAAAAAAAAKkAAAAAMAAAAAAAAACAAAAAgAIA AJgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIACAACcAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA AQAAmAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAJwAAAAAIACpAAAAADAAAAAAAAAAgAAA AIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAAAEAAAAAygAAAH4CAAB/AgAA1AIAAEvIADAAEAAAAAAAAAIAAAADAAIA AAAAAAAAgAdLyAAwAQAAAAAAAAACAAAAAQABAAIAAAAAAGoHAkAAClsBmwEAAAAAAAAAAAAA AQAAAAAAAAAgB0uIADAAEAAAAAAAAAEAAAAAAAAAAAAAAAQOnwcABgAAhgkAAKYKAADSCgAA BgAAAAoAAAAMAAAAAAYAAA0JAAB+CgAA0AoAANIKAAAHAAAACQAAAAsAAAANAAAAAAYAANIK AAAIAAAAcAAAAJYAAAClAAAAgQIAAKcCAADOAgAA0gIAABNYFP8VhBNYFP8VhA8AAPA4AAAA AAAG8BgAAAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcA ABAADwAC8JIAAAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABT AAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP//CgAA AAYAEOAEChAAAQCsgYMEBgAR4AQKEQABAJzKgwQGAPbhBAoRAAEARECEBAYAD+IEChAAAQA0 e4gEBgD44QQKEQABAJRuiAQGABDiBAoQAAEAbFEkAAYA+uEEChEAAQDUxiEABgAR4gQKEAAB AKRshAQGAPzhBAoRAAEAHPskAAYAEuIEChAAAQAULBwAHQAAAB0AAACxAQAAsQEAAO8BAADv AQAALQIAAC0CAABrAgAAawIAANQCAAAAAAAAAgABAAAAAgACAAAAAgADAAAAAgAEAAAAAgAF AAAAAgAGAAAAAgAHAAAAAgAIAAAAAgAJAAAAAgAhAAAAIQAAALUBAAC1AQAA8wEAAPMBAAAx AgAAMQIAAG8CAABvAgAA1AIAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAA AAkAAAACAAAAOAAAAAkAEQAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncwSAQ2l0eQCAOQAAAAoAEgAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncwWAcGxhY2UAgAwAAAEcLxUGAAAAAAoAAAAAAAkAAAAAAAkAAAAAAAoA AAAAAAkAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAkAAAAAAAoAAAAAAAAAAADRAgAA0QIAANQC AAADAAQAAwAAAAAA1AIAAAcAAAAAACMAAAAlAAAAQwAAAHAAAADKAAAAhwEAAKcBAADFAQAA AQIAAAMCAAA/AgAAQQIAAH0CAADUAgAABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAAA AADUAgAABwAWAAAABAAAAAgAAADlAAAAAAAAABUAAABZNgAArHABAPI0KgCYdi8AUnk6ANFe PADeNz8Asj5XAL8eZgDER2cAwVtuAH0TcgC3LHMAERJ6AIAVgQAAM40ACCCoACcvwgALFeAA HhvgAMFR+gBERv4AAAAAACMAAAAkAAAApwAAAIcBAAB+AgAAfwIAAIACAACBAgAA0AIAANEC AADUAgAACAAAAAIBAACeAQAACAEAAAICAAACAgAAhgIAACIBAAK+AQACAgEAAJYBAAD/QAOA AQDRAgAA0QIAAIzdlwQBAAAA0QIAAAAAAQDRAgAAlP/AewIQAAAAAAAAANICAACwAAAQAEAA AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD/ /wAAAAD//wAAAgD//wAAAAAGAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/ AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIF BwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC BId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADUmkAEAAAILCAYDCQIFAgSH AgAAAAAAAAAAAAAAAAAAnwAAAAAAAABJAG0AcABhAGMAdAAAADcxkAEAAAIHBAkCAgUCBAQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByAAAANSYAAAAAAgsGBAMFBAQC BId6AGEAAACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAEADEIiBgA8NACAABo AQAAAAAqLKjGRCyoxoIVo4YFABYAAABrAAAAZwIAAAEAAQAAAAQAAxAFAAAAawAAAGcCAAAB AAEAAAAFAAAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgHoAW0ALQAgYF+NAAAEQAZAGQAAAAZAAAA0QIAANECAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA AAAACTODEQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAp8P8PAQAB PwAA5AQAAP///3////9/////f////3////9/////f////3/eNz8AAAAAADIAAAAAAAAAAAAA AAAAAAAAAP//EgAAAAAAAAASAFMAQQBWAEUAIABZAE8AVQBSACAAQgBVAFMASQBOAEUAUwBT AAAAAAAAAA4AVwBpAGwAbABpAGEAbQAgAEUAcwB0AGgAZQByAA4AVwBpAGwAbABpAGEAbQAg AEUAcwB0AGgAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwBAAASAAAAAQAAAJgA AAACAAAAoAAAAAMAAAC8AAAABAAAAMgAAAAFAAAA4AAAAAYAAADsAAAABwAAAPgAAAAIAAAA CAEAAAkAAAAgAQAAEgAAACwBAAAKAAAATAEAAAsAAABYAQAADAAAAGQBAAANAAAAcAEAAA4A AAB8AQAADwAAAIQBAAAQAAAAjAEAABMAAACUAQAAAgAAAOQEAAAeAAAAFAAAAFNBVkUgWU9V UiBCVVNJTkVTUwAAHgAAAAQAAAAAAAAAHgAAABAAAABXaWxsaWFtIEVzdGhlcgAAHgAAAAQA AAAAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwAAB4AAAAQAAAAV2lsbGlhbSBFc3Ro ZXIAAB4AAAAEAAAANQAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAAAE yBIDAAAAQAAAAACUeJp/PsYBQAAAAAAU0r7ouMYBQAAAAAAYmtHruMYBAwAAAAEAAAADAAAA awAAAAMAAABnAgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAA AAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgB AAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAAqAAAABcAAACwAAAA CwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwAAAD3AAAAAgAAAOQE AAAeAAAAIAAAAFBob2VuaXggTWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAAAwAAAAUAAAADAAAA AQAAAAMAAADRAgAAAwAAAOYVCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q AAABAAAAEwAAAFNBVkUgWU9VUiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAA AAEAAAAAAAAUAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9Q SURfSExJTktTAAIAAADkBAAAQQAAAMwAAAAMAAAAAwAAADMAIwADAAAAAwAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAAOgAvAC8AdABlAG0AbgBpAGUAcAByAG8AZwBpAC4A YwBvAG0ALwAAAB8AAAABAAAAAAASAAMAAAAzACMAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAA HwAAABgAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAAcgBvAGcAaQAuAGMAbwBtAC8A AAAfAAAAAQAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAAP7///8YAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA /v///yMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAD+////KwAAACwAAAAtAAAALgAAAC8A AAAwAAAAMQAAAP7////9////NAAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAA AAAgk4jy67jGATYAAACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAAAAAQAAAAAAAAMQBUAGEAYgBsAGUA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAA URUAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAuHAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAAAAAQAAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAP7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG HwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABX b3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAOBO twb2uMYBNgAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEA AAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAABRFQAA AAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC4cAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAAP7///8YAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA/v///yMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAD+//////////////////////////////////// ///////////////////////////+/////v///0EAAAD9////OgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAP7////+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////+/wAA BQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOX CAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACYAAAABgAAAKAAAAARAAAA qAAAABcAAACwAAAACwAAALgAAAAQAAAAwAAAABMAAADIAAAAFgAAANAAAAANAAAA2AAAAAwA AAD3AAAAAgAAAOQEAAAeAAAAIAAAAFBob2VuaXggTWFuYWdlbWVudCBDb3Jwb3JhdGlvbgAA AwAAAAUAAAADAAAAAQAAAAMAAADRAgAAAwAAAOYVCwALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAALAAAAAAAAAB4QAAABAAAAEwAAAFNBVkUgWU9VUiBCVVNJTkVTUwAMEAAAAgAAAB4AAAAG AAAAVGl0bGUAAwAAAAEAAAAAAAAUAQAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEA AAACAAAADAAAAF9QSURfSExJTktTAAIAAADkBAAAQQAAAMwAAAAMAAAAAwAAADMAIwADAAAA AwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAAOgAvAC8AdABlAG0AbgBpAGUA cAByAG8AZwBpAC4AYwBvAG0ALwAAAB8AAAABAAAAAAASAAMAAAAzACMAAwAAAAAAAAADAAAA AAAAAAMAAAAFAAAAHwAAABgAAABoAHQAdABwADoALwAvAHQAZQBtAG4AaQBlAHAAcgBvAGcA aQAuAGMAbwBtAC8AAAAfAAAAAQAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiAAAA ABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADkAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0001_01C6B9DF.C0323800-- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 10 06:13:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7XP-0002Zq-Jg for ipdvb-archive@ietf.org; Thu, 10 Aug 2006 06:13:15 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB7XO-00088c-5V for ipdvb-archive@ietf.org; Thu, 10 Aug 2006 06:13: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 k7A9sEnI014870 for ; Thu, 10 Aug 2006 10:54:14 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7A9sEDf014869 for ipdvb-subscribed-users; Thu, 10 Aug 2006 10:54: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 [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7A9s72L014855 for ; Thu, 10 Aug 2006 10:54:07 +0100 (BST) Message-ID: <44DB023F.8070602@erg.abdn.ac.uk> Date: Thu, 10 Aug 2006 10:54:07 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol Author(s) : H. Cruickshank, et al. Filename : draft-cruickshank-ipdvb-sec-req-03.txt Pages : 17 Date : 2006-8-9 This document provides a threat analysis and derives security requirements for MPEG-2 transmission links using the Unidirectional Lightweight Encapsulation (ULE). It also provides the motivation for ULE link-level security. This work is intended as a work item of the ipdvb WG, and contributions are sought from the IETF on this topic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cruickshank-ipdvb-sec-req-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-cruickshank-ipdvb-sec-req-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipdvb@erg.abdn.ac.uk Thu Aug 10 06:19:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB7dm-0006Aa-3Q for ipdvb-archive@ietf.org; Thu, 10 Aug 2006 06:19:50 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB7dl-0000E6-NF for ipdvb-archive@ietf.org; Thu, 10 Aug 2006 06:19:50 -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 k7AA5Yur016205 for ; Thu, 10 Aug 2006 11:05:34 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7AA5YTh016204 for ipdvb-subscribed-users; Thu, 10 Aug 2006 11:05: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 [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7AA5Oxe016178 for ; Thu, 10 Aug 2006 11:05:24 +0100 (BST) Message-ID: <44DB04E4.2050602@erg.abdn.ac.uk> Date: Thu, 10 Aug 2006 11:05:24 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt References: <44DB023F.8070602@erg.abdn.ac.uk> In-Reply-To: <44DB023F.8070602@erg.abdn.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 X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a The authors have posted a new revision of their requirements I-D with arequest to make this a WG I-D, as discussed at the IETF meeting in Montreal. I have a few questions that I would like to see clarified by the WG via this list and/or the authors before this can proceed. These are: 1) Could the people on the mailing list clarify which SPD selectors we think should be used (NPA/MAC address, SID, etc), detailing the various options and needs, including what happens when we use the bridging header, and whether policy also can be determined based on the Type field in combination with a NPA/MAC address. 2) Can we determine precisely what we man by a "Stream". Does a Stream always only have ONE originating source? That is, does the PID imply a specific intended source? I'd really like to see a section on what constitutes a stream - for this the list needs to agree if a stream has only one source (or may have multiple sources), etc. This section should also elaborate how data can be inserted in a stream during an attack and say (if you can) how significant this threat is. 3) Is there anything else that may be missing from this document? Gorry Fairhurst From owner-ipdvb@erg.abdn.ac.uk Mon Aug 14 06:25:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCZdJ-00084g-W4 for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 06:25:21 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCZdH-0005PJ-Qd for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 06:25:21 -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 k7E9oh33027542 for ; Mon, 14 Aug 2006 10:50:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7E9ohe8027541 for ipdvb-subscribed-users; Mon, 14 Aug 2006 10:50: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 dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7E9oWjk027525 for ; Mon, 14 Aug 2006 10:50:32 +0100 (BST) Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id DA4E7943AD; Mon, 14 Aug 2006 11:50:28 +0200 (CEST) Received: from [141.201.123.67] (unknown [141.201.123.67]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id 50395925AC for ; Mon, 14 Aug 2006 11:50:25 +0200 (CEST) Message-ID: <44E04772.5050105@cosy.sbg.ac.at> Date: Mon, 14 Aug 2006 11:50:42 +0200 From: Michael Noisternig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt References: <44DB023F.8070602@erg.abdn.ac.uk> <44DB04E4.2050602@erg.abdn.ac.uk> In-Reply-To: <44DB04E4.2050602@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on dobermann.cosy.sbg.ac.at X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.4, No, No 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 k7E9oh33027542 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Hello everyone, this is my first post here, so just a few words to introduce myself... I'm a student of computer science and mathematics at the University of Salzburg, and I've been working as a project assistent in the areas of ULE and security for a couple of months now. I'm currently working on a draft that is hopefully going to be released soon. I've read the current version of the ULE security requirements draft, and there are few things I want to comment on. The first thing is, it reads a lot better now than the last version I read (-01). :-) So here are my other comments: =A73.2, last paragraph: - data integrity alone does not provide authentication - the defence statement is oversimplifying and belongs to the requirements section =A73.3, threat cases 2 and 3: one can distinguish between two other cases: (a) insider attacks, i.e. active attacks from adverseries in the know of certain keys -> protection against this attack requires source authentication (e.g. digitial signatures) (b) outsider attacks, i.e. active attacks from outside of a VPN -> in this case simple MACs are sufficient (i.e. group authenticatio= n) =A74: all the references to section 2 should be 3 =A74, security requirements list: - instead of "ULE source authentication is required..." should more generally say "integrity protection and authentication is required..." - missing L2 ULE sender and receiver authentication (entitiy authenticati= on) $4, other general requirements list: - might mention requirement for policy management - integrity of control messages (SI tables): as said before, what we want is authentication =A74, security requirements case 2: - MACs do NOT provide source authentication for cases 2 and 3 (subcase (a= )) - if mentioning TESLA should first speak of digital signatures (btw, TESLA introduces further latencies at the receiver side and still requires digital signatures (for signing the head of the hash chains)) =A75, first paragraph, last sentence: ...impact on bandwidth? =A75, last list item: I don't see how the issue of address preservation is of relevance to the ULE scenario. AFAIK address preservation is important for correct=20 routing within multicast trees, but since in ULE networks data is simply=20 sent from one L2 point to the next I don't understand the problem. =A76.1, disadvantages: third item should probably mean "Encryption of the MAC/NPA address is=20 not permitted in MPE systems." =A76.2: - references to section 2 should be 3 - information in first paragraph is redundant, i.e. already in the requirements section (section 4) =A77, second paragraph: It should better read "There is an optional requirement for L2 authentication and integrity assurance as well as protection against insertion of other data into the ULE stream (i.e. replay attacks)." Gorry Fairhurst wrote: >=20 > 2) Can we determine precisely what we man by a "Stream". Does a Stream= =20 > always only have ONE originating source? That is, does the PID imply a=20 > specific intended source? It is my understanding that there can only be at most one designated sender per PID, basically due to multiple synchronization problems otherwise. However, this does not preclude the possibility of a=20 sophisticated active adversery injecting data on the same PID. Regards, Michael Noisternig From owner-ipdvb@erg.abdn.ac.uk Mon Aug 14 07:23:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCaXZ-0006zq-Sv for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 07:23:29 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCaXY-0002Y6-Fx for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 07:23:29 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7EB6JRn002902 for ; Mon, 14 Aug 2006 12:06:19 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7EB6JUK002901 for ipdvb-subscribed-users; Mon, 14 Aug 2006 12:06:19 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from esacom57-int.estec.esa.int (esacom57-ext.estec.esa.int [131.176.107.4]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7EB6C73002885 for ; Mon, 14 Aug 2006 12:06:12 +0100 (BST) Received: from esacom52.estec.esa.int (esacom52.estec.esa.int [131.176.7.7]) by esacom57-int.estec.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id k7EB66Wn029153 for ; Mon, 14 Aug 2006 13:06:06 +0200 (MET DST) Received: from estecmta1.estec.esa.int (estecmta1.estec.esa.int [131.176.1.131]) by esacom52.estec.esa.int (8.12.10/8.12.10/ESA-Internal-v3.2) with ESMTP id k7EB66HX017234 for ; Mon, 14 Aug 2006 13:06:06 +0200 (MET DST) Subject: Stephane Combes is out of the office. From: Stephane.Combes@esa.int To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Mon, 14 Aug 2006 13:06:05 +0200 X-MIMETrack: Serialize by Router on estecmta1/estec/ESA(Release 6.5.5FP1 | April 14, 2006) at 08/14/2006 13:06:06 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea I will be out of the office starting 14/08/2006 and will not return until 28/08/2006. I will respond to your message when I return. For urgent matters, please contact Xavier Lobao (xavier.lobao@esa.int). From owner-ipdvb@erg.abdn.ac.uk Mon Aug 14 09:50:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCcpc-0008QV-MW for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 09:50:16 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCcpb-0005s6-0s for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 09:50:16 -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 k7EDXidH013597 for ; Mon, 14 Aug 2006 14:33:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7EDXi1b013596 for ipdvb-subscribed-users; Mon, 14 Aug 2006 14:33: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 hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7EDXZYp013580 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 14 Aug 2006 14:33:35 +0100 (BST) Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k7EDPSmI025772; Mon, 14 Aug 2006 14:25:29 +0100 (BST) Received: from bradford.ac.uk (thallium.cen.brad.ac.uk [143.53.238.78]) by radon.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k7EDPRgS020971; Mon, 14 Aug 2006 14:25:27 +0100 (BST) Received: from 143.53.20.59 ([143.53.20.59]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Mon, 14 Aug 2006 14:25:27 +0100 Message-ID: <1155561927.44e079c777a2c@webmail6.brad.ac.uk> Date: Mon, 14 Aug 2006 14:25:27 +0100 From: P.Pillai@Bradford.ac.uk To: Michael Noisternig Cc: ipdvb@erg.abdn.ac.uk Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt In-Reply-To: <44E04772.5050105@cosy.sbg.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.20.59 X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k7EDXidH013597 X-Spam-Score: 0.2 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Hi Michael, Thanx for your comments. See inline. Quoting Michael Noisternig : > Hello everyone, > > this is my first post here, so just a few words to introduce myself... > I'm a student of computer science and mathematics at the University of > Salzburg, and I've been working as a project assistent in the areas of > ULE and security for a couple of months now. I'm currently working on a > draft that is hopefully going to be released soon. > > I've read the current version of the ULE security requirements draft, > and there are few things I want to comment on. The first thing is, it > reads a lot better now than the last version I read (-01). :-) > > So here are my other comments: > > =A73.2, last paragraph: > - data integrity alone does not provide authentication > - the defence statement is oversimplifying and belongs to the > requirements section Yes, Data integrity is different from data authentication, but the same M= AC can be used to provide both data integrity and data authentication. > > =A73.3, threat cases 2 and 3: > one can distinguish between two other cases: > (a) insider attacks, i.e. active attacks from adverseries in the know o= f > certain keys > -> protection against this attack requires source authentication > (e.g. digitial signatures) This is more part of key management techniques. An adversary (even if it = knows the keys) has to still over-ride the original transmission stream and del= iver a modified stream =96 this is Case 2 as described in the draft. > (b) outsider attacks, i.e. active attacks from outside of a VPN > -> in this case simple MACs are sufficient (i.e. group authenticat= ion) Note that the Secure ULE aims to secure only between the ULE encapsulatio= n gateways and the ULE receivers. > > =A74: all the references to section 2 should be 3 Thanx, will modify these. > > =A74, security requirements list: > - instead of "ULE source authentication is required..." should more > generally say "integrity protection and authentication is required..." Yes, will change this > - missing L2 ULE sender and receiver authentication (entitiy authentica= tion) This is part of the initial key exchange and authorisation phase =96 it i= s present in the requirements lists in section 4 > > $4, other general requirements list: > - might mention requirement for policy management The policy management should be part of the key management system. Could= add a line for this > - integrity of control messages (SI tables): as said before, what we > want is authentication Please see section 3.1. The integrity of the SI tables been discussed in = Section 3.1 and it is stated that this is out of scope of the ULE security as the= se tables are not encapsulated by ULE. > > =A74, security requirements case 2: > - MACs do NOT provide source authentication for cases 2 and 3 (subcase = (a)) The MAC is used to make sure that the data has been sent by the correct s= ource =96 hence provides source authentication. I am not sure why you say that it d= oes not provide any source authentication. > - if mentioning TESLA should first speak of digital signatures > (btw, TESLA introduces further latencies at the receiver side and still > requires digital signatures (for signing the head of the hash chains)) TESLA is only mentioned as an option that may be possible. > > =A75, first paragraph, last sentence: > ...impact on bandwidth? > > =A75, last list item: > I don't see how the issue of address preservation is of relevance > to the ULE scenario. AFAIK address preservation is important for correc= t > routing within multicast trees, but since in ULE networks data is simpl= y > sent from one L2 point to the next I don't understand the problem. > > =A76.1, disadvantages: > third item should probably mean "Encryption of the MAC/NPA address is > not permitted in MPE systems." Will change this > > =A76.2: > - references to section 2 should be 3 > - information in first paragraph is redundant, i.e. already in the > requirements section (section 4) > > =A77, second paragraph: > It should better read "There is an optional requirement for L2 > authentication and integrity assurance as well as protection against > insertion of other data into the ULE stream (i.e. replay attacks)." > > Gorry Fairhurst wrote: > > > > 2) Can we determine precisely what we man by a "Stream". Does a Stre= am > > always only have ONE originating source? That is, does the PID imply = a > > specific intended source? > > It is my understanding that there can only be at most one designated > sender per PID, basically due to multiple synchronization problems > otherwise. However, this does not preclude the possibility of a > sophisticated active adversery injecting data on the same PID. > > Regards, > Michael Noisternig > > Regards Prashant --=20 Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Mon Aug 14 10:24:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCdMG-0002x5-SS for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 10:24:00 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCdMG-00007Q-Bz for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 10:24: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 k7EE7eRd016643 for ; Mon, 14 Aug 2006 15:07:40 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7EE7eZI016642 for ipdvb-subscribed-users; Mon, 14 Aug 2006 15:07:40 +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 k7EE7S4Z016619 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 14 Aug 2006 15:07:29 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.12411404; Mon, 14 Aug 2006 10:07:03 -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: RE: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt Date: Mon, 14 Aug 2006 10:07:03 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C1701792BBC@morse.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt Thread-Index: Aca/jb79211+n6msRB2XxHSI/mHuWAAF+/dA From: "Allison, Art" To: X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id k7EE7eLU016639 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 k7EE7eRd016643 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 I have not contributed my point of view in a long time, but the last line= of this post prompts me to do so once again in hopes that some new parti= cipants will at least have more information about MPEG-2 TS and RF distri= bution. =20 When the MPEG-2 TS ULE packets are delivered via an RF channel; be it ove= r cable, satellite, or terrestrial; to succeed in an attack, the RF signa= l must be over powered. If the attacker can do that, they can replace th= e entire stream (or indeed they could receive the stream and selectively = substitute some packets-but why?). However, the risk assessment should c= onsider the practical difficulties and potential benefits of the attack m= ode. A mobile truck could indeed deny service to a small radius of terre= strial receivers, perhaps even to a smaller radius or satellite receivers= , and a cable cut on a pole can wipe out an entire area. These attacks a= re difficult to mount and easy to detect and counter. =20 =20 If one is concerned about protection of the distribution link, [where the= packets are themselves sent as part of an entire MPEG-2 TS using another= protocol such as TCP or AVT], that seems better done by protecting the p= rotocol delivering the entire set of packets, rather than within the pack= et. And there is a long-defined method for protecting the entire content= s of an MPEG-2 packet, independent of its payload (which can be employed = on a PID by PID basis). I still see placing security at the ULE level as unneeded, even a 'poor' = design choice, but having a standard to enable a solution should this des= ign choice be made is perhaps better than not having one. =20 Art _____________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N Street, NW Washington, D.C. 20036 Phone: 202.429.5418 Fax: 202.777.4981 aallison@nab.org The National Association of Broadcasters is a trade association that advo= cates on behalf of more than 8,300 free, local radio and television stati= ons and also broadcast networks before Congress, the Federal Communicatio= ns Commission and the Courts. -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On B= ehalf Of Michael Noisternig Sent: Monday, August 14, 2006 5:51 AM To: ipdvb@erg.abdn.ac.uk Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-= 03.txt Hello everyone, this is my first post here, so just a few words to introduce myself... I'm a student of computer science and mathematics at the University of Sa= lzburg, and I've been working as a project assistent in the areas of ULE = and security for a couple of months now. I'm currently working on a draft= that is hopefully going to be released soon. I've read the current version of the ULE security requirements draft, and= there are few things I want to comment on. The first thing is, it reads = a lot better now than the last version I read (-01). :-) So here are my other comments: =A73.2, last paragraph: - data integrity alone does not provide authentication - the defence statement is oversimplifying and belongs to the requirement= s section =A73.3, threat cases 2 and 3: one can distinguish between two other cases: (a) insider attacks, i.e. active attacks from adverseries in the know of = certain keys -> protection against this attack requires source authentication (e.= g. digitial signatures) (b) outsider attacks, i.e. active attacks from outside of a VPN -> in this case simple MACs are sufficient (i.e. group authenticatio= n) =A74: all the references to section 2 should be 3 =A74, security requirements list: - instead of "ULE source authentication is required..." should more gener= ally say "integrity protection and authentication is required..." - missing L2 ULE sender and receiver authentication (entitiy authenticati= on) $4, other general requirements list: - might mention requirement for policy management - integrity of control messages (SI tables): as said before, what we want= is authentication =A74, security requirements case 2: - MACs do NOT provide source authentication for cases 2 and 3 (subcase (a= )) - if mentioning TESLA should first speak of digital signatures (btw, TESL= A introduces further latencies at the receiver side and still requires di= gital signatures (for signing the head of the hash chains)) =A75, first paragraph, last sentence: ...impact on bandwidth? =A75, last list item: I don't see how the issue of address preservation is of relevance to the = ULE scenario. AFAIK address preservation is important for correct routing= within multicast trees, but since in ULE networks data is simply sent fr= om one L2 point to the next I don't understand the problem. =A76.1, disadvantages: third item should probably mean "Encryption of the MAC/NPA address is not= permitted in MPE systems." =A76.2: - references to section 2 should be 3 - information in first paragraph is redundant, i.e. already in the requir= ements section (section 4) =A77, second paragraph: It should better read "There is an optional requirement for L2 authentica= tion and integrity assurance as well as protection against insertion of o= ther data into the ULE stream (i.e. replay attacks)." Gorry Fairhurst wrote: >=20 > 2) Can we determine precisely what we man by a "Stream". Does a=20 > Stream always only have ONE originating source? That is, does the PID=20 > imply a specific intended source? It is my understanding that there can only be at most one designated send= er per PID, basically due to multiple synchronization problems otherwise.= However, this does not preclude the possibility of a sophisticated activ= e adversery injecting data on the same PID. Regards, Michael Noisternig From owner-ipdvb@erg.abdn.ac.uk Mon Aug 14 11:42:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GCeab-0006wu-AA for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 11:42:53 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCeaY-00057M-MG for ipdvb-archive@ietf.org; Mon, 14 Aug 2006 11:42:53 -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 k7EFOftl022620 for ; Mon, 14 Aug 2006 16:24:41 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7EFOebG022619 for ipdvb-subscribed-users; Mon, 14 Aug 2006 16:24:40 +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 dobermann.cosy.sbg.ac.at (dobermann.cosy.sbg.ac.at [141.201.2.56]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7EFO8xb022602 for ; Mon, 14 Aug 2006 16:24:08 +0100 (BST) Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id 0C72294C03; Mon, 14 Aug 2006 17:24:09 +0200 (CEST) Received: from [141.201.123.67] (unknown [141.201.123.67]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id 9816E94C54 for ; Mon, 14 Aug 2006 17:24:04 +0200 (CEST) Message-ID: <44E095A5.6030009@cosy.sbg.ac.at> Date: Mon, 14 Aug 2006 17:24:21 +0200 From: Michael Noisternig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt References: <1155561927.44e079c777a2c@webmail6.brad.ac.uk> In-Reply-To: <1155561927.44e079c777a2c@webmail6.brad.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on dobermann.cosy.sbg.ac.at X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.4, No, No 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 k7EFOftl022620 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Hi Prashant, thanks for your quick reply. See comments inline. P.Pillai@Bradford.ac.uk wrote: > Hi Michael, >> =A73.2, last paragraph: >> - data integrity alone does not provide authentication >> - the defence statement is oversimplifying and belongs to the >> requirements section >=20 > Yes, Data integrity is different from data authentication, but the same= MAC can > be used to provide both data integrity and data authentication. Integrity of messages is automatically assured by their correct=20 authentication, so yes, MACs provide both authentication and integrity.=20 But you are not speaking about MACs in that paragraph or section. A CRC=20 or any unkeyed hash provides integrity protection but is certainly not=20 effective against active adverseries. >> =A73.3, threat cases 2 and 3: >> one can distinguish between two other cases: >> (a) insider attacks, i.e. active attacks from adverseries in the know = of >> certain keys >> -> protection against this attack requires source authentication >> (e.g. digitial signatures) >=20 > This is more part of key management techniques. An adversary (even if i= t knows > the keys) has to still over-ride the original transmission stream and d= eliver a > modified stream =96 this is Case 2 as described in the draft. >> (b) outsider attacks, i.e. active attacks from outside of a VPN >> -> in this case simple MACs are sufficient (i.e. group authentica= tion) >=20 > Note that the Secure ULE aims to secure only between the ULE encapsulat= ion > gateways and the ULE receivers. Well, I speak about the case where a ULE receiver can act as a sender,=20 i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared=20 authentication key for MACs) acting as a sender can successfully forge=20 messages, but not when digital signatures are used (case a). However, a=20 sender who does not know the MAC key (e.g. because he is not part of the=20 VPN within the same ULE network) will not be able to forge messages=20 (case b). Note that even when there is only one ULE encapsulator an active=20 adversary may invalidate the one-sender assumption, and so you again=20 cannot detect forged messages for case a when MACs are used. >> =A74: all the references to section 2 should be 3 > Thanx, will modify these. >> =A74, security requirements list: >> - instead of "ULE source authentication is required..." should more >> generally say "integrity protection and authentication is required..." > Yes, will change this >=20 >> - missing L2 ULE sender and receiver authentication (entitiy authentic= ation) > This is part of the initial key exchange and authorisation phase =96 it= is present > in the requirements lists in section 4 Well, it was just my impression, if you mention authorization separately=20 from key management, you should also mention entity authentication. >> =A74, security requirements case 2: >> - MACs do NOT provide source authentication for cases 2 and 3 (subcase= (a)) > The MAC is used to make sure that the data has been sent by the correct= source =96 > hence provides source authentication. I am not sure why you say that it= does not > provide any source authentication. Multiple senders. This is why you want TESLA. (In multiple sender scenarios MACs can only provide group authentication.= ) >> - if mentioning TESLA should first speak of digital signatures >> (btw, TESLA introduces further latencies at the receiver side and stil= l >> requires digital signatures (for signing the head of the hash chains)) > TESLA is only mentioned as an option that may be possible. Best regards, Michael From owner-ipdvb@erg.abdn.ac.uk Tue Aug 15 12:27:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1lk-0007Ds-OT for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 12:27:56 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD1lg-0006iZ-2H for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 12:27: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 k7FG5PDe010573 for ; Tue, 15 Aug 2006 17:05:25 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7FG5PFg010572 for ipdvb-subscribed-users; Tue, 15 Aug 2006 17:05:25 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k7FG5DuB010515 for ; Tue, 15 Aug 2006 17:05:14 +0100 (BST) Received: (qmail 64881 invoked by uid 0); 15 Aug 2006 12:05:13 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 15 Aug 2006 12:05:13 -0400 Received: (qmail 21183 invoked from network); 15 Aug 2006 12:05:12 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 15 Aug 2006 12:05:12 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k7FCG9x06670; Tue, 15 Aug 2006 08:16:09 -0400 Date: Tue, 15 Aug 2006 08:16:09 -0400 (EDT) From: George Gross To: Subject: RE: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt In-Reply-To: <33CB4DEADE8C734CAF59FA0B47E14C1701792BBC@morse.NAB.ORG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by erg.abdn.ac.uk id k7FG5PYx010569 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 k7FG5PDe010573 X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Hi Art, On Mon, 14 Aug 2006, Allison, Art wrote: > > > I have not contributed my point of view in a long time, but the last > line of this post prompts me to do so once again in hopes that some > new participants will at least have more information about MPEG-2 TS > and RF distribution. > > When the MPEG-2 TS ULE packets are delivered via an RF channel; be it > over cable, satellite, or terrestrial; to succeed in an attack, the RF > signal must be over powered. If the attacker can do that, they can > replace the entire stream (or indeed they could receive the stream and > selectively substitute some packets-but why?). One of the use cases for IPDVB is as an intra-company virtual LAN (e.g. several dozen SOHO distributed over a region). In this trust model, the I= P communications between peer LAN endpoints would normally be considered reliable and they would not be authenticated or encrypted at the IP layer. Even if one did apply IPsec, this would negatively interact with PEP sessions. In this scenario, the Adversary's motivation is economic and dependent on the value of the company information that could be compromised by eavesdropping or alteration. One could envision all kinds of mischief if an Adversary were able to intercept and alter those communications at the IPDVB Layer-2. So the "why" is entirely up to the Adversary's game plan. > However, the risk > assessment should consider the practical difficulties and potential > benefits of the attack mode. A mobile truck could indeed deny service > to a small radius of terrestrial receivers, perhaps even to a smaller > radius or satellite receivers, and a cable cut on a pole can wipe out > an entire area. These attacks are difficult to mount and easy to > detect and counter. The perceived difficulty of attack is an illusion, it would hardly deter = a well funded Adversary such as an organized crime family or a rogue nation state. All they'd need for motivation is either a high value target, or else a design a mobile wireless unit that would attack a number of lower value targets. Expecting these victems to anticipate, detect, and counter such attacks (especially when wireless), is optimistic. > If one is concerned about protection of the distribution link, > [where the packets are themselves sent as part of an entire MPEG-2 TS > using another protocol such as TCP or AVT], that seems better done by > protecting the protocol delivering the entire set of packets, rather > than within the packet. A more pragmatic security policy is defence in depth, in which every laye= r in the protocol stack participates in securing the application end to end. Unfortunately, satellite communications that use PEP will have problems with IPsec gateways at layer-3. In contrast, a layer-2 encryption and authentication protocol is transparent to PEP. Layer-2 encryption also ha= s the benefit that the IP traffic temporarily transiting a satellite sub-network (i.e. terrestrial link fail-over) does not require the remot= e layer-3 endpoints to define security policies contingent on the change in their IP packet's routing path. > And there is a long-defined method for > protecting the entire contents of an MPEG-2 packet, independent of its > payload (which can be employed on a PID by PID basis). We have already established on this list several months back that the PID does not offer the fine granularity of key management needed to secure IP over MPEG and ULE. > > I still see placing security at the ULE level as unneeded, even a > 'poor' design choice, but having a standard to enable a solution > should this design choice be made is perhaps better than not having > one. As explained above, layer-2 security is hardly a "poor" design choice. Rather, it represents another tool in the MPEG-2 network operator's security toolchest. br, George > > Art > _____________ > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N Street, NW > Washington, D.C. 20036 > Phone: 202.429.5418 > Fax: 202.777.4981 > aallison@nab.org > > The National Association of Broadcasters is a trade association that ad= vocates on behalf of more than 8,300 free, local radio and television sta= tions and also broadcast networks before Congress, the Federal Communicat= ions Commission and the Courts. > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On= Behalf Of Michael Noisternig > Sent: Monday, August 14, 2006 5:51 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-re= q-03.txt > > Hello everyone, > > this is my first post here, so just a few words to introduce myself... > I'm a student of computer science and mathematics at the University of = Salzburg, and I've been working as a project assistent in the areas of UL= E and security for a couple of months now. I'm currently working on a dra= ft that is hopefully going to be released soon. > > I've read the current version of the ULE security requirements draft, a= nd there are few things I want to comment on. The first thing is, it read= s a lot better now than the last version I read (-01). :-) > > So here are my other comments: > > =A73.2, last paragraph: > - data integrity alone does not provide authentication > - the defence statement is oversimplifying and belongs to the requireme= nts section > > =A73.3, threat cases 2 and 3: > one can distinguish between two other cases: > (a) insider attacks, i.e. active attacks from adverseries in the know o= f certain keys > -> protection against this attack requires source authentication (= e.g. digitial signatures) > (b) outsider attacks, i.e. active attacks from outside of a VPN > -> in this case simple MACs are sufficient (i.e. group authenticat= ion) > > =A74: all the references to section 2 should be 3 > > =A74, security requirements list: > - instead of "ULE source authentication is required..." should more gen= erally say "integrity protection and authentication is required..." > - missing L2 ULE sender and receiver authentication (entitiy authentica= tion) > > $4, other general requirements list: > - might mention requirement for policy management > - integrity of control messages (SI tables): as said before, what we wa= nt is authentication > > =A74, security requirements case 2: > - MACs do NOT provide source authentication for cases 2 and 3 (subcase = (a)) > - if mentioning TESLA should first speak of digital signatures (btw, TE= SLA introduces further latencies at the receiver side and still requires = digital signatures (for signing the head of the hash chains)) > > =A75, first paragraph, last sentence: > ...impact on bandwidth? > > =A75, last list item: > I don't see how the issue of address preservation is of relevance to th= e ULE scenario. AFAIK address preservation is important for correct routi= ng within multicast trees, but since in ULE networks data is simply sent = from one L2 point to the next I don't understand the problem. > > =A76.1, disadvantages: > third item should probably mean "Encryption of the MAC/NPA address is n= ot permitted in MPE systems." > > =A76.2: > - references to section 2 should be 3 > - information in first paragraph is redundant, i.e. already in the requ= irements section (section 4) > > =A77, second paragraph: > It should better read "There is an optional requirement for L2 authenti= cation and integrity assurance as well as protection against insertion of= other data into the ULE stream (i.e. replay attacks)." > > Gorry Fairhurst wrote: > > > > 2) Can we determine precisely what we man by a "Stream". Does a > > Stream always only have ONE originating source? That is, does the PID > > imply a specific intended source? > > It is my understanding that there can only be at most one designated se= nder per PID, basically due to multiple synchronization problems otherwis= e. However, this does not preclude the possibility of a sophisticated act= ive adversery injecting data on the same PID. > > Regards, > Michael Noisternig > > From owner-ipdvb@erg.abdn.ac.uk Tue Aug 15 14:46:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3vY-0007m9-36 for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 14:46:12 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3vW-0006U1-IA for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 14:46:12 -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 k7FIXg6m021664 for ; Tue, 15 Aug 2006 19:33:42 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7FIXgdk021663 for ipdvb-subscribed-users; Tue, 15 Aug 2006 19:33: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 smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k7FIXT0w021629 for ; Tue, 15 Aug 2006 19:33:29 +0100 (BST) Received: (qmail 37426 invoked by uid 0); 15 Aug 2006 14:33:28 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 15 Aug 2006 14:33:28 -0400 Received: (qmail 6007 invoked from network); 15 Aug 2006 14:33:27 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 15 Aug 2006 14:33:27 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k7FEiOA06796; Tue, 15 Aug 2006 10:44:24 -0400 Date: Tue, 15 Aug 2006 10:44:24 -0400 (EDT) From: George Gross To: Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt In-Reply-To: <44E095A5.6030009@cosy.sbg.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by erg.abdn.ac.uk id k7FIXgHU021660 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 k7FIXg6m021664 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Hi Michael, in looking over this thread, I think that there might be confusion about which threat model is being assumed by you versus the one assumed by Prashant. The group key management subsystem does the authentication and authorization of the IPDVB group membership. The network's security polic= y administrator decides what constitutes a group's membership and whether there is an unacceptable risk of an insider attack that the group must be defended against. For a basic security policy, group authentication is sufficient because group members are trusted. Source authentication using digital signature or TESLA is not required. In the event that the group's authentication ke= y is compromised then the scope of the damage is limited to only that group rather than all groups sharing that MPEG TS. Limiting the size of each group can help minimize this risk. For a security policy that considers an insider attack a risk, then sourc= e authentication would be a reasonable mechanism to counter that vulnerability. However, I have not heard on this list any use cases that would need that service at layer-2. Michael, did you have such an example in mind for IPDVB? hth, George On Mon, 14 Aug 2006, Michael Noisternig wrote: > Hi Prashant, > > thanks for your quick reply. See comments inline. > > P.Pillai@Bradford.ac.uk wrote: > > Hi Michael, > > > > >> =A73.2, last paragraph: > >> - data integrity alone does not provide authentication > >> - the defence statement is oversimplifying and belongs to the > >> requirements section > > > > Yes, Data integrity is different from data authentication, but the sa= me MAC can > > be used to provide both data integrity and data authentication. > > Integrity of messages is automatically assured by their correct > authentication, so yes, MACs provide both authentication and integrity. > But you are not speaking about MACs in that paragraph or section. A CRC > or any unkeyed hash provides integrity protection but is certainly not > effective against active adverseries. > > >> =A73.3, threat cases 2 and 3: > >> one can distinguish between two other cases: > >> (a) insider attacks, i.e. active attacks from adverseries in the kno= w of > >> certain keys > >> -> protection against this attack requires source authenticatio= n > >> (e.g. digitial signatures) > > > > This is more part of key management techniques. An adversary (even if= it knows > > the keys) has to still over-ride the original transmission stream and= deliver a > > modified stream =96 this is Case 2 as described in the draft. > >> (b) outsider attacks, i.e. active attacks from outside of a VPN > >> -> in this case simple MACs are sufficient (i.e. group authenti= cation) > > > > Note that the Secure ULE aims to secure only between the ULE encapsul= ation > > gateways and the ULE receivers. > > Well, I speak about the case where a ULE receiver can act as a sender, > i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared > authentication key for MACs) acting as a sender can successfully forge > messages, but not when digital signatures are used (case a). However, a > sender who does not know the MAC key (e.g. because he is not part of th= e > VPN within the same ULE network) will not be able to forge messages > (case b). > > Note that even when there is only one ULE encapsulator an active > adversary may invalidate the one-sender assumption, and so you again > cannot detect forged messages for case a when MACs are used. > > >> =A74: all the references to section 2 should be 3 > > Thanx, will modify these. > >> =A74, security requirements list: > >> - instead of "ULE source authentication is required..." should more > >> generally say "integrity protection and authentication is required..= ." > > Yes, will change this > > > >> - missing L2 ULE sender and receiver authentication (entitiy authent= ication) > > This is part of the initial key exchange and authorisation phase =96 = it is present > > in the requirements lists in section 4 > > Well, it was just my impression, if you mention authorization separatel= y > from key management, you should also mention entity authentication. > > > > >> =A74, security requirements case 2: > >> - MACs do NOT provide source authentication for cases 2 and 3 (subca= se (a)) > > The MAC is used to make sure that the data has been sent by the corre= ct source =96 > > hence provides source authentication. I am not sure why you say that = it does not > > provide any source authentication. > > Multiple senders. This is why you want TESLA. > (In multiple sender scenarios MACs can only provide group authenticatio= n.) > > >> - if mentioning TESLA should first speak of digital signatures > >> (btw, TESLA introduces further latencies at the receiver side and st= ill > >> requires digital signatures (for signing the head of the hash chains= )) > > TESLA is only mentioned as an option that may be possible. > > > > Best regards, > Michael > From owner-ipdvb@erg.abdn.ac.uk Tue Aug 15 15:12:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD4Kr-0007S1-39 for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 15:12:21 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD4Kq-0008Uq-EJ for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 15:12:21 -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 k7FIuGo1023489 for ; Tue, 15 Aug 2006 19:56:16 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7FIuGVs023488 for ipdvb-subscribed-users; Tue, 15 Aug 2006 19:56:16 +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 k7FIu1Db023467 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 15 Aug 2006 19:56:02 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.12442327; Tue, 15 Aug 2006 14:55:34 -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: RE: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt Date: Tue, 15 Aug 2006 14:55:33 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C1701792BE0@morse.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt Thread-Index: AcbAidubyBXIAB2uTcmVF0fDVWxJjAAEba1A From: "Allison, Art" To: X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id k7FIuGwD023485 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 k7FIuGo1023489 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd I remain unconvinced...so I guess will have leave it with acknowledging t= hat we assign different risk levels and disagree on the appropriateness o= f this solution. We will learn who was correct by the marketplace decidin= g to implement or not. Art _____________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N Street, NW Washington, D.C. 20036 Phone: 202.429.5418 Fax: 202.777.4981 aallison@nab.org The National Association of Broadcasters is a trade association that advo= cates on behalf of more than 8,300 free, local radio and television stati= ons and also broadcast networks before Congress, the Federal Communicatio= ns Commission and the Courts. -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On B= ehalf Of George Gross Sent: Tuesday, August 15, 2006 8:16 AM To: ipdvb@erg.abdn.ac.uk Subject: RE: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-= 03.txt Hi Art, On Mon, 14 Aug 2006, Allison, Art wrote: > > > I have not contributed my point of view in a long time, but the last=20 > line of this post prompts me to do so once again in hopes that some=20 > new participants will at least have more information about MPEG-2 TS=20 > and RF distribution. > > When the MPEG-2 TS ULE packets are delivered via an RF channel; be it=20 > over cable, satellite, or terrestrial; to succeed in an attack, the RF=20 > signal must be over powered. If the attacker can do that, they can=20 > replace the entire stream (or indeed they could receive the stream and=20 > selectively substitute some packets-but why?). One of the use cases for IPDVB is as an intra-company virtual LAN (e.g. several dozen SOHO distributed over a region). In this trust model, the I= P communications between peer LAN endpoints would normally be considered = reliable and they would not be authenticated or encrypted at the IP layer. Even if one did apply IPsec, this would negatively interact with PEP sess= ions. In this scenario, the Adversary's motivation is economic and depend= ent on the value of the company information that could be compromised by = eavesdropping or alteration. One could envision all kinds of mischief if an Adversary were able to int= ercept and alter those communications at the IPDVB Layer-2. So the "why" = is entirely up to the Adversary's game plan. > However, the risk > assessment should consider the practical difficulties and potential=20 > benefits of the attack mode. A mobile truck could indeed deny service=20 > to a small radius of terrestrial receivers, perhaps even to a smaller=20 > radius or satellite receivers, and a cable cut on a pole can wipe out=20 > an entire area. These attacks are difficult to mount and easy to=20 > detect and counter. The perceived difficulty of attack is an illusion, it would hardly deter = a well funded Adversary such as an organized crime family or a rogue nati= on state. All they'd need for motivation is either a high value target, o= r else a design a mobile wireless unit that would attack a number of lowe= r value targets. Expecting these victems to anticipate, detect, and count= er such attacks (especially when wireless), is optimistic. > If one is concerned about protection of the distribution link,=20 > [where the packets are themselves sent as part of an entire MPEG-2 TS=20 > using another protocol such as TCP or AVT], that seems better done by=20 > protecting the protocol delivering the entire set of packets, rather=20 > than within the packet. A more pragmatic security policy is defence in depth, in which every laye= r in the protocol stack participates in securing the application end to e= nd. Unfortunately, satellite communications that use PEP will have problems w= ith IPsec gateways at layer-3. In contrast, a layer-2 encryption and auth= entication protocol is transparent to PEP. Layer-2 encryption also has th= e benefit that the IP traffic temporarily transiting a satellite sub-netw= ork (i.e. terrestrial link fail-over) does not require the remote layer-3 endpoints to define security policies contingent on the change in= their IP packet's routing path. > And there is a long-defined method for protecting the entire contents=20 > of an MPEG-2 packet, independent of its payload (which can be employed=20 > on a PID by PID basis). We have already established on this list several months back that the PID= does not offer the fine granularity of key management needed to secure I= P over MPEG and ULE. > > I still see placing security at the ULE level as unneeded, even a=20 > 'poor' design choice, but having a standard to enable a solution=20 > should this design choice be made is perhaps better than not having=20 > one. As explained above, layer-2 security is hardly a "poor" design choice. Rather, it represents another tool in the MPEG-2 network operator's secur= ity toolchest. br, George > > Art > _____________ > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N Street, NW > Washington, D.C. 20036 > Phone: 202.429.5418 > Fax: 202.777.4981 > aallison@nab.org > > The National Association of Broadcasters is a trade association that ad= vocates on behalf of more than 8,300 free, local radio and television sta= tions and also broadcast networks before Congress, the Federal Communicat= ions Commission and the Courts. > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]=20 > On Behalf Of Michael Noisternig > Sent: Monday, August 14, 2006 5:51 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: WG/Authors Opinions please=20 > :draft-cruickshank-ipdvb-sec-req-03.txt > > Hello everyone, > > this is my first post here, so just a few words to introduce myself... > I'm a student of computer science and mathematics at the University of = Salzburg, and I've been working as a project assistent in the areas of UL= E and security for a couple of months now. I'm currently working on a dra= ft that is hopefully going to be released soon. > > I've read the current version of the ULE security requirements draft,=20 > and there are few things I want to comment on. The first thing is, it=20 > reads a lot better now than the last version I read (-01). :-) > > So here are my other comments: > > =A73.2, last paragraph: > - data integrity alone does not provide authentication > - the defence statement is oversimplifying and belongs to the=20 > requirements section > > =A73.3, threat cases 2 and 3: > one can distinguish between two other cases: > (a) insider attacks, i.e. active attacks from adverseries in the know o= f certain keys > -> protection against this attack requires source authentication=20 > (e.g. digitial signatures) > (b) outsider attacks, i.e. active attacks from outside of a VPN > -> in this case simple MACs are sufficient (i.e. group=20 > authentication) > > =A74: all the references to section 2 should be 3 > > =A74, security requirements list: > - instead of "ULE source authentication is required..." should more gen= erally say "integrity protection and authentication is required..." > - missing L2 ULE sender and receiver authentication (entitiy=20 > authentication) > > $4, other general requirements list: > - might mention requirement for policy management > - integrity of control messages (SI tables): as said before, what we=20 > want is authentication > > =A74, security requirements case 2: > - MACs do NOT provide source authentication for cases 2 and 3 (subcase=20 > (a)) > - if mentioning TESLA should first speak of digital signatures (btw,=20 > TESLA introduces further latencies at the receiver side and still=20 > requires digital signatures (for signing the head of the hash chains)) > > =A75, first paragraph, last sentence: > ...impact on bandwidth? > > =A75, last list item: > I don't see how the issue of address preservation is of relevance to th= e ULE scenario. AFAIK address preservation is important for correct routi= ng within multicast trees, but since in ULE networks data is simply sent = from one L2 point to the next I don't understand the problem. > > =A76.1, disadvantages: > third item should probably mean "Encryption of the MAC/NPA address is n= ot permitted in MPE systems." > > =A76.2: > - references to section 2 should be 3 > - information in first paragraph is redundant, i.e. already in the=20 > requirements section (section 4) > > =A77, second paragraph: > It should better read "There is an optional requirement for L2 authenti= cation and integrity assurance as well as protection against insertion of= other data into the ULE stream (i.e. replay attacks)." > > Gorry Fairhurst wrote: > > > > 2) Can we determine precisely what we man by a "Stream". Does a=20 > > Stream always only have ONE originating source? That is, does the=20 > > PID imply a specific intended source? > > It is my understanding that there can only be at most one designated se= nder per PID, basically due to multiple synchronization problems otherwis= e. However, this does not preclude the possibility of a sophisticated act= ive adversery injecting data on the same PID. > > Regards, > Michael Noisternig > > From owner-ipdvb@erg.abdn.ac.uk Tue Aug 15 17:30:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6U4-0000Jz-My for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 17:30:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD5QB-0005Sq-IH for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 16:21:55 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GD58N-0007SF-AG for ipdvb-archive@ietf.org; Tue, 15 Aug 2006 16:03:35 -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 k7FJka7K027596 for ; Tue, 15 Aug 2006 20:46:36 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7FJkaRU027595 for ipdvb-subscribed-users; Tue, 15 Aug 2006 20:46:36 +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 puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [141.201.2.23]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7FJkS8v027578 for ; Tue, 15 Aug 2006 20:46:28 +0100 (BST) Received: from [172.16.10.249] (83-64-176-129.alpenstrasse.xdsl-line.inode.at [83.64.176.129]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 4F41422833B for ; Tue, 15 Aug 2006 21:46:28 +0200 (CEST) Message-ID: <44E224C0.60303@cosy.sbg.ac.at> Date: Tue, 15 Aug 2006 21:47:12 +0200 From: Michael Noisternig User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hello George, thanks for commenting on this. See below. George Gross wrote: > Hi Michael, > > in looking over this thread, I think that there might be confusion about > which threat model is being assumed by you versus the one assumed by > Prashant. The group key management subsystem does the authentication and > authorization of the IPDVB group membership. The network's security policy > administrator decides what constitutes a group's membership and whether > there is an unacceptable risk of an insider attack that the group must be > defended against. > > For a basic security policy, group authentication is sufficient because > group members are trusted. Source authentication using digital signature > or TESLA is not required. In the event that the group's authentication key > is compromised then the scope of the damage is limited to only that group > rather than all groups sharing that MPEG TS. Limiting the size of each > group can help minimize this risk. > > For a security policy that considers an insider attack a risk, then source > authentication would be a reasonable mechanism to counter that > vulnerability. However, I have not heard on this list any use cases that > would need that service at layer-2. This is exactly what I was talking about. I am fully aware that insider attacks are more unlikely than attacks from outside a VPN (or virtual LAN, to stay with your terminology) within the ULE network, and that most will be fine with group authentication (i.e. MACs). (And there are good other reasons why one would want to stick with MACs.) I was just trying to point out that... > one can distinguish between two other cases: > (a) insider attacks, i.e. active attacks from adverseries in the know of > certain keys > -> protection against this attack requires source authentication > (e.g. digitial signatures) > (b) outsider attacks, i.e. active attacks from outside of a VPN > -> in this case simple MACs are sufficient (i.e. group authentication) > Michael, did you have such an example in mind for IPDVB? Yes, I was considering just another threat model in which MACs do not provide source authentication. I guess the authors of that draft have also considered that threat once because of mentioning TESLA. > > hth, > George Best regards, Michael From owner-ipdvb@erg.abdn.ac.uk Thu Aug 24 13:27:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIyq-0004O6-Pn for ipdvb-archive@ietf.org; Thu, 24 Aug 2006 13:27:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHKz-0003T2-7A for ipdvb-archive@ietf.org; Thu, 24 Aug 2006 11:41:45 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGHDx-00076g-LX for ipdvb-archive@ietf.org; Thu, 24 Aug 2006 11:34:30 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7OFFiI6007517 for ; Thu, 24 Aug 2006 16:15:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7OFFiCD007516 for ipdvb-subscribed-users; Thu, 24 Aug 2006 16:15: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 [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7OFFYr2007489 for ; Thu, 24 Aug 2006 16:15:35 +0100 (BST) Message-ID: <44EDC297.5050309@erg.abdn.ac.uk> Date: Thu, 24 Aug 2006 16:15:35 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: New rev of WG document following WGLC (draft-ietf-ipdvb-ar-05.txt) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.5 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da The Editors of the WG draft draft-ietf-ipdvb-ar have now completed the corrections that resulted from the WGLC and a new I-D will shortly be issued. A summary of the changes is provided below. The I-D will then be sent to the IESG with a request to publish as an Informational RFC. best wishes, Gorry and Marie-Jose. --- WG-05 (following WGLC) * Fixed security issues noted by George Gross. * Added text on Mobility, topology changes with AR cache. * To be consistent with RFC4326, NPA = ULA address indicated by the D-bit, whereas MAC means IEEE-style address. I've reworked the text to make this clearer. Also made all "NPA/MAC" into "MAC/NPA". * Added notes on AR caches when used in mobile/ST topology changes. * Also note a mistake to section (iii) which was confusing about L2 multicast addresses, this now reads: " (iii) IP and other protocols may view sets of L3 multicast addresses as link-local. This may produce unexpected results if frames with the corresponding multicast L2 addresses are distributed to systems in a different L3 network or multicast scope (see sections 3.2 and 5.6)" * Section 2, Added: MAC Address: A 6 byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA). * Section 3, Revised bullet into two points: A scalable architecture that may support large numbers of systems within the MPEG-2 network [RFC4259]. A method for transmission of AR information from an AR Server to clients that minimise the transmission cost (link local multicast, is preferable to subnet broadcast). * Section 3, changed "context" to "scope". * Section 4.3. Revised wording on T Stream v. TS Logical Channel. * Section 5.4. 2nd para, added (mapping the IP address to the L2 address) * Added: The default parameters specified in RFC 2461 for the ND protocol can introduce interoperability problems (e.g. a failure to resolve when the link RTT exceed 3 seconds) and performance degradation (duplicate ND messages with a link RTT > 1 second) when used in networks were the link RTT is significantly larger than experienced by Ethernet LANs. Tuning of the protocol parameters (e.g. RTR_SOLICITATION_INTERVAL) is therefore recommended when using network links with appreciable delay (Section 6.3.2 of [RFC2461]). --- From owner-ipdvb@erg.abdn.ac.uk Fri Aug 25 03:36:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGWF9-0005dd-Us for ipdvb-archive@ietf.org; Fri, 25 Aug 2006 03:36:43 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGWF9-0001GJ-Dk for ipdvb-archive@ietf.org; Fri, 25 Aug 2006 03:36:43 -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 k7P7MEv7014310 for ; Fri, 25 Aug 2006 08:22:14 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7P7MEOZ014309 for ipdvb-subscribed-users; Fri, 25 Aug 2006 08:22: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 [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7P7M4xE014295 for ; Fri, 25 Aug 2006 08:22:04 +0100 (BST) Message-ID: <44EEA51C.4070006@erg.abdn.ac.uk> Date: Fri, 25 Aug 2006 08:22:04 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION:draft-ietf-ipdvb-ar-05.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over DVB Working Group of the IETF. Title : Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks Author(s) : G. Fairhurst, M. Montpetit Filename : draft-ietf-ipdvb-ar-05.txt Pages : 0 Date : 2006-8-24 This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. The document reviews current methods appropriate to a range of technologies (DVB, ATSC, DOCSIS, and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol, and provides guidance on usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipdvb-ar-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipdvb-ar-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipdvb@erg.abdn.ac.uk Wed Aug 30 13:28:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GITrK-000464-Iq for ipdvb-archive@ietf.org; Wed, 30 Aug 2006 13:28:14 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GITcW-0007UL-MY for ipdvb-archive@ietf.org; Wed, 30 Aug 2006 13:12:58 -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 k7UGuiD1022446 for ; Wed, 30 Aug 2006 17:56:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7UGui5H022445 for ipdvb-subscribed-users; Wed, 30 Aug 2006 17:56: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 [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7UGuUv7022419; Wed, 30 Aug 2006 17:56:30 +0100 (BST) Message-ID: <44F5C33F.9000202@erg.abdn.ac.uk> Date: Wed, 30 Aug 2006 17:56:31 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk, P.Pillai@Bradford.ac.uk, mnoist@cosy.sbg.ac.at CC: "S.Iyengar" Subject: Trying to find words to describe how PIDs are used..... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Repost: My last posting to the list seemed to have gone astray, so I shall try an updated repost. I was trying to use some of the email from others to propose some text that answered the second set of questions. > 2) Can we determine precisely what we man by a "Stream". > Does a Stream always only have ONE originating source? > That is, does the PID imply a specific intended source? Here is some draft text, that could perhaps be placed at the end of section 3.2. I'd be very pleased to receive comments/corrections so we converge on some good description of this, since I think this relates directly to the need for authentication. THOUGHTS??? Comments and corrections please... Best wishes, Gorry ---- In a MPEG-2 Transmission network, the originating source of MPEG-2 TS Packets is either a L2 interface device (media encoder, encapsulation gateway, etc) or a L2 network device (TS multiplexor, etc). These devices may, but do not necessarily, have an associated IP address. In the case of an encapsulation gateway (e.g. ULE sender), the device may operate at L2 or L3, and is not normally the originator of an IP traffic flow, and usually the IP source address of the packets that it forwards do not correspond to an IP address associated with the device. When authentication of the IP source is required this must be provided by IPsec, TLS, etc. operating at a higher layer. The TS Packets are carried to the Receiver over a physical layer that usually includes Forward Error Correction and synchronisation processing that makes injection of single TS Packets very difficult. Replacement of a sequence of packets is difficult, but possible. Each Receiver needs to identify a TS Logical Channel (or MPEG-2 Stream) to reassemble the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this association is made via the Packet Identifier, PID [ISO-MPEG]. At the sender, each source associates a locally unique set of PID values with each stream it originates. However, there is no required relationship between the PID value used at the sender and that received at the Receiver. Network devices may re-number the PID values associated with one or more TS Logical Channels (Streams) to prevent clashes at a multiplexor between input Streams with the same PID carried on different input multiplexes. A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by PID value). The Stream of TS Packets carried in a multiplex are usually received by many Receivers. One method is to secure the entire Stream at teh MPEG-2 TS level. This approach is well-suited to TV-transmission, data-push, etc, where the PID carries one or a set of flows with similar security requirements. Where the Stream carries a set of IP traffic flows to different destinations with a range of properties (multicast, unicast, etc) this it is often not appropriate to provide IP confidentiality services for the entire Stream. A finer-grain control is required that at least allows control to the level of a single MAC/NPA address. However, there is only one valid source of data for each MPEG-2 Stream (i.e. PID). Although an attacker that is able to modify the content of the received multiplex (e.g. replay data) could inject data locally with an arbitrary PID value. --- From owner-ipdvb@erg.abdn.ac.uk Wed Aug 30 14:50:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIV8q-0004FI-9L for ipdvb-archive@ietf.org; Wed, 30 Aug 2006 14:50:24 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIV8p-0007re-ON for ipdvb-archive@ietf.org; Wed, 30 Aug 2006 14:50:24 -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 k7UIVOph029591 for ; Wed, 30 Aug 2006 19:31:24 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7UIVObS029590 for ipdvb-subscribed-users; Wed, 30 Aug 2006 19:31: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 nab.org (foxtrot.nab.org [209.116.240.194]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7UIV8Nb029572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 30 Aug 2006 19:31:09 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.12817065; Wed, 30 Aug 2006 14:30:51 -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="us-ascii" Subject: RE: Trying to find words to describe how PIDs are used..... Date: Wed, 30 Aug 2006 14:30:51 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C1701792C6F@morse.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trying to find words to describe how PIDs are used..... Thread-Index: AcbMWfcd6dbq0MlvSAmyX/FZfv6vHgAAhQ6g From: "Allison, Art" To: , , Cc: "S.Iyengar" X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id k7UIVOAS029587 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: 6640e3bbe8a4d70c4469bcdcbbf0921d Well, indeed it is important to define terms. At the top level; per 13818-1, there are Program Streams and Transport Streams. First, put aside Program Streams. (From 13818-1:"The Program Stream is designed for use in relatively error-free environments and is suitable for applications which may involve software processing of system information such as interactive multi-media applications. Program Stream packets may be of variable and relatively great length.") Continuing from 13818-1: "The Transport Stream combines one or more programs with one or more independent time bases into a single stream. PES packets made up of elementary streams that form a program share a common timebase. The Transport Stream is designed for use in environments where errors are likely, such as storage or transmission in lossy or noisy media. Transport Stream packets are 188 bytes in length." A Packetized Elementary stream can be constructed from a continuous sequence of PES packets of one elementary stream with one stream ID. So 'MPEG-2 Stream' is indeed ambiguous in meaning. Notwithstanding the mental discord, I attempted modifications in below demarked by // _____________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N Street, NW Washington, D.C. 20036 Phone: 202.429.5418 Fax: 202.777.4981 aallison@nab.org The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts. -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Gorry Fairhurst Sent: Wednesday, August 30, 2006 12:57 PM To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; mnoist@cosy.sbg.ac.at Cc: S.Iyengar Subject: Trying to find words to describe how PIDs are used..... Repost: My last posting to the list seemed to have gone astray, so I shall try an updated repost. I was trying to use some of the email from others to propose some text that answered the second set of questions. > 2) Can we determine precisely what we man by a "Stream". //AA>I think a modifier should always be used as this word is overloaded and usage here does not directly map to MPEG-2 systems.// > Does a Stream always only have ONE originating source? //AA>I think that is so... if not then the meaning is lost on me.// > That is, does the PID imply a specific intended source? //AA>No, because as you cover below, these PIDs are ephemeral and changeable by any multiplexer. If the PID is anounced in a PMT, it can change with each PMT section, although typically it does not.// Here is some draft text, that could perhaps be placed at the end of section 3.2. I'd be very pleased to receive comments/corrections so we converge on some good description of this, since I think this relates directly to the need for authentication. THOUGHTS??? Comments and corrections please... Best wishes, Gorry ---- In a MPEG-2 Transmission network, the originating source of MPEG-2 TS Packets is either a L2 interface device (media encoder, encapsulation gateway, etc) or a L2 network device (TS multiplexor, etc). These devices may, but do not necessarily, have an associated IP address. In the case of an encapsulation gateway (e.g. ULE sender), the device may operate at L2 or L3, and is not normally the originator of an IP traffic flow, and usually the IP source address of the packets that it forwards do not correspond to an IP address associated with the device. When authentication of the IP source is required this must be provided by IPsec, TLS, etc. operating at a higher layer. The TS Packets are carried to the Receiver over a physical layer that usually includes Forward Error Correction //(which can time shift data by interleaving data from multiple unrelated TS packets)// and synchronisation processing that makes injection of single TS Packets very difficult. Replacement of a sequence of packets is difficult, but possible. Each Receiver needs to identify a TS Logical Channel (or MPEG-2 //Elementary// Stream) to reassemble the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this association is made via the Packet Identifier, PID [ISO-MPEG]. At the sender, each source associates a locally unique set of PID values with each stream it originates. However, there is no required relationship between the PID value used at the sender and that received at the Receiver. Network devices may re-number the PID values associated with one or more TS Logical Channels (Streams) to prevent clashes at a multiplexor between input Streams with the same PID carried on different input multiplexes //(updating the PMT[ISO-MPEG] if the data is reference in such)//. A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by PID value). The Stream of TS Packets carried in a multiplex are usually received by many Receivers. One method is to secure the entire Stream at the MPEG-2 TS level. This approach is well-suited to TV-transmission, data-push, etc, where the PID carries one or a set of flows with similar security requirements. Where the Stream carries a set of IP traffic flows to different destinations with a range of properties (multicast, unicast, etc) this it is often not appropriate to provide IP confidentiality services for the entire Stream. A finer-grain control is required that at least allows control to the level of a single MAC/NPA address. However, there is only one valid source of data for each MPEG-2 //Elementary// Stream (i.e. PID) //for some duration//. //The duration may be only until the next PMT arrives in some systems. It may be until the next annuncement/discovery data is received in other systems.// Although an attacker that is able to modify the content of the received multiplex (e.g. replay data) could inject data locally with an arbitrary PID value. --- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 31 05:16:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIieW-0003Fh-L8 for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 05:16:00 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIieV-00006u-UY for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 05:16: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 k7V90sK6027167 for ; Thu, 31 Aug 2006 10:00:54 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7V90sFH027166 for ipdvb-subscribed-users; Thu, 31 Aug 2006 10:00: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 [139.133.207.155] (dhcp-207-155.erg.abdn.ac.uk [139.133.207.155]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7V902Im026805; Thu, 31 Aug 2006 10:00:02 +0100 (BST) Message-ID: <44F6A514.20705@erg.abdn.ac.uk> Date: Thu, 31 Aug 2006 10:00:04 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk, P.Pillai@Bradford.ac.uk, mnoist@cosy.sbg.ac.at, S.Iyengar@surrey.ac.uk, AAllison@nab.org Subject: Re: Trying to find words to describe how PIDs are used..... References: <33CB4DEADE8C734CAF59FA0B47E14C1701792C6F@morse.NAB.ORG> In-Reply-To: <33CB4DEADE8C734CAF59FA0B47E14C1701792C6F@morse.NAB.ORG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Thanks Art, I think the only way to make sure people understand is to get the language correct. While I was trying to be precise on the security aspects, my language got a little loose again, sorry. I agree with all you say, we should remember the context of an IP over ULE Stream which serves a (large) community of Receivers... and the document should be clear on this from the start. I've incorporated your corrections, and a few more to tighten this up, do people think this is better? Gorry ---- Perhaps it may better to preface the introduction with something better text, e.g. replacing it with?: OLD: Abstract This document provides a threat analysis and derives security requirements for MPEG-2 transmission links using the Unidirectional Lightweight Encapsulation (ULE). It also provides the motivation for ULE link-level security. This work is intended as a work item of the ipdvb WG, and contributions are sought from the IETF on this topic. SUGGESTION? Abstract The MPEG-2 standard defined by ISO 13818-1 [ref] supports a range of transmission methods for a range of services. This document examines the provides a threat analysis and derives security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The document also provides the motivation for link-level security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. --- Suggestion to add text to 3.2 (although on re-reading, perhaps adding something like this in 3.1 befor the final paragraph of the section, is a better place??): In a MPEG-2 TS transmission network, the originating source of TS Packets is either a L2 interface device (media encoder, encapsulation gateway, etc) or a L2 network device (TS multiplexor, etc). These devices may, but do not necessarily, have an associated IP address. In the case of an encapsulation gateway (e.g. ULE sender), the device may operate at L2 or L3, and is not normally the originator of an IP traffic flow, and usually the IP source address of the packets that it forwards do not correspond to an IP address associated with the device. When authentication of the IP source is required this must be provided by IPsec, TLS, etc. operating at a higher layer. The TS Packets are carried to the Receiver over a physical layer that usually includes Forward Error Correction coding that interleaves the bytes of several consecutive, but unrelated, TS Packets. FEC coding and synchronisation processing makes injection of single TS Packets very difficult. Replacement of a sequence of packets is also difficult, but possible (see section 3.2). A Receiver in a MPEG-2 TS transmission network needs to identify a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this association is made via the Packet Identifier, PID [ISO-MPEG]. At the sender, each source associates a locally unique set of PID values with each stream it originates. However, there is no required relationship between the PID value used at the sender and that received at the Receiver. Network devices may re-number the PID values associated with one or more TS Logical Channels (e.g. ULE Streams) to prevent clashes at a multiplexor between input streams with the same PID carried on different input multiplexes (updating entries in the PMT [ISO-MPEG], and other SI tables that reference the PID value). A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by their PID value). The PID associated with an Elementary Stream can be modified (e.g. in some systems by reception of an updated SI table, or in other systems until the next annuncement/discovery data is received). An attacker that is able to modify the content of the received multiplex (e.g. replay data and/or control information) could inject data locally into the received stream with an arbitrary PID value. One method to provide security is to secure the entire Stream at the MPEG-2 TS level. This stream of TS Packets carried in a multiplex are usually received by many Receivers. The approach is well-suited to TV-transmission, data-push, etc, where the PID carries one or a set of flows (e.g. video/audio Packetized Elementary Stream (PES) Packets) with similar security requirements. Where a ULE Stream carries a set of IP traffic flows to different destinations with a range of properties (multicast, unicast, etc), it is often not appropriate to provide IP confidentiality services for the entire ULE Stream. For many expected applications of ULE, a finer-grain control is therefore required, at least permitting control of data confidentiality/authorisation at the level of a single MAC/NPA address. However there is only one valid source of data for each MPEG-2 Elementary Stream, bound to a PID value. This observation could simplify the requirement for authentication of the source of a ULE Stream. --- Allison, Art wrote: > Well, indeed it is important to define terms. > At the top level; per 13818-1, there are Program Streams and Transport > Streams. > First, put aside Program Streams. (From 13818-1:"The Program Stream is > designed for use in relatively error-free environments and is suitable > for applications which may involve software processing of system > information such as interactive multi-media applications. Program Stream > packets may be of variable and relatively great length.") > Continuing from 13818-1: > "The Transport Stream combines one or more programs with one or more > independent time bases into a single stream. PES packets made up of > elementary streams that form a program share a common timebase. The > Transport Stream is designed for use in environments where errors are > likely, such as storage or transmission in lossy or noisy media. > Transport Stream packets are 188 bytes in length." > > A Packetized Elementary stream can be constructed from a continuous > sequence of PES packets of one elementary stream with one stream ID. > > So 'MPEG-2 Stream' is indeed ambiguous in meaning. > Notwithstanding the mental discord, I attempted modifications in > below demarked by // > > > > _____________ > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N Street, NW > Washington, D.C. 20036 > Phone: 202.429.5418 > Fax: 202.777.4981 > aallison@nab.org > > The National Association of Broadcasters is a trade association that > advocates on behalf of more than 8,300 free, local radio and television > stations and also broadcast networks before Congress, the Federal > Communications Commission and the Courts. > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On > Behalf Of Gorry Fairhurst > Sent: Wednesday, August 30, 2006 12:57 PM > To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; mnoist@cosy.sbg.ac.at > Cc: S.Iyengar > Subject: Trying to find words to describe how PIDs are used..... > > > Repost: My last posting to the list seemed to have gone astray, so I > shall try an updated repost. > > I was trying to use some of the email from others to propose some text > that answered the second set of questions. > > > 2) Can we determine precisely what we man by a "Stream". > //AA>I think a modifier should always be used as this word is overloaded > and usage here does not directly map to MPEG-2 systems.// > > Does a Stream always only have ONE originating source? > //AA>I think that is so... if not then the meaning is lost on me.// > > That is, does the PID imply a specific intended source? > //AA>No, because as you cover below, these PIDs are ephemeral and > changeable by any multiplexer. > If the PID is anounced in a PMT, it can change with each PMT section, > although typically it does not.// > Here is some draft text, that could perhaps be placed at the end of > section 3.2. I'd be very pleased to receive comments/corrections so we > converge on some good description of this, since I think this relates > directly to the need for authentication. > > THOUGHTS??? Comments and corrections please... > > Best wishes, > > Gorry > > > ---- > > In a MPEG-2 Transmission network, the originating source of MPEG-2 TS > Packets is either a L2 interface device (media encoder, encapsulation > gateway, etc) or a L2 network device (TS multiplexor, etc). These > devices may, but do not necessarily, have an associated IP address. In > the case of an encapsulation gateway (e.g. ULE sender), the device may > operate at L2 or L3, and is not normally the originator of an IP traffic > flow, and usually the IP source address of the packets that it forwards > do not correspond to an IP address associated with the device. When > authentication of the IP source is required this must be provided by > IPsec, TLS, etc. operating at a higher layer. > > The TS Packets are carried to the Receiver over a physical layer that > usually includes Forward Error Correction //(which can time shift data > by interleaving data from multiple unrelated TS packets)// and > synchronisation processing that makes injection of single TS Packets > very difficult. Replacement of a sequence of packets is difficult, but > possible. > > Each Receiver needs to identify a TS Logical Channel (or MPEG-2 > //Elementary// Stream) to reassemble the fragments of PDUs sent by a L2 > source [RFC4259]. In an > MPEG-2 TS, this association is made via the Packet Identifier, PID > [ISO-MPEG]. At the sender, each source associates a locally unique set > of PID values with each stream it originates. However, there is no > required relationship between the PID value used at the sender and that > received at the Receiver. Network devices may re-number the PID values > associated with one or more TS Logical Channels (Streams) to prevent > clashes at a multiplexor between input Streams with the same PID carried > on different input multiplexes //(updating the PMT[ISO-MPEG] if the data > is reference in such)//. A device may also modify and/or insert new SI > data into the control plane (also sent as TS Packets identified by PID > value). > > The Stream of TS Packets carried in a multiplex are usually received by > many Receivers. One method is to secure the entire Stream at the MPEG-2 > TS level. This approach is well-suited to TV-transmission, data-push, > etc, where the PID carries one or a set of flows with similar security > requirements. Where the Stream carries a set of IP traffic flows to > different destinations with a range of properties (multicast, unicast, > etc) this it is often not appropriate to provide IP confidentiality > services for the entire Stream. A finer-grain control is required that > at least allows control to the level of a single MAC/NPA address. > However, there is only one valid source of data for each MPEG-2 > //Elementary// Stream (i.e. PID) //for some duration//. //The duration > may be only until the next PMT arrives in some systems. It may be until > the next annuncement/discovery data is received in other systems.// > Although an attacker that is able to modify the content of the received > multiplex (e.g. replay data) could inject data locally with an arbitrary > PID value. > > --- > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 31 08:52:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIm1e-0007YA-2s for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 08:52:06 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIm1b-0001k6-8B for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 08:52:06 -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 k7VCW4So016492 for ; Thu, 31 Aug 2006 13:32:04 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7VCW454016491 for ipdvb-subscribed-users; Thu, 31 Aug 2006 13:32:04 +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 k7VCTI4Q014775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 31 Aug 2006 13:29:19 +0100 (BST) Received: from ([199.29.3.25]) by maildc2.nab.org with ESMTP id 4028857.12836554; Thu, 31 Aug 2006 08:28:56 -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="us-ascii" Subject: RE: Trying to find words to describe how PIDs are used..... Date: Thu, 31 Aug 2006 08:28:56 -0400 Message-ID: <33CB4DEADE8C734CAF59FA0B47E14C1701792C73@morse.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trying to find words to describe how PIDs are used..... Thread-Index: AcbM3ATC9e9/PfJoQuaamcdp6A2h8AAHPGFQ From: "Allison, Art" To: , , , X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id k7VCUVuY015756 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: 025f8c5000216988bfe31585db759250 Much better.. Good even. Art _____________ Art Allison Director, Advanced Engineering Science & Technology National Association of Broadcasters 1771 N Street, NW Washington, D.C. 20036 Phone: 202.429.5418 Fax: 202.777.4981 aallison@nab.org The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts. -----Original Message----- From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Thursday, August 31, 2006 5:00 AM To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; mnoist@cosy.sbg.ac.at; S.Iyengar@surrey.ac.uk; Allison, Art Subject: Re: Trying to find words to describe how PIDs are used..... Thanks Art, I think the only way to make sure people understand is to get the language correct. While I was trying to be precise on the security aspects, my language got a little loose again, sorry. I agree with all you say, we should remember the context of an IP over ULE Stream which serves a (large) community of Receivers... and the document should be clear on this from the start. I've incorporated your corrections, and a few more to tighten this up, do people think this is better? Gorry ---- Perhaps it may better to preface the introduction with something better text, e.g. replacing it with?: OLD: Abstract This document provides a threat analysis and derives security requirements for MPEG-2 transmission links using the Unidirectional Lightweight Encapsulation (ULE). It also provides the motivation for ULE link-level security. This work is intended as a work item of the ipdvb WG, and contributions are sought from the IETF on this topic. SUGGESTION? Abstract The MPEG-2 standard defined by ISO 13818-1 [ref] supports a range of transmission methods for a range of services. This document examines the provides a threat analysis and derives security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The document also provides the motivation for link-level security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. --- Suggestion to add text to 3.2 (although on re-reading, perhaps adding something like this in 3.1 befor the final paragraph of the section, is a better place??): In a MPEG-2 TS transmission network, the originating source of TS Packets is either a L2 interface device (media encoder, encapsulation gateway, etc) or a L2 network device (TS multiplexor, etc). These devices may, but do not necessarily, have an associated IP address. In the case of an encapsulation gateway (e.g. ULE sender), the device may operate at L2 or L3, and is not normally the originator of an IP traffic flow, and usually the IP source address of the packets that it forwards do not correspond to an IP address associated with the device. When authentication of the IP source is required this must be provided by IPsec, TLS, etc. operating at a higher layer. The TS Packets are carried to the Receiver over a physical layer that usually includes Forward Error Correction coding that interleaves the bytes of several consecutive, but unrelated, TS Packets. FEC coding and synchronisation processing makes injection of single TS Packets very difficult. Replacement of a sequence of packets is also difficult, but possible (see section 3.2). A Receiver in a MPEG-2 TS transmission network needs to identify a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this association is made via the Packet Identifier, PID [ISO-MPEG]. At the sender, each source associates a locally unique set of PID values with each stream it originates. However, there is no required relationship between the PID value used at the sender and that received at the Receiver. Network devices may re-number the PID values associated with one or more TS Logical Channels (e.g. ULE Streams) to prevent clashes at a multiplexor between input streams with the same PID carried on different input multiplexes (updating entries in the PMT [ISO-MPEG], and other SI tables that reference the PID value). A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by their PID value). The PID associated with an Elementary Stream can be modified (e.g. in some systems by reception of an updated SI table, or in other systems until the next annuncement/discovery data is received). An attacker that is able to modify the content of the received multiplex (e.g. replay data and/or control information) could inject data locally into the received stream with an arbitrary PID value. One method to provide security is to secure the entire Stream at the MPEG-2 TS level. This stream of TS Packets carried in a multiplex are usually received by many Receivers. The approach is well-suited to TV-transmission, data-push, etc, where the PID carries one or a set of flows (e.g. video/audio Packetized Elementary Stream (PES) Packets) with similar security requirements. Where a ULE Stream carries a set of IP traffic flows to different destinations with a range of properties (multicast, unicast, etc), it is often not appropriate to provide IP confidentiality services for the entire ULE Stream. For many expected applications of ULE, a finer-grain control is therefore required, at least permitting control of data confidentiality/authorisation at the level of a single MAC/NPA address. However there is only one valid source of data for each MPEG-2 Elementary Stream, bound to a PID value. This observation could simplify the requirement for authentication of the source of a ULE Stream. --- Allison, Art wrote: > Well, indeed it is important to define terms. > At the top level; per 13818-1, there are Program Streams and Transport > Streams. > First, put aside Program Streams. (From 13818-1:"The Program Stream is > designed for use in relatively error-free environments and is suitable > for applications which may involve software processing of system > information such as interactive multi-media applications. Program > Stream packets may be of variable and relatively great length.") > Continuing from 13818-1: > "The Transport Stream combines one or more programs with one or more > independent time bases into a single stream. PES packets made up of > elementary streams that form a program share a common timebase. The > Transport Stream is designed for use in environments where errors are > likely, such as storage or transmission in lossy or noisy media. > Transport Stream packets are 188 bytes in length." > > A Packetized Elementary stream can be constructed from a continuous > sequence of PES packets of one elementary stream with one stream ID. > > So 'MPEG-2 Stream' is indeed ambiguous in meaning. > Notwithstanding the mental discord, I attempted modifications in > below demarked by // > > > > _____________ > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N Street, NW > Washington, D.C. 20036 > Phone: 202.429.5418 > Fax: 202.777.4981 > aallison@nab.org > > The National Association of Broadcasters is a trade association that > advocates on behalf of more than 8,300 free, local radio and > television stations and also broadcast networks before Congress, the > Federal Communications Commission and the Courts. > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] > On Behalf Of Gorry Fairhurst > Sent: Wednesday, August 30, 2006 12:57 PM > To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; > mnoist@cosy.sbg.ac.at > Cc: S.Iyengar > Subject: Trying to find words to describe how PIDs are used..... > > > Repost: My last posting to the list seemed to have gone astray, so I > shall try an updated repost. > > I was trying to use some of the email from others to propose some text > that answered the second set of questions. > > > 2) Can we determine precisely what we man by a "Stream". > //AA>I think a modifier should always be used as this word is > overloaded and usage here does not directly map to MPEG-2 systems.// > > Does a Stream always only have ONE originating source? > //AA>I think that is so... if not then the meaning is lost on me.// > > That is, does the PID imply a specific intended source? > //AA>No, because as you cover below, these PIDs are ephemeral and > changeable by any multiplexer. > If the PID is anounced in a PMT, it can change with each PMT section, > although typically it does not.// Here is some draft text, that could > perhaps be placed at the end of section 3.2. I'd be very pleased to > receive comments/corrections so we converge on some good description > of this, since I think this relates directly to the need for > authentication. > > THOUGHTS??? Comments and corrections please... > > Best wishes, > > Gorry > > > ---- > > In a MPEG-2 Transmission network, the originating source of MPEG-2 TS > Packets is either a L2 interface device (media encoder, encapsulation > gateway, etc) or a L2 network device (TS multiplexor, etc). These > devices may, but do not necessarily, have an associated IP address. In > the case of an encapsulation gateway (e.g. ULE sender), the device may > operate at L2 or L3, and is not normally the originator of an IP > traffic flow, and usually the IP source address of the packets that it > forwards do not correspond to an IP address associated with the > device. When authentication of the IP source is required this must be > provided by IPsec, TLS, etc. operating at a higher layer. > > The TS Packets are carried to the Receiver over a physical layer that > usually includes Forward Error Correction //(which can time shift data > by interleaving data from multiple unrelated TS packets)// and > synchronisation processing that makes injection of single TS Packets > very difficult. Replacement of a sequence of packets is difficult, but > possible. > > Each Receiver needs to identify a TS Logical Channel (or MPEG-2 > //Elementary// Stream) to reassemble the fragments of PDUs sent by a > L2 source [RFC4259]. In an > MPEG-2 TS, this association is made via the Packet Identifier, PID > [ISO-MPEG]. At the sender, each source associates a locally unique set > of PID values with each stream it originates. However, there is no > required relationship between the PID value used at the sender and > that received at the Receiver. Network devices may re-number the PID > values associated with one or more TS Logical Channels (Streams) to > prevent clashes at a multiplexor between input Streams with the same > PID carried on different input multiplexes //(updating the > PMT[ISO-MPEG] if the data is reference in such)//. A device may also > modify and/or insert new SI data into the control plane (also sent as > TS Packets identified by PID value). > > The Stream of TS Packets carried in a multiplex are usually received > by many Receivers. One method is to secure the entire Stream at the > MPEG-2 TS level. This approach is well-suited to TV-transmission, > data-push, etc, where the PID carries one or a set of flows with > similar security requirements. Where the Stream carries a set of IP > traffic flows to different destinations with a range of properties > (multicast, unicast, > etc) this it is often not appropriate to provide IP confidentiality > services for the entire Stream. A finer-grain control is required that > at least allows control to the level of a single MAC/NPA address. > However, there is only one valid source of data for each MPEG-2 > //Elementary// Stream (i.e. PID) //for some duration//. //The duration > may be only until the next PMT arrives in some systems. It may be > until the next annuncement/discovery data is received in other > systems.// Although an attacker that is able to modify the content of > the received multiplex (e.g. replay data) could inject data locally > with an arbitrary PID value. > > --- > From owner-ipdvb@erg.abdn.ac.uk Thu Aug 31 11:40:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIoeo-0006Nh-Nm for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 11:40:43 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIoel-0002fQ-2K for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 11:40:42 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7VFF0Td016373 for ; Thu, 31 Aug 2006 16:15:00 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7VFExH4016371 for ipdvb-subscribed-users; Thu, 31 Aug 2006 16:14:59 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from ads40.surrey.ac.uk (ads40.surrey.ac.uk [131.227.102.140]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7VFAbvx015174 for ; Thu, 31 Aug 2006 16:10:37 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 16:10:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD0F.9AE7ED12" Subject: RE: Trying to find words to describe how PIDs are used..... Date: Thu, 31 Aug 2006 16:10:33 +0100 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD3FD@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trying to find words to describe how PIDs are used..... Thread-Index: AcbM2/ncNmdsnOEgQbe0KbEIf6YVNAAMoJQ1 From: To: , , , , X-OriginalArrivalTime: 31 Aug 2006 15:10:34.0298 (UTC) FILETIME=[9B7509A0:01C6CD0F] X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: ad21aece51aeebf80192250df67eab8a This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CD0F.9AE7ED12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gorry and Art, Thank you for the comments and valuable input. I agree with the fact = that the abstract should be reworded as mentioned below and that the = remaining text should come at the start of section 3 before 3.1 system = components. =20 Regards Sunny =20 *********************************************************** Sunil Iyengar, Research Fellow, Networks Group, Centre For Communication And Systems Research(CCSR), School of Electronics, Computing & Mathematics, University Of Surrey, Guildford GU2 7XH, Surrey, England, United Kingdom. Office: +44 (0)1483 686008 *********************************************************** ________________________________ From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] Sent: Thu 31/08/2006 10:00 To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; = mnoist@cosy.sbg.ac.at; Iyengar S Mr (CCSR); AAllison@nab.org Subject: Re: Trying to find words to describe how PIDs are used..... Thanks Art, I think the only way to make sure people understand is to get the language correct. While I was trying to be precise on the security aspects, my language got a little loose again, sorry. I agree with all you say, we should remember the context of an IP over ULE Stream which serves a (large) community of Receivers... and the document should be clear on this from the start. I've incorporated your corrections, and a few more to tighten this up, do people think this is better? Gorry ---- Perhaps it may better to preface the introduction with something better text, e.g. replacing it with?: OLD: Abstract This document provides a threat analysis and derives security requirements for MPEG-2 transmission links using the Unidirectional Lightweight Encapsulation (ULE). It also provides the motivation for ULE link-level security. This work is = intended as a work item of the ipdvb WG, and contributions are sought = from the IETF on this topic. SUGGESTION? Abstract The MPEG-2 standard defined by ISO 13818-1 [ref] supports a range of transmission methods for a range of services. This document examines the provides a threat analysis and derives security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The document also provides the motivation for link-level security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. --- Suggestion to add text to 3.2 (although on re-reading, perhaps adding something like this in 3.1 befor the final paragraph of the section, is a better place??): In a MPEG-2 TS transmission network, the originating source of TS Packets is either a L2 interface device (media encoder, encapsulation gateway, etc) or a L2 network device (TS multiplexor, etc). These devices may, but do not necessarily, have an associated IP address. In the case of an encapsulation gateway (e.g. ULE sender), the device may operate at L2 or L3, and is not normally the originator of an IP traffic flow, and usually the IP source address of the packets that it forwards do not correspond to an IP address associated with the device. When authentication of the IP source is required this must be provided by IPsec, TLS, etc. operating at a higher layer. The TS Packets are carried to the Receiver over a physical layer that usually includes Forward Error Correction coding that interleaves the bytes of several consecutive, but unrelated, TS Packets. FEC coding and synchronisation processing makes injection of single TS Packets very difficult. Replacement of a sequence of packets is also difficult, but possible (see section 3.2). A Receiver in a MPEG-2 TS transmission network needs to identify a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this association is made via the Packet Identifier, PID [ISO-MPEG]. At the sender, each source associates a locally unique set of PID values with each stream it originates. However, there is no required relationship between the PID value used at the sender and that received at the Receiver. Network devices may re-number the PID values associated with one or more TS Logical Channels (e.g. ULE Streams) to prevent clashes at a multiplexor between input streams with the same PID carried on different input multiplexes (updating entries in the PMT [ISO-MPEG], and other SI tables that reference the PID value). A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by their PID value). The PID associated with an Elementary Stream can be modified (e.g. in some systems by reception of an updated SI table, or in other systems until the next annuncement/discovery data is received). An attacker that is able to modify the content of the received multiplex (e.g. replay data and/or control information) could inject data locally into the received stream with an arbitrary PID value. One method to provide security is to secure the entire Stream at the MPEG-2 TS level. This stream of TS Packets carried in a multiplex are usually received by many Receivers. The approach is well-suited to TV-transmission, data-push, etc, where the PID carries one or a set of flows (e.g. video/audio Packetized Elementary Stream (PES) Packets) with similar security requirements. Where a ULE Stream carries a set of IP traffic flows to different destinations with a range of properties (multicast, unicast, etc), it is often not appropriate to provide IP confidentiality services for the entire ULE Stream. For many expected applications of ULE, a finer-grain control is therefore required, at least permitting control of data confidentiality/authorisation at the level of a single MAC/NPA address. However there is only one valid source of data for each MPEG-2 Elementary Stream, bound to a PID value. This observation could simplify the requirement for authentication of the source of a ULE = Stream. --- Allison, Art wrote: > Well, indeed it is important to define terms. > At the top level; per 13818-1, there are Program Streams and Transport > Streams. > First, put aside Program Streams. (From 13818-1:"The Program Stream is > designed for use in relatively error-free environments and is suitable > for applications which may involve software processing of system > information such as interactive multi-media applications. Program = Stream > packets may be of variable and relatively great length.") > Continuing from 13818-1: > "The Transport Stream combines one or more programs with one or more > independent time bases into a single stream. PES packets made up of > elementary streams that form a program share a common timebase. The > Transport Stream is designed for use in environments where errors are > likely, such as storage or transmission in lossy or noisy media. > Transport Stream packets are 188 bytes in length." > > A Packetized Elementary stream can be constructed from a continuous > sequence of PES packets of one elementary stream with one stream ID. > > So 'MPEG-2 Stream' is indeed ambiguous in meaning. > Notwithstanding the mental discord, I attempted modifications in > below demarked by // > > > > _____________ > Art Allison > Director, Advanced Engineering > Science & Technology > National Association of Broadcasters > 1771 N Street, NW > Washington, D.C. 20036 > Phone: 202.429.5418 > Fax: 202.777.4981 > aallison@nab.org > > The National Association of Broadcasters is a trade association that > advocates on behalf of more than 8,300 free, local radio and = television > stations and also broadcast networks before Congress, the Federal > Communications Commission and the Courts. > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] = On > Behalf Of Gorry Fairhurst > Sent: Wednesday, August 30, 2006 12:57 PM > To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; = mnoist@cosy.sbg.ac.at > Cc: S.Iyengar > Subject: Trying to find words to describe how PIDs are used..... > > > Repost: My last posting to the list seemed to have gone astray, so I > shall try an updated repost. > > I was trying to use some of the email from others to propose some text > that answered the second set of questions. > > > 2) Can we determine precisely what we man by a "Stream". > //AA>I think a modifier should always be used as this word is = overloaded > and usage here does not directly map to MPEG-2 systems.// > > Does a Stream always only have ONE originating source? > //AA>I think that is so... if not then the meaning is lost on me.// > > That is, does the PID imply a specific intended source? > //AA>No, because as you cover below, these PIDs are ephemeral and > changeable by any multiplexer. > If the PID is anounced in a PMT, it can change with each PMT section, > although typically it does not.// > Here is some draft text, that could perhaps be placed at the end of > section 3.2. I'd be very pleased to receive comments/corrections so we > converge on some good description of this, since I think this relates > directly to the need for authentication. > > THOUGHTS??? Comments and corrections please... > > Best wishes, > > Gorry > > > ---- > > In a MPEG-2 Transmission network, the originating source of MPEG-2 TS > Packets is either a L2 interface device (media encoder, encapsulation > gateway, etc) or a L2 network device (TS multiplexor, etc). These > devices may, but do not necessarily, have an associated IP address. In > the case of an encapsulation gateway (e.g. ULE sender), the device may > operate at L2 or L3, and is not normally the originator of an IP = traffic > flow, and usually the IP source address of the packets that it = forwards > do not correspond to an IP address associated with the device. When > authentication of the IP source is required this must be provided by > IPsec, TLS, etc. operating at a higher layer. > > The TS Packets are carried to the Receiver over a physical layer that > usually includes Forward Error Correction //(which can time shift data > by interleaving data from multiple unrelated TS packets)// and > synchronisation processing that makes injection of single TS Packets > very difficult. Replacement of a sequence of packets is difficult, but > possible. > > Each Receiver needs to identify a TS Logical Channel (or MPEG-2 > //Elementary// Stream) to reassemble the fragments of PDUs sent by a = L2 > source [RFC4259]. In an > MPEG-2 TS, this association is made via the Packet Identifier, PID > [ISO-MPEG]. At the sender, each source associates a locally unique set > of PID values with each stream it originates. However, there is no > required relationship between the PID value used at the sender and = that > received at the Receiver. Network devices may re-number the PID = values > associated with one or more TS Logical Channels (Streams) to prevent > clashes at a multiplexor between input Streams with the same PID = carried > on different input multiplexes //(updating the PMT[ISO-MPEG] if the = data > is reference in such)//. A device may also modify and/or insert new = SI > data into the control plane (also sent as TS Packets identified by PID > value). > > The Stream of TS Packets carried in a multiplex are usually received = by > many Receivers. One method is to secure the entire Stream at the = MPEG-2 > TS level. This approach is well-suited to TV-transmission, data-push, > etc, where the PID carries one or a set of flows with similar security > requirements. Where the Stream carries a set of IP traffic flows to > different destinations with a range of properties (multicast, unicast, > etc) this it is often not appropriate to provide IP confidentiality > services for the entire Stream. A finer-grain control is required that > at least allows control to the level of a single MAC/NPA address. > However, there is only one valid source of data for each MPEG-2 > //Elementary// Stream (i.e. PID) //for some duration//. //The duration > may be only until the next PMT arrives in some systems. It may be = until > the next annuncement/discovery data is received in other systems.// > Although an attacker that is able to modify the content of the = received > multiplex (e.g. replay data) could inject data locally with an = arbitrary > PID value. > > --- > ------_=_NextPart_001_01C6CD0F.9AE7ED12 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: Trying to find words to describe how PIDs are = used.....=0A= =0A= =0A=
=0A=
Hi Gorry and =0A= Art,
=0A=
Thank you for the comments = and valuable =0A= input. I agree with the fact that the abstract should be reworded as = mentioned =0A= below and that the remaining text should come at the start of section 3 = before =0A= 3.1 system components.
=0A=
 
=0A=
Regards
=0A=
Sunny
=0A=
 
=0A=
=0A=
***********************************************************
S= unil =0A= Iyengar,
Research Fellow, Networks Group,
Centre For Communication = And =0A= Systems Research(CCSR),
School of Electronics, Computing & =0A= Mathematics,
University Of Surrey, Guildford GU2 7XH,
Surrey, = England, =0A= United Kingdom.
Office: +44 (0)1483 =0A= 686008
***********************************************************
=
=0A=

=0A=
=0A= From: Gorry Fairhurst =0A= [mailto:gorry@erg.abdn.ac.uk]
Sent: Thu 31/08/2006 = 10:00
To: =0A= ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; mnoist@cosy.sbg.ac.at; = Iyengar S =0A= Mr (CCSR); AAllison@nab.org
Subject: Re: Trying to find words = to =0A= describe how PIDs are used.....

=0A=
=0A=

Thanks Art,

I think the only way to make sure = people =0A= understand is to get the
language correct. While I was trying to be = precise =0A= on the security
aspects, my language got a little loose again, =0A= sorry.

I agree with all you say, we should remember the context = of an IP =0A= over
ULE Stream which serves a (large) community of Receivers... and =0A= the
document should be clear on this from the start. I've = incorporated =0A= your
corrections, and a few more to tighten this up, do people think = this =0A= is
  better?

Gorry


----

Perhaps it may = better =0A= to preface the introduction with something better
text, e.g. = replacing it =0A= with?:

OLD:
Abstract

      = ;  =0A= This document provides a threat analysis and derives =0A= security
        requirements for = MPEG-2 =0A= transmission links using = the
        =0A= Unidirectional Lightweight Encapsulation (ULE). It also =0A= provides
        the motivation = for ULE =0A= link-level security. This work is =0A= intended
        as a work item of = the =0A= ipdvb WG, and contributions are sought =0A= from
        the IETF on this =0A= topic.

SUGGESTION?

Abstract

The MPEG-2 standard = defined by =0A= ISO 13818-1 [ref] supports a range of
transmission methods for a = range of =0A= services. This document examines the
provides a threat analysis and = derives =0A= security requirements when using
the Transport Stream, TS, to support = an =0A= Internet network-layer using
Unidirectional Lightweight Encapsulation = (ULE), =0A= RFC 4326. The document
also provides the motivation for link-level = security =0A= for a ULE Stream. A
ULE Stream may be used to send IPv4 packets, IPv6 =0A= packets, and other
Protocol Data Units (PDUs) to an arbitrarily large = number =0A= of Receivers
supporting unicast and/or multicast =0A= transmission.

---

Suggestion to add text to 3.2 (although = on =0A= re-reading, perhaps adding
something like this in 3.1 befor the final =0A= paragraph of the section, is
a better place??):

In a MPEG-2 TS =0A= transmission network, the originating source of TS
Packets is either = a L2 =0A= interface device (media encoder, encapsulation
gateway, etc) or a L2 = network =0A= device (TS multiplexor, etc). These
devices may, but do not = necessarily, have =0A= an associated IP address. In
the case of an encapsulation gateway = (e.g. ULE =0A= sender), the device may
operate at L2 or L3, and is not normally the =0A= originator of an IP traffic
flow, and usually the IP source address = of the =0A= packets that it forwards
do not correspond to an IP address = associated with =0A= the device. When
authentication of the IP source is required this = must be =0A= provided by
IPsec, TLS, etc. operating at a higher layer.

The = TS =0A= Packets are carried to the Receiver over a physical layer = that
usually =0A= includes Forward Error Correction coding that interleaves the
bytes = of =0A= several consecutive, but unrelated, TS Packets. FEC coding =0A= and
synchronisation processing makes injection of single TS Packets =0A= very
difficult. Replacement of a sequence of packets is also = difficult, =0A= but
possible (see section 3.2).

A Receiver in a MPEG-2 TS = transmission =0A= network needs to identify a
TS Logical Channel (or MPEG-2 Elementary = Stream) =0A= to reassemble the
fragments of PDUs sent by a L2 source [RFC4259]. In = an =0A= MPEG-2 TS, this
association is made via the Packet Identifier, PID =0A= [ISO-MPEG]. At the
sender, each source associates a locally unique = set of PID =0A= values with
each stream it originates. However, there is no required =0A= relationship
between the PID value used at the sender and that = received at =0A= the
Receiver.  Network devices may re-number the PID values = associated =0A= with
one or more TS Logical Channels (e.g. ULE Streams) to prevent = clashes =0A= at
a multiplexor between input streams with the same PID carried =0A= on
different input multiplexes (updating entries in the PMT = [ISO-MPEG], =0A= and
other SI tables that reference the PID value).  A device may = also =0A= modify
and/or insert new SI data into the control plane (also sent as =0A= TS
Packets identified by their PID value).

The PID associated = with an =0A= Elementary Stream can be modified (e.g. in
some systems by reception = of an =0A= updated SI table, or in other systems
until the next = annuncement/discovery =0A= data is received).  An attacker
that is able to modify the = content of =0A= the received multiplex (e.g.
replay data and/or control information) = could =0A= inject data locally into
the received stream with an arbitrary PID =0A= value.

One method to provide security is to secure the entire = Stream at =0A= the
MPEG-2 TS level. This stream of TS Packets carried in a multiplex =0A= are
usually received by many Receivers. The approach is well-suited =0A= to
TV-transmission, data-push, etc, where the PID carries one or a = set =0A= of
flows (e.g. video/audio Packetized Elementary Stream (PES) = Packets) =0A= with
similar security requirements.

Where a ULE Stream carries = a set =0A= of IP traffic flows to different
destinations with a range of = properties =0A= (multicast, unicast, etc), it is
often not appropriate to provide IP =0A= confidentiality services for the
entire ULE Stream. For many expected =0A= applications of ULE, a finer-grain
control is therefore required, at = least =0A= permitting control of data
confidentiality/authorisation at the level = of a =0A= single MAC/NPA address.
However there is only one valid source of = data for =0A= each MPEG-2
Elementary Stream, bound to a  PID value. This = observation =0A= could
simplify the requirement for authentication of the source of a = ULE =0A= Stream.

---


Allison, Art wrote:

> Well, = indeed it is =0A= important to define terms.
> At the top level; per 13818-1, there = are =0A= Program Streams and Transport
> Streams.
> First, put aside = Program =0A= Streams. (From 13818-1:"The Program Stream is
> designed for use = in =0A= relatively error-free environments and is suitable
> for = applications =0A= which may involve software processing of system
> information such = as =0A= interactive multi-media applications. Program Stream
> packets may = be of =0A= variable and relatively great length.")
> Continuing from = 13818-1:
> =0A= "The Transport Stream combines one or more programs with one or = more
> =0A= independent time bases into a single stream. PES packets made up = of
> =0A= elementary streams that form a program share a common timebase. = The
> =0A= Transport Stream is designed for use in environments where errors = are
> =0A= likely, such as storage or transmission in lossy or noisy media.
> =0A= Transport Stream packets are 188 bytes in length."
>
> A = Packetized =0A= Elementary stream can be constructed from a continuous
> sequence = of PES =0A= packets of one elementary stream with one stream ID.
>
> So = 'MPEG-2 =0A= Stream' is indeed ambiguous in meaning.
> Notwithstanding the = mental =0A= discord, I attempted modifications in
> <yourspeak> below = demarked =0A= by //
>
>
>
> _____________
> Art = Allison
> =0A= Director, Advanced Engineering
> Science & Technology
> = National =0A= Association of Broadcasters
> 1771 N Street, NW
> = Washington, D.C. =0A= 20036
> Phone: 202.429.5418
> Fax: 202.777.4981
> =0A= aallison@nab.org
>
> The National Association of = Broadcasters is a =0A= trade association that
> advocates on behalf of more than 8,300 = free, =0A= local radio and television
> stations and also broadcast networks = before =0A= Congress, the Federal
> Communications Commission and the =0A= Courts.
>
> -----Original Message-----
> From: =0A= owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac= .uk] =0A= On
> Behalf Of Gorry Fairhurst
> Sent: Wednesday, August 30, = 2006 =0A= 12:57 PM
> To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk; =0A= mnoist@cosy.sbg.ac.at
> Cc: S.Iyengar
> Subject: Trying to = find =0A= words to describe how PIDs are used.....
>
>
> Repost: = My last =0A= posting to the list seemed to have gone astray, so I
> shall try = an =0A= updated repost.
>
> I was trying to use some of the email = from =0A= others to propose some text
> that answered the second set of =0A= questions.
>
>  > 2) Can  we determine = precisely what =0A= we man by a "Stream".
> //AA>I think a modifier should always = be used =0A= as this word is overloaded
> and usage here does not directly map = to =0A= MPEG-2 systems.//
>  > Does a Stream always only have ONE =0A= originating source?
>  //AA>I think that is so... if not = then the =0A= meaning is lost on me.//
>  > That is, does the PID imply = a =0A= specific intended source?
> //AA>No, because as you cover = below, these =0A= PIDs are ephemeral and
> changeable by any multiplexer.
> If = the PID =0A= is anounced in a PMT, it can change with each PMT section,
> = although =0A= typically it does not.//
> Here is some draft text, that could = perhaps be =0A= placed at the end of
> section 3.2. I'd be very pleased to receive =0A= comments/corrections so we
> converge on some good description of = this, =0A= since I think this relates
> directly to the need for =0A= authentication.
>
> THOUGHTS??? Comments and corrections =0A= please...
>
> Best wishes,
>
> =0A= Gorry
>
>
> ----
>
> In a MPEG-2 = Transmission =0A= network, the originating source of MPEG-2 TS
> Packets is either a = L2 =0A= interface device (media encoder, encapsulation
> gateway, etc) or = a L2 =0A= network device (TS multiplexor, etc). These
> devices may, but do = not =0A= necessarily, have an associated IP address. In
> the case of an =0A= encapsulation gateway (e.g. ULE sender), the device may
> operate = at L2 or =0A= L3, and is not normally the originator of an IP traffic
> flow, = and =0A= usually the IP source address of the packets that it forwards
> do = not =0A= correspond to an IP address associated with the device. When
> =0A= authentication of the IP source is required this must be provided = by
> =0A= IPsec, TLS, etc. operating at a higher layer.
>
> The TS = Packets are =0A= carried to the Receiver over a physical layer that
> usually = includes =0A= Forward Error Correction //(which can time shift data
> by = interleaving =0A= data from multiple unrelated TS packets)// and
> synchronisation =0A= processing that makes injection of single TS Packets
> very = difficult. =0A= Replacement of a sequence of packets is difficult, but
> =0A= possible.
>
> Each Receiver needs to identify a TS Logical = Channel =0A= (or MPEG-2
> //Elementary// Stream) to reassemble the fragments of = PDUs =0A= sent by a L2
> source [RFC4259]. In an
> MPEG-2 TS, this = association =0A= is made via the Packet Identifier, PID
> [ISO-MPEG]. At the = sender, each =0A= source associates a locally unique set
> of PID values with each = stream it =0A= originates. However, there is no
> required relationship between = the PID =0A= value used at the sender and that
> received at the = Receiver.  =0A= Network devices may re-number the PID values
> associated with one = or more =0A= TS Logical Channels (Streams) to prevent
> clashes at a = multiplexor =0A= between input Streams with the same PID carried
> on different = input =0A= multiplexes //(updating the PMT[ISO-MPEG] if the data
> is = reference in =0A= such)//.  A device may also modify and/or insert new SI
> = data into =0A= the control plane (also sent as TS Packets identified by PID
> =0A= value).
>
> The Stream of TS Packets carried in a multiplex = are =0A= usually received by
> many Receivers. One method is to secure the = entire =0A= Stream at the MPEG-2
> TS level. This approach is well-suited to =0A= TV-transmission, data-push,
> etc, where the PID carries one or a = set of =0A= flows with similar security
> requirements. Where the Stream = carries a set =0A= of IP traffic flows to
> different destinations with a range of = properties =0A= (multicast, unicast,
> etc) this it is often not appropriate to = provide IP =0A= confidentiality
> services for the entire Stream. A finer-grain = control is =0A= required that
> at least allows control to the level of a single = MAC/NPA =0A= address.
> However, there is only one valid source of data for = each =0A= MPEG-2
> //Elementary// Stream (i.e. PID) //for some duration//. = //The =0A= duration
> may be only until the next PMT arrives in some systems. = It may =0A= be until
> the next annuncement/discovery data is received in = other =0A= systems.//
> Although an attacker that is able to modify the = content of =0A= the received
> multiplex (e.g. replay data) could inject data = locally with =0A= an arbitrary
> PID value.
>
> =0A= ---
>

=0A= =0A= =0A= ------_=_NextPart_001_01C6CD0F.9AE7ED12-- From owner-ipdvb@erg.abdn.ac.uk Thu Aug 31 11:41:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIofE-0006Ul-Lr for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 11:41:08 -0400 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIofA-0002gW-Ur for ipdvb-archive@ietf.org; Thu, 31 Aug 2006 11:41: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 k7VFMBdf019811 for ; Thu, 31 Aug 2006 16:22:11 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k7VFMAJS019806 for ipdvb-subscribed-users; Thu, 31 Aug 2006 16:22:10 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k7VFIQ1U017815 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 31 Aug 2006 16:18:26 +0100 (BST) Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k7VFIPEf000400; Thu, 31 Aug 2006 16:18:25 +0100 (BST) Received: from bradford.ac.uk (thallium.cen.brad.ac.uk [143.53.238.78]) by radon.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k7VFIF3K020647; Thu, 31 Aug 2006 16:18:15 +0100 (BST) Received: from 143.53.20.59 ([143.53.20.59]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Thu, 31 Aug 2006 16:18:15 +0100 Message-ID: <1157037495.44f6fdb7a5f11@webmail6.brad.ac.uk> Date: Thu, 31 Aug 2006 16:18:15 +0100 From: P.Pillai@Bradford.ac.uk To: gorry@erg.abdn.ac.uk Cc: ipdvb@erg.abdn.ac.uk, P.Pillai@Bradford.ac.uk, mnoist@cosy.sbg.ac.at, S.Iyengar@surrey.ac.uk, AAllison@nab.org Subject: Re: Trying to find words to describe how PIDs are used..... In-Reply-To: <44F6A514.20705@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.20.59 X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Hi Gorry, Thanx a lot for this text. After chatting with you during the SATNEX summer school I was also planning to write such a para. But this is perfect. I think this is more suitable for Section 3.1, than Section 3.2. Just a few minor changes/comments. See inline Regards Prashant Quoting Gorry Fairhurst : > Thanks Art, > > I think the only way to make sure people understand is to get the > language correct. While I was trying to be precise on the security > aspects, my language got a little loose again, sorry. > > I agree with all you say, we should remember the context of an IP over > ULE Stream which serves a (large) community of Receivers... and the > document should be clear on this from the start. I've incorporated your > corrections, and a few more to tighten this up, do people think this is > better? > > Gorry > > > ---- > > Perhaps it may better to preface the introduction with something better > text, e.g. replacing it with?: > > OLD: > Abstract > > This document provides a threat analysis and derives security > requirements for MPEG-2 transmission links using the > Unidirectional Lightweight Encapsulation (ULE). It also provides > the motivation for ULE link-level security. This work is intended > as a work item of the ipdvb WG, and contributions are sought from > the IETF on this topic. > > SUGGESTION? > > Abstract > > The MPEG-2 standard defined by ISO 13818-1 [ref] supports a range of > transmission methods for a range of services. This document examines the > provides a threat analysis and derives security requirements when using > the Transport Stream, TS, to support an Internet network-layer using > Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The document > also provides the motivation for link-level security for a ULE Stream. A > ULE Stream may be used to send IPv4 packets, IPv6 packets, and other > Protocol Data Units (PDUs) to an arbitrarily large number of Receivers > supporting unicast and/or multicast transmission. > PP: We shall replace the old abstract with this one PP: Line 2 - delete "examines the" PP: Line 4 - replace "network-layer" with "network-layer protocol" > --- > > Suggestion to add text to 3.2 (although on re-reading, perhaps adding > something like this in 3.1 befor the final paragraph of the section, is > a better place??): > > In a MPEG-2 TS transmission network, the originating source of TS > Packets is either a L2 interface device (media encoder, encapsulation > gateway, etc) or a L2 network device (TS multiplexor, etc). These > devices may, but do not necessarily, have an associated IP address. In > the case of an encapsulation gateway (e.g. ULE sender), the device may > operate at L2 or L3, and is not normally the originator of an IP traffic > flow, and usually the IP source address of the packets that it forwards > do not correspond to an IP address associated with the device. When > authentication of the IP source is required this must be provided by > IPsec, TLS, etc. operating at a higher layer. > > The TS Packets are carried to the Receiver over a physical layer that > usually includes Forward Error Correction coding that interleaves the > bytes of several consecutive, but unrelated, TS Packets. FEC coding and > synchronisation processing makes injection of single TS Packets very > difficult. Replacement of a sequence of packets is also difficult, but > possible (see section 3.2). > > A Receiver in a MPEG-2 TS transmission network needs to identify a > TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the > fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this > association is made via the Packet Identifier, PID [ISO-MPEG]. At the > sender, each source associates a locally unique set of PID values with > each //elementary//stream it originates. However, there is no required relationship > between the PID value used at the sender and that received at the > Receiver. Network devices may re-number the PID values associated with > one or more TS Logical Channels (e.g. ULE Streams) to prevent clashes at > a multiplexor between input streams with the same PID carried on > different input multiplexes (updating entries in the PMT [ISO-MPEG], and > other SI tables that reference the PID value). A device may also modify > and/or insert new SI data into the control plane (also sent as TS > Packets identified by their PID value). > > The PID associated with an Elementary Stream can be modified (e.g. in > some systems by reception of an updated SI table, or in other systems > until the next annuncement/discovery data is received). An attacker > that is able to modify the content of the received multiplex (e.g. > replay data and/or control information) could inject data locally into > the received stream with an arbitrary PID value. > > One method to provide security is to secure the entire Stream at the > MPEG-2 TS level. This stream of TS Packets carried in a multiplex are > usually received by many Receivers. The approach is well-suited to > TV-transmission, data-push, etc, where the PID carries one or a set of > flows (e.g. video/audio Packetized Elementary Stream (PES) Packets) with > similar security requirements. > > Where a ULE Stream carries a set of IP traffic flows to different > destinations with a range of properties (multicast, unicast, etc), it is > often not appropriate to provide IP confidentiality services for the > entire ULE Stream. For many expected applications of ULE, a finer-grain > control is therefore required, at least permitting control of data > confidentiality/authorisation at the level of a single MAC/NPA address. > However there is only one valid source of data for each MPEG-2 > Elementary Stream, bound to a PID value. This observation could > simplify the requirement for authentication of the source of a ULE Stream. > > --- > -- Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------