From owner-ipdvb@erg.abdn.ac.uk Thu May 04 05:58:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbabl-00047z-BJ for ipdvb-archive@ietf.org; Thu, 04 May 2006 05:58:53 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbabj-00022C-Tm for ipdvb-archive@ietf.org; Thu, 04 May 2006 05:58: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 k449iD5W018035 for ; Thu, 4 May 2006 10:44:13 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k449iD90018034 for ipdvb-subscribed-users; Thu, 4 May 2006 10:44:13 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.17] (maxp12.dialup.abdn.ac.uk [139.133.201.171]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k449hrgQ017992 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 May 2006 10:44:02 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 04 May 2006 10:23:32 +0100 Subject: I-D ACTION:draft-ietf-ipdvb-ar-03.txt (WG I-D) From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ipdvb-ar-03.txt (WG I-D) Thread-Index: AcZvXGk+p4EoPttPEdq19QAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 for IP Datagrams over MPEG-2 Networks Author(s) : G. Fairhurst, M. Montpetit Filename : draft-ietf-ipdvb-ar-03.txt Pages : 0 Date : 2006-5-3 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. 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-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-ietf-ipdvb-ar-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-ietf-ipdvb-ar-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. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-ipdvb@erg.abdn.ac.uk Thu May 04 06:05:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbaic-0005mg-D6 for ipdvb-archive@ietf.org; Thu, 04 May 2006 06:05:58 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbaic-0002Fg-05 for ipdvb-archive@ietf.org; Thu, 04 May 2006 06:05: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 k449iAnM018019 for ; Thu, 4 May 2006 10:44:10 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k449iAl6018018 for ipdvb-subscribed-users; Thu, 4 May 2006 10:44: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 [10.0.1.17] (maxp12.dialup.abdn.ac.uk [139.133.201.171]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k449hrgP017992 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 4 May 2006 10:43:57 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 04 May 2006 10:23:09 +0100 Subject: I-D ACTION:draft-ppillai-ipdvb-sule-00.txt (Individual Submission) From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" CC: "P.Pillai@Bradford.ac.uk" , Fun Hu Message-ID: Thread-Topic: I-D ACTION:draft-ppillai-ipdvb-sule-00.txt (Individual Submission) Thread-Index: AcZvXFuImk/KJttPEdq19QAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Unidirectional Lightweight Encapsulation Protocol Author(s) : P. Pillai, Y. Hu Filename : draft-ppillai-ipdvb-sule-00.txt Pages : 17 Date : 2006-5-3 This document describes the Secure Unidirectional Encapsulation Protocol (S-ULE) that secures the IP traffic transported using ULE to provide data authentication, data confidentiality, data integrity and to mechanisms to prevent replay attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ppillai-ipdvb-sule-00.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-ppillai-ipdvb-sule-00.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-ppillai-ipdvb-sule-00.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 May 04 08:29:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbcxR-0004HX-4V for ipdvb-archive@ietf.org; Thu, 04 May 2006 08:29:25 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbcxO-0008Vw-LW for ipdvb-archive@ietf.org; Thu, 04 May 2006 08:29:25 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k44CM1rW029148 for ; Thu, 4 May 2006 13:22:01 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k44CM1vQ029147 for ipdvb-subscribed-users; Thu, 4 May 2006 13:22:01 +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 k44CLqQZ029128 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 4 May 2006 13:21:52 +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 k44CLnmA015378 for ; Thu, 4 May 2006 13:21:49 +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 k44CLmib013824 for ; Thu, 4 May 2006 13:21:49 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Thu, 04 May 2006 13:21:48 +0100 Message-ID: <1146745308.4459f1dcc2119@webmail6.brad.ac.uk> Date: Thu, 04 May 2006 13:21:48 +0100 From: P.Pillai@Bradford.ac.uk To: "ipdvb@erg.abdn.ac.uk" Subject: draft-ppillai-ipdvb-sule-00.txt 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.31.49 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.7 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hello Everyone, We have submitted a new ID (draft-ppillai-ipdvb-sule-00.txt) looking into some security aspects for ULE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ppillai-ipdvb-sule-00.txt All Comments/Suggestions are welcome. Regards Prashant -- 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 From owner-ipdvb@erg.abdn.ac.uk Fri May 05 01:40:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbt3U-0007xP-2X for ipdvb-archive@ietf.org; Fri, 05 May 2006 01:40:44 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbt3S-0001gR-Mn for ipdvb-archive@ietf.org; Fri, 05 May 2006 01:40:44 -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 k455b8N2009525 for ; Fri, 5 May 2006 06:37:08 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k455b8UW009524 for ipdvb-subscribed-users; Fri, 5 May 2006 06:37:08 +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 nrg.cs.usm.my (nrg.cs.usm.my [202.170.56.22]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k455atca009497 for ; Fri, 5 May 2006 06:36:59 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 9DD12220125 for ; Fri, 5 May 2006 13:36:48 +0800 (MYT) Received: from nrg.cs.usm.my ([127.0.0.1]) by localhost (nrg.cs.usm.my [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10654-01 for ; Fri, 5 May 2006 13:36:46 +0800 (MYT) Received: by nrg.cs.usm.my (Postfix, from userid 48) id 40D2522012D; Fri, 5 May 2006 13:36:46 +0800 (MYT) Received: from 10.207.160.203 (SquirrelMail authenticated user wcang) by 10.207.160.104 with HTTP; Fri, 5 May 2006 13:36:46 +0800 (MYT) Message-ID: <16548.10.207.160.203.1146807406.squirrel@10.207.160.104> Date: Fri, 5 May 2006 13:36:46 +0800 (MYT) Subject: DVB-s receiver card From: "Ang Way Chuang" To: ip-dvb@erg.abdn.ac.uk User-Agent: SquirrelMail/1.4.5-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at nrg.cs.usm.my X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hi all, Can anyone tell which DVB-s receiver card is capable of working with symbol rate below 1Msps? The WinTV Nova can't work below that rate. I can't find any datasheet from Hauppage website to confirm the spec of WinTV NOVA card. I also notice that most cards support 1 - 45 Msps only. Thanks in advance. Regards, Ang Way Chuang -- May you be well and happy. From owner-ipdvb@erg.abdn.ac.uk Fri May 05 01:41:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbt40-0007xb-Hk for ipdvb-archive@ietf.org; Fri, 05 May 2006 01:41:16 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbt40-0001hD-4u for ipdvb-archive@ietf.org; Fri, 05 May 2006 01:41: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 k455VEim009155 for ; Fri, 5 May 2006 06:31:14 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k455VE33009154 for ipdvb-subscribed-users; Fri, 5 May 2006 06:31: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 nrg.cs.usm.my (nrg.cs.usm.my [202.170.56.22]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k455V5vY009137 for ; Fri, 5 May 2006 06:31:06 +0100 (BST) Received: from localhost (localhost.localdomain [127.0.0.1]) by nrg.cs.usm.my (Postfix) with ESMTP id 2DD6C220125 for ; Fri, 5 May 2006 13:30:59 +0800 (MYT) Received: from nrg.cs.usm.my ([127.0.0.1]) by localhost (nrg.cs.usm.my [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10224-08 for ; Fri, 5 May 2006 13:30:57 +0800 (MYT) Received: by nrg.cs.usm.my (Postfix, from userid 48) id 1928922014C; Fri, 5 May 2006 13:30:57 +0800 (MYT) Received: from 10.207.160.203 (SquirrelMail authenticated user wcang) by 10.207.160.104 with HTTP; Fri, 5 May 2006 13:30:57 +0800 (MYT) Message-ID: <13456.10.207.160.203.1146807057.squirrel@10.207.160.104> Date: Fri, 5 May 2006 13:30:57 +0800 (MYT) Subject: DVB-s receiver card From: "Ang Way Chuang" To: ipdvb@erg.abdn.ac.uk User-Agent: SquirrelMail/1.4.5-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at nrg.cs.usm.my X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi all, Can anyone tell which DVB-s receiver card is capable of working with symbol rate below 1Msps? The WinTV Nova can't work below that rate. I can't find any datasheet from Hauppage website to confirm the spec of WinTV NOVA card. I also notice that most cards support 1 - 45 Msps only. Thanks in advance. Regards, Ang Way Chuang -- May you be well and happy. From owner-ipdvb@erg.abdn.ac.uk Wed May 10 11:10:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqKI-00072o-Jo for ipdvb-archive@ietf.org; Wed, 10 May 2006 11:10:10 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqKG-0001op-2e for ipdvb-archive@ietf.org; Wed, 10 May 2006 11:10:10 -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 k4AEl1oh029673 for ; Wed, 10 May 2006 15:47:01 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4AEl1ph029672 for ipdvb-subscribed-users; Wed, 10 May 2006 15:47:01 +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.151] (dhcp-207-151.erg.abdn.ac.uk [139.133.207.151]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4AEktgD029658; Wed, 10 May 2006 15:46:56 +0100 (BST) Message-ID: <4461FCE6.7050209@erg.abdn.ac.uk> Date: Wed, 10 May 2006 15:47:02 +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: Rupert Goodings Subject: Comments requested to draft-ieft-ipdvb-ar-03 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: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 The AR draft has been udpated. The authors would like to request comments on this version of the draft from the list. The current I-D is at: http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-03.txt The differences between this and the previous I-D are at: http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/draft-ietf-ipdvb-ar-03-from-02.diff.html To start the process, I am reposting a summary of some of some open comments (from a detailed comments to the rev -02 of the AR draft, sent by Rupert Goodings), in case you (or anyone else on the list) wish to respond and discuss these for the next rev of the document. Please do send email with anything the authors have missed, or any other comments! Best wishes, Gorry Fairhurst (as AR I-D co-editor) --------------- 1) AR motivation. > >>> > Rupert Goodings wrote: >>> > more discussion in section 6 (or later) to indicate what AR work >>> > is needed - >>> > i.e. explain why a new AR protocol is (or isn't!) needed. This is not an easy call to make in a general document, two-way satellite systems (as you hint) do not currently use IETF-defined protocols, and perform AR using other means. On the other hand, we've seen presentations at the IETF using ND,ARP over UDLR, and IETF-defined protocols are used in DOCSIS, etc......... What else do you think we should/could say? It is clearly within the Charter of the WG to define a new protocol, should there be demand and a clear requirement, and this should be done in the IETF. Is there interest in doing this? --------------- 2) Bridging case. > >>> > Rupert Goodings wrote: >>> > First some comments on the new introduction. >>> > >>> > The bridging case implies a problem...you state: >>> > "the systems R1, R2 will normally use standard IETF-defined AR >>> > mechanisms (e.g. ARP [RFC826], ND [RFC2461) edge-to-edge >>> > across theIP subnetwork." >>> > >>> > Now you have already identified that the satellite link >>> > causes problems for AR. >> ##rg## I am referring to Para 5 of the intro where you state: >>"The numbers of Receivers connected via a single MPEG-2 link may be >>much larger than found in other common LAN technologies, (e.g. >>Ethernet). This has implications on design/configuration of the address >>resolution mechanisms." >> >> ==>hence it reads oddly to go on to state "OK to use ARP" >> in the bridged case. > Some new text added in rev-03, does it address your concerns, or did we miss some points? --------------- 2) Multicast AR. PIM, IGMP, ... > >>> > Rupert Goodings wrote: >>> > new/more of the source address aspects (I call this SSM in my >>> > comments). What I mean here is features to manage groups in >>> > terms of BOTH S and G not just [*,G] group management. >>> > > >> Including PIM, IGMP, etc. What do you suggest we add here, that is important to Address Resolution? --------------- 3) Multicast AR: Sources > >>> > Rupert Goodings wrote: >>> > Section 3.2. >>> > General comment is to suggest that this section should >>> > also discuss SSM aspects >>##gf## Do you have somne particular text in mind? >>##rg## See above. Section 3.2. only deals with the mapping >> and filtering ofthe destination IP group address. I was >> suggesting that you could also discuss possible source >> filtering... >> I appreciate that this is may not be applicable >> here since static RFC1112 mapping applies (?). >> So my comment may simply be a request >> to explain better the use (or not) of >> source addresses in the MMT and INT tables. >>> > - in the above case, extra AR traffic may be OK if it >>> > saves resources. Should we add some text on this? - If I understood, this concerns the RFC1112 mapping of IPv4 addresses to MAC addresses (and the corresponding IPv6 mapping) which are static. One problem this raises is a lack of differentiation between two IP multicast flows that map to the same MAC address - examples include: (i) the "address overlap" (sets of IP (G) map to the same MAC), (ii) a specified G destination address may be used by two different S sources in SSM, therefore mapping G to a MAC address is not sufficient. (iii) a local scope (two IP addresses are in different admin scopes and hence are not the same group, but map to the same MAC - if sent on the same interface) One solution to this, which came up at the mboned WG sometime ago was to map some addresses to specific OTHER multicast addresses using a differentmapping function. Such methods have been proposed in the context of multicast Internet exchanges using L2 switches to connect routers, where operators need to provide policy-based multicast routing between different exchange points and want to avoid leaking and forwarding traffic that happens to map to the same MAC address. This requires a multicast AR method to define the "exceptions" or new mapping associations and inform all receivers. Have I understood your point? What do you think we should say? >>> > [Later I note that the INT does seem to offer support >>> > for SSM?] Yes. --------------- 4) Additional references Do you have a citation(s) that you think would be useful to relate this document (e.g. to work within ETSI concerning AR). Provisional document titles may be OK, providing these are finalised by the time the I-D reaches the RFC-Editor (probably summer 2006). From owner-ipdvb@erg.abdn.ac.uk Thu May 11 05:48:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7n0-0005CT-Be for ipdvb-archive@ietf.org; Thu, 11 May 2006 05:48:58 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe7my-0008Cl-Se for ipdvb-archive@ietf.org; Thu, 11 May 2006 05:48: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 k4B9LHPi017067 for ; Thu, 11 May 2006 10:21:17 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4B9LHvR017066 for ipdvb-subscribed-users; Thu, 11 May 2006 10:21: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 [10.0.1.34] (maxp27.dialup.abdn.ac.uk [139.133.201.186]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4B9L0wj017035 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 11 May 2006 10:21:03 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 11 May 2006 10:23:24 +0100 From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ03I1dy/fQjuDPEdqCEwAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt 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: 8b30eb7682a596edff707698f4a80f7d 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, S. Iyengar, L. Duquerroy Filename : draft-cruickshank-ipdvb-sec-req-01.txt Pages : 13 Date : 2006-5-09 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-01.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-01.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 Best wishes, G Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Thu May 11 13:00:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeEWp-0004r2-0k for ipdvb-archive@ietf.org; Thu, 11 May 2006 13:00:43 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeEWo-0002n1-0c for ipdvb-archive@ietf.org; Thu, 11 May 2006 13:00: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 k4BGmaIw019832 for ; Thu, 11 May 2006 17:48:36 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4BGmZ2Z019831 for ipdvb-subscribed-users; Thu, 11 May 2006 17:48:35 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from ads40.surrey.ac.uk (ads40.surrey.ac.uk [131.227.102.140]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4BGmRQR019813 for ; Thu, 11 May 2006 17:48:27 +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, 11 May 2006 17:48:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6751A.B678B0AF" Subject: RE: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Date: Thu, 11 May 2006 17:45:48 +0100 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD331@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: <018160DBE8D48349A0CABF4424C3DC21AAD331@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ03I1dy/fQjuDPEdqCEwAKlc/qXgAPc3Lz From: To: Cc: , X-OriginalArrivalTime: 11 May 2006 16:48:22.0422 (UTC) FILETIME=[B6DDB360:01C6751A] 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: 052f5f7988f6d35f983a2680181d544b This is a multi-part message in MIME format. ------_=_NextPart_001_01C6751A.B678B0AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gorry,=0A= Please find attached the first version of the ULE-Security draft. Can you p= lease have a look at it and then if okay please submit it on our behalf.=0A= =20=0A= Cheers=0A= Sunny=0A= =20=0A= ***********************************************************=0A= Sunil Iyengar,=0A= Research Fellow, Networks Group,=0A= Centre For Communication And Systems Research(CCSR),=0A= School of Electronics, Computing & Mathematics,=0A= University Of Surrey, Guildford GU2 7XH,=0A= Surrey, England, United Kingdom.=0A= Office: +44 (0)1483 686008=0A= ***********************************************************=0A= =0A= =0A= ________________________________=0A= =0A= From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst=0A= Sent: Thu 11/05/2006 10:23=0A= To: ipdvb@erg.abdn.ac.uk=0A= Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt=0A= =0A= =0A= =0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts=0A= directories.=0A= =0A= =0A= Title : Security requirements for the Unidirectional=0A= Lightweight Encapsulation (ULE) protocol=0A= Author(s) : H. Cruickshank, S. Iyengar, L. Duquerroy=0A= Filename : draft-cruickshank-ipdvb-sec-req-01.txt=0A= Pages : 13=0A= Date : 2006-5-09=0A= =0A= =0A= This document provides a threat analysis and derives security=0A= requirements for MPEG-2 transmission links using the Unidirectional=0A= Lightweight Encapsulation (ULE). It also provides the motivation for=0A= ULE link level security. This work is intended as a work item of the=0A= ipdvb WG, and contributions are sought from the IETF on this topic.=0A= =0A= =0A= A URL for this Internet-Draft is:=0A= http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-01.txt= =0A= =0A= Internet-Drafts are also available by anonymous FTP. Login with the username= =0A= "anonymous" and a password of your e-mail address. After logging in,=0A= type "cd internet-drafts" and then=0A= "get draft-cruickshank-ipdvb-sec-req-01.txt".=0A= =0A= A list of Internet-Drafts directories can be found in=0A= http://www.ietf.org/shadow.html=0A= or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A= =0A= =0A= Best wishes,=0A= =0A= G Fairhurst=0A= (ipdvb WG Chair)=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_001_01C6751A.B678B0AF Content-Type: text/plain; name="msg-14532-171.txt" Content-Disposition: attachment; filename="msg-14532-171.txt" Content-Transfer-Encoding: 8bit Hi Gorry, Please find attached the first version of the ULE-Security draft. Can you please have a look at it and then if okay please submit it on our behalf. Cheers Sunny *********************************************************** 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: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst Sent: Thu 11/05/2006 10:23 To: ipdvb@erg.abdn.ac.uk Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt 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, S. Iyengar, L. Duquerroy Filename : draft-cruickshank-ipdvb-sec-req-01.txt Pages : 13 Date : 2006-5-09 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-01.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-01.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 Best wishes, G Fairhurst (ipdvb WG Chair) ------_=_NextPart_001_01C6751A.B678B0AF Content-Type: application/octet-stream; name="draft-cruicksh.txt" Content-Disposition: attachment; filename="draft-cruicksh.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQogICAgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAg ICAgICAgICAgICAgICAgICAgIEguIENydWlja3NoYW5rIA0KICAgIEludGVy bmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUy4gSXllbmdhciANCiAgICBEb2N1bWVudDogZHJhZnQtY3J1aWNr c2hhbmstaXBkdmItc2VjLSAgICAgICAgIFVuaXZlcnNpdHkgb2YgU3VycmV5 IA0KICAgIDAwLnR4dCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBEdXF1ZXJyb3kgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFsY2F0ZWwgQWxlbmlhIFNwYWNlIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICBDYXRlZ29yeTogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMSBNYXkgMjAwNiANCiAgICAgDQogICAgIA0K ICAgICAgICAgICAgQSBTZWN1cmUgRXh0ZW5zaW9uIGZvciB0aGUgVW5pZGly ZWN0aW9uYWwgTGlnaHR3ZWlnaHQgDQogICAgICAgICAgICBFbmNhcHN1bGF0 aW9uIChVTEUpIHByb3RvY29sIA0KICAgICANCiAgICAgDQogICAgU3RhdHVz IG9mIHRoaXMgRHJhZnQgDQogICAgICAgIA0KICAgICAgIEJ5IHN1Ym1pdHRp bmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50 cyB0aGF0ICANCiAgICAgICBhbnkgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3Ro ZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgDQogICAgICAg YXdhcmUgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55 IG9mIHdoaWNoIGhlIG9yIHNoZSANCiAgICAgICBiZWNvbWVzIGF3YXJlIHdp bGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2 IG9mICANCiAgICAgICBCQ1AgNzkuIA0KICAgICAgICANCiAgICAgICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZyANCiAgICAgICBUYXNrIEZvcmNlIChJRVRGKSwg aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQg DQogICAgICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICAgICAgRHJhZnRzLiAN CiAgICAgICAgDQogICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggDQogICAgICAg bW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlciAgDQogICAgICAgZG9jdW1lbnRzIGF0IGFueSB0aW1l LiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0gDQogICAg ICAgRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRo ZW0gb3RoZXIgdGhhbiBhcyAid29yayAgDQogICAgICAgaW4gcHJvZ3Jlc3Mi LiANCiAgICAgICAgDQogICAgICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvMWlkLWFic3RyYWN0cy5odG1sLiANCiAgICAgICAg DQogICAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERp cmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiANCiAgICAgICAgDQogICAgICAg IA0KICAgICAgIEFic3RyYWN0IA0KICAgICAgICANCiAgICAgICBUaGlzIGRv Y3VtZW50IHByb3Bvc2VzIGFuIGV4dGVuc2lvbiBmb3JtYXQgZm9yIHRoZSBV bmlkaXJlY3Rpb25hbCANCiAgICAgICBMaWdodHdlaWdodCBFbmNhcHN1bGF0 aW9uIChVTEUpIHByb3RvY29sLiANCiAgICAgICAgDQogICAgICAgVGhpcyB3 b3JrIGlzIGludGVuZGVkIGFzIGEgd29yayBpdGVtIG9mIHRoZSBpcGR2YiBX RywgYW5kIA0KICAgICAgIGNvbnRyaWJ1dGlvbnMgYXJlIHNvdWdodCBmcm9t IHRoZSBJRVRGIG9uIHRoaXMgdG9waWMuIA0KICAgICAgICANCiAgICAgICAg DQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQoMICAgICAgICANCiAg ICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAg IA0KICAgICAgDQogICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA2ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgMV0gDQoMICAg IElOVEVSTkVUIERSQUZUIEVuY2Fwc3VsYXRpb24gZm9yIElQIG92ZXIgTVBF Ry0yL0RWQiAgICAgICAgTWF5IDIwMDYgDQogICAgIA0KICAgICANCiAgICAg ICBUYWJsZSBvZiBDb250ZW50cyANCiAgICAgICAgDQogICAgICAgMS4gSW50 cm9kdWN0aW9uIA0KICAgICAgICAgICAgMS4xIERlZmluaXRpb25zIHVzZWQg aW4gdGhpcyBkb2N1bWVudCANCiAgICAgICAyLiBMaW5rIFNlY3VyaXR5IFBy b3RvY29sIA0KICAgICAgICAgICAgMi4xIEVuY3J5cHRpb24gb2YgdGhlIFNO RFUgcGF5bG9hZCAgDQogICAgICAgICAgICAyLjIgRW5jcnlwdGlvbiBFeHRl bnNpb24gSGVhZGVyIGZvcm1hdCANCiAgICAgICAzLiBLZXkgRXhjaGFuZ2Ug UHJvY2VkdXJlICANCiAgICAgICAgICAgIDMuMSBJUHNlYyBLZXkgTWFuYWdl bWVudCBmb3IgTDIgDQogICAgICAgICAgICAzLjIgQWx0ZXJuYXRpdmUgS2V5 IE1hbmFnZW1lbnQgIA0KICAgICAgIDQuIFN1bW1hcnkgDQogICAgICAgNS4g QWNrbm93bGVkZ21lbnRzIA0KICAgICAgIDYuIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIA0KICAgICAgIDcuIFJlZmVyZW5jZXMgDQogICAgICAgNy4xIE5v cm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgICAgIDcuMiBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIA0KICAgICAgIDguIEF1dGhvcnMnIEFkZHJlc3NlcyANCiAg ICAgICA5LiBJUFIgTm90aWNlcyANCiAgICAgICAgICAgIDkuMSBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IA0KICAgICAgICAgICAgOS4yIERp c2NsYWltZXIgb2YgVmFsaWRpdHkgDQogICAgICAgMTAuIENvcHlyaWdodCBT dGF0ZW1lbnQgDQogICAgICAgMTEuIElBTkEgQ29uc2lkZXJhdGlvbnMgDQog ICAgICAgQW5uZXhlIEEuIEV4YW1wbGVzIG9mIHVzZSANCiAgICAgDQogICAg IA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAg ICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAg IA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAg ICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAg IA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAg ICAgICAgDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAg IA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAgICANCgwg ICAgICAgIA0KICAgICAgICANCiAgICAgICAgDQogICAgICAgIA0KICAgICAg ICANCiAgICAgIA0KICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtwYWdlIDJdIA0KDCAg ICBJTlRFUk5FVCBEUkFGVCBFbmNhcHN1bGF0aW9uIGZvciBJUCBvdmVyIE1Q RUctMi9EVkIgICAgICAgIE1heSAyMDA2IA0KICAgICANCiAgICAgDQogICAg MS4gSW50cm9kdWN0aW9uIA0KICAgICAgICANCiAgICAgICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gaGVhZGVyIGZvciBwcm92aWRp bmcgbGluayAgDQogICAgICAgbGF5ZXIgc2VjdXJpdHkgZm9yIHRoZSBVTEUg W2lwZHZiLXVsZV0gZW5jYXBzdWxhdGlvbiB3aGljaCAgDQogICAgICAgc3Vw cG9ydHMgdHJhbnNwb3J0IG9mIElQIGRhdGFncmFtcyBvciBvdGhlciBuZXR3 b3JrIGxheWVyIHBhY2tldHMgDQogICAgICAgb3ZlciBJU08gTVBFRy0yIFRy YW5zcG9ydCBTdHJlYW1zIFtpc28tbXBlZ10uIA0KICAgICAgICANCiAgICAg ICBJbiBNUEVHLTIgdHJhbnNtaXNzaW9uIG5ldHdvcmtzIGVtcGxveWluZyBV TEUsIHRoZXJlIGlzIGEgbmVlZCB0byANCiAgICAgICBwcm92aWRlIGxpbmst bGF5ZXIgKEwyKSBzZWN1cml0eSwgcGFydGljdWxhcmx5IHdoZXJlIG5ldHdv cmsgIA0KICAgICAgIGxheWVyIGFuZCB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJp dHkgKGUuZy4gSVBzZWMsIFRMUykgbWF5IG5vdCBiZSANCiAgICAgICBzdWZm aWNpZW50LiBUaGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFyZSBwcmVzZW50 ZWQgaW4gZHJhZnQtDQogICAgICAgY3J1aWNrc2hhbmstaXBkdmItc2VjLXJl cS0wMS4gDQogICAgICAgIA0KICAgICAgIFVMRSBtYXkgdXNlIGFuZCBiZW5l Zml0IGZyb20gSUVURiBrZXkgbWFuYWdlbWVudCBwcm90b2NvbHMsIHN1Y2gg IA0KICAgICAgIGFzIHRoZSBNU0VDIEdET0kgW21zZWMtZ2RvaSwgcmZjIDM1 NDddIGFuZCBHU0FLTVAgW21zZWMtZ3Nha21wXS4gDQogICAgICAgVGhpcyBk b2VzIG5vdCBwcmVjbHVkZSB0aGUgdXNlIG9mIG90aGVyIGtleSBtYW5hZ2Vt ZW50IG1ldGhvZHMgaW4gDQogICAgICAgc2NlbmFyaW9zIHdoaWNoIGJlbmVm aXQgZnJvbSB0aGlzLiANCiAgICAgICAgDQogICAgICAgSW4gc29tZSBjdXJy ZW50IGVuY2Fwc3VsYXRpb24gbWV0aG9kcywgZS5nLiBNUEUgW2V0c2ktZGF0 XSwgDQogICAgICAgZW5jcnlwdGlvbiBvZiB0aGUgTUFDIGFkZHJlc3MgcmVx dWlyZXMgZWFjaCBSZWNlaXZlciB0byBkZWNyeXB0ICANCiAgICAgICBhbGwg ZW5jcnlwdGVkIGRhdGEgc2VudCB1c2luZyBhIFRTIExvZ2ljYWwgQ2hhbm5l bCAoUElEKSwgYmVmb3JlICANCiAgICAgICBpdCBjYW4gdGhlbiBmaWx0ZXIg dGhlIFBEVXMgdGhhdCBtYXRjaGVzIHRoZSBzZXQgb2YgTUFDL05QQSANCiAg ICAgICBhZGRyZXNzZXMgdGhhdCB0aGUgUmVjZWl2ZXIgd2lzaGVzIHRvIHJl Y2VpdmUsIHRoZXJlZm9yZSAgDQogICAgICAgZW5jcnlwdGlvbiBvZiB0aGUg TVBFIE1BQyBhZGRyZXNzIGlzIG5vdCBwZXJtaXR0ZWQgaW4gc3VjaCAgDQog ICAgICAgc3lzdGVtcy4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtb2Rl IGluIHRoYXQgcHJvdmlkZXMgb3B0aW9uYWwgDQogICAgICAgc3VwcG9ydCBm b3IgdXNpbmcgdGVtcG9yYXJ5IExheWVyIDIgTUFDL05QQSBhZGRyZXNzLiAg DQogICAgICAgIA0KICAgICAgIFRvIHN1cHBvcnQgbGluayBsZXZlbCBlbmNy eXB0aW9uLCBhbiBlbmNyeXB0aW9uICANCiAgICAgICBleHRlbnNpb24gaGVh ZGVyIGlzIGRlZmluZWQsIGFuZCBpbmNsdWRlZCBpbiB0aGUgU05EVSBwYXls b2FkLiAgDQogICAgICAgVGhpcyBhcHByb2FjaCBpcyBnZW5lcmljIGFuZCBk ZWNvdXBsZXMgdGhlIGVuY2Fwc3VsYXRpb24gZnJvbSB0aGUgDQogICAgICAg ZXZvbHV0aW9uIG9mIGZ1dHVyZSBzZWN1cml0eSBtZXRob2RzLiAgDQogICAg ICAgIA0KICAgICAgIFRoZSBwcm9wb3NlZCBhcHByb2FjaCBzdWdnZXN0cyBh IG5ldyBVTEUgTWFuZGF0b3J5IEV4dGVuc2lvbiAgDQogICAgICAgaGVhZGVy IGZvciBhIHNlY3VyaXR5LiBFbmNyeXB0aW9uIGFsZ29yaXRobXMsIGtleSBs ZW5ndGhzLCBldGMuICANCiAgICAgICB3aWxsIGJlIGRlZmluZWQgbWFraW5n IHVzZSBvZiB0aGUgc3RhbmRhcmQgSVBzZWMgc3VpdGVzIFttc2VjXSwgIA0K ICAgICAgIGFzIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24gaWQgc2ltaWxhciB0 byB0aGUgSVBzZWMgU1BJIFtJUHNlY10gaXMgDQogICAgICAgdXNlZC4gVGhl IGZvY3VzIGlzIG9uIHByb3ZpZGluZyBzdWl0YWJsZSBsaW5rIGVuY3J5cHRp b24uICANCiAgICAgICBIb3dldmVyLCBMaW5rIGxheWVyIGRhdGEgaW50ZWdy aXR5IGlzIHByb3ZpZGVkIGFzIGFuIG9wdGlvbmFsIA0KICAgICAgIHNlY3Vy aXR5IHNlcnZpY2UsIGVzcGVjaWFsbHkgZm9yIHN5c3RlbXMgd2hlcmUgdGhl cmUgYXJlIHNldmVyYWwgIA0KICAgICAgIFVMRSB0cmFuc21pdHRlcnMgKGUu Zy4gc2F0ZWxsaXRlIG1lc2hlZCBzeXN0ZW1zIHdpdGggT24tQm9hcmQgDQog ICAgICAgUHJvY2Vzc2luZykgDQogICAgICAgIA0KICAgICANCiAgICAxLjEg RGVmaW5pdGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgICAgICAN CiAgICAgICAgDQogICAgICAgICAgIEFFUyAgICBBZHZhbmNlZCBFbmNyeXB0 aW9uIFN0YW5kYXJkIFttc2VjLWdzYWttcF0gDQogICAgICAgICAgICBELWJp dCAgRGVzdGluYXRpb24gQWRkcmVzcyBPbWl0dGVkIGZpZWxkIFtpcGR2Yi11 bGVdIA0KICAgICAgICAgICAgRFZCICAgIERpZ2l0YWwgVmlkZW8gQnJvYWRj YXN0IA0KICAgICAgICAgICBHRE9JICAgR3JvdXAgRG9tYWluIG9mIEludGVy cHJldGF0aW9uIFttc2VjLWdkb2ldIA0KICAgICAgICAgICBHU0tBTVAgR3Jv dXAgU2VjdXJlIEFzc29jaWF0aW9uIEtleSBNYW5hZ2VtZW50IFByb3RvY29s ICANCiAgICAgICAgICAgICAgICAgIFttc2VjZ3Nha21wXSANCiAgICAgICAg ICAgIElQc2VjICBJbnRlcm5ldCBQcm90b2NvbCBTZWN1cml0eSBzdWl0ZSBb aXBzZWMsIHJmY3MgMjQwMSwgDQogICAgICAgICAgICAgICAgICAgMjQwMiBh bmQgMjQwNl0gDQogICAgICAgICAgIEwyICAgICBMaW5rIExheWVyIA0KICAg ICAgICAgICAgTVBFICAgIE11bHRpLVByb3RvY29sIEVuY2Fwc3VsYXRpb24g W2V0c2ktZGF0XSANCgwgICAgICAgICAgICBOQVQgICAgTmV0d29yayBBZGRy ZXNzIFRyYW5zbGF0aW9uIFtyZmMgMzcxNV0gDQogICAgICAgICAgIE5DQyAg ICBOZXR3b3JrIENvbnRyb2wgQ2VudHJlIA0KICAgICAgICAgICBQRVAgICAg UHJvdG9jb2wgRW5oYW5jaW5nIFByb3h5IFtyZmMgMzEzNV0gDQogICAgICAg ICAgIFBJRCAgICBQYWNrZXQgSWRlbnRpZmllciBbaXNvLW1wZWddIA0KICAg ICAgICAgICBQRFUgICAgUHJvdG9jb2wgRGF0YSBVbml0IChJUCBwYWNrZXks IE1QTFMgZnJhbWUsIGV0YykgDQogICAgICANCiAgICBFeHBpcmVzIE5vdmVt YmVyIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbcGFnZSAzXSANCgwgICAgSU5URVJORVQgRFJBRlQgRW5jYXBzdWxhdGlv biBmb3IgSVAgb3ZlciBNUEVHLTIvRFZCICAgICAgICBNYXkgMjAwNiANCiAg ICAgDQogICAgIA0KICAgICAgICAgICBTSEEtMSAgU3RhbmRhcmQgSGFzaCBB bGdvcml0aG0gMSBbbXNlYy1nc2FrbXBdIA0KICAgICAgICAgICBTSUQgICAg U2VjdXJpdHkgSWRlbnRpZmllciANCiAgICAgICAgICAgU05EVSAgIFN1Ym5l dHdvcmsgRGF0YSBVbml0IFtpcGR2Yi11bGVdIA0KICAgICAgICAgICBURVNM QSAgVGltZWQgRWZmaWNpZW50IFN0cmVhbSBMb3NzLVRvbGVyYW50IEF1dGhl bnRpY2F0aW9uIA0KICAgICAgICAgICBUTFMgICAgVHJhbnNwb3J0IExheWVy IFNlY3VyaXR5IFt0bHNdIA0KICAgICAgICAgICBUUyAgICAgTVBFRy0yIFRy YW5zcG9ydCBTdHJlYW0gW2lwZHZiLWFyY2hdIA0KICAgICAgICAgICBVTEUg ICAgVW5pZGlyZWN0aW9uYWwtTGlnaHR3ZWlnaHQgRW5jYXBzdWxhdGlvbiAN CiAgICAgDQogICAgIA0KICAgIDIuIExpbmsgU2VjdXJpdHkgUHJvdG9jb2wg DQogICAgICAgIA0KICAgICAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhl IGxpbmsgc2VjdXJpdHkgcHJvdG9jb2wgZm9yIHRoZSBVTEUgDQogICAgICAg cHJvdG9jb2wuIA0KICAgICAgICANCiAgICAyLjEgRW5jcnlwdGlvbiBvZiB0 aGUgU05EVSBwYXlsb2FkIA0KICAgICAgICANCiAgICAgICBUaGUgc2VjdXJp dHkgc3VpdGUgb2YgYWxnb3JpdGhtcyBmb3IgZGF0YSBlbmNyeXB0aW9uIGFu ZCBkYXRhIA0KICAgICAgIGludGVncml0eSBzcGVjaWZpZWQgaW4gSVBzZWMv TVNFQyB3aWxsIGJlIHVzZWQgZm9yIFVMRSBzZWN1cml0eS4gDQogICAgICAg IA0KICAgICAgIFRoZSBTTkRVIHBhZGRpbmcgbXVzdCBiZSB1c2VkIGluIG9y ZGVyIHRvIG1ha2UgdGhlIFNORFUgbGVuZ3RoIGFzIA0KICAgICAgIG11bHRp cGxlcyBvZiA4IG9yIDE2IGJ5ZXMgZGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9m IGVuY3J5cHRpb24gDQogICAgICAgYWxnb3JpdGhtIHVzZWQuIA0KICAgICAg ICANCiAgICAgICBBbm90aGVyIGlzc3VlIGlzIGtleSBzcGFjZSB0aGVyZSBp cyBhIG5lZWQgZm9yIHR3byBkYXRhYmFzZXMgZm9yICANCiAgICAgICB0aGUg Y29ycmVjdCBwcm9jZXNzaW5nIG9uIHNlY3VyaXR5IGluIFVMRSBUcmFuc21p dHRlcnMgYW5kIA0KICAgICAgIFJlY2VpdmVyczogDQogICAgICAgIA0KICAg ICAgIC4gU2VjdXJpdHkgUG9saWN5IERhdGFiYXNlIChTUEQpOiBUaGlzIGRh dGFiYXNlIGNvbnRhaW5zIHRoZSANCiAgICAgICAgICBwb2xpY2llcyB0aGF0 IGRldGVybWluZSB0aGUgcHJvY2Vzc2luZyBvZiBhbGwgVUxFIGluYm91bmQg LyANCiAgICAgICAgICBvdXRib3VuZCB0cmFmZmljIChzdWNoIGFzIGVuY3J5 cHRpbmcgYWxsIG91dGJvdW5kIFVMRSB0cmFmZmljIA0KICAgICAgICAgIGRl c3RpbmVkIHRvIGEgY2VydGFpbiB0ZXJtaW5hbCkuICANCiAgICAgICAuIFNl Y3VyaXR5IEFzc29jaWF0aW9uIERhdGFiYXNlIChTQUQpOiBFYWNoIGVudHJ5 IGRlZmluZXMgdGhlIA0KICAgICAgICAgIHBhcmFtZXRlcnMgYXNzb2NpYXRl ZCB3aXRoIG9uZSBVTEUtU0lEIHN1Y2ggYXMgZW5jcnlwdGlvbiAgDQogICAg ICAgLiBrZXlzLiBFYWNoIFVMRS1TSUQgaGFzIGFuIGVudHJ5IGluIHRoZSBT QUQuIA0KICAgICAgICANCiAgICAgICBUaGUgbWFpbiBhaW0gb2YgdGhpcyBk b2N1bWVudCBpcyB0byByZS11c2UgZXhpc3RpbmcgdGVjaG5pcXVlcyBpbiAN CiAgICAgICBJUHNlYyBhcmNoaXRlY3R1cmUgYW5kIHRoZXJlZm9yZSB0aGUg U0RQLCBTQUQgYW5kIHdpbGwgZm9sbG93IHRoZSANCiAgICAgICBmb3JtYXQg b2YgdGhlc2UgZGF0YWJhc2VzIGFzIGRlZmluZWQgaW4gUkZDIDQzMDEgW3Jm YyA0MzAxXS4gDQogICAgICAgVGhlIGVuY3J5cHRpb24gaXMgZG9uZSBvbiB0 aGUgZW50aXJlIFBEVSBpbmNsdWRpbmcgdGhlIGNoZWNrc3VtLiAgDQogICAg ICAgSW4gdGhlIGNhc2Ugb2YgdXNpbmcgc2VxdWVuY2UgbnVtYmVycyB0aGUg c2VxdWVuY2UgbnVtYmVyIGZpZWxkICANCiAgICAgICBpcyBub3QgaW5jbHVk ZWQgaW4gdGhlIGVuY3J5cHRpb24gcHJvY2VzcyBJbiBvcmRlciB0byBwcmV2 ZW50IA0KICAgICAgIGFnYWluc3QgdGhlIGhpamFja2luZyBvZiB0aGUgTVBF RzItVFMgdHJhbnNwb3J0IHN0cmVhbSwgYSBzb3VyY2UgDQogICAgICAgYXV0 aGVudGljYXRpb24gaW50ZWdyaXR5IGJsb2NrIGlzIGFwcGVuZGVkIHRvIHRo ZSBhYm92ZSBtZW50aW9uZWQgDQogICAgICAgZW5jcnlwdGVkIGJsb2NrLiBU aGlzIGludGVncml0eSBpcyBhcHBsaWVkIG92ZXIgdGhlIHdob2xlIFNORFUg DQogICAgICAgaW5jbHVkaW5nIHRoZSBoZWFkZXIgYW5kIGFmdGVyIGVuY3J5 cHRpb24gKGFuZCBpZiBpbmNsdWRlZCB0aGUgDQogICAgICAgc2VxdWVuY2Ug bnVtYmVyIGZpZWxkIHRvbykuIEF0IHRoZSByZWNlaXZlciBlbmQgaWYgdGhl IGludGVncml0eSANCiAgICAgICBjaGVjayBmYWlscyB0aGUgcmVjZWl2ZXIg Y2FuIGRyb3AgdGhlIHBhY2tldCB3aXRob3V0IGRlY3J5cHRpbmcgIA0KICAg ICAgIHRoZSBwYWNrZXQuIFRoZSBjaG9pY2Ugb2YgdGhlIGludGVncml0eSBz ZXJ2aWNlIGlzIGZsYWdnZWQgYXMgYSANCiAgICAgICBtYXR0ZXIgb2YgcG9s aWN5IGJ5IHRoZSBnYXRld2F5IGFuZCBpcyBoYW5kbGVkIGJ5IHRoZSBrZXkg IA0KICAgICAgIG1hbmFnZW1lbnQgc3lzdGVtLiANCiAgICAgICAgDQogICAg ICAgSW4gb3JkZXIgdG8gcHJldmVudCByZXBsYXkgYXR0YWNrcywgdGhlIG9w dGlvbmFsIGZpZWxkIG9mICANCiAgICAgICBzZXF1ZW5jZSBudW1iZXIgaXMg YWRkZWQgdG8gdGhlIGVuY3J5cHRlZCBwYXlsb2FkLiBUaGlzIGZpZWxkIGlz IA0KICAgICAgIGxlZnQgaW4gdGhlIG9wZW4gYW5kIGRvZXMgbm90IG5lZWQg dG8gYmUgZW5jcnlwdGVkLiBJdCBpcyBhIDMyICANCiAgICAgICBiaXQgdmFs dWUgYW5kIGl0IGZvbGxvd3MgdGhlIFVMRS1TSUQgZmllbGQuIFRoZSBjaG9p Y2Ugb2YgdXNpbmcgDQogICAgICAgc2VxdWVuY2UgbnVtYmVycyBpcyBkaWN0 YXRlZCBieSBwb2xpY3kgYW5kIGlzIGRvbmUgYnkgdGhlIGtleSANCgwgICAg ICAgbWFuYWdlbWVudCBzeXN0ZW0uIA0KICAgICAgICANCiAgICAgICAgDQog ICAgIA0KICAgIDIuMiBFbmNyeXB0aW9uIEV4dGVuc2lvbiBIZWFkZXIgZm9y bWF0IA0KICAgICAgDQogICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA2ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3BhZ2UgNF0gDQoM ICAgIElOVEVSTkVUIERSQUZUIEVuY2Fwc3VsYXRpb24gZm9yIElQIG92ZXIg TVBFRy0yL0RWQiAgICAgICAgTWF5IDIwMDYgDQogICAgIA0KICAgICANCiAg ICAgDQogICAgICAgQSBVTEUgW2lwZHZiLXVsZV0gZW5jcnlwdGlvbiBoZWFk ZXIgZXh0ZW5zaW9uIGlzIGRlZmluZWQgZm9yIHVzZSANCiAgICAgICB3aXRo IGFueSBVTEUgcGF5bG9hZC4gVGhpcyBleHRlbnNpb24gaGVhZGVyIE1BWSBk aXJlY3RseSBmb2xsb3cgIA0KICAgICAgIHRoZSBVTEUgYmFzZSBoZWFkZXIg KGFzIGlsbHVzdHJhdGVkIGluIGZpZ3VyZXMgMSBhbmQgMikuIEl0IE1BWSAg DQogICAgICAgYWxzbyBmb2xsb3cgYW5vdGhlciBzcGVjaWZpZWQgZXh0ZW5z aW9uIGhlYWRlci4gDQogICAgICAgIA0KICAgICAgIFRoZSBFbmNyeXB0aW9u IEV4dGVuc2lvbiBpcyBhIE1hbmRhdG9yeSBVTEUgRXh0ZW5zaW9uIEhlYWRl ci4gIA0KICAgICAgIFRoaXMgbWVhbnMgdGhhdCBhIFJlY2VpdmVyIE1VU1Qg ZWl0aGVyIHByb2Nlc3MgdGhpcyBoZWFkZXIsICANCiAgICAgICBiZWZvcmUg aXQgcHJvY2Vzc2VzIHRoZSBuZXh0IGhlYWRlciAob3IgdGhlIGVuY2xvc2Vk IFBEVSk7ICANCiAgICAgICBvdGhlcndpc2UgdGhlIGVudGlyZSBTTkRVIGlz IHRvIGJlIGRpc2NhcmRlZC4gVGhlIGZpcnN0IHR3byAgDQogICAgICAgYnl0 ZXMgb2YgdGhlIGVuY3J5cHRlZCBkYXRhIGJsb2NrIGNvbnRhaW4gYSBVTEUg VHlwZSBmaWVsZCwgIA0KICAgICAgIGRlZmluZWQgYnkgW2lwZHZiLXVsZV0g dGhhdCBzcGVjaWZpZXMgdGhlIHR5cGUvZXh0ZW5zaW9uIGhlYWRlciAgDQog ICAgICAgdGhhdCBmb2xsb3dzLiANCiAgICAgICAgIA0KICAgICAgIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBvbmUgY29kZS1wb2ludCBmb3IgZW5jcnlwdGlv biBoZWFkZXJzLiAgDQogICAgICAgU05EVXMgdGhhdCBhcmUgbm90IGVuY3J5 cHRlZCBkbyBOT1QgaW5jbHVkZSB0aGlzIGhlYWRlci4gDQogICAgICAgIA0K ICAgICAgIElBTkEgYWN0aW9uIGlzIHJlcXVpcmVkIHRvIGFzc2lnbiBhIG9u ZSBjb2RlIHBvaW50IGZyb20gVUxFIA0KICAgICAgIE1hbmRhdG9yeSBOZXh0 LUxheWVyLUhlYWRlciBSZWdpc3RyeS4gDQogICAgICAgIA0KICAgICAgIDAw WVkgU2VjdXJlIFVMRSBBICANCiAgICAgICAgDQogICAgICAgVGhlIFVMRSBT ZWN1cml0eSBJRGVudGlmaWVyIChVTEUtU0lEKSBpcyBhIDMyIGJpdCB2YWx1 ZS4gVGhlICANCiAgICAgICBVTEUtU0lEIGNhbiBiZSB1c2VkIGJ5IGEgUmVj ZWl2ZXIgdG8gZmlsdGVyIFBEVXMgaW4gIA0KICAgICAgIGNvbmp1bmN0aW9u IHdpdGggdGhlIHNldCBvZiBNQUMvTlBBIGFkZHJlc3NlcyB0aGF0IGl0IHdp c2hlcyB0byANCiAgICAgICByZWNlaXZlLiBVTEUtU0lEIHRvIGhhdmUgYSBz aW1pbGFyIGZvcm1hdCB0byB0aGUgU2VjdXJpdHkgIA0KICAgICAgIFBhcmFt ZXRlciBJbmRleCAoU1BJKSB1c2VkIGluIElQU0VDIGFuZCBNU0VDIHByb3Rv Y29scy4gDQogICAgICAgIA0KICAgICAgIFRoZSBleHRlbnNpb24gTUFZIGJl IHVzZWQgd2l0aCBQRFVzIHRoYXQgY2FycnkgYSBOUEEvTUFDIGFkZHJlc3Mg DQogICAgICAgKEQ9MCkgb3Igd2l0aCBQRFVzIHRoYXQgb21pdCB0aGlzIGZp ZWxkIChEPTEpLiBJbiB0aGUgbGF0dGVyICANCiAgICAgICBjYXNlLCB0aGVy ZSBpcyBubyBNQUMgYWRkcmVzcyBwcmVzZW50IHRvIGEgcmVjZWl2ZXIgb2Yg YW4gIA0KICAgICAgIGVuY3J5cHRlZCBVTEUgUERVLiANCiAgICAgDQogICAg ICAgUmVjZWl2ZXIgTlBBL01BQyBhZGRyZXNzIGhpZGluZyBpcyBhbiBpbXBv cnRhbnQgb2JqZWN0aXZlIGZvciBVTEUgDQogICAgICAgc2VjdXJpdHkuICBV c2luZyBvcHRpb24gRD0xIChubyBNQUMvTlBBIGFkZHJlc3MpIGlzIE9LIGFz IGxvbmcgYXMgDQogICAgICAgdGhlIFVMRS1TSUQgaXMgdW5pcXVlIGluIHRo ZSB3aG9sZSBVTEUgbmV0d29yay4gIFRoaXMgaW1wbGllcyB0aGUgDQogICAg ICAgbmVlZCBmb3IgYSBjZW50cmFsaXNlZCBrZXkgbWFuYWdlbWVudCBzeXN0 ZW0gdGhhdCBnZW5lcmF0ZXMgdGhlICANCiAgICAgICBVTEUtU0lELiBJZiBN QUMvTlBBIGFkZHJlc3MgaXMgdXNlZCAob3B0aW9uIEQ9MCksIHRoZW4gdGhl ICANCiAgICAgICBOZXR3b3JrIENvbnRyb2wgQ2VudGVyIChOQ0MpIGlzIHJl c3BvbnNpYmxlIGZvciBnZW5lcmF0aW5nIHRoaXMgDQogICAgICAgdGVtcG9y YXJ5IE1BQy9OUEEgYWRkcmVzcy4gVGhlIHRlbXBvcmFyeSBNQUMvTlBBIGFk ZHJlc3Mgc2hvdWxkICANCiAgICAgICBiZSB1c2VkIGZvciBhbGwgc2VjdXJl IGNvbW11bmljYXRpb25zIHdpdGggdGhhdCBSZWNlaXZlci4gSW4gIA0KICAg ICAgIGFkZGl0aW9uLCB0aGUgdGVtcG9yYXJ5IE1BQy9OUEEgYWRkcmVzcyB3 aWxsIGNoYW5nZSBmcm9tIHRpbWUgdG8gDQogICAgICAgdGltZSBkZXBlbmRp bmcgb24gdGhlIHNlY3VyaXR5IHBvbGljeSBhbmQgaXQgaXMgbm90IGRpcmVj dGx5ICANCiAgICAgICByZWxhdGVkIHRvIGVhY2ggVUxFIHNlc3Npb24uIEl0 IGNhbiBjaGFuZ2UgcGVyaW9kaWNhbGx5IChmb3IgIA0KICAgICAgIGV4YW1w bGUgYWZ0ZXIgYSBzcGVjaWZpZWQgcGVyaW9kIG9mIHRpbWUgYW5kL29yIGFm dGVyIGEgc3BlY2lmaWVkIA0KICAgICAgIHZvbHVtZSBvZiB0cmFmZmljIGhh cyBiZWVuIHNlbnQgdG8gdGhhdCB0ZXJtaW5hbCkuICBUaGUgdGVtcG9yYXJ5 IA0KICAgICAgIE1BQy9OUEEgYWRkcmVzcyBpcyB1c2VkIGluIGFzc29jaWF0 aW9uIHdpdGggdGhlIFVMRS1TSUQgZm9yICANCiAgICAgICBzcGVjaWZpYyBz ZXNzaW9uIHNlY3VyaXR5LiBJdCBpcyBlbnZpc2FnZWQgdGhhdCB0aGVyZSB3 aWxsIGJlICANCiAgICAgICBzbWFsbCBpbXBhY3Qgb24gdGhlIE5DQyBmb3Ig aGFuZGxpbmcgdHdvIE1BQy9OUEEgYWRkcmVzc2VzIGZvciAgDQogICAgICAg ZWFjaCB0ZXJtaW5hbC4gDQogICAgICAgIA0KICAgICAgIEluIG9yZGVyIHRv IHByZXZlbnQgcmVwbGF5IGF0dGFja3MgYSBvcHRpb25hbCAzMi1iaXQgc2Vx dWVuY2UgIA0KICAgICAgIG51bWJlciBoYXMgYmVlbiBhZGRlZCB0byB0aGUg VUxFIFNORFUuIFRoZSB2YWx1ZSBvZiB0aGlzIHNlcXVlbmNlIA0KICAgICAg IG51bWJlciB3b3VsZCBiZSBzZXQgdG8gMCBhdCB0aGUgYmVnaW5uaW5nIG9m IHRoZSBzZXNzaW9uLiAgVGhlIA0KICAgICAgIGdhdGV3YXkgd291bGQgbW9u b3RvbmljYWxseSBpbmNyZW1lbnQgdGhpcyBudW1iZXIgd2hlbiBpdCBzZW5k cyBhIA0KICAgICAgIHBhY2tldCB0byB0aGUgcmVjZWl2ZXIgYW5kIHRoZSBy ZWNlaXZlciB3b3VsZCB2ZXJpZnkgdGhlIGNvcnJlY3QgDQoMICAgICAgIHNl cXVlbmNlIG51bWJlci4gSWYgYW4gYWR2ZXJzYXJ5IHRyaWVzIHRvIGluamVj dCBvciByZXBsYXkgb2xkIA0KICAgICAgIHBhY2tldHMgdGhlIHNlcXVlbmNl IG51bWJlciB3b3VsZCBub3QgbWF0Y2guIFRoaXMgd291bGQgcmVzdWx0IGlu IA0KICAgICAgIGRpc2NhcmRpbmcgdGhlIHBhY2tldC4gDQogICAgICAgIA0K ICAgICAgIFRoZSBvcHRpb25hbCBzb3VyY2UgYXV0aGVudGljYXRpb24gYmxv Y2sgaXMgbmVjZXNzYXJ5IGluICANCiAgICAgIA0KICAgIEV4cGlyZXMgTm92 ZW1iZXIgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtwYWdlIDVdIA0KDCAgICBJTlRFUk5FVCBEUkFGVCBFbmNhcHN1bGF0 aW9uIGZvciBJUCBvdmVyIE1QRUctMi9EVkIgICAgICAgIE1heSAyMDA2IA0K ICAgICANCiAgICAgDQogICAgICAgc2l0dWF0aW9ucyB3aGVyZSB0aGUgTVBF RzItVFMgc3RyZWFtIGNhbiBiZSBoaWphY2tlZC4gVGhpcyBibG9jayANCiAg ICAgICBwcmV2ZW50cyB0aGUgYXR0YWNrIGFuZCBhbHNvIHByb3ZpZGVzIGRh dGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uLiANCiAgICAgICBMaWdodCB3ZWln aHQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyAoZS5nLiBURVNMQSBbdGVz bGFdIGNvdWxkICANCiAgICAgICBiZSB1c2VkIGZvciB0aGlzIHNlY3VyaXR5 IHNlcnZpY2UuIA0KICAgICANCiAgICAgICAgDQogICAgICAgICArLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rIA0K ICAgICAgICAgfDAgfCAgICAgTGVuZ3RoICgyQikgICAgfCAgIFR5cGUgPSBT ZWN1cmUgVUxFICAgfCANCiAgICAgICAgICstLSstLSstLSstLSstLSstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSsgDQogICAgICAgICB8ICAg IFJlY2VpdmVyIHRlbXBvcmFyeSBOUEEgQWRkcmVzcyAoNkIpICAgICAgICB8 IA0KICAgICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgKy0tKy0tKy0t Ky0tKy0tKy0tKy0tKy0tKyANCiAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgVUxFIFNJRCAgICAgICAgIHwgDQogICAgICAgICAr LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0r LS0rIA0KICAgICAgICAgfCAgICAgICAgVUxFIFNJRCAgICAgICAgfFNlcS4g TnVtYmVyIChvcHRpb25hbCkgfCANCiAgICAgICAgICstLSstLSstLSstLSst LSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLXwgDQogICAgICAg ICArICAgIFNlcSBOdW1iZXIgKDRCKSAgICB8ICAgICAgICAgICAgICAgICAg ICAgICB8IA0KICAgICAgICAgfC0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKyAg ICAgICAgICAgICAgICAgICAgIHwgfCANCiAgICAgICAgIHwgICAgICAgICAg ICAgICBFbmNyeXB0ZWQgQmxvY2sgICAgICAgICAgICAgICAgIHwgDQogICAg ICAgICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0r LS0rLS0rLS0rIA0KICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgIHwgICAgICAg ICAgSW50ZWdyaXR5IEJsb2NrIChvcHRpb25hbCkgICAgICAgICAgIHwgDQog ICAgICAgICArLS0rLS0rLS0rLS0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0t Ky0tKy0tKy0tKy18IA0KICAgICAgICANCiAgICAgICBGaWd1cmUgMTogU05E VSBGb3JtYXQgZm9yIHRoZSBFbmNyeXB0aW9uIEhlYWRlciAoRD0wKSANCiAg ICAgICAgDQogICAgICAgIA0KICAgICAgICAgKy0tKy0tKy0tKy0tKy0tKy0t Ky0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKyANCiAgICAgICAgIHwx IHwgICAgIExlbmd0aCAoMkIpICAgfCAgICAgVHlwZSA9IFNlY3VyZSBVTEUg IHwgDQogICAgICAgICArLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rIA0KICAgICAgICAgfCAgICAgICAgICAgICAg ICAgVUxFIFNJRCAoNEIpICAgICAgICAgICAgICAgICAgfCANCiAgICAgICAg ICstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSst LSstLSsgDQogICAgICAgICB8ICAgICAgIFNlcS4gTnVtYmVyIChvcHRpb25h bCkgKDRCKSAgICAgICAgICAgICB8IA0KICAgICAgICAgfC0tKy0tKy0tKy0t Ky0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKy0tKyANCiAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICsgDQogICAgICAgICAgICAgICAgICAgICAgICBFbmNyeXB0ZWQg QmxvY2sgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCiAg ICAgICAgICstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSstLSst LSstLSstLSstLSsgDQogICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgKyAgICAg ICAgICBJbnRlZ3JpdHkgQmxvY2sgKG9wdGlvbmFsKSAgICAgICAgICAgKyAN CiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgDQogICAgICAgICArLS0rLS0rLS0rLS0rLS0rLS0r LS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rLS0rIA0KICAgICAgICANCiAg ICAgICBGaWd1cmUgMjogU05EVSBGb3JtYXQgZm9yIHRoZSBFbmNyeXB0aW9u IEhlYWRlciAoRD0xKS4gDQogICAgICAgIA0KICAgICAgIFRoaXMgZW5jcnlw dGlvbiBoZWFkZXIgaGFzIGEgdHlwZSB2YWx1ZSB3aXRoIG9uZSBvZiB0d28g SUFOQS0NCiAgICAgICBhc3NpZ25lZCAxNi1iaXQgbmV4dC1sYXllci1oZWFk ZXIgdmFsdWVzLiANCiAgICAgDQogICAgIA0KICAgIDMgS2V5IEV4Y2hhbmdl IFByb2NlZHVyZXMgIA0KICAgICAgICANCiAgICAgICBUaGlzIHNlY3Rpb24g ZGVzY3JpYmVzIHRoZSBrZXkgZXhjaGFuZ2UgcHJvY2VkdXJlLCB1c2VkIHRv ICANCiAgICAgICBpbnN0YWxsIGFuZCBtYW5hZ2UgdGhlIGtleXMgYXQgUmVj ZWl2ZXJzLiAgVGhlcmUgaXMgYSBuZWVkIHRvICANCiAgICAgICB0YWtlIGlu dG8gYWNjb3VudCB0aGUgdHdvIGNhc2VzIGRlc2NyaWJlZCBpbiBbaXBkdmIt YXJjaF0sIGJvdGggDQogICAgICAgdW5pZGlyZWN0aW9uYWwgYW5kIGJpLWRp cmVjdGlvbmFsIHRyYW5zZmVycy4gIA0KICAgICAgICANCiAgICAgICBUaGUg a2V5IG1hbmFnZW1lbnQgcHJvY2VkdXJlcyBhcmUgaW5kZXBlbmRlbnQgZnJv bSB0aGUgVUxFIA0KDCAgICAgICBvcGVyYXRpb25zLiBEdXJpbmcgdGhlIGtl eSBleGNoYW5nZSBwcm9jZWR1cmUsIHRoZSBVTEUtU0lEIHdpbGwgIA0KICAg ICAgIGJlIGRlZmluZWQuIA0KICAgICAgICANCiAgICAgICBUaGUgZXhhY3Qg ZGF0YSBlbmNyeXB0aW9uIGFuZCBkYXRhIGludGVncml0eSBjaG9pY2VzIGFy ZSAgDQogICAgICAgbGlua2VkIHRvIHRoZSBrZXkgbWFuYWdlbWVudCBzeXN0 ZW1zIGluIHVzZS4gT25lIGV4YW1wbGUgaXMgdGhlICANCiAgICAgIA0KICAg IEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtwYWdlIDZdIA0KDCAgICBJTlRFUk5FVCBEUkFG VCBFbmNhcHN1bGF0aW9uIGZvciBJUCBvdmVyIE1QRUctMi9EVkIgICAgICAg IE1heSAyMDA2IA0KICAgICANCiAgICAgDQogICAgICAgc2VjdXJpdHkgc3Vp dGUgMSAoZGVmaW5lZCBpbiBHU0FLTVAgW21zZWMtZ3Nha21wXSkuICBUaGlz IHVzZXMgIA0KICAgICAgIEFFUyAoQ0JDIG1vZGUsIEtleSBMZW5ndGg6IDEy OCBiaXRzKSBmb3IgZGF0YSBlbmNyeXB0aW9uIGFuZCAgDQogICAgICAgRFNT LUFTTjEtREVSIGZvciBkaWdpdGFsIHNpZ25hdHVyZSBhbmQgU0hBLTEgYXMg dGhlIEhhc2ggIA0KICAgICAgIGFsZ29yaXRobS4gT3RoZXIgc3VpdGVzIHdp bGwgYmUgYWRkZWQgaW4gZnV0dXJlIHZlcnNpb25zLiANCiAgICAgICAgDQog ICAgICAgQSBkZXRhaWxlZCBrZXkgbWFuYWdlbWVudCBzeXN0ZW0gaXMgbm90 IHByZXNlbnRlZCBpbiB0aGlzICANCiAgICAgICBkb2N1bWVudCwgYnV0IHR3 byBhcHByb2FjaGVzIGFyZSBvdXRsaW5lZC4gDQogICAgICAgIA0KICAgICAN CiAgICAzLjEgSVBzZWMgS2V5IE1hbmFnZW1lbnQgZm9yIEwyIA0KICAgICAg ICANCiAgICAgICBFeGlzdGluZyBrZXkgbWFuYWdlbWVudCBzeXN0ZW1zIGNh biBiZSB1c2VkIHN1Y2ggYXMgdGhlIE1TRUMga2V5IA0KICAgICAgIGV4Y2hh bmdlIHByb3RvY29scywgR0RPSSBhbmQgR1NBS01QIFttc2VjLWdkb2kgYW5k IG1zZWMtZ3Nha21wXS4gDQogICAgICAgVGhlIGZvcm1hdCBvZiB0aGUgVUxF LVNJRCB3aWxsIGJlIGlkZW50aWNhbCB0byB0aGUgc2VjdXJpdHkgDQogICAg ICAgYXNzb2NpYXRpb24gYXMgZGVmaW5lZCBpbiBHRE9JIG9yIEdTQUtNUC4g VGhlIGluaXRpYWwga2V5ICANCiAgICAgICBleGNoYW5nZSBiZXR3ZWVuIHRo ZSBzZWN1cml0eSBzZXJ2ZXIgKHdoaWNoIG1heSByZXNpZGUgd2l0aCBOQ0Mp ICANCiAgICAgICBhbmQgdGhlIFVMRSBSZWNlaXZlciBjYW4gYmUgdHJhbnNw b3J0ZWQgZWl0aGVyIHdpdGhpbiB0aGUgVUxFIA0KICAgICAgIG5ldHdvcmsg b3IgbWF5IGJlIHBlcmZvcm1lZCBieSBzb21lIG90aGVyIG1lYW5zLiAgVGhp cyBpcyBhICANCiAgICAgICBtYXR0ZXIgb2YgcG9saWN5IGFuZCBhbiBhcmNo aXRlY3R1cmUgZGVjaXNpb24uICBGb3IgZXhhbXBsZSwgZm9yICANCiAgICAg ICBiaS1kaXJlY3Rpb25hbCB0cmFuc2ZlcnMgdGhlIHdob2xlIGtleSBleGNo YW5nZSBwcm9jZWR1cmVzIGNvdWxkICANCiAgICAgICBiZSBjYXJyaWVkIHdp dGhpbiB0aGUgVUxFIG5ldHdvcmssIHdoaWxlIGZvciB1bmlkaXJlY3Rpb25h bCANCiAgICAgICB0cmFuc2ZlcnMsIHNvbWUgb3RoZXIgYmlkaXJlY3Rpb25h bCBjb25uZWN0aW9uIHNob3VsZCBiZSB1c2VkLiANCiAgICAgICAgDQogICAg ICAgIA0KICAgIDMuMiBBbHRlcm5hdGl2ZSBLZXkgTWFuYWdlbWVudCAgDQog ICAgICAgIA0KICAgICAgIFRoZSBtZXRob2QgZGVzY3JpYmVkIGhlcmUgZm9y IGxpbmsgZW5jcnlwdGlvbiBjb3VsZCBiZSB1c2VkIHdpdGggDQogICAgICAg YWx0ZXJuYXRpdmUga2V5IG1hbmFnZW1lbnQgc3lzdGVtcyB3aGVuIHVzZWQg IA0KICAgICAgIGFzIGEgcGFydCBvZiBhIHN5c3RlbSB0aGF0IGFscmVhZHkg aW1wbGVtZW50cyBhIGtleSBtYW5hZ2VtZW50IA0KICAgICAgIGluZnJhc3Ry dWN0dXJlIChlLmcuIHRoZSBEVkItUkNTIHNlY3VyaXR5IHN5c3RlbSBbZXRz aS1kdmJyY3NdKS4gDQogICAgICAgVGhlIGZvcm1hdCBvZiB0aGUgVUxFLVNJ RCB3aWxsIGJlIHRoZSBzYW1lIGZvcm1hdCBhcyBkZWZpbmVkIGluICANCiAg ICAgICBEVkItUkNTIHNlY3VyaXR5IHByb2NlZHVyZXMuIA0KICAgICAgICAN CiAgICAgICAgDQogICAgNC4gU3VtbWFyeSANCiAgICAgICAgDQogICAgICAg VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHNlY3VyaXR5IGZyYW1ld29yayBm b3IgYSBsYXllciAyICANCiAgICAgICBzZWN1cml0eSBtZXRob2QgZGVzaWdu ZWQgZm9yIHRoZSBVbmlkaXJlY3Rpb25hbC1MaWdodHdlaWdodCANCiAgICAg ICBFbmNhcHN1bGF0aW9uIChVTEUpIHByb3RvY29sLiBJdCBwcm9wb3NlcyBh biBleHRlbnNpb24gZm9ybWF0IGZvciANCiAgICAgICB0aGUgVW5pZGlyZWN0 aW9uYWwgTGlnaHR3ZWlnaHQgRW5jYXBzdWxhdGlvbiAoVUxFKSBwcm90b2Nv bC4gIA0KICAgICAgIFRoZSBrZXkgbWFuYWdlbWVudCBmb3IgdGhpcyBwcm90 b2NvbCBtYXkgYmUgcGVyZm9ybWVkIHVzaW5nIElQc2VjIA0KICAgICAgIG1l dGhvZHMgc3VjaCBhcyB0aGUgbXNlYyBnc2FrbXAgYW5kIGdkb2kgcHJvdG9j b2xzIG9yIHVzaW5nIG90aGVyIA0KICAgICAgIG1ldGhvZHMgbm90IGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudC4gDQogICAgICAgIA0KICAgICAgICANCiAg ICA1LiBBY2tub3dsZWRnbWVudHMgDQogICAgICAgIA0KICAgICAgIFRoZSBh dXRob3JzIGFja25vd2xlZGdlIHRoZSBoZWxwIGFuZCBhZHZpY2UgZnJvbSBH b3JyeSAgDQogICAgICAgRmFpcmh1cnN0IChVbml2ZXJzaXR5IG9mIEFiZXJk ZWVuKSBpbiB0aGUgcHJlcGFyYXRpb24gb2YgdGhpcyAgDQogICAgICAgZHJh ZnQuIA0KICAgICAgICANCiAgICAgICAgDQogICAgNi4gU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgDQogICAgIA0KICAgICAgIExpbmstbGV2ZWwgKEwyKSBl bmNyeXB0aW9uIG9mIElQIHRyYWZmaWMgaXMgY29tbW9ubHkgdXNlZCBpbiAN CiAgICAgICBicm9hZGNhc3QvcmFkaW8gbGlua3MgdG8gc3VwcGxlbWVudCBF bmQtdG8tRW5kIHNlY3VyaXR5IChlLmcuIA0KDCAgICAgICBwcm92aWRlZCBi eSBUTFMsIFNTSCwgT3BlbiBQR1AsIFMvTUlNRSwgSVBzZWMpLiBBIGNvbW1v biAgDQogICAgICAgb2JqZWN0aXZlIGlzIHRvIHByb3ZpZGUgdGhlIHNhbWUg bGV2ZWwgb2YgcHJpdmFjeSBhcyB0ZXJyZXN0cmlhbCANCiAgICAgICBsaW5r cy4gQW4gSVNQIG9yIFVzZXIgbWF5IGFsc28gd2lzaCB0byBwcm92aWRlIGVu ZC10by1lbmQgIA0KICAgICAgIHNlY3VyaXR5IHNlcnZpY2VzIHRvIHRoZSBl bmQtdXNlcnMgKGJhc2VkIG9uIHRoZSB3ZWxsIGtub3duIA0KICAgICAgIG1l Y2hhbmlzbXMgc3VjaCBhcyBJUHNlYykuIA0KICAgICAgDQogICAgRXhwaXJl cyBOb3ZlbWJlciAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW3BhZ2UgN10gDQoMICAgIElOVEVSTkVUIERSQUZUIEVuY2Fw c3VsYXRpb24gZm9yIElQIG92ZXIgTVBFRy0yL0RWQiAgICAgICAgTWF5IDIw MDYgDQogICAgIA0KICAgICANCiAgICAgICAgDQogICAgICAgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgbWV0aG9kIHRvIHByb3ZpZGUgb3B0aW9uYWwgbGlu ayAgDQogICAgICAgZW5jcnlwdGlvbi4gVGhlIG1ldGhvZCBtYXkgYWxzbyBz dXBwb3J0IG9wdGlvbmFsIGxpbmsgbGV2ZWwgDQogICAgICAgaW50ZWdyaXR5 IC8gYXV0aGVudGljYXRpb24gb2YgdGhlIFNORFUgcGF5bG9hZCBwbHVzIHNl cXVlbmNlICANCiAgICAgICBudW1iZXJzIGZvciBhbnRpLXJlbGF5IGF0dGFj a3MuICANCiAgICAgICAgDQogICAgICAgVGhpcyBpcyBwcm92aWRlZCBpbiBh IGZsZXhpYmxlIHdheSB1c2luZyBhIFVMRSBNYW5kYXRvcnkgIA0KICAgICAg IEV4dGVuc2lvbiBIZWFkZXIuIFRoaXMgZGVjb3VwbGVzIHNwZWNpZmljYXRp b24gb2YgdGhlIHNlY3VyaXR5IA0KICAgICAgIGZ1bmN0aW9ucyBmcm9tIHRo ZSBlbmNhcHN1bGF0aW9uIGZ1bmN0aW9ucy4gVGhpcyBtZXRob2QgYWxzbyAN CiAgICAgICBzdXBwb3J0cyBlbmNyeXB0aW9uIG9mIHRoZSBOUEEvTUFDIGFk ZHJlc3Nlcy4gIFRoZSBlbmNyeXB0aW9uICANCiAgICAgICBhbmQgaW50ZWdy aXR5IGFsZ29yaXRobXMgYXJlIHNpbWlsYXIgdG8gdGhlIG9uZXMgdXNlZCBp biAgDQogICAgICAgSVBTRUMvTVNFQyBwcm90b2NvbHMuIA0KICAgICANCiAg ICAgICAgDQogICAgNy4gUmVmZXJlbmNlcyANCiAgICAgDQogICAgICAgNy4x IE5vcm1hdGl2ZSBSZWZlcmVuY2VzICANCiAgICAgICAgDQogICAgICAgW2lz by1tcGVnXSBJU08vSUVDIERJUyAxMzgxOC0xICJJbmZvcm1hdGlvbiB0ZWNo bm9sb2d5IC0tICANCiAgICAgICBHZW5lcmljIGNvZGluZyBvZiBtb3Zpbmcg cGljdHVyZXMgYW5kIGFzc29jaWF0ZWQgYXVkaW8gIA0KICAgICAgIGluZm9y bWF0aW9uOiBTeXN0ZW1zIiwgSW50ZXJuYXRpb25hbCBTdGFuZGFyZHMgT3Jn YW5pc2F0aW9uICANCiAgICAgICAoSVNPKS4gDQogICAgICAgIA0KICAgICAg IFtldHNpLWRhdF0gRU4gMzAxIDE5MiwgIkRpZ2l0YWwgVmlkZW8gQnJvYWRj YXN0aW5nICANCiAgICAgICAoRFZCKTsgRFZCIFNwZWNpZmljYXRpb25zIGZv ciBEYXRhIEJyb2FkY2FzdGluZyIsICANCiAgICAgICBFdXJvcGVhbiBUZWxl Y29tbXVuaWNhdGlvbnMgU3RhbmRhcmRzIEluc3RpdHV0ZSAoRVRTSSkuIA0K ICAgICAgICANCiAgICAgICBbcmZjIDIxMTldIEJyYWRuZXIsIFMuLCAiS2V5 IFdvcmRzIGZvciBVc2UgaW4gUkZDcyB0byBJbmRpY2F0ZSANCiAgICAgICBS ZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAx OTk3LiANCiAgICAgICAgDQogICAgICAgW2lwZHZiLXVsZV0gRmFpcmh1cnN0 LCBHLiwgQ29sbGluaS1Ob2NrZXIsICJVbmRpcmVjdGlvbmFsIA0KICAgICAg IExpZ2h0d2VpZ2h0IEVuY2Fwc3VsYXRpb24gKFVMRSkgZm9yIHRyYW5zbWlz c2lvbiBvZiBJUCAgDQogICAgICAgZGF0YWdyYW1zIG92ZXIgYW4gTVBFRy0y IFRyYW5zcG9ydCBTdHJlYW0iLCA8ZHJhZnQtaWV0Zi11bGUtIA0KICAgICAg IDA2LnR4dD4sIElFVEYgV29yayBpbiBQcm9ncmVzcy4gDQogICAgICAgIA0K ICAgICAgIDcuMiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIA0KICAgICAgICAg ICAgDQogICAgICAgW2V0c2ktZHZicmNzXSAiRGlnaXRhbCBWaWRlbyBCcm9h ZGNhc3RpbmcgKERWQikgLS0gaW50ZXJhY3Rpb24gDQogICAgICAgY2hhbm5l bCBmb3Igc2F0ZWxsaXRlIGRpc3RyaWJ1dGlvbiBzeXN0ZW1zIiwgRVRTSSBF TiAzMDEgNzkwICANCiAgICAgICBWMS40LjEgKDIwMDUtMDQpIA0KICAgICAg ICANCiAgICAgICBbbXNlYy1nc2FrbXBdIEggSGFybmV5IChTUEFSVEEgKSwg ZXQgYWwsICJHU0FLTVA6IEdyb3VwIFNlY3VyZSANCiAgICAgICBBc3NvY2lh dGlvbiBHcm91cCBNYW5hZ2VtZW50IFByb3RvY29sIiwgPGRyYWZ0LWlldGYt bXNlYy1nc2FrbXAgDQogICAgICAgLXNlYy0xMC50eHQ+LCBJRVRGIFdvcmsg aW4gUHJvZ3Jlc3MuIA0KICAgICANCiAgICAgICBbbXNlYy1nZG9pLCBSRkMg MzU0N10gTS4gQmF1Z2hlciAsIGV0IGFsLCAiR0RPSTogVGhlIEdyb3VwICAN CiAgICAgICBEb21haW4gb2YgSW50ZXJwcmV0YXRpb24iIFJGQyAzNTQ3LiAN CiAgICAgICAgDQogICAgICAgW25hdCwgcmZjIDM3MTVdIEIuIEFib2JhIGFu ZCBXIERpeHNvbiwgIiBJUHNlYy1OZXR3b3JrIEFkZHJlc3MgDQogICAgICAg VHJhbnNsYXRpb24gKE5BVCkgQ29tcGF0aWJpbGl0eSBSZXF1aXJlbWVudHMi IA0KICAgICAgICANCiAgICAgICBbaXBkdmItYXJjaF0gTS5KLiBNb250cGV0 aXQgZWQuLCBldCBhbCwgIkZyYW1ld29yayBmb3IgIA0KICAgICAgIHRyYW5z bWlzc2lvbiBvZiBJUCBkYXRhZ3JhbXMgb3ZlciBNUEVHLTIgTmV0d29ya3Mi LCA8ZHJhZnQtaWV0Zi0NCiAgICAgICBpcGR2Yi1hcmNoLTA0LnR4dD4sIElF VEYgV29yayBpbiBQcm9ncmVzcy4gDQogICAgICAgIA0KICAgICAgIFttc2Vj XSBodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbXNlYy1jaGFy dGVyLmh0bWwgDQoMICAgICAgICANCiAgICAgICBbSVBzZWNdIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy93Zy0NCiAgICAgICBkaXIuaHRt bCNTZWN1cml0eSUyMEFyZWEuIFJGQ3MgMjQwMSwgMjQwMiBhbmQgMjQwNiAN CiAgICAgICAgDQogICAgICAgW3Rsc10gaHR0cDovL3d3dy5pZXRmLm9yZy9o dG1sLmNoYXJ0ZXJzL3Rscy1jaGFydGVyLmh0bWwgDQogICAgICANCiAgICBF eHBpcmVzIE5vdmVtYmVyIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbcGFnZSA4XSANCgwgICAgSU5URVJORVQgRFJBRlQg RW5jYXBzdWxhdGlvbiBmb3IgSVAgb3ZlciBNUEVHLTIvRFZCICAgICAgICBN YXkgMjAwNiANCiAgICAgDQogICAgIA0KICAgICAgICANCiAgICAgICBbcmZj IDMxMzVdIEJvcmRlciwgSi4sIEtvam8sIE0uLCBHcmluZXIsIEouLCBNb250 ZW5lZ3JvLCBHLiwgIA0KICAgICAgIGFuZCBaLiBTaGVsYnksICJQZXJmb3Jt YW5jZSBFbmhhbmNpbmcgUHJveGllcyBJbnRlbmRlZCB0byAgDQogICAgICAg TWl0aWdhdGUgTGluay1SZWxhdGVkIERlZ3JhZGF0aW9ucyIsIFJGQyAzMTM1 LCBKdW5lIDIwMDEuIA0KICAgICAgICANCiAgICAgICBbcmZjIDQzMDFdIFMu IEtlbnQsIGV0IGFsLCAiU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIGZvciB0aGUg IA0KICAgICAgIEludGVybmV0IFByb3RvY29sIiwgUkZDIDQzMDEsIERlY2Vt YmVyIDIwMDYuIA0KICAgICAgICANCiAgICAgICBbdGVzbGFdIEEuIFBlcnJp ZywgZXQgYWwsICJUaW1lZCBFZmZpY2llbnQgU3RyZWFtIExvc3MtIA0KICAg ICAgIFRvbGVyYW50IEF1dGhlbnRpY2F0aW9uIiwgUkZDIDQwODIsIEp1bmUg MjAwNS4gDQogICAgICAgIA0KICAgICANCiAgICAgDQogICAgOC5BdXRob3Jz JyBBZGRyZXNzZXMgDQogICAgICAgIA0KICAgICANCiAgICAgICBIYWl0aGFt IENydWlja3NoYW5rICANCiAgICAgICBDZW50cmUgZm9yIENvbW11bmljYXRp b25zIFN5c3RlbSBSZXNlYXJjaCAoQ0NTUikgIA0KICAgICAgIFVuaXZlcnNp dHkgb2YgU3VycmV5IA0KICAgICAgIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIg N1hIICANCiAgICAgICBVSyAgDQogICAgICAgRW1haWw6IGguY3J1aWNrc2hh bmtAc3VycmV5LmFjLnVrICANCiAgICAgICAgDQogICAgICAgU3VuaWwgSXll bmdhciAgDQogICAgICAgQ2VudHJlIGZvciBDb21tdW5pY2F0aW9ucyBTeXN0 ZW0gUmVzZWFyY2ggKENDU1IpICANCiAgICAgICBVbml2ZXJzaXR5IG9mIFN1 cnJleSANCiAgICAgICBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdYSCAgDQog ICAgICAgVUsgIA0KICAgICAgIEVtYWlsOiBTLkl5ZW5nYXJAc3VycmV5LmFj LnVrICANCiAgICAgDQogICAgICAgTGF1cmVuY2UgRHVxdWVycm95ICANCiAg ICAgICBSZXNlYXJjaCBEZXBhcnRtZW50L0FkdmFuY2VkIFRlbGVjb20gU2F0 ZWxsaXRlIFN5c3RlbXMgDQogICAgICAgQWxjYXRlbCBBbGVuaWEgU3BhY2Us IFRvdWxvdXNlIA0KICAgICAgIEZyYW5jZSANCiAgICAgICBFLU1haWw6IExh dXJlbmNlLkR1cXVlcnJveUBzcGFjZS5hbGNhdGVsLmZyIA0KICAgICAgICAN CiAgICAgICAgDQogICAgOS4gSVBSIE5vdGljZXMgDQogICAgIA0KICAgIDku MSBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IA0KICAgICAgICAN CiAgICAgICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcg dGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueSANCiAgICAgICBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1p Z2h0IGJlIGNsYWltZWQgDQogICAgICAgdG8gcGVydGFpbiB0byB0aGUgaW1w bGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJl ZCANCiAgICAgICBpbiB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCANCiAgICAgICByaWdodHMg bWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQg cmVwcmVzZW50IHRoYXQgDQogICAgICAgaXQgaGFzIG1hZGUgYW55IGluZGVw ZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIA0K ICAgICAgIEluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVz cGVjdCB0byByaWdodHMgaW4gUkZDIA0KICAgICAgIGRvY3VtZW50cyBjYW4g YmUgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuIA0KICAgICAgICANCiAg ICAgICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElF VEYgU2VjcmV0YXJpYXQgYW5kIGFueSANCiAgICAgICBhc3N1cmFuY2VzIG9m IGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0 IG9mIGFuIA0KICAgICAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5l cmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSANCiAgICAg ICBvZiBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMg b3IgdXNlcnMgb2YgdGhpcyANCiAgICAgICBzcGVjaWZpY2F0aW9uIGNhbiBi ZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRv cnkgDQogICAgICAgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuIA0KDCAg ICAgICAgDQogICAgICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3Rl ZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uICANCiAgICAgIA0K ICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtwYWdlIDldIA0KDCAgICBJTlRFUk5FVCBE UkFGVCBFbmNhcHN1bGF0aW9uIGZvciBJUCBvdmVyIE1QRUctMi9EVkIgICAg ICAgIE1heSAyMDA2IA0KICAgICANCiAgICAgDQogICAgICAgYW55IGNvcHly aWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3Ro ZXIgIA0KICAgICAgIHByb3ByaWV0YXJ5IHJpZ2h0cyB0aGF0IG1heSBjb3Zl ciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkICANCiAgICAgICB0 byBpbXBsZW1lbnQgdGhpcyBzdGFuZGFyZC4gUGxlYXNlIGFkZHJlc3MgdGhl IGluZm9ybWF0aW9uIHRvIHRoZSANCiAgICAgICBJRVRGIGF0IGlldGYtaXBy QGlldGYub3JnLiANCiAgICAgICAgDQogICAgOS4yIERpc2NsYWltZXIgb2Yg VmFsaWRpdHkgDQogICAgICAgIA0KICAgICAgIFRoaXMgZG9jdW1lbnQgYW5k IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRl ZCAgDQogICAgICAgb24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRS SUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSANCiAgICAgICBSRVBS RVNFTlRTIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVS TkVUIFNPQ0lFVFkgIA0KICAgICAgIEFORCBUSEUgSU5URVJORVQgRU5HSU5F RVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgDQog ICAgICAgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBM SU1JVEVEIFRPIEFOWSBXQVJSQU5UWSAgDQogICAgICAgVEhBVCBUSEUgVVNF IE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0Ug QU5ZICANCiAgICAgICBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElF UyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyAgDQogICAgICAgRk9S IEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCiAgICAgICAgDQogICAgICAgIA0K ICAgIDEwLiBDb3B5cmlnaHQgU3RhdGVtZW50IA0KICAgICAgICANCiAgICAg ICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4g DQogICAgICAgIA0KICAgICAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIA0KICAg ICAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZv cnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIA0KICAgICAgIHJldGFpbiBhbGwg dGhlaXIgcmlnaHRzLiANCiAgICAgICAgDQogICAgICAgIA0KICAgIDEyLiBJ QU5BIENvbnNpZGVyYXRpb25zICANCiAgICAgICAgDQogICAgICAgVGhpcyBk b2N1bWVudCB3aWxsIHJlcXVpcmUgSUFOQSBpbnZvbHZlbWVudC4gVG8gYXNz aWduIGEgcGFpciBvZiANCiAgICAgICBNYW5kYXRvcnkgaGVhZGVyIGV4dGVu c2lvbiB2YWx1ZXMgZnJvbSB0aGUgVUxFIFJlZ2lzdHJ5LiANCiAgICAgICAg DQogICAgICAgIA0KICAgICAgIEFubmV4ZSBBLiBFeGFtcGxlcyBvZiB1c2Ug DQogICAgICAgIA0KICAgICAgICAgICBObyBleGFtcGxlcyBvZiB1c2UgYXJl IHByb3ZpZGVkIGluIHRoaXMgcmV2aXNpb24gb2YgdGhlICANCiAgICAgICAg ICAgSS1ELiANCiAgICAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCgwgICAgICANCiAgICBFeHBpcmVzIE5vdmVtYmVyIDIw MDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtwYWdl IDEwXSANCgw= ------_=_NextPart_001_01C6751A.B678B0AF-- From owner-ipdvb@erg.abdn.ac.uk Fri May 12 08:18:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeWbO-0008V1-VH for ipdvb-archive@ietf.org; Fri, 12 May 2006 08:18:38 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeWbN-0007p6-4T for ipdvb-archive@ietf.org; Fri, 12 May 2006 08:18:38 -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 k4CBxkje011772 for ; Fri, 12 May 2006 12:59:46 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4CBxkM3011771 for ipdvb-subscribed-users; Fri, 12 May 2006 12:59:46 +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 lin.calsoft.co.in (lin.calsoft.co.in [203.129.222.68]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4CBxY34011752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 12 May 2006 12:59:38 +0100 (BST) Received: from [172.16.71.90] ([220.227.139.90]) (authenticated bits=0) by lin.calsoft.co.in (8.12.8/8.12.8) with ESMTP id k4CBxRs5015102 for ; Fri, 12 May 2006 17:29:34 +0530 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 12 May 2006 17:29:28 +0530 Subject: Re: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt From: William Stanislaus To: Ipdvb IETF Message-ID: Thread-Topic: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ03I1dy/fQjuDPEdqCEwAKlc/qXgA3vfKW In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-MailScanner: Found to be clean X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hello, I'm a bit confused, sometime before we received similar draft from P.Pillai on the same area ( secure ULE). The security requirements discussed by "draft-ppillai-ipdvb-sule-00.txt" are already discussed in detail by "draft-cruickshank-ipdvb-sec-req-01.txt". In general, the DVB terminals are just a forwarders i.e. Forwards IP packets from DVB interface to Ethernet interface (DVB-S/DVB-RCS) and forwards IP packets from Ethernet interface to DVB interface (DVB-RCS). They don't do much packet processing, that makes the DVB terminal simple and cheaper in performance. I was wondering there was no discussion in these drafts about the performance issues by implementing these security encryptions and decryptions. In these drafts it was referred to IPSEC and its functionalities, but at the same time we should not forget the IPSEC performance degrades and hardware based accelerators Best Regards, William Stanislaus | Technical Consultant Nortel Networks Division | CalSoft email: williams@calsoft.co.in | Mobile: (+91) 98409 10581 SkypeIn (VoIP): +1 (650) 515 3738 www.californiasw.com > From: Gorry Fairhurst > Reply-To: > Date: Thu, 11 May 2006 10:23:24 +0100 > To: "ipdvb@erg.abdn.ac.uk" > Conversation: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt > Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt > > > 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, S. Iyengar, L. Duquerroy > Filename : draft-cruickshank-ipdvb-sec-req-01.txt > Pages : 13 > Date : 2006-5-09 > > > 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-01.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-01.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 > > > Best wishes, > > G Fairhurst > (ipdvb WG Chair) > > > From owner-ipdvb@erg.abdn.ac.uk Fri May 12 08:56:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeXBb-0006Si-6T for ipdvb-archive@ietf.org; Fri, 12 May 2006 08:56:03 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeXBZ-0001gN-LV for ipdvb-archive@ietf.org; Fri, 12 May 2006 08:56:03 -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 k4CCbOm6014839 for ; Fri, 12 May 2006 13:37:24 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4CCbOXG014838 for ipdvb-subscribed-users; Fri, 12 May 2006 13:37: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 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 k4CCbFDl014822 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 12 May 2006 13:37:15 +0100 (BST) Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.6/8.13.4) with ESMTP id k4CCb3nS025454; Fri, 12 May 2006 13:37:04 +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 k4CCb2jX024999; Fri, 12 May 2006 13:37:03 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Fri, 12 May 2006 13:37:02 +0100 Message-ID: <1147437422.4464816ed28ab@webmail6.brad.ac.uk> Date: Fri, 12 May 2006 13:37:02 +0100 From: P.Pillai@Bradford.ac.uk To: William Stanislaus Cc: ipdvb@erg.abdn.ac.uk Subject: Re: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt In-Reply-To: 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.31.49 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 k4CCbOm6014839 X-Spam-Score: 0.2 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Hi William, The draft (draft-ppillai-ipdvb-sule-00.txt) that I submitted a few days b= ack (3rd May) was to look into how the different security requirements of dat= a confidentiality, data authentication, data integrity and replay attacks prevention can be met by using a modified ULE SNDU. It is not intended to= be a =93security requirement=94 draft. The reason why I have added the securit= y requirement section in my draft is because the security requirements draf= t (draft-cruickshank-ipdvb-sec-req-00.txt) that was submitted a few months = back did not address all these security requirements. The new revision of the security draft (draft-cruickshank-ipdvb-sec-req-0= 1.txt) submitted on the 9th of May now addresses the need for these different se= curity features. I agree with you that there are performance issues when security overhead= s would be added to ULE. But this is a price that one has to pay to get the secur= ity services. It is a trade-off. Also there are several hardware accelerators present that do enhance the performances of these security algorithms (bo= th for encryption and generation of MACs) Regards Prashant Pillai Quoting William Stanislaus : > Hello, > I'm a bit confused, sometime before we received similar draft from P.Pi= llai > on the same area ( secure ULE). > The security requirements discussed by "draft-ppillai-ipdvb-sule-00.txt= " are > already discussed in detail by "draft-cruickshank-ipdvb-sec-req-01.txt". > > In general, the DVB terminals are just a forwarders i.e. Forwards IP pa= ckets > from DVB interface to Ethernet interface (DVB-S/DVB-RCS) and forwards I= P > packets from Ethernet interface to DVB interface (DVB-RCS). They don't = do > much packet processing, that makes the DVB terminal simple and cheaper = in > performance. I was wondering there was no discussion in these drafts ab= out > the performance issues by implementing these security encryptions and > decryptions. In these drafts it was referred to IPSEC and its > functionalities, but at the same time we should not forget the IPSEC > performance degrades and hardware based accelerators > > Best Regards, > William Stanislaus | Technical Consultant > Nortel Networks Division | CalSoft > email: williams@calsoft.co.in | Mobile: (+91) 98409 10581 > SkypeIn (VoIP): +1 (650) 515 3738 > www.californiasw.com > > > > > > From: Gorry Fairhurst > > Reply-To: > > Date: Thu, 11 May 2006 10:23:24 +0100 > > To: "ipdvb@erg.abdn.ac.uk" > > Conversation: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt > > Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt > > > > > > 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, S. Iyengar, L. Duquerroy > > Filename : draft-cruickshank-ipdvb-sec-req-01.txt > > Pages : 13 > > Date : 2006-5-09 > > > > > > This document provides a threat analysis and derives security > > requirements for MPEG-2 transmission links using the Unidirectiona= l > > Lightweight Encapsulation (ULE). It also provides the motivation f= or > > ULE link level security. This work is intended as a work item of t= he > > ipdvb WG, and contributions are sought from the IETF on this topic. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-0= 1.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-01.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 > > > > > > Best wishes, > > > > G Fairhurst > > (ipdvb WG Chair) > > > > > > > > > --=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 Fri May 12 13:07:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feb6g-0000Lw-5w for ipdvb-archive@ietf.org; Fri, 12 May 2006 13:07:14 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Feb6e-0006zk-FM for ipdvb-archive@ietf.org; Fri, 12 May 2006 13:07:14 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4CH0E8D003408 for ; Fri, 12 May 2006 18:00:14 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4CH0Ebr003400 for ipdvb-subscribed-users; Fri, 12 May 2006 18:00: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 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 k4CH06jt003196 for ; Fri, 12 May 2006 18:00:07 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 18:00:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Date: Fri, 12 May 2006 18:00:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ03I1dy/fQjuDPEdqCEwAKlc/qXgA3vfKWAAmUNxA= From: To: Cc: , X-OriginalArrivalTime: 12 May 2006 17:00:02.0175 (UTC) FILETIME=[825D48F0:01C675E5] 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 k4CH0E0U003377 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: 0cff8c3ec906d056784362c06f5f88c1 Hi William, This draft ( draft-cruickshank-ipdvb-sec-req-01.txt) is about specifying the actual security requirements before talking about solutions. Currently, there are two proposed solution: One is Preshant's document (draft-ppillai-ipdvb-sule-00.txt). We, the authors of this draft (draft-cruickshank-ipdvb-sec-req-01.txt) also in the process of submitting our solution to the ipdvb group. The two solutions have some similarities and some differences. We might converge in the future into one solution. However, regarding the security requirements, there were several comments in the past from the ipdvb group about the old version of the draft (draft-cruickshank-ipdvb-sec-req-00.txt). The new version address these issues. Here is a summary of the major comments raised and the responses that are included in the new draft: * Comment: Section 1: Can you also identify what is it that is being protected? (Security objectives ** Response: The main objective of this document is to specify the requirements for securing the link between the Encapsulation Gateways (ULE source) and Receivers only. I * Comment: Section 1.1: SI issues: this document must identify the control-plane dependencies that are a function of a MPEG-2 transmission network. In particular, what are the properties, potential threats, and the security assumptions (e.g. The device generating MPEG-2 SI are trusted) ** Response: In MPEG-2 transmission network there are several signalling messages that broadcast by the Network Control Centre (NCC). Examples of these signalling messages or (SI tables) are PAT - Program Association Table, PMT - Program Map Table and NIT - Network Information Table. In existing MPEG-2 transmission network, these messages broadcast in clear (no encryption or integrity checks). The integrity of these messages is important for the correct working ULE network. However, securing these messages is out of scope for ULE security. * Comment: What are the goals of the security integrity check ** Response: ULE source authentication and its packet integrity checks are required. * Comment: Section 3: Layer L2 terminal authentication. This point needs more elaboration ** Response: This section is combined with the active threats. *Comment: Section 4.2: There is a need to protect the identity of ULE encapsulator/Receivers over the ULE broadcast medium; IPsec can not provide this service. Is it that IPsec can not provide this. Or that Ipsec is not well-suited to provide this. The interfaces of these devices also do not necessarily have IP addresses (they can be L2 devices). ** Response: this text is added to the draft. * Comment: Section 5.1: Another disadvantage. There is an additional issue with key distribution in that a channel needs to be created to distribute and control the use of the keys. IP-based methods to perform this are well-known, and do not require new protocol machinery. This point needs more elaboration ** Response: this text is added. * Comment: Two other point that were raised in the WG meeting of IETF-62: Are there any specific requirements on the crypto and IP-based key management algorithms that can be used with this approach ** Response : No . Haitham (& Sunny and Laurence) ---- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of William Stanislaus Sent: 12 May 2006 12:59 To: Ipdvb IETF Subject: Re: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt Hello, I'm a bit confused, sometime before we received similar draft from P.Pillai on the same area ( secure ULE). The security requirements discussed by "draft-ppillai-ipdvb-sule-00.txt" are already discussed in detail by "draft-cruickshank-ipdvb-sec-req-01.txt". In general, the DVB terminals are just a forwarders i.e. Forwards IP packets from DVB interface to Ethernet interface (DVB-S/DVB-RCS) and forwards IP packets from Ethernet interface to DVB interface (DVB-RCS). They don't do much packet processing, that makes the DVB terminal simple and cheaper in performance. I was wondering there was no discussion in these drafts about the performance issues by implementing these security encryptions and decryptions. In these drafts it was referred to IPSEC and its functionalities, but at the same time we should not forget the IPSEC performance degrades and hardware based accelerators Best Regards, William Stanislaus | Technical Consultant Nortel Networks Division | CalSoft email: williams@calsoft.co.in | Mobile: (+91) 98409 10581 SkypeIn (VoIP): +1 (650) 515 3738 www.californiasw.com > From: Gorry Fairhurst > Reply-To: > Date: Thu, 11 May 2006 10:23:24 +0100 > To: "ipdvb@erg.abdn.ac.uk" > Conversation: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt > Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt > > > 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, S. Iyengar, L. Duquerroy > Filename : draft-cruickshank-ipdvb-sec-req-01.txt > Pages : 13 > Date : 2006-5-09 > > > 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-01 > .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-01.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 > > > Best wishes, > > G Fairhurst > (ipdvb WG Chair) > > > From owner-ipdvb@erg.abdn.ac.uk Mon May 15 12:32:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FffzG-0007mH-Ea for ipdvb-archive@ietf.org; Mon, 15 May 2006 12:32:02 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FffzE-0005Xx-UQ for ipdvb-archive@ietf.org; Mon, 15 May 2006 12:32:02 -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 k4FGNe3Y023504 for ; Mon, 15 May 2006 17:23:40 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4FGNeD4023503 for ipdvb-subscribed-users; Mon, 15 May 2006 17:23: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 [139.133.207.163] (dhcp-207-163.erg.abdn.ac.uk [139.133.207.163]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4FGNQFF023447 for ; Mon, 15 May 2006 17:23:26 +0100 (BST) Message-ID: <4468AA77.8030808@erg.abdn.ac.uk> Date: Mon, 15 May 2006 17:21: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: Re: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt References: <1147437422.4464816ed28ab@webmail6.brad.ac.uk> In-Reply-To: <1147437422.4464816ed28ab@webmail6.brad.ac.uk> 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 k4FGNe3Y023504 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Prashat, Thanks for submitting your draft. Focussing for the moment on the=20 security requirements and architecture: Are there any issues that you think you should be addressed in the=20 security requirements document that are not currently captured in draft -= 01? Or any areas that you think should also be considered? Gorry P.Pillai@Bradford.ac.uk wrote: > Hi William, >=20 > The draft (draft-ppillai-ipdvb-sule-00.txt) that I submitted a few days= back > (3rd May) was to look into how the different security requirements of d= ata > confidentiality, data authentication, data integrity and replay attacks > prevention can be met by using a modified ULE SNDU. It is not intended = to be a > =93security requirement=94 draft. The reason why I have added the secur= ity > requirement section in my draft is because the security requirements dr= aft > (draft-cruickshank-ipdvb-sec-req-00.txt) that was submitted a few month= s back > did not address all these security requirements. >=20 > The new revision of the security draft (draft-cruickshank-ipdvb-sec-req= -01.txt) > submitted on the 9th of May now addresses the need for these different = security > features. >=20 > I agree with you that there are performance issues when security overhe= ads would > be added to ULE. But this is a price that one has to pay to get the sec= urity > services. It is a trade-off. Also there are several hardware accelerato= rs > present that do enhance the performances of these security algorithms (= both for > encryption and generation of MACs) >=20 > Regards > Prashant Pillai >=20 >=20 >=20 > Quoting William Stanislaus : >=20 >=20 >>Hello, >>I'm a bit confused, sometime before we received similar draft from P.Pi= llai >>on the same area ( secure ULE). >>The security requirements discussed by "draft-ppillai-ipdvb-sule-00.txt= " are >>already discussed in detail by "draft-cruickshank-ipdvb-sec-req-01.txt". >> >>In general, the DVB terminals are just a forwarders i.e. Forwards IP pa= ckets >>from DVB interface to Ethernet interface (DVB-S/DVB-RCS) and forwards I= P >>packets from Ethernet interface to DVB interface (DVB-RCS). They don't = do >>much packet processing, that makes the DVB terminal simple and cheaper = in >>performance. I was wondering there was no discussion in these drafts ab= out >>the performance issues by implementing these security encryptions and >>decryptions. In these drafts it was referred to IPSEC and its >>functionalities, but at the same time we should not forget the IPSEC >>performance degrades and hardware based accelerators >> >>Best Regards, >>William Stanislaus | Technical Consultant >>Nortel Networks Division | CalSoft >>email: williams@calsoft.co.in | Mobile: (+91) 98409 10581 >>SkypeIn (VoIP): +1 (650) 515 3738 >>www.californiasw.com >> >> >> >> >> >>>From: Gorry Fairhurst >>>Reply-To: >>>Date: Thu, 11 May 2006 10:23:24 +0100 >>>To: "ipdvb@erg.abdn.ac.uk" >>>Conversation: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt >>>Subject: I-D ACTION: draft-cruickshank-ipdvb-sec-req-01.txt >>> >>> >>>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, S. Iyengar, L. Duquerroy >>> Filename : draft-cruickshank-ipdvb-sec-req-01.txt >>> Pages : 13 >>> Date : 2006-5-09 >>> >>> >>> 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 fo= r >>> ULE link level security. This work is intended as a work item of th= e >>> 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-01= .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-01.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 >>> >>> >>>Best wishes, >>> >>>G Fairhurst >>>(ipdvb WG Chair) >>> >>> >>> >> >> >> >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Tue May 16 04:27:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffutz-0002SN-Sl for ipdvb-archive@ietf.org; Tue, 16 May 2006 04:27:35 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffuty-0008SE-FW for ipdvb-archive@ietf.org; Tue, 16 May 2006 04:27: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 k4G8HwtD018354 for ; Tue, 16 May 2006 09:17:58 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4G8HwHc018353 for ipdvb-subscribed-users; Tue, 16 May 2006 09:17:58 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.163] (dhcp-207-163.erg.abdn.ac.uk [139.133.207.163]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4G8Hhe3018329 for ; Tue, 16 May 2006 09:17:43 +0100 (BST) Message-ID: <44698AA8.8030908@erg.abdn.ac.uk> Date: Tue, 16 May 2006 09:17:44 +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: Re: I-D ACTION: draft-cruickshank-ipdvb-sec-01.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: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Secure Extension for the Unidirectional Lightweight Encapsulation (ULE) protocol Author(s) : H. Cruickshank, S. Iyengar, L. Duquerroy Filename : draft-cruickshank-ipdvb-sec-01.txt Pages : 10 Date : 2006-5-11 This document proposes an extension format for the Unidirectional Lightweight Encapsulation (ULE) protocol. 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-01.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-01.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 Best wishes, G Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Tue May 16 10:55:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0x8-0004hy-RJ for ipdvb-archive@ietf.org; Tue, 16 May 2006 10:55: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 1Fg09R-0007x1-Ok for ipdvb-archive@ietf.org; Tue, 16 May 2006 10:03: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 1Fg00v-0006N9-G8 for ipdvb-archive@ietf.org; Tue, 16 May 2006 09:55: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 k4GDXYq7016524 for ; Tue, 16 May 2006 14:33:34 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4GDXWUp016523 for ipdvb-subscribed-users; Tue, 16 May 2006 14:33:32 +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 k4GDXEWu016501 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 16 May 2006 14:33:14 +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 k4GDX8Nw009080 for ; Tue, 16 May 2006 14:33:13 +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 k4GDX8mq001069 for ; Tue, 16 May 2006 14:33:08 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Tue, 16 May 2006 14:33:08 +0100 Message-ID: <1147786388.4469d4946c2c6@webmail6.brad.ac.uk> Date: Tue, 16 May 2006 14:33:08 +0100 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt 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.31.49 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 k4GDXYq7016524 X-Spam-Score: -2.6 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Hi Gorry and Haitham, The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt) add= resses most of the security requirements that shall/may be required for the ULE = links. I have just a few comments on the draft. 1. Is there a particular reason why the security measurements are only ta= ken for wireless MPEG2 networks (as indicated in the Introduction section)? Why a= re the wireline MPEG2 networks more secure? I think that the security requiremen= ts should be for any MPEG2 networks, wired or wireless. 2. Network access control is also an important security requirement. Ther= e is no point to just secure the user traffic, when this user has not been authen= ticated and authorised for the connection. This may be coupled with key managemen= t. 3. This document aims to basically highlight the security requirements th= at are important for securing (just) the MPEG2 link. Hence this is important fro= m the point of view of the MPEG2 Network Provider (NP). As the MPEG2 Network provider has no control on any end-to-end security mechanism, it is somet= hing that should not directly affect the security requirements on the ULE Link= . ULE Security should aim to provide all the security requirements. The text le= ads to confusion where the Section 2, Last paragraph mentions that the ULE authentication and Integrity are required especially because active attac= ks are possible at the receiver end; while Section 3 suddenly states that these = are optional requirements. There are contradicting sentences in the document, like in Section 5 2nd = para, the documents says that =93ULE link security is considered as an addition= al security mechanism to IP transport and application Layer security.=94 But= the very next sentence says that =93It should provide similar functions to th= at of IPsec=85=94. It leads to a confusion as to why to we need same level of s= ecurity at two layers. I agree with the fact that ULE security should provide high security simi= lar to IPSec, but just because their may be end-to-end mechanism present (which = the MPEG2 network provider cannot control anyways) we should not decide that = the other requirements (like source authentication, integrity etc) are option= al. 4. There are quite a few typo errors in the document, but I guess this is= not so important at this moment and could be looked into when we submit the draf= t as a WG item. Regards Prashant Pillai Quoting Gorry Fairhurst : > Prashat, > > Thanks for submitting your draft. Focussing for the moment on the > security requirements and architecture: > > Are there any issues that you think you should be addressed in the > security requirements document that are not currently captured in draft= -01? > > Or any areas that you think should also be considered? > > Gorry > --=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 Fri May 19 07:52:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3XC-0005e0-5x for ipdvb-archive@ietf.org; Fri, 19 May 2006 07:52:46 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh3XA-00022a-NM for ipdvb-archive@ietf.org; Fri, 19 May 2006 07:52:46 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4JBUMJi004345 for ; Fri, 19 May 2006 12:30:22 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4JBUMQA004344 for ipdvb-subscribed-users; Fri, 19 May 2006 12:30:22 +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.163] (dhcp-207-163.erg.abdn.ac.uk [139.133.207.163]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4JBUC8R004326 for ; Fri, 19 May 2006 12:30:12 +0100 (BST) Message-ID: <446DAC45.3040007@erg.abdn.ac.uk> Date: Fri, 19 May 2006 12:30:13 +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: 66th IETF - Montreal, Quebec, Canada 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: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 The Sixty-Sixth IETF meeting will be held 9-14 July 2006 at Montreal, Quebec, Canada. IETF Meetings start Monday morning and run through Friday lunchtime, with late scheduling changes. Newcomers' training and technical tutorials take place on the previous Sunday afternoon. Participants should plan their travel accordingly. http://www.ietf.org/meetings/IETF-66.html There is currently no Agenda published for the IETF Meeting week, but the IPDVB WG will meet, and has requested a meeting time of 2 hours duration. We are now willing to take items for this WG agenda. Some important dates are: * April, Month of - IETF Online Registration is now available * June 19, Monday - Final Working Group and BOF agenda to be published * June 19, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (13:00 UTC/GMT) * June 26, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) * June 30, Friday - Early-Bird registration and payment cut-off at 12:00 noon ET (16:00 UTC/GMT) http://www.ietf.org/meetings/cutoff_dates_66B.html Best wishes & look forward to seeing you there, if you can make it! Gorry Fairhurst From owner-ipdvb@erg.abdn.ac.uk Fri May 19 08:30:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh47W-00060t-Pi for ipdvb-archive@ietf.org; Fri, 19 May 2006 08:30:18 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh47U-0003sc-9G for ipdvb-archive@ietf.org; Fri, 19 May 2006 08:30:18 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4JC5aeq007030 for ; Fri, 19 May 2006 13:05:36 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4JC5a4O007029 for ipdvb-subscribed-users; Fri, 19 May 2006 13:05: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 nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.197]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4JC5SwW007011 for ; Fri, 19 May 2006 13:05:28 +0100 (BST) Received: by nz-out-0102.google.com with SMTP id i1so600766nzh for ; Fri, 19 May 2006 05:05:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=K8iLW7ebpNNVrnQNpTfw7e5iBOllYLONDo8M+dmdIz47vO32ePd7yT5Y9yynFmtvtjaOIhSMy6tJZN+o1534nqdck8HMx9rOauJCE8yqosyDb1/4w6XZRWhGi9lYOEEiHt9PWka3jtjpFmzYR1ETQI9uAo4kjscLFiMAGMrCvis= Received: by 10.64.156.20 with SMTP id d20mr1341652qbe; Fri, 19 May 2006 05:05:25 -0700 (PDT) Received: by 10.65.200.16 with HTTP; Fri, 19 May 2006 05:05:25 -0700 (PDT) Message-ID: <7935e2f10605190505m2673a405t44e15f8742884e5f@mail.gmail.com> Date: Fri, 19 May 2006 14:05:25 +0200 From: "Juan Cantillo" To: ipdvb@erg.abdn.ac.uk Subject: Re: 66th IETF - Montreal, Quebec, Canada Cc: "Jerome Lacan" In-Reply-To: <446DAC45.3040007@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_95529_28513882.1148040325469" References: <446DAC45.3040007@erg.abdn.ac.uk> 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: 386e0819b1192672467565a524848168 ------=_Part_95529_28513882.1148040325469 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Gorry, I will attend the meeting, and I look forward to seeing you in Montreal. Di= d you receive our last mail concerning the actions to be taken for our draft, and the attached AIAA paper? Regards, Juan On 5/19/06, Gorry Fairhurst wrote: > > > The Sixty-Sixth IETF meeting will be held 9-14 July 2006 at Montreal, > Quebec, Canada. > > IETF Meetings start Monday morning and run through Friday lunchtime, > with late scheduling changes. Newcomers' training and technical > tutorials take place on the previous Sunday afternoon. Participants > should plan their travel accordingly. > > http://www.ietf.org/meetings/IETF-66.html > > There is currently no Agenda published for the IETF Meeting week, but > the IPDVB WG will meet, and has requested a meeting time of 2 hours > duration. We are now willing to take items for this WG agenda. > > Some important dates are: > > * April, Month of - IETF Online Registration is now available > * June 19, Monday - Final Working Group and BOF agenda to be published > * June 19, Monday - Internet Draft Cut-off for initial document (-00) > submission by 09:00 ET (13:00 UTC/GMT) > * June 26, Monday - Internet Draft final submission cut-off by 09:00 ET > (13:00 UTC/GMT) > * June 30, Friday - Early-Bird registration and payment cut-off at 12:00 > noon ET (16:00 UTC/GMT) > > http://www.ietf.org/meetings/cutoff_dates_66B.html > > Best wishes & look forward to seeing you there, if you can make it! > > Gorry Fairhurst > ------=_Part_95529_28513882.1148040325469 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear Gorry,
 
I will attend the meeting, and I look forward to seeing you in Montrea= l. Did you receive our last mail concerning the actions to be taken for our= draft, and the attached AIAA paper?
Regards,
Juan

 
On 5/19/06, = Gorry Fairhurst <gorry@erg.a= bdn.ac.uk> wrote:

The Sixty-Sixth IETF meeting= will be held 9-14 July 2006 at Montreal,
Quebec, Canada.

IETF Me= etings start Monday morning and run through Friday lunchtime,
with late scheduling changes. Newcomers' training and technical
tuto= rials take place on the previous Sunday afternoon. Participants
should p= lan their travel accordingly.

http://www.ietf.org/meetings/IETF-66.html

There is currently no = Agenda published for the IETF Meeting week, but
the IPDVB WG will meet, = and has requested a meeting time of 2 hours
duration. We are now willing= to take items for this WG agenda.

Some important dates are:

* April, Month of - IETF Online Re= gistration is now available
* June 19, Monday - Final Working Group and = BOF agenda to be published
* June 19, Monday - Internet Draft Cut-off fo= r initial document (-00)
submission by 09:00 ET (13:00 UTC/GMT)
* June 26, Monday - Internet = Draft final submission cut-off by 09:00 ET
(13:00 UTC/GMT)
* June 30,= Friday - Early-Bird registration and payment cut-off at 12:00
noon ET (= 16:00 UTC/GMT)

http= ://www.ietf.org/meetings/cutoff_dates_66B.html

Best wishes &= look forward to seeing you there, if you can make it!

Gorry Fairhur= st

------=_Part_95529_28513882.1148040325469-- From owner-ipdvb@erg.abdn.ac.uk Fri May 19 09:08:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh4iW-0004QI-9H for ipdvb-archive@ietf.org; Fri, 19 May 2006 09:08:32 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh4iT-0006Rd-NS for ipdvb-archive@ietf.org; Fri, 19 May 2006 09:08:32 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4JCjCqY010178 for ; Fri, 19 May 2006 13:45:12 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4JCjC7F010177 for ipdvb-subscribed-users; Fri, 19 May 2006 13:45:12 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mermoz.ensica.fr (loghost.ensica.fr [192.70.110.90]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4JCj2qF009883 for ; Fri, 19 May 2006 13:45:02 +0100 (BST) Received: from ZELDA (localhost [127.0.0.1]) by mermoz.ensica.fr (8.10.2+Sun/jtpda-5.3.1) with ESMTP id k4JCiiQ14052 for ; Fri, 19 May 2006 14:44:44 +0200 (MEST) From: =?iso-8859-1?Q?J=E9r=F4me_Lacan?= To: Subject: RE: 66th IETF - Montreal, Quebec, Canada Date: Fri, 19 May 2006 14:44:57 +0200 Message-ID: <004201c67b42$094c6f60$9f7a36c1@ZELDA> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C67B52.CCD53F60" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ7P01/ifTz0rxxS/e+KxE4jrXpuAAAqqKQ In-Reply-To: <7935e2f10605190505m2673a405t44e15f8742884e5f@mail.gmail.com> X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C67B52.CCD53F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tu peux me l'envoyer maintenant ? =20 il faut vraiment que j'imprime.. _____ =20 De : owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] De = la part de Juan Cantillo Envoy=E9 : vendredi 19 mai 2006 14:05 =C0 : ipdvb@erg.abdn.ac.uk Cc : Jerome Lacan Objet : Re: 66th IETF - Montreal, Quebec, Canada Dear Gorry, =20 I will attend the meeting, and I look forward to seeing you in Montreal. = Did you receive our last mail concerning the actions to be taken for our = draft, and the attached AIAA paper? Regards, Juan =20 On 5/19/06, Gorry Fairhurst wrote:=20 The Sixty-Sixth IETF meeting will be held 9-14 July 2006 at Montreal, Quebec, Canada. IETF Meetings start Monday morning and run through Friday lunchtime,=20 with late scheduling changes. Newcomers' training and technical tutorials take place on the previous Sunday afternoon. Participants should plan their travel accordingly. http://www.ietf.org/meetings/IETF-66.html There is currently no Agenda published for the IETF Meeting week, but the IPDVB WG will meet, and has requested a meeting time of 2 hours duration. We are now willing to take items for this WG agenda.=20 Some important dates are: * April, Month of - IETF Online Registration is now available * June 19, Monday - Final Working Group and BOF agenda to be published * June 19, Monday - Internet Draft Cut-off for initial document (-00)=20 submission by 09:00 ET (13:00 UTC/GMT) * June 26, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) * June 30, Friday - Early-Bird registration and payment cut-off at 12:00 noon ET (16:00 UTC/GMT)=20 http://www.ietf.org/meetings/cutoff_dates_66B.html Best wishes & look forward to seeing you there, if you can make it! Gorry Fairhurst=20 ------=_NextPart_000_0043_01C67B52.CCD53F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tu peux me l'envoyer maintenant = ?
 
il faut vraiment que = j'imprime..

De : = owner-ipdvb@erg.abdn.ac.uk=20 [mailto:owner-ipdvb@erg.abdn.ac.uk] De la part de Juan=20 Cantillo
Envoy=E9 : vendredi 19 mai 2006 = 14:05
=C0 :=20 ipdvb@erg.abdn.ac.uk
Cc : Jerome = Lacan
Objet :=20 Re: 66th IETF - Montreal, Quebec, Canada

Dear Gorry,
 
I will attend the meeting, and I look forward to seeing you in = Montreal.=20 Did you receive our last mail concerning the actions to be taken for = our=20 draft, and the attached AIAA paper?
Regards,
Juan

 
On 5/19/06, Gorry=20 Fairhurst <gorry@erg.abdn.ac.uk> = wrote:=20

The=20 Sixty-Sixth IETF meeting will be held 9-14 July 2006 at = Montreal,
Quebec,=20 Canada.

IETF Meetings start Monday morning and run through = Friday=20 lunchtime,
with late scheduling changes. Newcomers' training and = technical
tutorials take place on the previous Sunday afternoon.=20 Participants
should plan their travel accordingly.

http://www.ietf.org/me= etings/IETF-66.html

There=20 is currently no Agenda published for the IETF Meeting week, = but
the IPDVB=20 WG will meet, and has requested a meeting time of 2 = hours
duration. We=20 are now willing to take items for this WG agenda.

Some = important=20 dates are:

* April, Month of - IETF Online Registration is = now=20 available
* June 19, Monday - Final Working Group and BOF agenda = to be=20 published
* June 19, Monday - Internet Draft Cut-off for initial = document=20 (-00)
submission by 09:00 ET (13:00 UTC/GMT)
* June 26, = Monday -=20 Internet Draft final submission cut-off by 09:00 ET
(13:00 = UTC/GMT)
*=20 June 30, Friday - Early-Bird registration and payment cut-off at=20 12:00
noon ET (16:00 UTC/GMT)

http://www.ie= tf.org/meetings/cutoff_dates_66B.html

Best=20 wishes & look forward to seeing you there, if you can make=20 it!

Gorry Fairhurst=20

------=_NextPart_000_0043_01C67B52.CCD53F60-- From owner-ipdvb@erg.abdn.ac.uk Sat May 20 03:30:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhLvH-0000mH-F5 for ipdvb-archive@ietf.org; Sat, 20 May 2006 03:30:51 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhLvE-0005Vo-Lb for ipdvb-archive@ietf.org; Sat, 20 May 2006 03:30:51 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4K6xiLB027683 for ; Sat, 20 May 2006 07:59:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4K6xiP9027682 for ipdvb-subscribed-users; Sat, 20 May 2006 07:59: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 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 k4K6xX3H027664 for ; Sat, 20 May 2006 07:59:35 +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); Sat, 20 May 2006 07:59:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C67BDA.EF2C831A" Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Date: Sat, 20 May 2006 07:59:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ49LigxJ5gdCJbRgeubU8ZceRWAwC5QkiZ From: To: X-OriginalArrivalTime: 20 May 2006 06:59:28.0228 (UTC) FILETIME=[EFC35240:01C67BDA] 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: cbb41f2dbf0f142369614756642005e3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C67BDA.EF2C831A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Many thanks Prashant,=0A= =0A= See responses in-line:=0A= =0A= =20=0A= ----=0A= Dr. Haitham S. Cruickshank=20=0A= Lecturer=20=0A= Communications Centre for Communication Systems Research (CCSR)=20=0A= School of Electronics, Computing and Mathematics=20=0A= University of Surrey, Guildford, Surrey GU2 7XH, UK=20=0A= =20=0A= Tel: +44 1483 686007 (indirect 689844)=20=0A= Fax: +44 1483 686011=20=0A= e-mail: H.Cruickshank@surrey.ac.uk=20=0A= http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=20=0A= =0A= ________________________________=0A= =0A= From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk=0A= Sent: Tue 16/05/2006 14:33=0A= To: ipdvb@erg.abdn.ac.uk=0A= Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt=0A= =0A= =0A= =0A= Hi Gorry and Haitham,=0A= =0A= The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt) addre= sses=0A= most of the security requirements that shall/may be required for the ULE li= nks.=0A= I have just a few comments on the draft.=0A= =0A= 1. Is there a particular reason why the security measurements are only take= n for=0A= wireless MPEG2 networks (as indicated in the Introduction section)? Why are= the=0A= wireline MPEG2 networks more secure? I think that the security requirements= =0A= should be for any MPEG2 networks, wired or wireless.=0A= =0A= Haitham: You are right the requirements should cover both wired and wireles= s environment. However, wireless environment is more vulnerable to security= attacks. For example eavesdroping is easier in wireless broadcast networks.= =0A= =0A= 2. Network access control is also an important security requirement. There = is no=0A= point to just secure the user traffic, when this user has not been authenti= cated=0A= and authorised for the connection. This may be coupled with key management.= =0A= =0A= Haitham: I agree. The draft does address this issues. May be we need to ma= ke it clearer.=0A= =0A= 3. This document aims to basically highlight the security requirements that= are=0A= important for securing (just) the MPEG2 link. Hence this is important from = the=0A= point of view of the MPEG2 Network Provider (NP). As the MPEG2 Network=0A= provider has no control on any end-to-end security mechanism, it is somethi= ng=0A= that should not directly affect the security requirements on the ULE Link. = ULE=0A= Security should aim to provide all the security requirements. The text lead= s to=0A= confusion where the Section 2, Last paragraph mentions that the ULE=0A= authentication and Integrity are required especially because active attacks= are=0A= possible at the receiver end; while Section 3 suddenly states that these are= =0A= optional requirements.=0A= =0A= Haitham: There are two points here: One, is interworking of end-to-end and = ULE link security. The draft highlights the fact that ULE security should n= ot be an obstacle against end-to-end security, if such service exists. For = example, if IPsec or transport layer end-to-end security is used, then ULE = security should allow passing such traffic as long as it is compliant with = general rules and plocies of that MPEG-2 transmission network. The second p= oint is the optional authentication and Integrity: The reason is that we wa= nt to leave a flexibility for the MPEG-2 transmission network to implement = it depending on the specific policies for each service. Some services might= not need authentication or data integrity. Any comments from ipdvb group a= re welcome on this issue.=0A= =0A= There are contradicting sentences in the document, like in Section 5 2nd pa= ra,=0A= the documents says that "ULE link security is considered as an additional= =0A= security mechanism to IP transport and application Layer security." But the= =0A= very next sentence says that "It should provide similar functions to that of= =0A= IPsec...". It leads to a confusion as to why to we need same level of secur= ity at=0A= two layers.=0A= =0A= Haitham: See answers above.=0A= =0A= I agree with the fact that ULE security should provide high security simila= r to=0A= IPSec, but just because their may be end-to-end mechanism present (which the= =0A= MPEG2 network provider cannot control anyways) we should not decide that the= =0A= other requirements (like source authentication, integrity etc) are optional.= =0A= =0A= Haitham: See answers above.=0A= =0A= 4. There are quite a few typo errors in the document, but I guess this is n= ot so=0A= important at this moment and could be looked into when we submit the draft = as a=0A= WG item.=0A= =0A= Haitham: Thanks.=0A= =0A= =0A= =0A= Regards=0A= Prashant Pillai=0A= =0A= Quoting Gorry Fairhurst :=0A= =0A= > Prashat,=0A= >=0A= > Thanks for submitting your draft. Focussing for the moment on the=0A= > security requirements and architecture:=0A= >=0A= > Are there any issues that you think you should be addressed in the=0A= > security requirements document that are not currently captured in draft -= 01?=0A= >=0A= > Or any areas that you think should also be considered?=0A= >=0A= > Gorry=0A= >=0A= =0A= --=0A= Prashant Pillai=0A= Research Assistant=0A= School of Engineering, Design and Technology=0A= University of Bradford=0A= Bradford, BD7 1DP=0A= West Yorkshire=0A= United Kingdom=0A= Phone: 0044-1274-233720=0A= email: p.pillai@bradford.ac.uk=0A= ------------------------------------------------------------=0A= This mail sent through IMP: http://webmail.brad.ac.uk=0A= To report misuse from this email address forward the message=0A= and full headers to misuse@bradford.ac.uk=0A= ------------------------------------------------------------=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C67BDA.EF2C831A Content-Type: text/plain; name="msg-23587-21.txt" Content-Disposition: attachment; filename="msg-23587-21.txt" Content-Transfer-Encoding: 8bit Many thanks Prashant, See responses in-line: ---- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk Sent: Tue 16/05/2006 14:33 To: ipdvb@erg.abdn.ac.uk Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Hi Gorry and Haitham, The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt) addresses most of the security requirements that shall/may be required for the ULE links. I have just a few comments on the draft. 1. Is there a particular reason why the security measurements are only taken for wireless MPEG2 networks (as indicated in the Introduction section)? Why are the wireline MPEG2 networks more secure? I think that the security requirements should be for any MPEG2 networks, wired or wireless. Haitham: You are right the requirements should cover both wired and wireless environment. However, wireless environment is more vulnerable to security attacks. For example eavesdroping is easier in wireless broadcast networks. 2. Network access control is also an important security requirement. There is no point to just secure the user traffic, when this user has not been authenticated and authorised for the connection. This may be coupled with key management. Haitham: I agree. The draft does address this issues. May be we need to make it clearer. 3. This document aims to basically highlight the security requirements that are important for securing (just) the MPEG2 link. Hence this is important from the point of view of the MPEG2 Network Provider (NP). As the MPEG2 Network provider has no control on any end-to-end security mechanism, it is something that should not directly affect the security requirements on the ULE Link. ULE Security should aim to provide all the security requirements. The text leads to confusion where the Section 2, Last paragraph mentions that the ULE authentication and Integrity are required especially because active attacks are possible at the receiver end; while Section 3 suddenly states that these are optional requirements. Haitham: There are two points here: One, is interworking of end-to-end and ULE link security. The draft highlights the fact that ULE security should not be an obstacle against end-to-end security, if such service exists. For example, if IPsec or transport layer end-to-end security is used, then ULE security should allow passing such traffic as long as it is compliant with general rules and plocies of that MPEG-2 transmission network. The second point is the optional authentication and Integrity: The reason is that we want to leave a flexibility for the MPEG-2 transmission network to implement it depending on the specific policies for each service. Some services might not need authentication or data integrity. Any comments from ipdvb group are welcome on this issue. There are contradicting sentences in the document, like in Section 5 2nd para, the documents says that "ULE link security is considered as an additional security mechanism to IP transport and application Layer security." But the very next sentence says that "It should provide similar functions to that of IPsec...". It leads to a confusion as to why to we need same level of security at two layers. Haitham: See answers above. I agree with the fact that ULE security should provide high security similar to IPSec, but just because their may be end-to-end mechanism present (which the MPEG2 network provider cannot control anyways) we should not decide that the other requirements (like source authentication, integrity etc) are optional. Haitham: See answers above. 4. There are quite a few typo errors in the document, but I guess this is not so important at this moment and could be looked into when we submit the draft as a WG item. Haitham: Thanks. Regards Prashant Pillai Quoting Gorry Fairhurst : > Prashat, > > Thanks for submitting your draft. Focussing for the moment on the > security requirements and architecture: > > Are there any issues that you think you should be addressed in the > security requirements document that are not currently captured in draft -01? > > Or any areas that you think should also be considered? > > Gorry > -- 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 ------------------------------------------------------------ ------_=_NextPart_001_01C67BDA.EF2C831A-- From owner-ipdvb@erg.abdn.ac.uk Mon May 22 08:30:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi9Yn-00046A-HL for ipdvb-archive@ietf.org; Mon, 22 May 2006 08:30:57 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi9Yk-0006J4-TE for ipdvb-archive@ietf.org; Mon, 22 May 2006 08:30:57 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4MC8AsM017995 for ; Mon, 22 May 2006 13:08:10 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4MC8A7j017994 for ipdvb-subscribed-users; Mon, 22 May 2006 13:08: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 k4MC81od017968 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 22 May 2006 13:08:01 +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 k4MC7A6G026531; Mon, 22 May 2006 13:07:10 +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 k4MC79Os008237; Mon, 22 May 2006 13:07:10 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Mon, 22 May 2006 13:07:09 +0100 Message-ID: <1148299629.4471a96dd4986@webmail6.brad.ac.uk> Date: Mon, 22 May 2006 13:07:09 +0100 From: P.Pillai@Bradford.ac.uk To: H.Cruickshank@surrey.ac.uk Cc: ipdvb@erg.abdn.ac.uk Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt In-Reply-To: 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.31.49 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 k4MC8AsM017995 X-Spam-Score: 0.2 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Hi Haitham, I have a few more comments on the draft: 1. As stated in Section 3 =96 =93Data confidentiality is the major requir= ement against passive threats (using encryption). L2 encryption or L3 (IPsec) Encryption can satisfy this requirement=94. I disagree with this. L3 (IP= SEC) Encryption would not be able to prevent passice threats like traffic anal= ysis as the outer IP header is not encrypted. The only drive to provide L2 sec= urity is to provide encryption of the complete higher layer packets to prevent = any traffic analysis. 2. Regarding the optional authentication and integrity. I think we need t= o be careful with the wording in the draft. - Is there a requirement for an =93optional authenticity/integrity mechan= ism=94 (like you said that some service may not need it)? or - Is there a definite requirement for authenticity/integrity mechanism ov= er the MPEG2 link? This may be optional at the ULE level when other authentication/integrity mechanisms at other layers may be present (like = IPSEC AH or ESP with Auth). I prefer the second option which emphasises on the requirement for authenticity/integrity but keeps it as an optional service at ULE. Could = the other members of the group also voice their opinion on this? 3. Who would be in-charge of selecting the Secure ULE level =96 the user = or the NCC? Does the NCC decide on the level of security to be used (according t= o the user profile, pricing plan, etc) or can the user select the level of secu= rity (so the user can select different security levels for different sessions)= ? 4. What about content protection? Do we need to address the support/interoperability with content protection mechanism (like DRM)? 5. What about Interworking with existing lower layer security mechanisms especially the ones specified in DVB RCS (MKE, EKE, QKE)? Do we expect a = user to perform DVB RCS security setup (using MKE, EKE, QKE), then perform ano= ther set of security setup for Secure ULE (using GDOI/GSAKMP etc) and then a f= inal end-to-end IPSEC setup (using IKE/ISAKMP or even GDOI/GSAKMP etc)? Regards Prashant Quoting H.Cruickshank@surrey.ac.uk: > Many thanks Prashant, > > See responses in-line: > > > ---- > Dr. Haitham S. Cruickshank > Lecturer > Communications Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey, Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > ________________________________ > > From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk > Sent: Tue 16/05/2006 14:33 > To: ipdvb@erg.abdn.ac.uk > Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt > > > > Hi Gorry and Haitham, > > The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt) > addresses > most of the security requirements that shall/may be required for the UL= E > links. > I have just a few comments on the draft. > > 1. Is there a particular reason why the security measurements are only = taken > for > wireless MPEG2 networks (as indicated in the Introduction section)? Why= are > the > wireline MPEG2 networks more secure? I think that the security requirem= ents > should be for any MPEG2 networks, wired or wireless. > > Haitham: You are right the requirements should cover both wired and wir= eless > environment. However, wireless environment is more vulnerable to securi= ty > attacks. For example eavesdroping is easier in wireless broadcast netwo= rks. > > 2. Network access control is also an important security requirement. Th= ere is > no > point to just secure the user traffic, when this user has not been > authenticated > and authorised for the connection. This may be coupled with key managem= ent. > > Haitham: I agree. The draft does address this issues. May be we need t= o make > it clearer. > > 3. This document aims to basically highlight the security requirements = that > are > important for securing (just) the MPEG2 link. Hence this is important f= rom > the > point of view of the MPEG2 Network Provider (NP). As the MPEG2 Network > provider has no control on any end-to-end security mechanism, it is som= ething > that should not directly affect the security requirements on the ULE Li= nk. > ULE > Security should aim to provide all the security requirements. The text = leads > to > confusion where the Section 2, Last paragraph mentions that the ULE > authentication and Integrity are required especially because active att= acks > are > possible at the receiver end; while Section 3 suddenly states that thes= e are > optional requirements. > > Haitham: There are two points here: One, is interworking of end-to-end = and > ULE link security. The draft highlights the fact that ULE security shou= ld not > be an obstacle against end-to-end security, if such service exists. For > example, if IPsec or transport layer end-to-end security is used, then = ULE > security should allow passing such traffic as long as it is compliant w= ith > general rules and plocies of that MPEG-2 transmission network. The seco= nd > point is the optional authentication and Integrity: The reason is that = we > want to leave a flexibility for the MPEG-2 transmission network to impl= ement > it depending on the specific policies for each service. Some services m= ight > not need authentication or data integrity. Any comments from ipdvb grou= p are > welcome on this issue. > > There are contradicting sentences in the document, like in Section 5 2n= d > para, > the documents says that "ULE link security is considered as an addition= al > security mechanism to IP transport and application Layer security." But= the > very next sentence says that "It should provide similar functions to th= at of > IPsec...". It leads to a confusion as to why to we need same level of > security at > two layers. > > Haitham: See answers above. > > I agree with the fact that ULE security should provide high security si= milar > to > IPSec, but just because their may be end-to-end mechanism present (whic= h the > MPEG2 network provider cannot control anyways) we should not decide tha= t the > other requirements (like source authentication, integrity etc) are opti= onal. > > Haitham: See answers above. > > 4. There are quite a few typo errors in the document, but I guess this = is not > so > important at this moment and could be looked into when we submit the dr= aft as > a > WG item. > > Haitham: Thanks. > > > > Regards > Prashant Pillai > --=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 May 22 09:58:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAvI-0005QA-Cu for ipdvb-archive@ietf.org; Mon, 22 May 2006 09:58:16 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiAvG-0001ZI-Hh for ipdvb-archive@ietf.org; Mon, 22 May 2006 09:58: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 k4MDfotI025410 for ; Mon, 22 May 2006 14:41:50 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4MDfoqw025409 for ipdvb-subscribed-users; Mon, 22 May 2006 14:41:50 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from 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 k4MDff1Y025393 for ; Mon, 22 May 2006 14:41:41 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 14:41:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Date: Mon, 22 May 2006 14:41:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ9mZCJyq1hEme8Qo2qVK+gFMkiMgACQlAg From: To: Cc: X-OriginalArrivalTime: 22 May 2006 13:41:36.0251 (UTC) FILETIME=[7202F4B0:01C67DA5] 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 k4MDfox9025406 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: a1f9797ba297220533cb8c3f4bc709a8 Hi Prashant, Many thanks for your comments. See replies in-line: ---- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] Sent: 22 May 2006 13:07 To: Cruickshank HS Dr (CCSR) Cc: ipdvb@erg.abdn.ac.uk Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Hi Haitham, I have a few more comments on the draft: 1. As stated in Section 3 - "Data confidentiality is the major requirement against passive threats (using encryption). L2 encryption or L3 (IPsec) Encryption can satisfy this requirement". I disagree with this. L3 (IPSEC) Encryption would not be able to prevent passice threats like traffic analysis as the outer IP header is not encrypted. The only drive to provide L2 security is to provide encryption of the complete higher layer packets to prevent any traffic analysis. Haitham: As you know that if IPsec is used in Tunnel mode then it will protect the inner IP header from traffic analysis. Of course, we have to live with the overheads of IPsec tunnel mode. 2. Regarding the optional authentication and integrity. I think we need to be careful with the wording in the draft. - Is there a requirement for an "optional authenticity/integrity mechanism" (like you said that some service may not need it)? or - Is there a definite requirement for authenticity/integrity mechanism over the MPEG2 link? This may be optional at the ULE level when other authentication/integrity mechanisms at other layers may be present (like IPSEC AH or ESP with Auth). I prefer the second option which emphasises on the requirement for authenticity/integrity but keeps it as an optional service at ULE. Could the other members of the group also voice their opinion on this? 3. Who would be in-charge of selecting the Secure ULE level - the user or the NCC? Does the NCC decide on the level of security to be used (according to the user profile, pricing plan, etc) or can the user select the level of security (so the user can select different security levels for different sessions)? Haitham: The draft states that the ULE link security focuses on security between the Encapsulation Gateways (ULE source) and Receivers. The level of security such as encryption key length and data integrity methods are part of key management exchange that should happen before ULE encryption or data integrity is performed. 4. What about content protection? Do we need to address the support/interoperability with content protection mechanism (like DRM)? Haitham: I think this is out of scope for ipdvb group. 5. What about Interworking with existing lower layer security mechanisms especially the ones specified in DVB RCS (MKE, EKE, QKE)? Do we expect a user to perform DVB RCS security setup (using MKE, EKE, QKE), then perform another set of security setup for Secure ULE (using GDOI/GSAKMP etc) and then a final end-to-end IPSEC setup (using IKE/ISAKMP or even GDOI/GSAKMP etc)? Haitham: The specific link layer system (DVB-RCS) is just one type of MPEG2- transmission networks. MKE, EKE and QKE are key agreement protocols for DVB-RCS. The ULE security draft mentions that key management (or key agreement protocols) should be decoupled from the ULE encryption/integrity. The reason is that the implementers of ULE security will be free to choose a suitable key management. Of course, the MSEC related protocols (GSAKMP/GDOI ...) are the best choices, in my opinion. Haitham Quoting H.Cruickshank@surrey.ac.uk: > Many thanks Prashant, > > See responses in-line: > > > ---- > Dr. Haitham S. Cruickshank > Lecturer > Communications Centre for Communication Systems Research (CCSR) School > of Electronics, Computing and Mathematics University of Surrey, > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > ________________________________ > > From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk > Sent: Tue 16/05/2006 14:33 > To: ipdvb@erg.abdn.ac.uk > Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt > > > > Hi Gorry and Haitham, > > The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt) > addresses > most of the security requirements that shall/may be required for the > ULE links. I have just a few comments on the draft. > > 1. Is there a particular reason why the security measurements are only > taken for wireless MPEG2 networks (as indicated in the Introduction > section)? Why are the > wireline MPEG2 networks more secure? I think that the security requirements > should be for any MPEG2 networks, wired or wireless. > > Haitham: You are right the requirements should cover both wired and > wireless environment. However, wireless environment is more vulnerable > to security attacks. For example eavesdroping is easier in wireless > broadcast networks. > > 2. Network access control is also an important security requirement. > There is no point to just secure the user traffic, when this user has > not been authenticated > and authorised for the connection. This may be coupled with key management. > > Haitham: I agree. The draft does address this issues. May be we need > to make it clearer. > > 3. This document aims to basically highlight the security requirements > that are important for securing (just) the MPEG2 link. Hence this is > important from the > point of view of the MPEG2 Network Provider (NP). As the MPEG2 Network > provider has no control on any end-to-end security mechanism, it is something > that should not directly affect the security requirements on the ULE Link. > ULE > Security should aim to provide all the security requirements. The text leads > to > confusion where the Section 2, Last paragraph mentions that the ULE > authentication and Integrity are required especially because active attacks > are > possible at the receiver end; while Section 3 suddenly states that these are > optional requirements. > > Haitham: There are two points here: One, is interworking of end-to-end > and ULE link security. The draft highlights the fact that ULE security > should not be an obstacle against end-to-end security, if such service > exists. For example, if IPsec or transport layer end-to-end security > is used, then ULE security should allow passing such traffic as long > as it is compliant with general rules and plocies of that MPEG-2 > transmission network. The second point is the optional authentication > and Integrity: The reason is that we want to leave a flexibility for > the MPEG-2 transmission network to implement it depending on the > specific policies for each service. Some services might not need > authentication or data integrity. Any comments from ipdvb group are > welcome on this issue. > > There are contradicting sentences in the document, like in Section 5 > 2nd para, the documents says that "ULE link security is considered as > an additional security mechanism to IP transport and application Layer > security." But the very next sentence says that "It should provide > similar functions to that of IPsec...". It leads to a confusion as to > why to we need same level of security at > two layers. > > Haitham: See answers above. > > I agree with the fact that ULE security should provide high security > similar to IPSec, but just because their may be end-to-end mechanism > present (which the MPEG2 network provider cannot control anyways) we > should not decide that the other requirements (like source > authentication, integrity etc) are optional. > > Haitham: See answers above. > > 4. There are quite a few typo errors in the document, but I guess this > is not so important at this moment and could be looked into when we > submit the draft as a > WG item. > > Haitham: Thanks. > > > > Regards > Prashant Pillai > -- 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 May 22 10:59:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBsJ-0000Da-Kj for ipdvb-archive@ietf.org; Mon, 22 May 2006 10:59:15 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBsI-0004lL-2a for ipdvb-archive@ietf.org; Mon, 22 May 2006 10:59: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 k4MEdtTK029942 for ; Mon, 22 May 2006 15:39:55 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4MEdtNx029941 for ipdvb-subscribed-users; Mon, 22 May 2006 15:39:55 +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 k4MEdlRn029918 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 22 May 2006 15:39:47 +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 k4MECMZo018511; Mon, 22 May 2006 15:12:22 +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 k4MECMdX023011; Mon, 22 May 2006 15:12:22 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Mon, 22 May 2006 15:12:22 +0100 Message-ID: <1148307142.4471c6c61ebd0@webmail6.brad.ac.uk> Date: Mon, 22 May 2006 15:12:22 +0100 From: P.Pillai@Bradford.ac.uk To: H.Cruickshank@surrey.ac.uk Cc: ipdvb@erg.abdn.ac.uk Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt In-Reply-To: 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.31.49 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: b2809b6f39decc6de467dcf252f42af1 Hi Haitham, I agree with you that in the tunnel mode the inner packet is encrypted so protected from traffic analysis. But the outer IP packet would still have the IP address of the ULE receiver (which acts as the gateway for the tunnel mode) at the user end. This could still be used for some form of traffic analysis (especially as for the MPEG2 network the user would be the ULE receiver and not the IP hosts connected behind it). Regards Prashant Quoting H.Cruickshank@surrey.ac.uk: > Hi Prashant, > > Many thanks for your comments. See replies in-line: > > ---- > > Dr. Haitham S. Cruickshank > > Lecturer > Communications Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey, Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > > -----Original Message----- > From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] > Sent: 22 May 2006 13:07 > To: Cruickshank HS Dr (CCSR) > Cc: ipdvb@erg.abdn.ac.uk > Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt > > > Hi Haitham, > > I have a few more comments on the draft: > > 1. As stated in Section 3 - "Data confidentiality is the major > requirement against passive threats (using encryption). L2 encryption > or L3 (IPsec) Encryption can satisfy this requirement". I disagree with > this. L3 (IPSEC) Encryption would not be able to prevent passice threats > like traffic analysis as the outer IP header is not encrypted. The only > drive to provide L2 security is to provide encryption of the complete > higher layer packets to prevent any traffic analysis. > > Haitham: As you know that if IPsec is used in Tunnel mode then it will > protect the inner IP header from traffic analysis. Of course, we have > to live with the overheads of IPsec tunnel mode. > > 2. Regarding the optional authentication and integrity. I think we need > to be careful with the wording in the draft. > > - Is there a requirement for an "optional authenticity/integrity > mechanism" (like you said that some service may not need it)? or > - Is there a definite requirement for authenticity/integrity mechanism > over the MPEG2 link? This may be optional at the ULE level when other > authentication/integrity mechanisms at other layers may be present (like > IPSEC AH or ESP with Auth). > > I prefer the second option which emphasises on the requirement for > authenticity/integrity but keeps it as an optional service at ULE. Could > the other members of the group also voice their opinion on this? > > 3. Who would be in-charge of selecting the Secure ULE level - the user > or the NCC? Does the NCC decide on the level of security to be used > (according to the user profile, pricing plan, etc) or can the user > select the level of security (so the user can select different security > levels for different sessions)? > > Haitham: The draft states that the ULE link security focuses on security > between the Encapsulation Gateways (ULE source) and Receivers. The > level of security such as encryption key length and data integrity > methods are part of key management exchange that should happen before > ULE encryption or data integrity is performed. > > > 4. What about content protection? Do we need to address the > support/interoperability with content protection mechanism (like DRM)? > > Haitham: I think this is out of scope for ipdvb group. > > 5. What about Interworking with existing lower layer security mechanisms > especially the ones specified in DVB RCS (MKE, EKE, QKE)? Do we expect a > user to perform DVB RCS security setup (using MKE, EKE, QKE), then > perform another set of security setup for Secure ULE (using GDOI/GSAKMP > etc) and then a final end-to-end IPSEC setup (using IKE/ISAKMP or even > GDOI/GSAKMP etc)? > > Haitham: The specific link layer system (DVB-RCS) is just one type of > MPEG2- transmission networks. MKE, EKE and QKE are key agreement > protocols for DVB-RCS. The ULE security draft mentions that key > management (or key agreement protocols) should be decoupled from the ULE > encryption/integrity. The reason is that the implementers of ULE > security will be free to choose a suitable key management. Of course, > the MSEC related protocols (GSAKMP/GDOI ...) are the best choices, in my > opinion. > > Haitham > > -- 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 May 22 11:09:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiC21-0003fL-2O for ipdvb-archive@ietf.org; Mon, 22 May 2006 11:09:17 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiC1z-0005HY-GS for ipdvb-archive@ietf.org; Mon, 22 May 2006 11:09:17 -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 k4MEoE3l001022 for ; Mon, 22 May 2006 15:50:14 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4MEoEwH001021 for ipdvb-subscribed-users; Mon, 22 May 2006 15:50: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 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 k4MEnxmZ000753 for ; Mon, 22 May 2006 15:49:59 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 15:49:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Date: Mon, 22 May 2006 15:49:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Thread-Index: AcZ9rblL7w1RD4IAT3KRSaivlzDjiQAAI0KQ From: To: Cc: X-OriginalArrivalTime: 22 May 2006 14:49:54.0657 (UTC) FILETIME=[FCDA1510:01C67DAE] 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 k4MEo9dr000951 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: d890c9ddd0b0a61e8c597ad30c1c2176 Hi again Prashant, Yes, you are right. In fact, one of the issues that we need to solve in the ULE security system, how to hide the identity of the ULE sender and receivers. In draft "draft-cruickshank-ipdvb-sec-01.txt", the proposal is to use temporary NPA/MAC addresses. Haitham ---- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey, Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ -----Original Message----- From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] Sent: 22 May 2006 15:12 To: Cruickshank HS Dr (CCSR) Cc: ipdvb@erg.abdn.ac.uk Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt Hi Haitham, I agree with you that in the tunnel mode the inner packet is encrypted so protected from traffic analysis. But the outer IP packet would still have the IP address of the ULE receiver (which acts as the gateway for the tunnel mode) at the user end. This could still be used for some form of traffic analysis (especially as for the MPEG2 network the user would be the ULE receiver and not the IP hosts connected behind it). Regards Prashant Quoting H.Cruickshank@surrey.ac.uk: > Hi Prashant, > > Many thanks for your comments. See replies in-line: > > ---- > > Dr. Haitham S. Cruickshank > > Lecturer > Communications Centre for Communication Systems Research (CCSR) School > of Electronics, Computing and Mathematics University of Surrey, > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > > -----Original Message----- > From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] > Sent: 22 May 2006 13:07 > To: Cruickshank HS Dr (CCSR) > Cc: ipdvb@erg.abdn.ac.uk > Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt > > > Hi Haitham, > > I have a few more comments on the draft: > > 1. As stated in Section 3 - "Data confidentiality is the major > requirement against passive threats (using encryption). L2 encryption > or L3 (IPsec) Encryption can satisfy this requirement". I disagree > with this. L3 (IPSEC) Encryption would not be able to prevent passice > threats like traffic analysis as the outer IP header is not encrypted. > The only drive to provide L2 security is to provide encryption of the > complete higher layer packets to prevent any traffic analysis. > > Haitham: As you know that if IPsec is used in Tunnel mode then it will > protect the inner IP header from traffic analysis. Of course, we have > to live with the overheads of IPsec tunnel mode. > > 2. Regarding the optional authentication and integrity. I think we > need to be careful with the wording in the draft. > > - Is there a requirement for an "optional authenticity/integrity > mechanism" (like you said that some service may not need it)? or > - Is there a definite requirement for authenticity/integrity mechanism > over the MPEG2 link? This may be optional at the ULE level when other > authentication/integrity mechanisms at other layers may be present > (like IPSEC AH or ESP with Auth). > > I prefer the second option which emphasises on the requirement for > authenticity/integrity but keeps it as an optional service at ULE. > Could the other members of the group also voice their opinion on this? > > 3. Who would be in-charge of selecting the Secure ULE level - the user > or the NCC? Does the NCC decide on the level of security to be used > (according to the user profile, pricing plan, etc) or can the user > select the level of security (so the user can select different > security levels for different sessions)? > > Haitham: The draft states that the ULE link security focuses on > security between the Encapsulation Gateways (ULE source) and > Receivers. The level of security such as encryption key length and > data integrity methods are part of key management exchange that should > happen before ULE encryption or data integrity is performed. > > > 4. What about content protection? Do we need to address the > support/interoperability with content protection mechanism (like DRM)? > > Haitham: I think this is out of scope for ipdvb group. > > 5. What about Interworking with existing lower layer security > mechanisms especially the ones specified in DVB RCS (MKE, EKE, QKE)? > Do we expect a user to perform DVB RCS security setup (using MKE, EKE, > QKE), then perform another set of security setup for Secure ULE (using > GDOI/GSAKMP > etc) and then a final end-to-end IPSEC setup (using IKE/ISAKMP or even > GDOI/GSAKMP etc)? > > Haitham: The specific link layer system (DVB-RCS) is just one type of > MPEG2- transmission networks. MKE, EKE and QKE are key agreement > protocols for DVB-RCS. The ULE security draft mentions that key > management (or key agreement protocols) should be decoupled from the > ULE encryption/integrity. The reason is that the implementers of ULE > security will be free to choose a suitable key management. Of course, > the MSEC related protocols (GSAKMP/GDOI ...) are the best choices, in > my opinion. > > Haitham > > -- 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 May 22 13:38:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEM5-0001Nq-N4 for ipdvb-archive@ietf.org; Mon, 22 May 2006 13:38:09 -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 1FiCUP-0006Xr-PM for ipdvb-archive@ietf.org; Mon, 22 May 2006 11:38:37 -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 1FiCOs-0003bz-Qc for ipdvb-archive@ietf.org; Mon, 22 May 2006 11:32:59 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4MFHYMb003056 for ; Mon, 22 May 2006 16:17:34 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4MFHYfw003055 for ipdvb-subscribed-users; Mon, 22 May 2006 16:17: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.163] (dhcp-207-163.erg.abdn.ac.uk [139.133.207.163]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4MFHAmU003038; Mon, 22 May 2006 16:17:10 +0100 (BST) Message-ID: <4471D5F6.80500@erg.abdn.ac.uk> Date: Mon, 22 May 2006 16:17:10 +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: P.Pillai@Bradford.ac.uk, "H.Cruickshank" Subject: Re: Comments on draft-cruickshank-ipdvb-sec-req-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -1.3 (-) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Following on from what Prashat has been saying, the current text says: " - Optional hiding of Layer 2 MAC/NPA address. This is needed particularly in the MPEG-2 broadcast networks to stop an intruder gaining information by observing the identity of the communicating parties and the volume of their traffic. - Layer L2 terminal authentication. This will be part of the key management. It will be performed during the initial key exchange and authentication phase. " Some more thoughts: * It probably is woirth being clear that by "optional" you mean that this is only needed in networks that require this additional service, and that you do not expect all networks to need to provide identity hiding. * Is it possible to cite some references to similar services over other technologies? * Some text to say why IPsec cannot provide this service would be good. * Finally, is the second part meant to be second point? - Thsi notion of authentication at L2 seems different to that at L3 (are the goals different?). Is authentication of Receivers optional in the architecture or required? Gorry H.Cruickshank@surrey.ac.uk wrote: > Hi again Prashant, > > Yes, you are right. In fact, one of the issues that we need to solve in > the ULE security system, how to hide the identity of the ULE sender and > receivers. In draft "draft-cruickshank-ipdvb-sec-01.txt", the proposal > is to use temporary NPA/MAC addresses. > > Haitham > > ---- > > Dr. Haitham S. Cruickshank > > Lecturer > Communications Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey, Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > > -----Original Message----- > From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] > Sent: 22 May 2006 15:12 > To: Cruickshank HS Dr (CCSR) > Cc: ipdvb@erg.abdn.ac.uk > Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt > > > Hi Haitham, > > I agree with you that in the tunnel mode the inner packet is encrypted > so protected from traffic analysis. But the outer IP packet would still > have the IP address of the ULE receiver (which acts as the gateway for > the tunnel mode) at the user end. This could still be used for some form > of traffic analysis (especially as for the MPEG2 network the user would > be the ULE receiver and not the IP hosts connected behind it). > > Regards > Prashant > > Quoting H.Cruickshank@surrey.ac.uk: > > >>Hi Prashant, >> >>Many thanks for your comments. See replies in-line: >> >>---- >> >>Dr. Haitham S. Cruickshank >> >>Lecturer >>Communications Centre for Communication Systems Research (CCSR) School > > >>of Electronics, Computing and Mathematics University of Surrey, >>Guildford, Surrey GU2 7XH, UK >> >>Tel: +44 1483 686007 (indirect 689844) >>Fax: +44 1483 686011 >>e-mail: H.Cruickshank@surrey.ac.uk >>http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ >> >> >> >> >>-----Original Message----- >>From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] >>Sent: 22 May 2006 13:07 >>To: Cruickshank HS Dr (CCSR) >>Cc: ipdvb@erg.abdn.ac.uk >>Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt >> >> >>Hi Haitham, >> >>I have a few more comments on the draft: >> >>1. As stated in Section 3 - "Data confidentiality is the major >>requirement against passive threats (using encryption). L2 encryption > > >>or L3 (IPsec) Encryption can satisfy this requirement". I disagree >>with this. L3 (IPSEC) Encryption would not be able to prevent passice >>threats like traffic analysis as the outer IP header is not encrypted. > > >>The only drive to provide L2 security is to provide encryption of the >>complete higher layer packets to prevent any traffic analysis. >> >>Haitham: As you know that if IPsec is used in Tunnel mode then it will > > >>protect the inner IP header from traffic analysis. Of course, we have > > >>to live with the overheads of IPsec tunnel mode. >> >>2. Regarding the optional authentication and integrity. I think we >>need to be careful with the wording in the draft. >> >>- Is there a requirement for an "optional authenticity/integrity >>mechanism" (like you said that some service may not need it)? or >>- Is there a definite requirement for authenticity/integrity mechanism > > >>over the MPEG2 link? This may be optional at the ULE level when other >>authentication/integrity mechanisms at other layers may be present >>(like IPSEC AH or ESP with Auth). >> >>I prefer the second option which emphasises on the requirement for >>authenticity/integrity but keeps it as an optional service at ULE. >>Could the other members of the group also voice their opinion on this? >> >>3. Who would be in-charge of selecting the Secure ULE level - the user > > >>or the NCC? Does the NCC decide on the level of security to be used >>(according to the user profile, pricing plan, etc) or can the user >>select the level of security (so the user can select different >>security levels for different sessions)? >> >>Haitham: The draft states that the ULE link security focuses on >>security between the Encapsulation Gateways (ULE source) and >>Receivers. The level of security such as encryption key length and >>data integrity methods are part of key management exchange that should > > >>happen before ULE encryption or data integrity is performed. >> >> >>4. What about content protection? Do we need to address the >>support/interoperability with content protection mechanism (like DRM)? >> >>Haitham: I think this is out of scope for ipdvb group. >> >>5. What about Interworking with existing lower layer security >>mechanisms especially the ones specified in DVB RCS (MKE, EKE, QKE)? >>Do we expect a user to perform DVB RCS security setup (using MKE, EKE, > > >>QKE), then perform another set of security setup for Secure ULE (using > > >>GDOI/GSAKMP >>etc) and then a final end-to-end IPSEC setup (using IKE/ISAKMP or even >>GDOI/GSAKMP etc)? >> >>Haitham: The specific link layer system (DVB-RCS) is just one type of >>MPEG2- transmission networks. MKE, EKE and QKE are key agreement >>protocols for DVB-RCS. The ULE security draft mentions that key >>management (or key agreement protocols) should be decoupled from the >>ULE encryption/integrity. The reason is that the implementers of ULE >>security will be free to choose a suitable key management. Of course, > > >>the MSEC related protocols (GSAKMP/GDOI ...) are the best choices, in >>my opinion. >> >>Haitham >> >> > > > From owner-ipdvb@erg.abdn.ac.uk Tue May 23 08:28:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiVzr-0005IC-8z for ipdvb-archive@ietf.org; Tue, 23 May 2006 08:28:23 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiVzo-0005AE-PP for ipdvb-archive@ietf.org; Tue, 23 May 2006 08:28:23 -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 k4NC47Dn006512 for ; Tue, 23 May 2006 13:04:07 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4NC47N6006511 for ipdvb-subscribed-users; Tue, 23 May 2006 13:04:07 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from 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 k4NC3rKA006490 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 23 May 2006 13:03:54 +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 k4NBkt1t009704 for ; Tue, 23 May 2006 12:46:55 +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 k4NBks9Y023479 for ; Tue, 23 May 2006 12:46:55 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Tue, 23 May 2006 12:46:54 +0100 Message-ID: <1148384814.4472f62ed08ee@webmail6.brad.ac.uk> Date: Tue, 23 May 2006 12:46:54 +0100 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk Subject: CRC Issue in Security Draft 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.31.49 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: 538aad3a3c4f01d8b6a6477ca4248793 Hi Haitham and Sunny, I have a few questions regarding your security draft(draft-cruickshank-ipdvb-sec-01.txt): 1) I am not sure as to what is the main reason for encrypting the entire PDU including the checksum as indicated by the draft on Page 4? As indicated in the RFC4326, section 7.2 the receiver should be able validate the CRC as soon as it gets the complete SNDU in the buffer. I do not think that encrypting of this CRC is a good idea, as this would violate the standard processing of the ULE SNDU, where it would be have to skip this CRC check and first perform decryption of the packets and then come back and perform the CRC check. (Hence it can no longer be just an extension header for ULE, as the processing has changed) 2) Even if the CRC is not encrypted, another major conflict in the SNDU format is the presence of the integrity block after your CRC. At the receiver side as indicated in the RFC4326, section 7.2 the receiver should be able validate the CRC as soon as it gets the complete SNDU in the buffer. At this stage the ideal working of the receiver (for standard ULE) is to take the last 32 bits which would be the CRC and perform the CRC check. But now the CRC is not at the end and it may be difficult to extract the CRC from the SNDU especially because the integrity block has not shown to have fixed size. 3) Also it is not clear why is the CRC required when the integrity block is present. The integrity block would be using much complex algorithms like HMACs etc to detect if there is any change in the transmitted data and the received data. This change could have resulted by an attacker modifying the message or could have also been due to transmission/processing errors. In either case the packets should be discarded. So does this not mean that the CRC is only duplicating the work and may not be really required when we have a stronger integrity block? Regards Prashant -- 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 Tue May 23 12:22:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiZeR-0003jn-9r for ipdvb-archive@ietf.org; Tue, 23 May 2006 12:22:31 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiZeL-0006P5-Li for ipdvb-archive@ietf.org; Tue, 23 May 2006 12:22:31 -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 k4NG6WKJ025817 for ; Tue, 23 May 2006 17:06:32 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4NG6WaK025816 for ipdvb-subscribed-users; Tue, 23 May 2006 17:06:32 +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 k4NG6L8n025798 for ; Tue, 23 May 2006 17:06:24 +0100 (BST) Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 17:06:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C67E82.D06DBCCE" Subject: RE: CRC Issue in Security Draft Date: Tue, 23 May 2006 17:06:13 +0100 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD359@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: <018160DBE8D48349A0CABF4424C3DC21AAD359@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: CRC Issue in Security Draft Thread-Index: AcZ+dViCP7iosBrVRM6/dEmEM8yXOAACiqKz From: To: X-OriginalArrivalTime: 23 May 2006 16:06:14.0808 (UTC) FILETIME=[D13F6980:01C67E82] 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: 325b777e1a3a618c889460b612a65510 This is a multi-part message in MIME format. ------_=_NextPart_001_01C67E82.D06DBCCE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Prashant and all,=0A= Thanks for your useful comments.=0A= =20=0A= Please find my comments below:=0A= =20=0A= 1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide= bit errors and integrity protection. And the receiver should first check C= RC before it gets the complete SNDU in the buffer. But once the security p= rocessing is done, at the receiver side the security process should be done= first and then handle the SNDU.=0A= =20=0A= 2) In case of having the cryptographic integrity block, I agree that the CR= C field becomes redundant whether it is encrypted or not. Because they both= are doing the same thing but with more assurance in the cryptographic case= (better anti collision properties). But the downside of this is more compl= exity.=0A= =20=0A= 3) If only encryption is done on the packet then I agree with you that the = CRC needs to be after the encryption block , so that some level of integrit= y is provided atleast against bit errors (physical channel).=0A= =20=0A= 4) The other option could be and this is addressed to the group to have a c= hoice between the CRC or additional integrity block (if needed).=0A= =20=0A= 5) I agree that the CRC should be after the encryption block, but may be re= dundant if using stronger cryptographic checksums.(MD5 , SHA-1).=0A= =20=0A= Regards=0A= Sunny=20=0A= =20=0A= ***********************************************************=0A= Sunil Iyengar,=0A= Research Fellow, Networks Group,=0A= Centre For Communication And Systems Research(CCSR),=0A= School of Electronics, Computing & Mathematics,=0A= University Of Surrey, Guildford GU2 7XH,=0A= Surrey, England, United Kingdom.=0A= Office: +44 (0)1483 686008=0A= ***********************************************************=0A= =0A= =0A= ________________________________=0A= =0A= From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk=0A= Sent: Tue 23/05/2006 12:46=0A= To: ipdvb@erg.abdn.ac.uk=0A= Subject: CRC Issue in Security Draft=0A= =0A= =0A= =0A= Hi Haitham and Sunny,=0A= =0A= I have a few questions regarding your security=0A= draft(draft-cruickshank-ipdvb-sec-01.txt):=0A= =0A= 1) I am not sure as to what is the main reason for encrypting the entire PDU= =0A= including the checksum as indicated by the draft on Page 4? As indicated in= the=0A= RFC4326, section 7.2 the receiver should be able validate the CRC as soon a= s it=0A= gets the complete SNDU in the buffer. I do not think that encrypting of this= =0A= CRC is a good idea, as this would violate the standard processing of the ULE= =0A= SNDU, where it would be have to skip this CRC check and first perform=0A= decryption of the packets and then come back and perform the CRC check. (He= nce=0A= it can no longer be just an extension header for ULE, as the processing has= =0A= changed)=0A= =0A= 2) Even if the CRC is not encrypted, another major conflict in the SNDU for= mat=0A= is the presence of the integrity block after your CRC. At the receiver side= as=0A= indicated in the RFC4326, section 7.2 the receiver should be able validate = the=0A= CRC as soon as it gets the complete SNDU in the buffer. At this stage the i= deal=0A= working of the receiver (for standard ULE) is to take the last 32 bits which= =0A= would be the CRC and perform the CRC check. But now the CRC is not at the e= nd=0A= and it may be difficult to extract the CRC from the SNDU especially because= the=0A= integrity block has not shown to have fixed size.=0A= =0A= 3) Also it is not clear why is the CRC required when the integrity block is= =0A= present. The integrity block would be using much complex algorithms like HM= ACs=0A= etc to detect if there is any change in the transmitted data and the receiv= ed=0A= data. This change could have resulted by an attacker modifying the message = or=0A= could have also been due to transmission/processing errors. In either case = the=0A= packets should be discarded. So does this not mean that the CRC is only=0A= duplicating the work and may not be really required when we have a stronger= =0A= integrity block?=0A= =0A= Regards=0A= Prashant=0A= =0A= =0A= --=0A= Prashant Pillai=0A= Research Assistant=0A= School of Engineering, Design and Technology=0A= University of Bradford=0A= Bradford, BD7 1DP=0A= West Yorkshire=0A= United Kingdom=0A= Phone: 0044-1274-233720=0A= email: p.pillai@bradford.ac.uk=0A= ------------------------------------------------------------=0A= This mail sent through IMP: http://webmail.brad.ac.uk=0A= To report misuse from this email address forward the message=0A= and full headers to misuse@bradford.ac.uk=0A= ------------------------------------------------------------=0A= =0A= =0A= =0A= ------_=_NextPart_001_01C67E82.D06DBCCE Content-Type: text/plain; name="msg-23911-31.txt" Content-Disposition: attachment; filename="msg-23911-31.txt" Content-Transfer-Encoding: 8bit Hi Prashant and all, Thanks for your useful comments. Please find my comments below: 1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide bit errors and integrity protection. And the receiver should first check CRC before it gets the complete SNDU in the buffer. But once the security processing is done, at the receiver side the security process should be done first and then handle the SNDU. 2) In case of having the cryptographic integrity block, I agree that the CRC field becomes redundant whether it is encrypted or not. Because they both are doing the same thing but with more assurance in the cryptographic case (better anti collision properties). But the downside of this is more complexity. 3) If only encryption is done on the packet then I agree with you that the CRC needs to be after the encryption block , so that some level of integrity is provided atleast against bit errors (physical channel). 4) The other option could be and this is addressed to the group to have a choice between the CRC or additional integrity block (if needed). 5) I agree that the CRC should be after the encryption block, but may be redundant if using stronger cryptographic checksums.(MD5 , SHA-1). Regards Sunny *********************************************************** 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: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk Sent: Tue 23/05/2006 12:46 To: ipdvb@erg.abdn.ac.uk Subject: CRC Issue in Security Draft Hi Haitham and Sunny, I have a few questions regarding your security draft(draft-cruickshank-ipdvb-sec-01.txt): 1) I am not sure as to what is the main reason for encrypting the entire PDU including the checksum as indicated by the draft on Page 4? As indicated in the RFC4326, section 7.2 the receiver should be able validate the CRC as soon as it gets the complete SNDU in the buffer. I do not think that encrypting of this CRC is a good idea, as this would violate the standard processing of the ULE SNDU, where it would be have to skip this CRC check and first perform decryption of the packets and then come back and perform the CRC check. (Hence it can no longer be just an extension header for ULE, as the processing has changed) 2) Even if the CRC is not encrypted, another major conflict in the SNDU format is the presence of the integrity block after your CRC. At the receiver side as indicated in the RFC4326, section 7.2 the receiver should be able validate the CRC as soon as it gets the complete SNDU in the buffer. At this stage the ideal working of the receiver (for standard ULE) is to take the last 32 bits which would be the CRC and perform the CRC check. But now the CRC is not at the end and it may be difficult to extract the CRC from the SNDU especially because the integrity block has not shown to have fixed size. 3) Also it is not clear why is the CRC required when the integrity block is present. The integrity block would be using much complex algorithms like HMACs etc to detect if there is any change in the transmitted data and the received data. This change could have resulted by an attacker modifying the message or could have also been due to transmission/processing errors. In either case the packets should be discarded. So does this not mean that the CRC is only duplicating the work and may not be really required when we have a stronger integrity block? Regards Prashant -- 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 ------------------------------------------------------------ ------_=_NextPart_001_01C67E82.D06DBCCE-- From owner-ipdvb@erg.abdn.ac.uk Tue May 23 14:52:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fibz7-0000QH-CX for ipdvb-archive@ietf.org; Tue, 23 May 2006 14:52:01 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fibz5-00059C-Qh for ipdvb-archive@ietf.org; Tue, 23 May 2006 14:52: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 k4NIbFrg006861 for ; Tue, 23 May 2006 19:37:15 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4NIbFPA006860 for ipdvb-subscribed-users; Tue, 23 May 2006 19:37:15 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from 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 k4NIb8XJ006844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 23 May 2006 19:37:09 +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 k4NIb8ZZ006480; Tue, 23 May 2006 19:37:08 +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 k4NIb81h003908; Tue, 23 May 2006 19:37:08 +0100 (BST) Received: from client-82-18-251-68.brhm.adsl.ntlworld.com (client-82-18-251-68.brhm.adsl.ntlworld.com [82.18.251.68]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Tue, 23 May 2006 19:37:08 +0100 Message-ID: <1148409428.44735654818e2@webmail6.brad.ac.uk> Date: Tue, 23 May 2006 19:37:08 +0100 From: P.Pillai@Bradford.ac.uk To: S.Iyengar@surrey.ac.uk Cc: ipdvb@erg.abdn.ac.uk Subject: RE: CRC Issue in Security Draft In-Reply-To: <018160DBE8D48349A0CABF4424C3DC21AAD359@EVS-EC1-NODE1.surrey.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: 82.18.251.68 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: 6ba8aaf827dcb437101951262f69b3de Hi Sunny, See replies inline: Quoting S.Iyengar@surrey.ac.uk: > Hi Prashant and all, > Thanks for your useful comments. > > Please find my comments below: > > 1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide > bit errors and integrity protection. And the receiver should first check CRC > before it gets the complete SNDU in the buffer. But once the security > processing is done, at the receiver side the security process should be done > first and then handle the SNDU. Prashant: The security processing should not be done before the CRC check and handling of the SNDU. This would violate the normal processing of the ULE SNDU and this would not be a standard extension (as you have proposed) as descirbed in the ULE RFC. If this is supposed to be a standard header extension (as described in Section 5 of RFC 4326) then the processing of the extension header (in this case the security extension header) should take place only after the the CRC check. Gorry, am I correct in saying this? > 2) In case of having the cryptographic integrity block, I agree that the CRC > field becomes redundant whether it is encrypted or not. Because they both are > doing the same thing but with more assurance in the cryptographic case > (better anti collision properties). But the downside of this is more > complexity. Prashant: The integrity block may increase complexity but there is definitely no use to have them both. > 3) If only encryption is done on the packet then I agree with you that the > CRC needs to be after the encryption block , so that some level of integrity > is provided atleast against bit errors (physical channel). > > 4) The other option could be and this is addressed to the group to have a > choice between the CRC or additional integrity block (if needed). Prashant: This is what I had proposed in my draft(draft-ppillai-ipdvb-sule-00.txt). But you have to be careful as you have proposed that the integrity block is optional. And also removing the CRC modifies the recevier processing of the SNDU as explanined in my draft. And this would not be a standard extension header. > 5) I agree that the CRC should be after the encryption block, but may be > redundant if using stronger cryptographic checksums.(MD5 , SHA-1). > > Regards > Sunny > > *********************************************************** > 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: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk > Sent: Tue 23/05/2006 12:46 > To: ipdvb@erg.abdn.ac.uk > Subject: CRC Issue in Security Draft > > > > Hi Haitham and Sunny, > > I have a few questions regarding your security > draft(draft-cruickshank-ipdvb-sec-01.txt): > > 1) I am not sure as to what is the main reason for encrypting the entire PDU > including the checksum as indicated by the draft on Page 4? As indicated in > the > RFC4326, section 7.2 the receiver should be able validate the CRC as soon as > it > gets the complete SNDU in the buffer. I do not think that encrypting of this > CRC is a good idea, as this would violate the standard processing of the ULE > SNDU, where it would be have to skip this CRC check and first perform > decryption of the packets and then come back and perform the CRC check. > (Hence > it can no longer be just an extension header for ULE, as the processing has > changed) > > 2) Even if the CRC is not encrypted, another major conflict in the SNDU > format > is the presence of the integrity block after your CRC. At the receiver side > as > indicated in the RFC4326, section 7.2 the receiver should be able validate > the > CRC as soon as it gets the complete SNDU in the buffer. At this stage the > ideal > working of the receiver (for standard ULE) is to take the last 32 bits which > would be the CRC and perform the CRC check. But now the CRC is not at the end > and it may be difficult to extract the CRC from the SNDU especially because > the > integrity block has not shown to have fixed size. > > 3) Also it is not clear why is the CRC required when the integrity block is > present. The integrity block would be using much complex algorithms like > HMACs > etc to detect if there is any change in the transmitted data and the received > data. This change could have resulted by an attacker modifying the message or > could have also been due to transmission/processing errors. In either case > the > packets should be discarded. So does this not mean that the CRC is only > duplicating the work and may not be really required when we have a stronger > integrity block? > > Regards > Prashant > > > -- > 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 > ------------------------------------------------------------ > > > > -- 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 Wed May 24 03:16:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FinbI-0000OR-8H for ipdvb-archive@ietf.org; Wed, 24 May 2006 03:16:12 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FinbG-0007DZ-RT for ipdvb-archive@ietf.org; Wed, 24 May 2006 03:16: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 k4O6x4bA029741 for ; Wed, 24 May 2006 07:59:04 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4O6x4co029740 for ipdvb-subscribed-users; Wed, 24 May 2006 07:59: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 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 k4O6wqr1029721 for ; Wed, 24 May 2006 07:58:52 +0100 (BST) Received: by dobermann.cosy.sbg.ac.at (Postfix, from userid 102) id C4B3D931FB; Wed, 24 May 2006 08:58:51 +0200 (CEST) Received: from [141.201.123.95] (dendroaspis.cosy.sbg.ac.at [141.201.123.95]) by dobermann.cosy.sbg.ac.at (Postfix) with ESMTP id 8F040931FA for ; Wed, 24 May 2006 08:58:48 +0200 (CEST) Message-ID: <44740452.2020406@cosy.sbg.ac.at> Date: Wed, 24 May 2006 08:59:30 +0200 From: Christian Praehauser User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: CRC Issue in Security Draft References: <018160DBE8D48349A0CABF4424C3DC21AAD359@EVS-EC1-NODE1.surrey.ac.uk> In-Reply-To: <018160DBE8D48349A0CABF4424C3DC21AAD359@EVS-EC1-NODE1.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hello Sunil! S.Iyengar@surrey.ac.uk wrote: > >1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide bit errors and integrity protection. And the receiver should first check CRC before it gets the complete SNDU in the buffer. But once the security processing is done, at the receiver side the security process should be done first and then handle the SNDU. > > The CRC also protects all extension headers, so it should be verified before inspecting/processing any extension headers. If you do not generate ULE SNDUs following the general format, you will get lots of ugly CRC errors at non-ULE-security-aware receivers. Repeating the question from Prashant: What is the reason for encrypting the whole SNDU including the CRC32? Is it a check if decryption was successful, thus avoiding to get wrong data up the receiver stack, e.g. if the transmitter/receiver keys are out of sync? Cheers, Christian. -- ________________________________________ | Christian Praehauser | |---------------------------------------| | Email: | | cpraehaus@cosy.sbg.ac.at | | Address: | | Institut fuer Computerwissenschaften | | Jakob-Haringer-Strasse 2 | | A-5020 Salzburg, Austria | |_______________________________________| From owner-ipdvb@erg.abdn.ac.uk Wed May 24 16:43:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0CE-0008AW-2u for ipdvb-archive@ietf.org; Wed, 24 May 2006 16:43:10 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0CB-0007JS-HE for ipdvb-archive@ietf.org; Wed, 24 May 2006 16:43:10 -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 k4OKLGXL001964 for ; Wed, 24 May 2006 21:21:16 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4OKLGIh001963 for ipdvb-subscribed-users; Wed, 24 May 2006 21:21: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 [10.0.1.74] (maxp2.dialup.abdn.ac.uk [139.133.201.161]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4OKKXG2001882 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 24 May 2006 21:21:03 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 24 May 2006 19:07:32 +0100 Subject: Re: CRC Issue in Security Draft From: Gorry Fairhurst To: , Message-ID: Thread-Topic: CRC Issue in Security Draft Thread-Index: AcZ/XO00K6jMdOtQEdqAcQAKlc/qXg== In-Reply-To: <1148409428.44735654818e2@webmail6.brad.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 On 23/5/06 19:37, "P.Pillai@Bradford.ac.uk" wrote: > Hi Sunny, > > See replies inline: > > Quoting S.Iyengar@surrey.ac.uk: > >> Hi Prashant and all, >> Thanks for your useful comments. >> >> Please find my comments below: >> >> 1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide >> bit errors and integrity protection. And the receiver should first check CRC >> before it gets the complete SNDU in the buffer. But once the security >> processing is done, at the receiver side the security process should be done >> first and then handle the SNDU. > > Prashant: The security processing should not be done before the CRC check and > handling of the SNDU. This would violate the normal processing of the ULE SNDU > and this would not be a standard extension (as you have proposed) as descirbed > in the ULE RFC. If this is supposed to be a standard header extension (as > described in Section 5 of RFC 4326) then the processing of the extension > header > (in this case the security extension header) should take place only after the > the CRC check. Gorry, am I correct in saying this? > Gorry: Extension headers do not impact the CRC-32. It therefore seems most desirable to use a security format that preserves the ULE framing and CRC usage that was defined in RFC 4326. > >> 2) In case of having the cryptographic integrity block, I agree that the CRC >> field becomes redundant whether it is encrypted or not. Because they both are >> doing the same thing but with more assurance in the cryptographic case >> (better anti collision properties). But the downside of this is more >> complexity. > > Prashant: The integrity block may increase complexity but there is definitely > no use to have them both. > I'd like to see the integrity requirements expressed clearer in the requirements I-D. >> 3) If only encryption is done on the packet then I agree with you that the >> CRC needs to be after the encryption block , so that some level of integrity >> is provided atleast against bit errors (physical channel). >> Yes. >> 4) The other option could be and this is addressed to the group to have a >> choice between the CRC or additional integrity block (if needed). > > Prashant: This is what I had proposed in my > draft(draft-ppillai-ipdvb-sule-00.txt). But you have to be careful as you have > proposed that the integrity block is optional. And also removing the CRC > modifies the recevier processing of the SNDU as explanined in my draft. And > this would not be a standard extension header. > >> 5) I agree that the CRC should be after the encryption block, but may be >> redundant if using stronger cryptographic checksums.(MD5 , SHA-1). >> Do we need a stronger check than a CRC-32 at the link layer? - there seems to be a trade-off between overhead and strength of check. >> Regards >> Sunny >> >> *********************************************************** >> 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: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk >> Sent: Tue 23/05/2006 12:46 >> To: ipdvb@erg.abdn.ac.uk >> Subject: CRC Issue in Security Draft >> >> >> >> Hi Haitham and Sunny, >> >> I have a few questions regarding your security >> draft(draft-cruickshank-ipdvb-sec-01.txt): >> >> 1) I am not sure as to what is the main reason for encrypting the entire PDU >> including the checksum as indicated by the draft on Page 4? As indicated in >> the >> RFC4326, section 7.2 the receiver should be able validate the CRC as soon as >> it >> gets the complete SNDU in the buffer. I do not think that encrypting of this >> CRC is a good idea, as this would violate the standard processing of the ULE >> SNDU, where it would be have to skip this CRC check and first perform >> decryption of the packets and then come back and perform the CRC check. >> (Hence >> it can no longer be just an extension header for ULE, as the processing has >> changed) >> >> 2) Even if the CRC is not encrypted, another major conflict in the SNDU >> format >> is the presence of the integrity block after your CRC. At the receiver side >> as >> indicated in the RFC4326, section 7.2 the receiver should be able validate >> the >> CRC as soon as it gets the complete SNDU in the buffer. At this stage the >> ideal >> working of the receiver (for standard ULE) is to take the last 32 bits which >> would be the CRC and perform the CRC check. But now the CRC is not at the end >> and it may be difficult to extract the CRC from the SNDU especially because >> the >> integrity block has not shown to have fixed size. >> >> 3) Also it is not clear why is the CRC required when the integrity block is >> present. The integrity block would be using much complex algorithms like >> HMACs >> etc to detect if there is any change in the transmitted data and the received >> data. This change could have resulted by an attacker modifying the message or >> could have also been due to transmission/processing errors. In either case >> the >> packets should be discarded. So does this not mean that the CRC is only >> duplicating the work and may not be really required when we have a stronger >> integrity block? >> >> Regards >> Prashant >> >> >> -- >> 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 Thu May 25 04:52:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjBZp-0002YH-Fb for ipdvb-archive@ietf.org; Thu, 25 May 2006 04:52:17 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjBZn-0004ue-Vc for ipdvb-archive@ietf.org; Thu, 25 May 2006 04:52:17 -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 k4P8hq6U025183 for ; Thu, 25 May 2006 09:43:52 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4P8hqRT025182 for ipdvb-subscribed-users; Thu, 25 May 2006 09:43:52 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from 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 k4P8hitI025166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 25 May 2006 09:43:44 +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 k4P8hc0L004848; Thu, 25 May 2006 09:43:38 +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 k4P8hc2r023539; Thu, 25 May 2006 09:43:38 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Thu, 25 May 2006 09:43:38 +0100 Message-ID: <1148546618.44756e3a2a3f8@webmail6.brad.ac.uk> Date: Thu, 25 May 2006 09:43:38 +0100 From: P.Pillai@Bradford.ac.uk To: S.Iyengar@surrey.ac.uk Cc: ipdvb@erg.abdn.ac.uk Subject: Re: CRC Issue in Security Draft - Why Encrypted type? In-Reply-To: <44740452.2020406@cosy.sbg.ac.at> 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.31.49 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: 41c17b4b16d1eedaa8395c26e9a251c4 Hi Sunny, I also wanted to ask one more thing- What is the reason to have an encrypted Type field? What do we need to protect it for? Regards Prashant Quoting Christian Praehauser : > Hello Sunil! > > S.Iyengar@surrey.ac.uk wrote: > > > > >1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide > bit errors and integrity protection. And the receiver should first check CRC > before it gets the complete SNDU in the buffer. But once the security > processing is done, at the receiver side the security process should be done > first and then handle the SNDU. > > > > > The CRC also protects all extension headers, so it should be verified > before inspecting/processing any extension headers. > If you do not generate ULE SNDUs following the general format, you will > get lots of ugly CRC errors at non-ULE-security-aware receivers. > > Repeating the question from Prashant: > What is the reason for encrypting the whole SNDU including the CRC32? > > Is it a check if decryption was successful, thus avoiding to get wrong > data up the receiver stack, e.g. if the transmitter/receiver keys are > out of sync? > > Cheers, > Christian. > > -- > ________________________________________ > | Christian Praehauser | > |---------------------------------------| > | Email: | > | cpraehaus@cosy.sbg.ac.at | > | Address: | > | Institut fuer Computerwissenschaften | > | Jakob-Haringer-Strasse 2 | > | A-5020 Salzburg, Austria | > |_______________________________________| > > -- 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 Thu May 25 05:21:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjC2Q-0001eC-NP for ipdvb-archive@ietf.org; Thu, 25 May 2006 05:21:50 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjC2P-0006fC-5h for ipdvb-archive@ietf.org; Thu, 25 May 2006 05:21: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 k4P9Cttk027816 for ; Thu, 25 May 2006 10:12:55 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4P9CtJU027815 for ipdvb-subscribed-users; Thu, 25 May 2006 10:12:55 +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 k4P9CmjP027799 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 25 May 2006 10:12:49 +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 k4P99Mcb008947; Thu, 25 May 2006 10:09:23 +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 k4P99LHM026802; Thu, 25 May 2006 10:09:21 +0100 (BST) Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Thu, 25 May 2006 10:09:21 +0100 Message-ID: <1148548161.4475744159eff@webmail6.brad.ac.uk> Date: Thu, 25 May 2006 10:09:21 +0100 From: P.Pillai@Bradford.ac.uk To: H.Cruickshank@surrey.ac.uk Cc: ipdvb@erg.abdn.ac.uk, Christian Praehauser Subject: Re: CRC Issue in Security Draft In-Reply-To: <44740452.2020406@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.31.49 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 k4P9Cttk027816 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Hi Haitham, In my opinion there are two alternatives for the CRC problem: The first i= s to replace the CRC completly with the Integrity block. The receivers who are= not configured for security will still use the CRC, while the others that are configured for security would expect to have an integrity block at the en= d of the SNDU instead of the CRC and hence have to just skip the CRC check. Christian, how feasible do you think this is? I have another alternate solution for the Secure ULE. I think this could = be used in the combined security draft that we plan to write together. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |D| Length | Type =3D S-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address * | | +------------------------------+ | | ULE_Security_ID | +------------------------------+-+-+--------------------------+ | ULE_Security_ID |S|A| Sequence Num.(Optional) | +------------------------------+-+-+--------------------------+ | Sequence Number (Optional) | MAC (Optional) | +------------------------------+------------------------------+ | MAC (Optional) | Type =3D Type of PDU | +------------------------------+------------------------------+ | | | | =3D Encrypted PDU =3D | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |1| Length (15 bits) | Type =3D S-ULE | +-+----------------------------+------------------------------+ | ULE_Security_ID | +-+-+---------------------------------------------------------+ |S|A| Sequence Number (Optional) | +-+-+--------------------------+------------------------------+ | Message Authentication Code (Optional) | +-------------------------------------------------------------+ | Type =3D IPv4 | | +------------------------------+ | | | | | =3D Encrypted IP Datagram =3D | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ The security extension header would be in complete accordance with the RF= C 4326. The processing of the ULE SNDU would also remain the same, and there woul= d be no violations. When the SNDU is received in the buffer, first the CRC check = is performed and then passed up for the processing of the SNDU. Two new fields have been added: S =96 Set to 1 if Sequence number is present else set to 0 A =96 Set to 1 of Message Authentication Code (Integrity block) is presen= t The ULE_secuirity_ID could be used to search the SAD to see if the option= al fields are present or not. But I Prefer to have the two 1-bit fields whic= h should provide faster processing of the SNDU (less searching from the database). The MAC would provide authenticity/integrity for the encrypted block (als= o for the sequence number if required). The processing steps at the transmitter would be: i) The higher layer PDU is encrypted. ii) The Encrypted PDU + Sequence Number + Key is used for generation of M= AC iii) Add all fields in the SNDU and then finally calculata the CRC and ad= d it in the end. The processing steps at the receiver would be: i) Perform CRC Check, Discard if mistmatch ii) ULE SNDU processing starts, sees that it is the mandatory security ex= tension header, reads the ULE SID iii) The next two fields can be used to see if the optional sequence numb= er and MAC are present or not iv) If Sequence number is present, then it would be verified to prevent r= eplayed packets v) Next the MAC is verified to make sure that there has been no modificat= ions to the PDU vi) Finally the decryption of the higher layer PDU is done and the PDU is= passed up. 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 Quoting Christian Praehauser : > Hello Sunil! > > S.Iyengar@surrey.ac.uk wrote: > > > > >1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to pr= ovide > bit errors and integrity protection. And the receiver should first chec= k CRC > before it gets the complete SNDU in the buffer. But once the security > processing is done, at the receiver side the security process should be= done > first and then handle the SNDU. > > > > > The CRC also protects all extension headers, so it should be verified > before inspecting/processing any extension headers. > If you do not generate ULE SNDUs following the general format, you will > get lots of ugly CRC errors at non-ULE-security-aware receivers. > > Repeating the question from Prashant: > What is the reason for encrypting the whole SNDU including the CRC32? > > Is it a check if decryption was successful, thus avoiding to get wrong > data up the receiver stack, e.g. if the transmitter/receiver keys are > out of sync? > > Cheers, > Christian. > --=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 Thu May 25 20:52:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQZ9-0001S7-94 for ipdvb-archive@ietf.org; Thu, 25 May 2006 20:52:35 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjQZ7-0003Po-Nc for ipdvb-archive@ietf.org; Thu, 25 May 2006 20:52: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 k4Q0ks4b007997 for ; Fri, 26 May 2006 01:46:54 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4Q0ksLE007996 for ipdvb-subscribed-users; Fri, 26 May 2006 01:46: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 asdc.com.cn ([211.151.89.22]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4Q0kDFl007979 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 26 May 2006 01:46:31 +0100 (BST) Message-Id: <200605260046.k4Q0kDFl007979@erg.abdn.ac.uk> Received: (qmail 26364 invoked by uid 503); 26 May 2006 00:47:12 -0000 Received: by simscan 1.1.0 ppid: 26264, pid: 26345, t: 0.1420s scanners: attach: 1.1.0 Received: from unknown (HELO asdcjoshua) (203.86.89.82) by asdc.com.cn with SMTP; 26 May 2006 00:47:11 -0000 From: "yangming" To: Subject: =?gb2312?B?tPC4tDogQ1JDIElzc3VlIGluIFNlY3VyaXR5IERyYWZ0?= Date: Fri, 26 May 2006 08:45:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1148548161.4475744159eff@webmail6.brad.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ/29S3WHEfETvTRV2FZFtwcytdVAAgentg X-Virus-Scanned: by Qfilter 1.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 k4Q0ks6o007993 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 k4Q0ks4b007997 X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.ab= dn.ac.uk] =B4=FA=B1=ED P.Pillai@Bradford.ac.uk =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA5=D4=C225=C8=D5 17:09 =CA=D5=BC=FE=C8=CB: H.Cruickshank@surrey.ac.uk =B3=AD=CB=CD: ipdvb@erg.abdn.ac.uk; Christian Praehauser =D6=F7=CC=E2: Re: CRC Issue in Security Draft Hi Haitham, In my opinion there are two alternatives for the CRC problem: The first i= s to replace the CRC completly with the Integrity block. The receivers who are not configured for security will still use the CRC, while the others that are configured for security would expect to have an integrity block at the en= d of the SNDU instead of the CRC and hence have to just skip the CRC check. Christian, how feasible do you think this is? I have another alternate solution for the Secure ULE. I think this could = be used in the combined security draft that we plan to write together. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |D| Length | Type =3D S-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address * | | +------------------------------+ | | ULE_Security_ID | +------------------------------+-+-+--------------------------+ | ULE_Security_ID |S|A| Sequence Num.(Optional) | +------------------------------+-+-+--------------------------+ | Sequence Number (Optional) | MAC (Optional) | +------------------------------+------------------------------+ | MAC (Optional) | Type =3D Type of PDU | +------------------------------+------------------------------+ | | | | =3D Encrypted PDU =3D | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |1| Length (15 bits) | Type =3D S-ULE | +-+----------------------------+------------------------------+ | ULE_Security_ID | +-+-+---------------------------------------------------------+ |S|A| Sequence Number (Optional) | +-+-+--------------------------+------------------------------+ | Message Authentication Code (Optional) | +-------------------------------------------------------------+ | Type =3D IPv4 | | +------------------------------+ | | | | | =3D Encrypted IP Datagram =3D | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ The security extension header would be in complete accordance with the RF= C 4326. The processing of the ULE SNDU would also remain the same, and there woul= d be no violations. When the SNDU is received in the buffer, first the CRC check = is performed and then passed up for the processing of the SNDU. Two new fields have been added: S =A8C Set to 1 if Sequence number is present else set to 0 A =A8C Set to 1 of Message Authentication Code (Integrity block) is prese= nt The ULE_secuirity_ID could be used to search the SAD to see if the option= al fields are present or not. But I Prefer to have the two 1-bit fields whic= h should provide faster processing of the SNDU (less searching from the database). The MAC would provide authenticity/integrity for the encrypted block (als= o for the sequence number if required). The processing steps at the transmitter would be: i) The higher layer PDU is encrypted. ii) The Encrypted PDU + Sequence Number + Key is used for generation of M= AC iii) Add all fields in the SNDU and then finally calculata the CRC and ad= d it in the end. The processing steps at the receiver would be: i) Perform CRC Check, Discard if mistmatch ii) ULE SNDU processing starts, sees that it is the mandatory security extension header, reads the ULE SID iii) The next two fields can be used to see if the optional sequence numb= er and MAC are present or not iv) If Sequence number is present, then it would be verified to prevent replayed packets v) Next the MAC is verified to make sure that there has been no modifications to the PDU vi) Finally the decryption of the higher layer PDU is done and the PDU is passed up. 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 Quoting Christian Praehauser : > Hello Sunil! > > S.Iyengar@surrey.ac.uk wrote: > > > > >1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide > bit errors and integrity protection. And the receiver should first chec= k CRC > before it gets the complete SNDU in the buffer. But once the security > processing is done, at the receiver side the security process should be done > first and then handle the SNDU. > > > > > The CRC also protects all extension headers, so it should be verified > before inspecting/processing any extension headers. > If you do not generate ULE SNDUs following the general format, you will > get lots of ugly CRC errors at non-ULE-security-aware receivers. > > Repeating the question from Prashant: > What is the reason for encrypting the whole SNDU including the CRC32? > > Is it a check if decryption was successful, thus avoiding to get wrong > data up the receiver stack, e.g. if the transmitter/receiver keys are > out of sync? > > Cheers, > Christian. > --=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 Thu May 25 20:58:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQf5-0004IZ-OP for ipdvb-archive@ietf.org; Thu, 25 May 2006 20:58:43 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjQf4-0004MB-6K for ipdvb-archive@ietf.org; Thu, 25 May 2006 20:58: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 k4Q0sh5f008396 for ; Fri, 26 May 2006 01:54:43 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4Q0shRH008395 for ipdvb-subscribed-users; Fri, 26 May 2006 01:54: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 asdc.com.cn ([211.151.89.22]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4Q0sIWB008365 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 26 May 2006 01:54:25 +0100 (BST) Message-Id: <200605260054.k4Q0sIWB008365@erg.abdn.ac.uk> Received: (qmail 29669 invoked by uid 503); 26 May 2006 00:55:14 -0000 Received: by simscan 1.1.0 ppid: 29646, pid: 29654, t: 0.1235s scanners: attach: 1.1.0 Received: from unknown (HELO asdcjoshua) (203.86.89.82) by asdc.com.cn with SMTP; 26 May 2006 00:55:13 -0000 From: "yangming" To: Subject: =?gb2312?B?tPC4tDogQ1JDIElzc3VlIGluIFNlY3VyaXR5IERyYWZ0?= Date: Fri, 26 May 2006 08:53:58 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200605260046.k4Q0kDFl007979@erg.abdn.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ/29S3WHEfETvTRV2FZFtwcytdVAAgentgAABDG6A= X-Virus-Scanned: by Qfilter 1.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 k4Q0shOI008392 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 k4Q0sh5f008396 X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c I just want to unsubscribe this user group=20 Thank you -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.ab= dn.ac.uk] =B4=FA=B1=ED yangming =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA5=D4=C226=C8=D5 8:46 =CA=D5=BC=FE=C8=CB: ipdvb@erg.abdn.ac.uk =D6=F7=CC=E2: =B4=F0=B8=B4: CRC Issue in Security Draft -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.ab= dn.ac.uk] =B4=FA=B1=ED P.Pillai@Bradford.ac.uk =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA5=D4=C225=C8=D5 17:09 =CA=D5=BC=FE=C8=CB: H.Cruickshank@surrey.ac.uk =B3=AD=CB=CD: ipdvb@erg.abdn.ac.uk; Christian Praehauser =D6=F7=CC=E2: Re: CRC Issue in Security Draft Hi Haitham, In my opinion there are two alternatives for the CRC problem: The first i= s to replace the CRC completly with the Integrity block. The receivers who are not configured for security will still use the CRC, while the others that are configured for security would expect to have an integrity block at the en= d of the SNDU instead of the CRC and hence have to just skip the CRC check. Christian, how feasible do you think this is? I have another alternate solution for the Secure ULE. I think this could = be used in the combined security draft that we plan to write together. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |D| Length | Type =3D S-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address * | | +------------------------------+ | | ULE_Security_ID | +------------------------------+-+-+--------------------------+ | ULE_Security_ID |S|A| Sequence Num.(Optional) | +------------------------------+-+-+--------------------------+ | Sequence Number (Optional) | MAC (Optional) | +------------------------------+------------------------------+ | MAC (Optional) | Type =3D Type of PDU | +------------------------------+------------------------------+ | | | | =3D Encrypted PDU =3D | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |1| Length (15 bits) | Type =3D S-ULE | +-+----------------------------+------------------------------+ | ULE_Security_ID | +-+-+---------------------------------------------------------+ |S|A| Sequence Number (Optional) | +-+-+--------------------------+------------------------------+ | Message Authentication Code (Optional) | +-------------------------------------------------------------+ | Type =3D IPv4 | | +------------------------------+ | | | | | =3D Encrypted IP Datagram =3D | | | | +-------------------------------------------------------------+ | Cyclic Redundancy Code | +-------------------------------------------------------------+ The security extension header would be in complete accordance with the RF= C 4326. The processing of the ULE SNDU would also remain the same, and there woul= d be no violations. When the SNDU is received in the buffer, first the CRC check = is performed and then passed up for the processing of the SNDU. Two new fields have been added: S =A8C Set to 1 if Sequence number is present else set to 0 A =A8C Set to 1 of Message Authentication Code (Integrity block) is prese= nt The ULE_secuirity_ID could be used to search the SAD to see if the option= al fields are present or not. But I Prefer to have the two 1-bit fields whic= h should provide faster processing of the SNDU (less searching from the database). The MAC would provide authenticity/integrity for the encrypted block (als= o for the sequence number if required). The processing steps at the transmitter would be: i) The higher layer PDU is encrypted. ii) The Encrypted PDU + Sequence Number + Key is used for generation of M= AC iii) Add all fields in the SNDU and then finally calculata the CRC and ad= d it in the end. The processing steps at the receiver would be: i) Perform CRC Check, Discard if mistmatch ii) ULE SNDU processing starts, sees that it is the mandatory security extension header, reads the ULE SID iii) The next two fields can be used to see if the optional sequence numb= er and MAC are present or not iv) If Sequence number is present, then it would be verified to prevent replayed packets v) Next the MAC is verified to make sure that there has been no modifications to the PDU vi) Finally the decryption of the higher layer PDU is done and the PDU is passed up. 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 Quoting Christian Praehauser : > Hello Sunil! > > S.Iyengar@surrey.ac.uk wrote: > > > > >1) As indicated in the ULE specs a 32 bit polynomial CRC is sued to provide > bit errors and integrity protection. And the receiver should first chec= k CRC > before it gets the complete SNDU in the buffer. But once the security > processing is done, at the receiver side the security process should be done > first and then handle the SNDU. > > > > > The CRC also protects all extension headers, so it should be verified > before inspecting/processing any extension headers. > If you do not generate ULE SNDUs following the general format, you will > get lots of ugly CRC errors at non-ULE-security-aware receivers. > > Repeating the question from Prashant: > What is the reason for encrypting the whole SNDU including the CRC32? > > Is it a check if decryption was successful, thus avoiding to get wrong > data up the receiver stack, e.g. if the transmitter/receiver keys are > out of sync? > > Cheers, > Christian. > --=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 Wed May 31 07:27:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlOrZ-00011B-M0 for ipdvb-archive@ietf.org; Wed, 31 May 2006 07:27:45 -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 1FlOl9-0000n6-HX for ipdvb-archive@ietf.org; Wed, 31 May 2006 07:21:07 -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 1FlOQ9-0005OS-Ei for ipdvb-archive@ietf.org; Wed, 31 May 2006 06:59:26 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4VAmFfF012858 for ; Wed, 31 May 2006 11:48:15 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4VAmF46012857 for ipdvb-subscribed-users; Wed, 31 May 2006 11:48:15 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [192.168.2.133] (p54996864.dip.t-dialin.net [84.153.104.100]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4VAm6pM012840 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 31 May 2006 11:48:07 +0100 (BST) User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 31 May 2006 12:50:58 +0200 Subject: Update of the Security Requirements I-D From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: Update of the Security Requirements I-D Thread-Index: AcaEoBlBV+SG+vCTEdqxfAAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f There has been some discussion of requirements and objectives on this list (and one new I-D with a security requirements section). I hope the requirements I-D could be sufficiently well developed that we can table this at the next IETF as a potential WG draft. It would now seem a good time to try to capture this discussion by adding text to the security requirements I-D. Would one of the current authors be willing to draft some modified text based on these discussions and to update their I-D? I'd also be interested to hear from others on the list who have experience with security protocols or understand requirements. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From owner-ipdvb@erg.abdn.ac.uk Wed May 31 09:51:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlR6o-0000Aj-KC for ipdvb-archive@ietf.org; Wed, 31 May 2006 09:51:38 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlR6l-00069x-45 for ipdvb-archive@ietf.org; Wed, 31 May 2006 09:51:38 -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 k4VDdsvW025650 for ; Wed, 31 May 2006 14:39:54 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k4VDds1O025649 for ipdvb-subscribed-users; Wed, 31 May 2006 14:39: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 kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k4VDdkSd025633 for ; Wed, 31 May 2006 14:39:46 +0100 (BST) Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BD7B01BAC4D for ; Wed, 31 May 2006 15:30:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <9686D711-6E29-465D-AB34-D16E185FE409@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ipdvb@erg.abdn.ac.uk From: Martin Stiemerling Subject: Comments on draft-ietf-ipdvb-ar-03.txt Date: Wed, 31 May 2006 15:39:40 +0200 X-Mailer: Apple Mail (2.750) X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Dear All, I have read the draft Address Resolution for IP Datagrams over MPEG-2 Networks (draft-ietf-ipdvb-ar-03.txt) and got to some questions. Some nits: - In Section 6.2, 6.3, and 6.4 it reads that the Ethernet Type (EtherType) is IANA assigned. This is IMO wrong, since the Ethernet Types are allocated by the IEEE. IANA only maintains a list of used (or once seen) types (http://www.iana.org/assignments/ethernet-numbers). - The section heading of 5.1 is too long, i.e., it is wrapped into two lines. - I assume the document should be the part on Submit AR Framework to IESG of the WG charter. If so, it would be good if the document title or the introduction would reflect this. Overall comments: As stated in the above section about nits, I assume the document should give the framework of address resolution for IP datagrams over MPEG-2 networks. The document gives an excellent overview about the actuall problem to be solved and the existing address resolution mechanisms in the IP world plus their mapping to MPEG-2 networks. The coverage of not only one technology but the inclusion of DVB, ATSC, DOCSIS and the respective variants in system tables is very helpful to understand the problem space and the trickiness of a fits all solution :-) After reading the whole document I have been nevertheless confused about it. When reading the title, I would expect a solution and after reading the document I did not know what the real conclusion of the document is. There are recommendations for the single technologies/techniques, which are fully OK, but what would be the next steps towards the address resolution solution? Can we reuse the existing protocols or do we need to go ahead with a new AR protocol (as the WG charter would let assume)? Kind Regards, Martin Stiemerling NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg WWW: http://www.netlab.nec.de