From owner-ipdvb@erg.abdn.ac.uk Wed Nov 01 02:09:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfADn-0005Ar-8k for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 02:09:11 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfA7g-0006vC-Bb for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 02:02:53 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA16b8WW002633 for ; Wed, 1 Nov 2006 06:37:08 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA16b85G002632 for ipdvb-subscribed-users; Wed, 1 Nov 2006 06:37:08 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from mail.jmn.net.id (mail.jmn.net.id [202.169.224.5]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA16Zc2l002585 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 1 Nov 2006 06:36:27 GMT Received: (qmail 26561 invoked by uid 510); 1 Nov 2006 13:29:48 +0700 Received: from 127.0.0.1 by semur.jmn.net.id (envelope-from , uid 509) with qmail-scanner-D0N0 (clamdscan: 0.88.2/1448. spamassassin: 3.1.1. perlscan: D0N0. Clear:RC:1(127.0.0.1):. Processed in 0.073697 secs); 01 Nov 2006 06:29:48 -0000 TuKaNG-ScAn-JMN-Mail-From: johanfirdi@jmn.net.id via semur.jmn.net.id TuKaNG-ScAn-JMN: D0N0 (Clear:RC:1(127.0.0.1):. Processed in 0.073697 secs Process 26554) Received: from localhost (HELO mail.jmn.net.id) (127.0.0.1) by mail.jmn.net.id with SMTP; 1 Nov 2006 13:29:48 +0700 Received: from 202.169.225.177 (proxying for unknown) (SquirrelMail authenticated user johanfirdi@jmn.net.id) by mail.jmn.net.id with HTTP; Wed, 1 Nov 2006 13:29:48 +0700 (WIT) Message-ID: <36877.202.169.225.177.1162362588.squirrel@mail.jmn.net.id> Date: Wed, 1 Nov 2006 13:29:48 +0700 (WIT) Subject: any dvb vendor have implemented ule ? From: "Johan firdianto" To: ipdvb@erg.abdn.ac.uk User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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: 30ac594df0e66ffa5a93eb4c48bcb014 dear guys, any dvb vendor have supported ule ?. receiver and IPE side. Thanks. Johan From owner-ipdvb@erg.abdn.ac.uk Wed Nov 01 10:26:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHyI-0003rz-GZ for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 10:25:42 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHkG-0002YA-58 for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 10:11:16 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA1EqnkZ015291 for ; Wed, 1 Nov 2006 14:52:49 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA1EqnOO015290 for ipdvb-subscribed-users; Wed, 1 Nov 2006 14:52:49 GMT 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 kA1EqdBS015270 for ; Wed, 1 Nov 2006 14:52:39 GMT Message-ID: <4548B4B7.3030801@erg.abdn.ac.uk> Date: Wed, 01 Nov 2006 14:52:39 +0000 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: any dvb vendor have implemented ule ? References: <36877.202.169.225.177.1162362588.squirrel@mail.jmn.net.id> In-Reply-To: <36877.202.169.225.177.1162362588.squirrel@mail.jmn.net.id> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 There are several ULE stacks. The ones that currently have sent information to the ipdvb WG are listed at: http://www.erg.abdn.ac.uk/ip-dvb/ipdvb-impl.html If other people have implementations / further information, please send corrections to this email list. best wishes, Gorry Faihurst Johan firdianto wrote: > dear guys, > > any dvb vendor have supported ule ?. > receiver and IPE side. > Thanks. > > Johan > > > From owner-ipdvb@erg.abdn.ac.uk Wed Nov 01 10:44:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGJ-0005D8-WC for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 10:44:20 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIAr-0002mA-9n for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 10:38:48 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA1FKutj017815 for ; Wed, 1 Nov 2006 15:20:56 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA1FKuea017814 for ipdvb-subscribed-users; Wed, 1 Nov 2006 15:20:56 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from dexter.ooi.net (dexter.ooi.net [66.251.134.16]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id kA1FKfkJ017791 for ; Wed, 1 Nov 2006 15:20:41 GMT Received: (qmail 22312 invoked by uid 108); 1 Nov 2006 15:22:13 -0000 Received: from unknown (HELO bear) (kevin@eccincorp.com@199.106.52.17) by dexter.ooi.net with SMTP; 1 Nov 2006 15:22:13 -0000 From: "Kevin Kimmich" To: Subject: RE: any dvb vendor have implemented ule ? Date: Wed, 1 Nov 2006 10:20:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4548B4B7.3030801@erg.abdn.ac.uk> Importance: Normal 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 I'd like to update our entry: Name of implementor : Efficient Channel Coding URL: www.eccincorp.com Contact: kevin@eccincorp.com ULE Gateway: iSatLite Network Interface Unit ULE Receiver: iSatLite Broadband Satellite Terminal Target platform/OS : Linux based embedded devices Latest known rev: draft-fair-ipdvb-ule-02 Air-interface: DVB-S2 Implementation type: Commercial Thanks, Kevin Kimmich software engineer Efficient Channel Coding, Inc. 216-441-8535 x 268 kevin@eccincorp.com -----Original Message----- From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On Behalf Of Gorry Fairhurst Sent: Wednesday, November 01, 2006 9:53 AM To: ipdvb@erg.abdn.ac.uk Subject: Re: any dvb vendor have implemented ule ? There are several ULE stacks. The ones that currently have sent information to the ipdvb WG are listed at: http://www.erg.abdn.ac.uk/ip-dvb/ipdvb-impl.html If other people have implementations / further information, please send corrections to this email list. best wishes, Gorry Faihurst Johan firdianto wrote: > dear guys, > > any dvb vendor have supported ule ?. > receiver and IPE side. > Thanks. > > Johan > > > From owner-ipdvb@erg.abdn.ac.uk Wed Nov 01 11:52:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfJKL-0007WT-1w for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 11:52:33 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfJKH-0000l9-Ja for ipdvb-archive@ietf.org; Wed, 01 Nov 2006 11:52:33 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA1GQrWj023315 for ; Wed, 1 Nov 2006 16:26:53 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA1GQrPO023314 for ipdvb-subscribed-users; Wed, 1 Nov 2006 16:26:53 GMT 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 kA1GQhqY023297 for ; Wed, 1 Nov 2006 16:26:43 GMT Message-ID: <4548CAC3.400@erg.abdn.ac.uk> Date: Wed, 01 Nov 2006 16:26:43 +0000 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: any dvb vendor have implemented ule ? 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: -2.8 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Thanks, the page has now been updated. Gorry Kevin Kimmich wrote: > I'd like to update our entry: > > Name of implementor : Efficient Channel Coding > URL: www.eccincorp.com > Contact: kevin@eccincorp.com > > ULE Gateway: iSatLite Network Interface Unit > ULE Receiver: iSatLite Broadband Satellite Terminal > Target platform/OS : Linux based embedded devices > Latest known rev: draft-fair-ipdvb-ule-02 > Air-interface: DVB-S2 > Implementation type: Commercial > > Thanks, > Kevin Kimmich > software engineer > Efficient Channel Coding, Inc. > 216-441-8535 x 268 > kevin@eccincorp.com > > > > -----Original Message----- > From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]On > Behalf Of Gorry Fairhurst > Sent: Wednesday, November 01, 2006 9:53 AM > To: ipdvb@erg.abdn.ac.uk > Subject: Re: any dvb vendor have implemented ule ? > > > There are several ULE stacks. The ones that currently have sent > information to the ipdvb WG are listed at: > > http://www.erg.abdn.ac.uk/ip-dvb/ipdvb-impl.html > > If other people have implementations / further information, please send > corrections to this email list. > > best wishes, > > Gorry Faihurst > > > Johan firdianto wrote: > > >>dear guys, >> >>any dvb vendor have supported ule ?. >>receiver and IPE side. >>Thanks. >> >>Johan >> >> >> > > > > From owner-ipdvb@erg.abdn.ac.uk Mon Nov 06 00:08:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggwib-0002Jg-Ly for ipdvb-archive@ietf.org; Mon, 06 Nov 2006 00:08:21 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggwib-0003oN-9s for ipdvb-archive@ietf.org; Mon, 06 Nov 2006 00:08:21 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA64pCX7022473 for ; Mon, 6 Nov 2006 04:51:12 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA64pC12022472 for ipdvb-subscribed-users; Mon, 6 Nov 2006 04:51:12 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.204.42] (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA64ov1G022440 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 6 Nov 2006 04:51:01 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Sun, 05 Nov 2006 21:50:44 -0700 Subject: Advance copies of meeting slides for the meeting on Thursday From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: Advance copies of meeting slides for the meeting on Thursday Thread-Index: AccBXx39XExgom1SEduCtAAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: -2.4 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I've uploaded advance copies of the slides that I have currently received for Thursday's meeting of the IPDVB WG. Other presenters - please could you send copies of your slides to me, and I will ensure they are uploaded. Advance copies of the presentations are extremely useful for people intend to participate via Jabber. Best wishes, Gorry (IPDVB WG Chair) From owner-ipdvb@erg.abdn.ac.uk Mon Nov 06 13:44:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9S4-000854-5Z for ipdvb-archive@ietf.org; Mon, 06 Nov 2006 13:44:08 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9S0-0008Su-D4 for ipdvb-archive@ietf.org; Mon, 06 Nov 2006 13:44:08 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA6I6dAX027328 for ; Mon, 6 Nov 2006 18:06:40 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA6I6dWO027327 for ipdvb-subscribed-users; Mon, 6 Nov 2006 18:06:39 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.71.147] (dhcp71-147.ietf67.org [130.129.71.147]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA6I6LK4027290 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 6 Nov 2006 18:06:27 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 06 Nov 2006 10:06:15 -0800 Subject: Remote Participation at IETF67 IPDVB WG From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: Remote Participation at IETF67 IPDVB WG Thread-Index: AccBzj/hfqpinG3BEduHQwAKlc/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: 9ed51c9d1356100bce94f1ae4ec616a9 The IETF meeting is (as usual) open to remote participation using audio and jabber. Details are below. Best wishes, Gorry ----- You can find the agenda and presentation materials at http://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 IPR reminder - RFC 3979 https://datatracker.ietf.org/public/ipr_disclosure.cgi If you know about IPR relevant to the technology and you are contributing, you have to speak up Audiocast http://videolab.uoregon.edu/events/ietf/ Jabber The new jabber server is located at dccp@jabber.ietf.org and is currently accessible. For those who are interested, please visit the above location to join any of the available chat rooms. Please note: All traffic within the defined rooms is being logged and updated every 5 minutes to the ietf.org website. To view the log directories, point your browser to http://www.ietf.org/meetings/ietf-logs/. If you click on a room directory, you will see one or more files named "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you click on one of those files, you will see all logged traffic for that day. Please visit the IETF Text Conferencing Web page (http://www.ietf.org/meetings/text_conf.html) for more information. From owner-ipdvb@erg.abdn.ac.uk Wed Nov 08 20:48:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghz1Z-00083D-AJ for ipdvb-archive@ietf.org; Wed, 08 Nov 2006 20:48:13 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghz1W-00017a-O8 for ipdvb-archive@ietf.org; Wed, 08 Nov 2006 20:48:13 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA91Vqa4020215 for ; Thu, 9 Nov 2006 01:31:52 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA91Vq23020214 for ipdvb-subscribed-users; Thu, 9 Nov 2006 01:31:52 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.71.147] (dhcp71-147.ietf67.org [130.129.71.147]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA91VP3q020143 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 9 Nov 2006 01:31:29 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 09 Nov 2006 01:31:20 +0000 Subject: I-D ACTION:draft-byun-ipdvb-ule-header-comp-00.txt From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" CC: Do Byun Message-ID: Thread-Topic: I-D ACTION:draft-byun-ipdvb-ule-header-comp-00.txt Thread-Index: AccDnsIgAMDn1G+SEduHQwAKlc/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 : Header Compression over Unidirectional Lightweight Encryption (ULE) Author(s) : D. Byun, et al. Filename : draft-byun-ipdvb-ule-header-comp-00.txt Pages : 8 Date : 2006-11-8 Multi-Protocol Encapsulation (MPE) is widely deployed in DVB-S and DVB-S2 networks [DVB-S2]. Replacing MPE with Unidirectional Lightweight Encryption (ULE) has been proposed to gain flexibility and reduce overhead. This paper introduces a signaling method for sending header-compressed unicast packets over satellite networks using ULE, taking advantage of ULE's increased flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-byun-ipdvb-ule-header-comp-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-byun-ipdvb-ule-header-comp-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-byun-ipdvb-ule-header-comp-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 Wed Nov 08 21:49:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghzz4-0004sS-4O for ipdvb-archive@ietf.org; Wed, 08 Nov 2006 21:49:42 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhzqB-0005Zu-GX for ipdvb-archive@ietf.org; Wed, 08 Nov 2006 21:40:33 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA929ZZV022968 for ; Thu, 9 Nov 2006 02:09:35 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kA929ZVj022967 for ipdvb-subscribed-users; Thu, 9 Nov 2006 02:09:35 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hnse2.hns.com (hnse2.hns.com [208.236.67.201]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kA929I4j022941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 9 Nov 2006 02:09:19 GMT Received: from excore8.hns.com (excore8.hns.com [139.85.52.156]) by hnse2.hns.com (Switch-3.1.9/Switch-3.1.9) with ESMTP id kA929Ald008366; Wed, 8 Nov 2006 21:09:11 -0500 (EST) Received: from hns.com (rasnvpn10.hns.com [139.85.221.93]) by excore8.hns.com (Switch-3.1.9/Switch-3.1.9) with ESMTP id kA927Kl2028746; Wed, 8 Nov 2006 21:07:33 -0500 (EST) Message-ID: <45528DB6.3070702@hns.com> Date: Wed, 08 Nov 2006 21:08:54 -0500 From: John Border User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: Carsten Bormann Subject: Re: ROHC and ULE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Carsten, This popped back to the top of my stack and finally re-read the presentation you gave. Where did ROHC go with 802.3? Is there a length-field encoding? Our draft proposes just a new EtherType. Your presentation implies there may be issues with just taking this simple approach... John Carsten Bormann wrote: > Hi Cedric, > > a couple of comments. > > I have made a couple of proposals at previous IPDVB meetings how to > integrate ROHC into ULE. > E.g., see http://www3.ietf.org/proceedings/05mar/slides/ipdvb-0.pdf > The most important input that would be useful at this point is how > ROHC will be used in actual systems, see below. > > >> Now, how having a multicast addressing to work with ROHC remains an >> open >> issue, but at least a basic solution would be the use of unidirectional >> mode (no need to acknowdege) > > > ROHC works fine in U-mode on unidirectional channels. > On a satellite link, the high delay for a context repair may actually > make this the best mode to look at. > >> Negociation of parameters between compressor and decompressor >> This point does not appear to be address in the document yet, but >> how to >> make the negociation is a real issue for the implementation of ROHC >> over >> ULE. Probably some propositions should be discussed here ? (e.g. use of >> default parameters according to the type of DVB network ? PPP >> replacement ? >> use of SI tables ? etc...) > > > We could probably come up with some default values. You would still > need to look at capacity points such as number of CIDs. > These could be "announced" (as opposed to "negotiated"). > >> ROHC recommendation >> We strongly believe that one of the output of the task shall be ROHC >> usage >> recommendations. This can be either parameters values proposition or >> analysis of the best suited mode depending on different scenarios >> (namely >> unidr system, satcom systems with a return link, in both mesh and star >> topologies) > > > I'm happy to do this work if enough people are interested. > >> ROHC adaptation >> A interesting point to investigate can be ROHC adaptation to fit the >> satellite systems and the ULE stack. Two approaches can be foreseen. >> The >> first one is dedicated to simplification of the compression scheme, > > > Actually, we have just done that: > > draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt > > "...The RoHCv2 specification introduce a number of > simplifications to the rules and algorithms that govern the > behavior of the > compression endpoints..." > >> and the >> second one to the optimisation of ROHC in this context. > > > see above/below... > >> >> ULE over ROHC ? >> This has never been proposed, but maybe the compression gain could be >> pushed a little more, if new ROHC profiles integrating ULE (i.e.. x/ >> IP/ULE) >> were supported ? What would be the main barriers for such an approach ? > > > These would probably be easy to add to ROHCv2. > > Gruesse, Carsten > > > From nagisa778@so-net.ne.jp Thu Nov 09 05:32:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi7Cw-0005sy-G2 for IPDVB-ARCHIVE@IETF.ORG; Thu, 09 Nov 2006 05:32:30 -0500 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 1Gi79t-00075p-AW for IPDVB-ARCHIVE@IETF.ORG; Thu, 09 Nov 2006 05:29:21 -0500 Received: from [222.170.90.223] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gi79o-0004BG-C0 for IPDVB-ARCHIVE@IETF.ORG; Thu, 09 Nov 2006 05:29:21 -0500 Received: from qdoefsqwe5 (unknown [34.100.155.4]) by smtp0 (Coremail) with SMTP id EyUi8Je5GiDo2Hzr.1 for ; Mon, 03 Nov 2003 20:02:47 +0800 (CST) X-Originating-IP: [34.100.155.4] Subject: =?iso-2022-jp?B?GyRCPiE8aiRLJDQkYSRzJEokNSQkGyhC?= From: =?shift-jis?B?bmFnaXNh?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C700DD.4EFE2780" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C700DD.4EFE2780 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 貴方のアドレス、アドレスを売っている業者から買いました。どうしても男性と体の 関係になりたくて、まだ経験した事無いんです。こちらでhttp://vqlh.com/?my17私 の写真確認して、もしOKでしたら、私のアドレスにメールください。マヤっていいま す。 メール受信拒否 I don't veceive yourmail ever_green_1313@yahoo.fr ------=_NextPart_000_0008_01C700DD.4EFE2780 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B5.J}$N%"%I%l%9!"%"%I%l%9$rGd$C$F$$$k6Hhttp://vqlh.com/?my17=1B$B;d$N


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
=1B$B%a!<%kI don't veceive = yourmail
ever_green_1313@yahoo.fr
------=_NextPart_000_0008_01C700DD.4EFE2780-- From owner-ipdvb@erg.abdn.ac.uk Thu Nov 09 20:19:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiL3Q-0001r8-U6 for ipdvb-archive@ietf.org; Thu, 09 Nov 2006 20:19:36 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiL3O-0003BU-FD for ipdvb-archive@ietf.org; Thu, 09 Nov 2006 20:19:36 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAA0xSp4015712 for ; Fri, 10 Nov 2006 00:59:28 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAA0xSfV015711 for ipdvb-subscribed-users; Fri, 10 Nov 2006 00:59:28 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.71.147] (dhcp71-147.ietf67.org [130.129.71.147]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAA0xA4i015673 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 10 Nov 2006 00:59:12 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 10 Nov 2006 00:59:04 +0000 Subject: Call for feedback: Security requirements for IETF IPDVB WG From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" CC: Gorry Fairhurst Message-ID: Thread-Topic: Call for feedback: Security requirements for IETF IPDVB WG Thread-Index: AccEY2qYqO/kFnBWEduHQwAKlc/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: b19722fc8d3865b147c75ae2495625f2 If you think this work is useful (should progress) please do email either the ipdvb WG list or the WG Chair. Comments on this topic should be received before 24th November 2006. --- The IETF ipdvb WG is planning to adopt the following Internet Draft as a work item: http://tools.ietf.org/wg/ipdvb/draft-cruickshank-ipdvb-sec-req-04.txt If accepted by the WG, the WG intends to request publication of a future revision as an Informational RFC, according to the Charter milestone in: http://www.ietf.org/html.charters/ipdvb-charter.html At this time we are asking working group members and interested parties to send comments/queries/objections to either the ipdvb WG mailing list (above) or the WG Chair (gorry@erg.abdn.ac.uk). In particular we are seeking feedback on any of: * Is this work useful to you or your organisation? * Are there any additional issues that you think that it may be useful to see addressed? * Do you have ideas/text/comments that you would like to contribute? Best wishes, Gorry Fairhurst (ipdvb WG Chair) --- From owner-ipdvb@erg.abdn.ac.uk Fri Nov 10 13:18:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Giaxe-0008LJ-E7 for ipdvb-archive@ietf.org; Fri, 10 Nov 2006 13:18:42 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Giaxc-0002mg-RK for ipdvb-archive@ietf.org; Fri, 10 Nov 2006 13:18:42 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAAHbFHo014255 for ; Fri, 10 Nov 2006 17:37:15 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAAHbFsU014254 for ipdvb-subscribed-users; Fri, 10 Nov 2006 17:37:15 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [130.129.71.147] (dhcp71-147.ietf67.org [130.129.71.147]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAAHadda014182 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 10 Nov 2006 17:36:41 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 10 Nov 2006 17:36:34 +0000 Subject: Re: ROHC and ULE From: Gorry Fairhurst To: CC: Carsten Bormann Message-ID: Thread-Topic: ROHC and ULE Thread-Index: AccE7sP5AnQ2mHDiEduHQwAKlc/qXg== In-Reply-To: <45528DB6.3070702@hns.com> 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Just to say, that the LLC mode was originally proposed for compatibility with bridged LAN segments (e.g. WiFi). My take (as a WG member) would be to reconsider this in the case for direct ULE transmission and look for a direct ULE-Type assignment from IANA rather than an LLC Type assignment from IEEE. Gorry On 9/11/06 02:08, "John Border" wrote: > > Carsten, > > This popped back to the top of my stack and finally re-read the > presentation you gave. Where did ROHC go with 802.3? Is there a > length-field encoding? Our draft proposes just a new EtherType. Your > presentation implies there may be issues with just taking this simple > approach... > > > John > > > Carsten Bormann wrote: > >> Hi Cedric, >> >> a couple of comments. >> >> I have made a couple of proposals at previous IPDVB meetings how to >> integrate ROHC into ULE. >> E.g., see http://www3.ietf.org/proceedings/05mar/slides/ipdvb-0.pdf >> The most important input that would be useful at this point is how >> ROHC will be used in actual systems, see below. >> >> >>> Now, how having a multicast addressing to work with ROHC remains an >>> open >>> issue, but at least a basic solution would be the use of unidirectional >>> mode (no need to acknowdege) >> >> >> ROHC works fine in U-mode on unidirectional channels. >> On a satellite link, the high delay for a context repair may actually >> make this the best mode to look at. >> >>> Negociation of parameters between compressor and decompressor >>> This point does not appear to be address in the document yet, but >>> how to >>> make the negociation is a real issue for the implementation of ROHC >>> over >>> ULE. Probably some propositions should be discussed here ? (e.g. use of >>> default parameters according to the type of DVB network ? PPP >>> replacement ? >>> use of SI tables ? etc...) >> >> >> We could probably come up with some default values. You would still >> need to look at capacity points such as number of CIDs. >> These could be "announced" (as opposed to "negotiated"). >> >>> ROHC recommendation >>> We strongly believe that one of the output of the task shall be ROHC >>> usage >>> recommendations. This can be either parameters values proposition or >>> analysis of the best suited mode depending on different scenarios >>> (namely >>> unidr system, satcom systems with a return link, in both mesh and star >>> topologies) >> >> >> I'm happy to do this work if enough people are interested. >> >>> ROHC adaptation >>> A interesting point to investigate can be ROHC adaptation to fit the >>> satellite systems and the ULE stack. Two approaches can be foreseen. >>> The >>> first one is dedicated to simplification of the compression scheme, >> >> >> Actually, we have just done that: >> >> draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt >> >> "...The RoHCv2 specification introduce a number of >> simplifications to the rules and algorithms that govern the >> behavior of the >> compression endpoints..." >> >>> and the >>> second one to the optimisation of ROHC in this context. >> >> >> see above/below... >> >>> >>> ULE over ROHC ? >>> This has never been proposed, but maybe the compression gain could be >>> pushed a little more, if new ROHC profiles integrating ULE (i.e.. x/ >>> IP/ULE) >>> were supported ? What would be the main barriers for such an approach ? >> >> >> These would probably be easy to add to ROHCv2. >> >> Gruesse, Carsten >> >> >> > > From svi@erf.hr Sat Nov 11 23:52:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj7KM-0007Hs-Tq for ipdvb-archive@megatron.ietf.org; Sat, 11 Nov 2006 23:52:19 -0500 Received: from antun.erf.hr ([161.53.229.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj7Cl-0003wM-Sf for ipdvb-archive@megatron.ietf.org; Sat, 11 Nov 2006 23:44:31 -0500 Received: from antun.erf.hr (svi@localhost.erf.hr [127.0.0.1]) by antun.erf.hr (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kAC4iK32031287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 12 Nov 2006 05:44:20 +0100 Received: (from svi@localhost) by antun.erf.hr (8.13.4/8.13.4/Submit) id kAC4iJgU006561 for ipdvb-archive@megatron.ietf.org; Sun, 12 Nov 2006 05:44:19 +0100 Date: Sun, 12 Nov 2006 05:44:19 +0100 Message-Id: <200611120444.kAC4iJgU006561@antun.erf.hr> from: "service@paypal.com" subject: PayPal Notification: Fraud Verification Process Content-Type: text/html To: undisclosed-recipients:; X-Virus-Scanned: by amavisd-new X-Spam-Score: 3.7 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 PayPal

PayPal is committed to maintaining a safe environment for its community of customers.
To protect the security of your account, PayPal employs some of the most advanced security
systems in the world and our anti-fraud teams regularly screen the PayPal system for unusual activity.

We are contacting you to remind you that on 11 Septembre 2006 our Account Review Team identified
some unusual activity in your account. In accordance with PayPal's User Agreement and to ensure that
your account has not been compromised, access to your account was limited. Your account access will
remain limited until this issue has been resolved.

To secure your account and quickly restore full access, we may require some additional information
from you for the following reason:

We have been notified that a card associated with your account has been reported as lost or stolen,
or that there were additional problems with your card.

This process is mandatory, and if not completed within the nearest time your account or credit
card may be subject for temporary suspension.

To securely confirm your PayPal information please click on the link bellow:

https://www.paypal.com/cgi-bin/webscr?cmd=_login-run

We encourage you to log in and perform the steps necessary to restore your account access as soon
as possible. Allowing your account access to remain limited for an extended period of time may result
in further limitations on the use of your account and possible account closure.

For more information about how to protect your account please visit PayPal Security Center. We apologize
for any incovenience this may cause, and we apriciate your assistance in helping us to maintain the integrity
of the entire PayPal system.

Thank you for using PayPal!
The PayPal Team

From svi@erf.hr Sat Nov 11 23:53:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj7KM-0007HE-LC for ipdvb-archive@ietf.org; Sat, 11 Nov 2006 23:52:18 -0500 Received: from antun.erf.hr ([161.53.229.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj7Cl-0003wS-Sf for ipdvb-archive@ietf.org; Sat, 11 Nov 2006 23:44:31 -0500 Received: from antun.erf.hr (svi@localhost.erf.hr [127.0.0.1]) by antun.erf.hr (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kAC4iL8I012317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 12 Nov 2006 05:44:21 +0100 Received: (from svi@localhost) by antun.erf.hr (8.13.4/8.13.4/Submit) id kAC4iLYJ000994 for ipdvb-archive@ietf.org; Sun, 12 Nov 2006 05:44:21 +0100 Date: Sun, 12 Nov 2006 05:44:21 +0100 Message-Id: <200611120444.kAC4iLYJ000994@antun.erf.hr> from: "service@paypal.com" subject: PayPal Notification: Fraud Verification Process Content-Type: text/html To: undisclosed-recipients:; X-Virus-Scanned: by amavisd-new X-Spam-Score: 3.7 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 PayPal

PayPal is committed to maintaining a safe environment for its community of customers.
To protect the security of your account, PayPal employs some of the most advanced security
systems in the world and our anti-fraud teams regularly screen the PayPal system for unusual activity.

We are contacting you to remind you that on 11 Septembre 2006 our Account Review Team identified
some unusual activity in your account. In accordance with PayPal's User Agreement and to ensure that
your account has not been compromised, access to your account was limited. Your account access will
remain limited until this issue has been resolved.

To secure your account and quickly restore full access, we may require some additional information
from you for the following reason:

We have been notified that a card associated with your account has been reported as lost or stolen,
or that there were additional problems with your card.

This process is mandatory, and if not completed within the nearest time your account or credit
card may be subject for temporary suspension.

To securely confirm your PayPal information please click on the link bellow:

https://www.paypal.com/cgi-bin/webscr?cmd=_login-run

We encourage you to log in and perform the steps necessary to restore your account access as soon
as possible. Allowing your account access to remain limited for an extended period of time may result
in further limitations on the use of your account and possible account closure.

For more information about how to protect your account please visit PayPal Security Center. We apologize
for any incovenience this may cause, and we apriciate your assistance in helping us to maintain the integrity
of the entire PayPal system.

Thank you for using PayPal!
The PayPal Team

From owner-ipdvb@erg.abdn.ac.uk Fri Nov 17 07:06:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl2UO-0003a2-At for ipdvb-archive@ietf.org; Fri, 17 Nov 2006 07:06:36 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl2UK-000858-PE for ipdvb-archive@ietf.org; Fri, 17 Nov 2006 07:06:36 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAHBkw50000399 for ; Fri, 17 Nov 2006 11:46:58 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAHBkwaU000397 for ipdvb-subscribed-users; Fri, 17 Nov 2006 11:46:58 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAHBkmEr000365 for ; Fri, 17 Nov 2006 11:46:48 GMT Message-ID: <455DA128.3040601@erg.abdn.ac.uk> Date: Fri, 17 Nov 2006 11:46:48 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Updated ULE Implementors Web Page: ULE support for Windows XP (ULENET) 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Dear all, I received an eamil from Christian Praehauser, requesting a new entry for the Implementation Web page for ULE for theimplementation for XP. The revised web page (with some other minor updates) is now at: http://www.erg.abdn.ac.uk/ip-dvb/ipdvb-impl.html Best wishes, Gorry Christian Praehauser wrote: > Hello Gorry. > > First, thanks again for presenting last week. > > For clarification: we've developed a ULE decapsulator which runs on > Windows XP SP2 or Windows MCE. It's called ulenet for Windows. > > What ulenet does: > On setup, it installs a virtual network adapter which is used to deliver > the decapsulated packets. > On startup, it reads a configuration file (where tuning, IP streams, > etc. are specified), tunes the DVB card (if enabled), and creates > decapsulation chains for the specified IP streams. You can define as > many IP streams as you like. You can also setup IP streams using MPE > encapsulation. All data which is received on the streams is delivered to > the virtual network adapter. > > ulenet works with DVB-C/S/T and requires a DVB receiver card with BDA > (Broadcast Driver Architecture) drivers. > Kind regards, > Christian. > > BTW, here's a list of some cards with BDA drivers available: > + TechnoTrend > - TT-budget / Nova > - TT TV-Stick/TT-connect S-2400 (USB2.0) > - TT-budget T-3000 > + TwinHan (www.twinhan.com) > - Ter (D+A) VP-3054 > - DVB-S PCI VP-1020,VP-1022,VP-1025,VP-1030,VP-1032 > - DVB-C PCI VP-2021,VP-2031 > - DVB-T VP-3020,VP-3021,VP-3040 > - Mantis/Hopper PCI VP-1034,VP-2033,VP-3030 > - MagicBox Pro USB VP-704A > - MagicBox II USB VP-7045,VP-7046 > - StarBox USB VP-7021 > - USB Stick USB VP-7049A > + TerraTec (www.terratec.com) > - Cinergy Hybrid T USB XS > - Cinergy 1200 DVB-S/C/T > - Cinergy 1400 DVB-T (XE) > - Cinergy 2400i DT (Hyprid DVB-T, PCIExpress) > + KNCOne (http://www.knc1.de/) > - TV Station DVB-S/C/T > - TV Station DVB-S/C/T Plus > + AVerMedia (www.avermedia.com) > - AVerTV DVB-T 777 > + Technisat > - AirStar TeleStick T1 (DVB-T) > From voiceprintsecurity.com@localwebshopping.com Fri Nov 17 11:46:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6qo-00075w-Hc for ipdvb-archive@megatron.ietf.org; Fri, 17 Nov 2006 11:46:02 -0500 Received: from d36-140-39.home1.cgocable.net ([24.36.140.39] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gl6qM-0003T1-T4 for ipdvb-archive@megatron.ietf.org; Fri, 17 Nov 2006 11:46:02 -0500 Message-ID: <000001c70a67$c49ed000$0100007f@localhost> From: "Carl Watson" To: Subject: Beware of fake pills Date: Fri, 17 Nov 2006 11:45:17 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C70A67.C49ED000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C70A67.C49ED000 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C70A67.C49ED000" ------=_NextPart_001_000E_01C70A67.C49ED000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please view as original HTML. ------=_NextPart_001_000E_01C70A67.C49ED000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
------=_NextPart_001_000E_01C70A67.C49ED000-- ------=_NextPart_000_0001_01C70A67.C49ED000 Content-Type: image/jpeg; name="img125.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAABQAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAFxUVIRchNB8fNEIvKS9CPTMyMjM9RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRgEZISEqJSozICAzRjMqM0ZGRjg4RkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG/8AAEQgAWgJBAwEiAAIRAQMRAf/EAI0AAAID AQEAAAAAAAAAAAAAAAQFAAEDAgYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAACAQIEAwcCBQEI AQUAAAABAgARAyExEgRBURNhcYGRIjIFoRSxwdFCUmLw4XKSotIjM4LxslMkFREBAAMAAQQC AgIDAAAAAAAAAAERIRIxQQIiYRPwUZEDcaEj/9oADAMBAAIRAxEAPwB1WSsy3iG3RlwGUB1t znpjdeecM6yaos1nnJqMtBlqk1RbqMlTFBlqk1iLKmTVFBnrHOVrHOLNc3t7W5d4aRzMk4DO oOcnUHOWiW9sKDEnMwa7cLZGSJtZihHUHOc9dB+4RFudy1CgOMR3EZTjnE4Rr3XWXnJ1V5zz e13uAVxSMlcGXqGXVXnJ1V5wCsuVB3WXnJ1l5wOXIovrLJ1VgsuAT1RJ1RB51INuqJOqJlSX SLKadQS+oJxSXSLWnXUEnU75KS6SWUrX3ya++dUl0iynGvv8pNff5TSk5Y0wEnJac6+/yhtu yKVbODWLetschDXPCZny7NRCjpHCc0Q8JzJMqvpoZXQByMqSW5SoUdueBnJsuJ3WTWecvKSo YlHHAzOpHA+UL6pk6xl5SnGAevsPlJr7D5QzqqcxJqtnhHL4OIPX3+Umvv8AKF0tnjSTpKcj HJOITX3+Umvv8oS1gjEYzDOXkcXOvvk6nfOqSqS2lK6nfJ1B2yUlRZS+oJOoJUqWyl9QSdQT mVFlO+oJOoJxKi0pp1RJ1RM5RNIKdtuET3GnfOPvbP8ANfMTz++v9R6cF/GLnPCc589dOGPY ffWP5r5idpurdz2sD3TxKgsaCel2Vrppptip4twmZ/srs14/12a9Tvk19h8oKeuP4yvubie5 azP2z+mvq+RmrsPlJqPI+Uxt75WwYEQxXDZS/an1sdR5Hyk1HkfKE1l1l+xngJkkkmWgl5Bc QrEhBBoY8rAN5Zx1jxnbxns5eUdwMuVJOrmuRQWIVcSZRh+xQKus5mSZpYaW9iiitw1PKR0s LkonVx6wZxWZiJnq1ddHJ3K2z6FFe6Wd45ExKTgiXjCXLO6+vMVg+NvFSZq8yM0he93VcDHA 8Z1dt6z1DOb6gGsJtJrtgiQA9YDhCrG7QYNBLiUMypMz4tRL0yXLJFYPudwlsegxMl0pJdcX BFFmm0+QF06Gwb8YzGM8biDUZz1Gzum7bVjmRESTAudShLlRYnUoToSKsSwJBOhIqUnQEgE6 AkVVJ1SWBOgJBzSXSdUnVJFcUmJxMIbATm0mpuwSWoiymhe0zgmpmlxqCkxrJBK5JVZVZRck qsqsIusqsqsqsC6yqyqzkmVF1nJMomUTKLJnNZRM5JlQx27lkq3AwG2dWPOFf9e37SP/AHf+ sxtLQTnHVvsukqk0pOaTbLikqdSoHMqdTmVFSpcqUVJLlQioJvL3SQnjC4h+SvamCDhJ5TUN RFyWsZkZ22EiKXYKMzODqL2G36j6jkI5ubkWQFE32m2W0gWattFY1InKZuXaIorTdvecIvGH lLyCrA0mqbZbZ1KtDN6uRTGW4TQqOGzGM2Q6cpOgCazU2wMplq4arjKY0lphMrprL2Y7mckk k7OQOso0IocpVZKzo5ll60bR7OExjd1Dihiy7aNs45TrE2xMMWji0nTtgHOkX7RQ1yp/bjGL tE9aIB7m4VKiukE4tygG93Y2ZGvUQwqpBXH6QvdVYC2M3IWIPnbnU3OhfbbAQeEx5zMdG/GL MdnuxvWK21YBRqJZh/tmd/fW9vcNq6rqy8iD+UnwqmxYZ2SouEUNQK6eGPbnBd1sru6vNevM iBj/ACr9BOdy3UDyy3LYvIdVsnTXIg8jOTYuuKqhPhNNzeHxVhNvtxqc+ssw4nj3wX403dw7 XtzV1XLUfSCcqg4TXOWeMM7ux3Bx0Gk02DBVKNgaznc7S9c3DXNqQgOICv8ApHNy4/2pYtpu oo1FDT1nn+cvOf0nGCq7s7l3FFJ8IL/+buCSNBwmFsbvd3Ftu7EMQPdG/wAvYrYDW2aocqtW NCowy7+Uc5XjBVd2N+0uplNOcPWym124vLb6zsSDyWnOnOZfCJdS8xY/8YRi4rhC/lbt9Bb6 TspZdTLqwxknymViIhhsnubu4EubdRbPuahFBzr2Qna2ilVtKWQE0IHCZfC23DPfvksAAgxJ 9xx8hMfll3RulWOm1X0BcFpwykiZgmIk3Gv+JlhgTpyPIxXYu2GsdC6oRqYXVzrzPHvh7Ai6 ts5W0AB59vjNRMzLMxAgTFGNx2SpDfsXKvjQzUTNH0vcvf8AxJQf4mmp6JBW/wAwltipD1GH uX9Ifbvl7a3TVQ9dOphw/wDGea+zNxs8WP4z1NwWk023IraUJgW/Sc9bxnc3BS210EsExajj /bCEvG3cCMTQor45gnhhJb61s3NIoiJpQJ+5m41zNIL8heumylwO1t3JwBwoMMosM+tyVj/4 y+vTHS1O79Z5zYWXu3Tcu3HYW1L58eEny21pdFGapUFgWJofGA73G8KFVxQE+okY07IBv/kT smCsGbUNQOvh4ATn46wz7Y23JYNcVUrw/lTwgXyyrudwzVwX0jwgFbPdfdW7t1kCBANJBNdR yxrwno9tcVbYDGr0GqmOPhE3x+0W3t7dth6HY3bh7Ml85xdH3DhDfIByt2R9OEinb3KnI+U4 N1RgTTvw/GIvmLaei2q9MjH0507f75fxjvZs3HJLqCgRWx9VeHLCVDwXkORr3Y/hLL04HyMQ /J3Llu700uOAAKjVxnOytvbtNdLt/wAhFscWPcTkID/X2HyldSoqASO6ILOwW2Wu23dnQatB wP8AfSDKDub6jcu2knGppGj03VrgAfp+svV2HyMR/KWLTIukKr6moLf8eFaZybLYs4puHcBq C2usg58uUWUctcANDgZZJ5Hyibcbo7dfttsSqpUa/wBxqccZrsrSJa13xra5X1Owyywrljxi 5SoMWbSKtUDmRKJiTabS/YuB7b+kH1DVUU418IztsCz6PZqOnu7OyaiUmG5MoDUQvM0nNZtt F1XR2VP5fnLPRmE+a3Y2tkE1xNMIBc3FyxZF9g2mikjWKjVlUaZXzqHdX7VgY8SP7dk6+R1b i21q2AuojUSy8MAM5ydWW1+XTcOLasQzGgDgUr3iMre6D1BB1qSCoxyiT434y3avLcZuoymu lch2k9kM3rm65UX9CE4LaXE9/MmW5KMTdP8ABvKcm8F94K/4hSLPlLK29ulpV0tX3n3GmdeO PfBfiVuIbpdibaoaqcq8JbSjzq6sUUt28PMzC3eF26LIcFzUkIKhQOZi35pXY27YYhgtXxOZ 7Jh8bs1t2rl5wGaqpbrzOf0i5Kg7W8QoN0FT2jCaayfarHuBgG93bbIdDbhdebtTj2Vg20Fx rZ3O4JuMW0W0JqteZGXdLcpUGxZqGiNXug1y4bdk3m1Ep71rppXLhAt3t0uuHJa09PUEyPaM RSa/JuRsrdpCSW4scSBz88ImZWIgHb+U+5uLat2hViFqzM2fjCd/8e7XmNpCErh/YwD4jaHq tdeoFpS3pPHIDxxnXzO3a3eAQsfSCwLVoZjVDbjbXbB/5FIhXxVsEvdYAhFwriNRwWbbYOvx 7dWtC/or2DGD7a8Usm0BmwcnnThHTVjT62o9LUABx9qio400jV/fnCLTuMCKnOnHT+o4wG3c Omg51HZz8Dy545wtBXGtDmKfnz7suyc+Ud3SfGRFpmc1w0zekwtekEcK4Dl/b6ZTWszMwVKj hOCZTNjSch1rnMtU2XATBs4RrFIMxDRJBtJJJO7iX1krOKyVnZyd1nLKGFDlKrJWBnYs9Itj nlOrjAYmdVnLqGGIrLaUW290lsBn/wC0E4tUjs0gYQNrSOSzOan+mNvtbbtUqMJt9vb/AIiT Gi629t7S22GsIDpKqeP0znaWA1ujABiOUYWrNtMAoEI6C8hETEE3JFfUXgOrVXUaQ64gjtE4 sDoVAdSre5WU0MetZQcBMHsof2iTDQC7q1bwyBz6Y0/6j6vKkrd7tNwCmrSpNTRTU8B9IQ22 tVxUSfbWv4j6xULclu3e1trq3Q9SvNfCdbrcWtxQF9Kr7VA/Uwt9pZ4oPrMvs7P8B9f1jE1j tb1mzqUMGD0BBB4dxk3LJfY3Ljkdy4CFWNnZD1CCvjDG21pgQVEYoDa3xt7T21fBqmuk5kAT tN8AgR3V6DT6tWPeMj35wgbe2VppE5b4+xp06B9ZKg0tTb2q1Yl/6VFB5mHrqdzcegJwAHAc pvt1T2lRUQrppyliYSbLrxIApWlRqpnTjSZX3DobVv0oTU+liT31jfppyl9NeUTMSRjz1mx0 nW4DUqa4o0LZ0YklPcan/sx+sbdNeUvprykxSpbvqXCiIdSoqN7uBPdMt1XdMGYkAYABDGbs VJolQP8AbX8cJQdq00cacf6v9v1EYF20ptgwxYNTNG4ZTG9Z67m45ap/oMcK9SPTTCvHlWWt wkA6M9P1ND5RgX2LpsW1RRiurS2hv3fSBNswaklv8k9BZbqe5aYA8eP6TNbrEVNvlz/p/wB3 +kyYoO8xvWBZbUumlCEalAKYwTbWm21wXFbEYexp6A7hiQCuYHPiSOXClTBxdJp6ae7nwpTh xziAp3dv7m51KkYUoUM127dC2Lfuo2v2NnzjE3CDimFT9GA/A1mtwhU1KtcufOkBDd2xvMXY tU4n0Qiyy2lS3cqQpOk6WBx+mfOMBdJK+jA0rnzNfw/CcE9VQCmZGGOGBP5SoB3e4O1UJbb/ AJanqHj2CvYJj9tvHK3aa+INQ34xk1sXwOpbByFWGPtrnnnhOEsKoFLdKhTgzfuPfw4yKFbc 73bLqdAo56R+Ulq8bqtuHUKyUKuK+o8sc4SoyJtiuHu1NSoJ417u+dsQ9GdNTDIY/wAdXdn6 YC2/t0usXxtscSKVXwImlolEFtirqvtqrVFc6RjrwPorQNz4U/Gs0cKpUBa1OOcuIDXcMKdM HDIU0r5Zt4yra6FpnDLYD+5KYA+dZjqNATbpWnPkf7eMsVCTcs6w/wCPX3N4f284Ph/Dxx/j X8cIRavNbRQEoGAJz4nu4SeU4RGlV1j92b4rhh7ScMuEu1aRrg0p6aHXqGFeFNWMY+1woXDD HGRbtaakoCBXsqG/QeckNALiG2LqUIW5SjKMqcKQG1Y6Lq6uKqa+1o9e4QTRKgZf5dX904N0 jNOfPhT8anylQt3n/wBoqSxBApihp+cvaU26sv8A2BqVAU8MsTGeskkaMjQZ/wAqV8sZwLpw qlK9/JT+f0jAq3dsbi4blSpOasp/ETbbObCdOuoA6hRMQe84RkWNDRMg3+k/nNwi8QIwIdxZ W6dbakbt9QPb385dj/iTpsysldQBDYHmCI90LylaF5RgW276pioI/wAKnHvJqxHlBd0PuWDM SABQAIaUjoqvKCbq4tpCaYxnUsu2u4tbUMuoMCQcVOYy4we89q85d7mLf0/3wZ9J4QV9PKYt qja7uLDbcWSdRX2UwzPqrEi3XtGgOE6AFcpm/qOEk6sY9JbWqg9kJQkQX4+4LlpeYwjALPNL 1RONEabapgJlde4oqgqYtKsU6B85j9otagY84EN3d/cpE2S8zCtRKVMd2ptOcAZl9oa1JNe+ addz4dsyO80nGSl16GSSSel5SqslZVZKzu4rrJWVWSsC6yVlVkrAusyZG/ax85pWSsoFXqhx UmnfDHuHmZzWUcY6gN77aszTvnD3Xp7j5zZ9vXEGZNZYcJcTS2/furk7eZndm/cZfc1e8y71 vmKTOwRaBA4yoyv7m6Mmb/MYOt+8xprb/MZ3uGrBlNDAKtbu7buCrtTL3GOOs5HuPnPO3Y62 pLW1rnSFXtr9wO1tmOGWJyhdy49MGPnAr9sgi4ua/UQhbgdajjJRZTe3d21dFwO2niNRj63e ZhXUfOee+QWhpwOMcbU1tr3CTuvYb1G5nzl9RuZ85lLlpGvUbmfOX1G5nzmVZdZKGvUbmZfU bmZjWXWKVr1G5mX1G5mZVl1koa9RuZhu1bUpxxrFtZmHZTVTQyTFtRJxfRmFVgRZxnWZLvry 50PeJoPkX4qD4zGwuSrqHmfOV1G5ma/f229yH6SC/tWzFPCn4S38JXyx6jczOeo3Mwkrtnya nj+ssbS23tevlLygqQnVbmfOV1W5nzhLbB+BBmZ2V0ZUMtwlSx6rcz5yuq3M+c6O3uj9pmbI y5g+UuM666rcz5yuq3M+cyrLlod9VuZ85Oq/M+c4klpHYd2IUMak0zjXeNot0GZIEX7NNd0c lxP5QnftVlXxnLy606ePS2aO1MzOtZ5mZjKSs1SNNbczK1tzM4rJWWh3rbmZNbczM6yVih3r bmZNbczOKyoR3rbmZNbczOJIFlyOM898hui76QcBG27vdJCZ5hyWNTOfnPZvxju6ZziKzOtZ WcsTm6LJ0iZAyzUmbWds90+kQdRHx15rbkD2nOeltXA4wiuxshaHac4SqlMROHlMTOPR4xUa YiXSCJuBkcIQt0GZJiUZSMRK6ijBlEJDAy6KZpL/AGEDWv4iZMFY4KPKH6UnJCiNWzOSSSeh 5ijSeUmk8oZJO+uWA9J5SaTyhkkaYD0nlJpPKGSRpgPSeUmk8oZJGmA9J5SaTyhkkaYD0nlJ pPKGSRpgMoTwmTbZHzQeUYyRphM/xdl/2keJmB+Ft8CwnoJI1Mebf4Ut+4+UJ22weyukmo4Y R3JGmFZ2zGZDZMtaZRzJL7GEG5+Na+pEIs7V7aBTmABG8kmmFvRaX0WjGSXTC7otJ0mjGSNM L+k0nSblGEkmmF/SblL6bcofJGmAOm3KcmyxjGSNXC3ovyk6L8oykk0ws6T8pOi3KM5I0wrN luU56B5GNpI1SoJcXIsPOard3C5MfHGMJJn+FBDd7gcj4TUb+5xSbzk+Ezi6z+9RvdbMhubZ 81p4U/CW3hMj4R/hWgtbZsjTx/WWNnZJ95PiIK3hMj4S+zPqbh7O2WgIH4xa7NfcvSg4TO3n wjFMpI6rPQLpblJpblDZJ11jAWluUmhuUNkjTAWhuUmhuUNkjTAWhuUmhuUNkjTAWhuUrQ3K HSRpjz+82d++aKMIB/8Aj7jkJ6+Scpq9dI6PJD4W92TofC3a+o4dk9XJM46fx/sjs/FW0zBJ 7YctkLgBDpJznj3tfbtQI268JwbJ5RhJJ6L7lL7VmymX2d0ZGO5JfRr/AKFAsX14zULfHKMp I9E9y7TenBtXjGkken5ae/5QuSVJOjk//9k= ------=_NextPart_000_0001_01C70A67.C49ED000 Content-Type: image/gif; name="pict63.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhQgLLAJEAAL7X8P//+wAnWP8AACH5BAAAAAAALAAAAABCAssAAAL/hI+py+0Po5y0 2ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvd+Phj8JkFGceg4cpQugSD0BESjNueGeq1g D1ukdxUMCwFMTbl1NqSJ49ja8j51O9s5zH7HYPE7/jd0FkcheEKIYWiCCKEINVJ349cSybD3 N/kX4WS1ENgmdnCk9Ek2OqpgijqWJqYqVBTaChp2WjpLa6uGC5tLKysam/vr25YptWmgSfWU vJnMZWxspbkwhfyMPE2dnbB83I3dnO3MtT2uXB6NMC6loHzdPQ1PfR3t/g6tnk7uXR+vD+7u mBdmczrxInXQIMKExA7KYujw4UJWE4HtSiBsIYKL/xwtNqwIEaRIRuTuvbPH7iQ9lCarWaNH qZ09fiZTvuyC8+VNljVXtlTH06bLm/nwcQuakia2nlMu5SDIieJIj8OAidzY8CKpVVQldozo UKvXrl8xkj0bUptAnUmLVmI7VChMouzesp3HzW1Rujbb5v371q7ednXl9hX8jGXcuHv7Mm28 +O4XqL3MBtOFOS2rj1urEltTNixmUxKvjr28S5XGsal+1fKlxS0zuDAj68yZtM5smdtq065J +d8/23Z3z1lWmO/heYp/2yluDrLs6JgArgVrethpjYbEaq8s1rUnzqW9T43airP5reMrly7W 07fzvUFdIp9LGH9g6YYb4P8mPphyiSXn1295NbecY/LtJ5+Akk3WG1bgefLdeWE1oFVXEpom XnnumRdae+9tR0aFooDFCIPKIVicfnQhyB9/gg2FmIL2BVhgjvThWKOBBTYT02MJzgdcdQ9s JloZSrZ2GXqfZbZaVRExsSRosHCV5JMbWtbkll1WRNJuADVYT4P18XXOddbxptSYcJUDp1Lr QCdOkEP6g99d66TD2D4CGXfUfbeh86CRhh6KKAVOJZonoyYsCp+jkk5K6QuQMnpppbE1ommn nn4Kaqiijkpqqaaeimqqqjrg1I1/papmFigct2qttpY65wSuNmZqppE+6oGvtw5LrAoqQrBr o6L/CvsAs7oGW2y00tZAa297OpgmStniJRShRK0lj58+6SmOt21Ze62bZd6mFpDSsKuugtPO Sy+wMgkZX440+gjvsU1pI6S2+SUY2Ey82hggbjsVeWe9Dj9MQq74YmugoD1azGOh/g4o6I4B Z/yqmfJubA2MzkKMcsogB0dxw9mqifHH3OaWK3K0Erkiv+D4+aed+g5oHVIqD010szjj9d+O QufDIo4yxmQztySTHORzI4NMoNVFb831gli3PGOMIasI5My2wTsw2QAu5R/OCpftY49dzz20 xINe1+e2vKY71554an33IxoD9ee7dxpO+B7eHmd42IkfTHfkkuNw8uSW/1+OuQ+VZ855555/ Dnrooo9Oeummn4566qpPS5J7bpBnRutRIoGI7KtncunmOuiORlawz+5lVC9k9IHtwP9Q++8x QMq7JJxa0Dwkyu4wWuw8GB+B8dgPsX3EmxrZvK/RVzF9ExHCFoyJ6V3JPmtWCtO+dhR1iBpW VcaP0JLq48LeePD7zr9U5M9/TxqN8g5UOH6gKxz+YGBTygWzlZirGuASTs2gEi51fUNc66rL IxbYNAe2KzGxuqDizDUDloEif7Mry3pc+JGOzCJE3EFLdrYkQ/1ZCIYM4d8O1+cKG64HWQZT Sc4OozXHeWxqjMvTv94UsJsRrIlHLNj0rCgZLP/+rFCWEtNGWCgeIRaQh1wKj4ZEE5LQfOiM GyKjG8nzxjaK0T/nm9rKIHfEB8Wsij67mRK3CLhjPU1mXCTYwew4Lmp5cYU/TKNV4miW13gG RSIiY2fWmJYyzhFMtrBSDzuppUamT1HTqdNJqEMuUwaNOV7LV8VQOSSaqfJVgmwlHwlnNp1R hmrj08Mi1eDIYF4FksFbjULKs8kR1TCTchSmGrEjTC8RE5ptc2UtY0m1tjXNlYac2DUD6TRb AtJnR1PYINGmyFjFcJMZSqaHjEkh7ixTlMrMyBAhScPj5ZNK7jxeH8sJUHHKzXHnGBwhsXk0 jzkooAWVF8ImxtCSGGn/nVKy0CWl8swv3c9+/quhPdcnPPUZgYAkkgp7lFk/kSKTn6AMk98m yMGd6SZO8QpZB/mksZfOEqcSbBNkUGimBerrfBqEnN26tcfbocp23UtBL2f1PKVKlVikqUBT oVqd6D11qlztqle/CtawinWsRzogHMy6CLT6ExBqNRYHdJesZc1NiipDUhLaKoGmxoF4hcDr B1QoK3IaDY8a+CUdSEfXC2yVdiKa6O+ualW/Qst71ZSA4EAgt8IidmaKDRXf5nnSLFUokh39 UmhD1NJXkDSlmlTpV8wYJoDFa5Y0gqAI87OvmsY0Rhf04AnhcVsPAkY4jytZAgMCXAvCVLf9 /3ilAh1oM2foraifAixot6NDhfBVMxYtaT9FCcMgBpGZgx1Ywro5XDK9CJ1+MCdxGqojh+YG aWcyIiAFdsuFCpS+B12bTStlXbum1DsgeiQBrRJNjFbShs0ELzs/kq7g+HFseowbbksmNs6i d4stQ1rVDnlHfBUxv7mMZX8jal5NBXi82C1t/9YpwO46GI305GiLnemRqpaXlrBEL6B4ljSj rJJNODnq2ZDatx5DtB/+5fCInRxBEcOyyQ+kafkStWIaExjBrrtxlPC54GjaGMdkXiurPhwf BmXTwwSSry5L/Mc8xlfOFT5xv76WxRCTuMlS8yxR5/nMDH3IyycCM/+huazRByeYlGxGU7f2 DGK/wEi9V/PmhcWJ5w1TeVxqS/GjP41ISP93VfwcMEhHO+YsrbZ/qoYN/W5ISeIpWDM+JKLd xETT2lqZb7uabqDwRonl7iSBa3LokWNKJ5P19ISyDLbFEPfjuyF5un5TKmRTtliy5kHbMKj1 52LFbURlO9zkLre5z43udKt73exud6WuTYMhMhYI8GaDCGZI0etJlq1YHfeZJ0uCUmNo3/qm 5rxvUO9BEHyk9Vx4X/mtcKxqdseCzcBWBc7wSSXcBRs/hMM3AG9BdHwJH+eSveXwVmSpHOCK /TPGY2zSBod25qo1LS/wR/Mcv5q0Thqjl0n/u2pWD9C0Ou5SzBP9UVpvF+kHrl8Y98fSoKc6 5kdnekXnx+IYFyO4HbTPnOpoDttW2YnoAKGwsnxo8gZa5yzu+Q3XTt5iGrqFima1JX8evLnL 3EPEnLug5T1jk2edwViPe7ApLelL5xnT4QTMk89u2M3oHe/dfYPAn86hMN9Cu3Vv8DTvLuYR tTPppu5y3+u+ZWjOWsZfTublEV1ZE69XoQ9NaOP17OZmRT6Uds3o6CfZevWM8fQHzjfnURML 1Rz/xWLufdUzOkrmv2ealCzzDyW5ZR1Pvvr0fD12rvVbb1BnRr8k6K/71FxNW3z3ew99dgoc UmkaX0MYD+nyuZIe//sjWo3H1L/BYQ1zDCZ6rieAobdXnTeA1ud9ZpZhRMIT7XVOG4ZihWRr drCAJcJ6qSdPwNN/JxJ479R+FtVYHEh/zRdPHuh5j/VIZeZ7FHJ6iyaCG5iC7ldoBDiDlhWB ruJe5pVNeaNn4NYBLwclVWdqUTd93rZRV8d2qFZRMkca9cdRQbd6o1V0OeckU2dgBgR7raF5 ssaF3rVzUah0+Ldqv5eEDJhkx6WDX1dCXCd2ejRl+5B7r4NuI+dud6gCdog5VYiHfeiHfwiI gSiIg+hVzOJvu0NxjGZxE7dy0PM9hEUsiYVlWrUqhvhvnQKBK3CIV1Zxv7KJKbdtFGgJlP8F K4yoYZOSiW7lPJ3FiqJIOcsDiZjQS5+4PGV3XMhGG8ZBVBnUdYnUW79GQuHXLtQWDzTBi2GH J724i8ZVLbfIM2lzD7PBi764XBsUjMXlW9KlXM/VZ9+ijcsYOF5TQSDki2xCXd4ojKfyRPGl Zl9TZIT0eGzzb8YYaflVRD4lavi4ju8oagqVLPpoZzCDFPsIFFFUWfdYkIs3TvaVkAvZH7T3 XksmVxLYTT3IgxVTGNs0WGumfv3xj43mkA9VI6F2NVEjZ9WyX8ZmVBZ2UKwUM3GGYRNIYS7T ZhApk7R4B3G4Mw7II+WHNVHzMuhXbBwZagi5bJsme8c2RTp5IFn/w5JNKZO8xZRLuVOEYZIc VpIpCTiypEBZk4wkqZSYmGlrw5Ez2SJXKYk3eZE+9hMBOZZvZk0riZZPyTRa+U8daXu5B5SW ZpV2CWdQU5OJFJJhqWJvWZESBZMWyZJb6V/AxjZk05b5aJgj+YPgxJdriSZCCZY5iE42iVAl lpkGdZLKopFw8yM42UVvOFuLA21c94y79ZC96GymmSYj05pyEplIJX7P1iZBlkU6xWyWKW0D BYxyqJnAyRjJqJuC6Zk8JZqreR+MCZtL81u4dDbKmTqoKYjhA4uqSIia850sQImWoonhaZ7n iZ7pqZ7r6Sji0wShSAfayZ7z6SmoCVfg/0mf+TkZ8BlYfaCf6naMtqgtu2hKuPZnJpQ4jLOb +JVsLkKOzGhbJFQmD+pbuDRb/5lu9GhfcfVfvqmX8qiUO2gYF/ObBsleIMqcC+NoLYKh57aZ c+YizYlmdFZ7cjFp+fKieDmQCcWiLVpuBaOTtakWZGJd0YaVcjhkT2mkzmGkGumRrylIEuaj 5vZN4cQHuVU+OQqSdRmVFNkwIuaWeCSfU1o0L2pOlyainPlpM/ojg2J7OcpLYdpmY0qmXONF RjZsCjoTbPgcTImdN3VrxgmlRIaN5Neb1EhbSAqodcqojeqojwqpkSqpk0qplWqpl4qpmaqp m8qpohIAnwqqof8qqqNKqqVqqqeKqqmqqqvKqq3qqq8Kq7Eqq7NKq7Vqq7eKq7mqq7vKq70a qyDgq8EqrMNKrMVqrMeKrMmqrMvKrMzaAc0KrdEqrdNKrdVqrdeKrdOaAaQKOqJqK946KeCK CeIaVtx6AeTqOeiKKuqKKOw6BO7qVfDqAKMqOvJqPi1gr5p4Mvm6A/yqVPRaAf4aOQI7m0Ao ZPfCAgTLZH+1r6EKPZelAgqrOgoLsDk5ao4isUchUYdHR/jqsIoCX1fQsKD6sJlFAhmLOhUb ASprPibbrh+7fhuLjLd1pxR6rjBrWfCFnI+5j3BysAggsdZIjDy7rTg7Viz7AEgrnkb/MbTh gI02gLIyy4/iJ6H44LQ/e7MkC7KI+URX67VT+1kAELRMS7RWu44WELWmo7QNsLZupY8PxCdd S6dAa7QPK7XlsrFl+7XPWre693V6K7cgGnYQMLZWC7hlm7WfGm5tuwCM22+6trdmK481kLYL e7iTK7mWS1xo27esYo2WG7mhe7YMULjQELima1xFq7Xa5rgJ0Lr2grqZK7ph+wKVK5CICy6n K1sYoLBX+7Oie7kGK7ade4mN07Nwq7qKy22vewDMS4rGG7yjewO2S0W+y42Z6xjCO6/Ey7HY e7rAi71sy719FLlCpr3iu7pk5bzDO74oh6Tga704QL0F+754/8u0ceIsvas40Lmgx+u76Ku8 iii4hdOQiRsAi0uw6ysCugGluku7tdu+oVK5upJtEwzB6Xu0CWzBKLPBh9LBs5kCH7wCIpyu GkzC83LCf5DCMLDCJtDClmOuEhDDn/PC7xrBX1DDI5DDA7u+ptqtN/wpOxyxQCy/RJyypUoB 2arES8zETezETwzFUTyrSSzFVWzFV4zFWazFW6yqVMzFXwzGYSzGY0zGuerFZYzGaazGa8zG UXzGbQzHcSzHc0zHuPrGdYzHXywAWDwAeezHxXrHqMoMn+oEr5oMvKoJYlzIoJrItLrIptrI 1nrIATDIhPzIpRrJlayrrCCqQRCqYv+QqqAMqpy8xAQhrJccqnsMq6qsrRPQqo+syqjMqrJ8 q7R8xZNMyXtsy7PMypDcy9O6yLFsycO8y4UczL+cq578qX08ysocAMrszKQKzcz8zNTcxKyM zLuazWAcyL4sqpqMy7icy76sy9icyZNszLF8zrlczrvMrLBczqSayPB8zOfcyOFsz+6Mq7Z8 zOOMyfHMzttMq9H8yc48zad60MscBk6sy4wM0OycyvqMzv4M0cSszhS9zpeczsLazeQc0R89 zv08zB6NyhtNyJYsyxs9zxddrfBM0d9s0g490jN90SZt0wKdq+I80jE9qjY907hKystczc2s 0AjNzAZd1Ez/HMkvjc0n7dTyzMg7ncogzdK9bNXCTMk/3asd7dE/bcqmrNUwvdOHnNIaTdY1 rcnAbM4vTdXqfM9X3dPx/NVLTaxLbdburNP6LKuifNTWHNSl+tdJXcpZHdUR/dZ0DdNN/dSE /dRYzdiPrdiKHaxcfaoirdW0jNdobdFxLdI3zdYtvdb8rNn+bNZxHdLZrNOnDNdiLci/rNev Ss3TLMoFvaoEPdRK3dPfnNuv3NhTXdiELdmQXdjBvdWuPMsyTdoYrdxhbdinvdlOrdKavdK/ rdYyLdpyXdXCDMubvd2WHawsfdmrDdLAjdOxGtvWfNu0rd6dHNtEjdu67dvxXdnD/03dVk3f i23f0E3dxS3DvGzX9GzO9YzYzx3Q6VzPFn3WpD3g71zJC+7cKH3YDn3gKy3g5b3PdE3PrI3S ic2rf03Ks+3eCk3QIJ6t/53PEi7Q6GzgBQ7hKI7i7VzRqb2rlA2tr12rNh7FOJ7FFq7E6P3H SozMPC7Iw0rjDO7gjnzktyzjYSzk2OrjP36tJh6rSX6rRQ7lV47lWa7l0mrlW+7lX87FBCHm YL6sXU7mZ47mW9zkaW6rZs7mbw7n7x3nk23cc27nd87QeM7fK6vnfe7nwPznZlzngU7oq7rm 1vrkWHzohY7Eg66q4Bzgi/7dOi7JAC7p4/3Pl67apS3hzf9d2ZZeq0EN4iQuzQvdzKaOyIxe q2a+3d4M2kqu4LVs4ZRe11iNz7FezABN64Dd3red0Lat3gad6Dmt6rTK6q6N4QEO0Sr+0M0N 4C/+3LdO4Zp+47q+4NPd4iwO4W4d6dA+rJgd2qMtz9a+6+w9qr/e10Yt2KRO7KkK1r7Kz1Oe rOXu5smu4c7d2cac6Wwd09xu2ivu3coazMy97Mju1ZGN3dFO7f5t8KzN02I98J/tqqKe7r4+ 7BY/yoKtzYa+36mu5r/q6I/O6cjN3Q1e3vmO7Z6+7bie1vMe5NuM8t5d1qd91uUuq/9970ue 7SQ/q7NN8ajO60Cv8boq5A1N4FL//ukDn+EKj9EuXdq5Lu4hDfL9bchrjelZDd48P+5MX9b5 zvLSCu7/zPRM/fIPntgL76ojL/F6XdILf97n7uPAXupwD++GrvaR3fG/XdXyHfERj9+2TvCM vffkPfV8zvE03fCdvtwSHd1HX/Il/9BoP+WuTfDT7fVYj/Bmb+11ffBa3/kanvWw+vbrHeJD v+6lT/Qcn9/e3vIc3tv1fd/Crfevn+mObfuFT7gMz+0Gbs8uru1bb+nt7NYIbvn+vqyQnuKR b/LdXvDCv/K1Hvzabu+KT/177fNAT+rRTOLsvs+HL9+PvdiPTvuyD9ywP/uCD8mxf/uw6ubR avOvLPnN//r+UBz/ynrxVVz0u93xPI73BJDIDHNPOTn4ZI1UtqVv9wYIxZEEvhNN1fUQ3IaN Xziu7bt98Z3vLR94GwSJQdpHx5gpXcyjU9HUzTbJnGY5bV5RVG3VWiuNRUXzGZ1Wr9lt9xvO e8Z9x3ntHieT6X3/HzBQcJBQphAnLAxva3Bv7BAyUnKSspIuzzIzyLFE0/MTNFTUD3PU9IOT 5HSVtdXVtPTVNHVE1vYWN9ctVleTtqw3WLiOdeiW9w9ZkJHoN8SGCkkx52xal9kaGjN7cEkp IpHZwyraZ+D8PCK9Y90A3RjlXV0eSHm4x17F2USG40Q8ChqAucghGLhIxcFlG/+iMJJSpcU/ gxCDtDNGbx68de08bNQIz4icLSOxYInYEMwFb9SkGQRH8iTMhirP7EOoMtzLkzgnQkEJkaTD iUPz9ekZcKAWn+WugCn5tOiNpCZhKnyIEgjHeewsXgTJ1d1HrXJ2+GOIweQECzDMqu3g8myG s20x/ABisx/OgHsjZlOq0yFWvQ+PKix0tO+cv9927gRaGPKblXxZJpYYkzKOd1+1DukaNp7X BKLrlV2J7TTNcTyd3IG7dII/Lm43OUPoha/QzIyDXmXdOiZRw91yI9YbPAnqtz1xT5asHOnT LoqGs8AYgCPpsOhSbAZbGtE4tqvBITFvd7XLCnHZoy3/bwYvi6oUHdM/7tv3S5n4jVvCbVm8 6PaCDrD+BIODwPx2W+44Hj7aajTvLhjrg7EolKqst9zT8L21OoyrCwfaW4+CkdyK6oT4Vpiv uG/8uorFEpl7jJrANNHtIKX2Y8hGGDmQqQ37cGSLSAZlNCdCCCf8CjvOmGxytCTBQ+QvoXor CbjZDuTJGy8IE7CpMJuxbRErnZrvifyaSw5NHZ3y5DSrEPuvoKBqZJObaurEk4kGK5vJHIw2 E8sjC0G6rskLMbxnFjIPQ/Gme6qTBdJBnmSlUkb/UHGhPPHx1Bamgsk0kEtXIVVTOjhNldVW Xa0E1VfZWFXWWm29NUhcKaFV/9deff1VPmAP4VXYYo3tNdZjcSBW2WadZTTZRbWRr5RJ9XD0 2WwBiZYOU0/hVjJDEoqE2eXw3MYOcEVSt54r60CX3U+tzPJP8aDK6rrOuItQUX4PRTTDZIbU b7wBqerTRXKxXXFOdD+x1qgijag2XtOOBBLMADHuwaLt/gUNypAr1K5faZPRKYMTPzySRLkU /mVa3Zbqcs+UvJyqYTNp1PJL54gQx+eZzPwpyzh1fm6wNzNmsDd8R4bQI5CfFhnggLddGT0P S4ytS9oaWTihhgNsjDL+LDPwzqS5BsjHyPTsUTEFg0PZZbM3VsNnE+eWEzOyhUA0O9KiPmFw 7KTGZ/8ZrBVTPDYOswakXHMlJtpv5ViUwu+5w2QbtSqF41buHCkqh0AXP9cSwdKLM8w5iEML fMl9Ey1ZQiURD6TglOsqWG/dsR4W7BQ4582+siODMfMY5Z5NebSLCD1uMDEefnnUd0nLz8yz d70jKQ+3/XvCmSw5WIG/YKlm0yk3mvtZg5/OSM17t5xGzHEGUE0BL89fz75Fn9FgD4AbgERU PLwF8D2lGx7LHOQ9kYHvgRGU2oOmpK03RI5grTlTSpoyFPQ1p14EXJOdEpMFyLSPWkRyTc74 JJjz0QxUP0sfoOrVud9wTFASypfsHAg4Ht7Oghd8nytQKJWKfUpTR1yDt2CrEUQ4YHAUojJD 0A4hxWsUAxdKdCIUndhFL1JCi0HcBz++WEYz+ueMaBgjGdPYRjde7Y21GWMc6VjHdd0shnZE xRrZqEc//hGQbuAjMAJZSEMeclmDJCQiGdnIRiryEY6U5CTtCElLXhKTmdTkJjnZSU9+EpSh FOUoSVlKU54SlalU5SpZ2UpXvhKWsZTlLGlZS1veEpe51OUuedlLX/4SmMEU5jCJWUxjhqAA ADs= ------=_NextPart_000_0001_01C70A67.C49ED000 Content-Type: image/gif; name="view97.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlh6AGCAKIAAP///8zMzMwAAGZmZjNm/wAAZgAAAAAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQEyAAAACwAAAAA6AGCAAAD/wi63P4wykmrvTjrzbv/YCiOZGmeaOoYhgqxHczB8tq6 +EnfFVs3O88vNVQUc8ik0uirHV1Pyy8KbD2pjGZzgl1igj3eyyrWdEPHs3fNnvFkalI8LC3b 6pl5+wGmYPt7fnYAeoGGh4RifVsLjIlTPmOOk2RUWnxwZI2ZmxFplTeXTJxDO6GQpJGJWW+q QU5lopSro62Nna+qtZ+oulqasMGthYjFX4qatHC4b0zOVZ3Kp7aeg8qrnITSErzRkM6im9PP tr7J5MzY1Kzep9vvrsCwz7RZ7ffgjKm3Tsb+Jd8W2QFUrxSyeurYVcMEjSBBG78QZit4Dhq9 IoAyDpRH8f+ORI7f1CXT+JFbRZIhEyr8x3LEPJH6LsmKuFJlvpoeLaYz2OWTQmGRrqzLtCXg wUdBR1bEd5MkNm370kVjVfSgUapV4+lqyXUDTZtTiT6sifLoGIbsHG49m/MdQno658m1Snen O58lc/20AvVu3akXTwouCVGsta6IF97BuO6mYseQ3+rEqTetWbiAJzJm23Gu5c9N/aK96jSr aKmYPaMGaynW4cSwcZJrJpfpxlGz4bZmy/GaZtdoc4eVHBh1WXGdz60N607lxI6Rs619SXT2 0n7lAMfePpk50GnIhCo3J7vKoHgUm7vdlXSluefuqUUMWZW9zeW6yQuLW85se/P/76UHVi3i DPMadwgmqOCCMRzIEjEMRijhhBSuAaEXjVWo4YYcdqjChRji5+GIJJZo4okopqjiiiy26OKL MMYo44w01mjjjTjmqOOOPPbo448tCiCkkCEMSeQEQwKp5JI+GnmkB04KQEGSTFZpJY1UFvnk lFteGaIc5znYIA6OkClmj1mCkCaSXXqpBIhtaQcmFGfOuV2aWUbJQJ5O7vnkmgDoqYCggxJp 5AKEBnooom36uaiij0IKqZSTuqlDmETU6caXd1L5aJSUfiqoqJQ66imojKI66ZGglgpooaOq umqrjSqZi3jhvdfefgT2aplrUQFYoH8GZtYbM/0VOJx1/7k6dsSprEYbKrSwwjptqQ3wKW2q hOL557YP4FmppNbSWiuQpsgp37rISqdcQeZd1O5t0MUnnFHTuYsePME2Zwp81Y5LrcDgLvoq uQiTq22qDDf86sNbDozwwegOttBVq6kmp7GLWUMfvawNJhRo+eWjFH9vPWton9Tq2TLLtS7s 8Leu0qwqxNg2HLDMCVfpFFbHZTxfTMt9XF9w60mFcWRkWZwbX4axt5QEfSpqNbfTXl1uoVo7 wLPCNOtsbsDZNurttWKf++PPxS0dMiZaGUTyWIT59FzQbbFNSl/DShZH1VVvvaqp1577tcQ8 U4xzuBGDO7HaPrKdHMlvP5baX/8DckwcGG7T3flRpnUc5xOAR1r62dKGTTbYjh/eJdqPYwu7 war3zKTk1I0jzXW04aJd7qtZ9BJEewU2dXEpq1cvu0YkD8HpjUMbfeo1V0944rXPOrC20JOa ds63Oz3sMAI+RAmvQOdKt6/EPSKssp6Hw5jc+fVyeQRnex29/rLvv/qsjvoe/2S2pm4FLnY6 s5Sl4KTABjowRwx8oAQnCKMIUvCCGMygBjfIwQ568IMgDKEIR0jCEprwhChMoQpXyEIPFeCF MIyhDGdIwxra8IY4zKEOd8jDHvrwh0AMohCHSMQiGpGGLYRADAfAxCY6kYlHjKIUp0jFKlrx iljMIg7/k/iAJUYgAAEYgBbHSMYymvGMaEQjFx3gRQiAEQBiTKMc50jHOtrRjEgwlx73CLkJ tVEBBCDAApjogzsa8pCITKQiY6gCPjrykZCMJB9VIMNAWhIAggQAGMMYRyQCwIoKmGEoeTjK Rd5wAaYE5SdTWUQUSPKVsIylI1FQSUsKMpObhGINSxlEXsLQlwUA5ilX2UNghlKYUiylMBkw zCouswHFJCYrhUiCPY5Alth8ZAmWCMZAYrIBYOykKKUJxGeOM5o/ROUvkUlFZZJznVt8pxHN WU55TjOaaqJVDijWSD2GYJ3exGRAFxBGRo7ymO5UpzuDyUyGOlShxIQoQ1d5/1B7jrOiCH0h M4+p0YZOdJ0QRag6DdrRj04UoxT9pEpXGtGQ+vKlKX1oRTsq0ZTO1KJ2/IA/VTS2D7xwAAK1 5UAVUFCNlrSmLXVoSZV61JtStKkxzegOWZpRqdJ0pfA8KFNnutRzmpSrShUpS5u6VHrCU6ZR xSpU1SrWVG5gpzCypgYKAFRbSqCoJF2oXpPKVJKSNa9J9ahBX0pTsvJyoX/tKliRudiYllWt W2WrY2XIxpMqFqt7PatVTZkBuNaopxeg6yct2c2harKT0MxsYsHqV5leFbIi9WFEswrZyGq2 sZfd5WQbu1G+olWiXqWsb6sa2Jb2dpqdlVWOPDuBYP8SoABCNe1pH2tb1YZVnpl1Km3ZiURP uvastqXtbcEr3NyGF7zWJa96LVtd2Lq3vKy0gHKVpM/mQrcAPrikA4qq3dVKdrLfdW1/BYxT ynp3s4h9qH/N61XEJvi9q+1qa6mb3eKit6+LlO8Bq1RfJb6QAECdAF5TC83XgjSyaW0oSt/L 2lMe2Ka1LbFJT+rbGV/1vC5lMEoHK9zj/parJT4scN3KpUh9ILqZxIB0IbDkNbQqAjAEMQXw es8qWzmL3L2ybKm24RE0mQJfbkCYnZyokYpWxOLUsprXPMQsszmHbDKylzN5Sf0GNaBCnUCe 73xnbw7VrtXsMjc3SehCp/n/zYhOtKLbiT85k2CgeKazpBcwZkonGZCTDqpAMc3pQBt5iU8M dRMXTepSm7qejONnByJt6U4DutUVMC2eYR3pV3s6Z6fOta533eZU95EDrHb1pV9d6U4z4JZJ DnaxdZqmQjv72dCOtrSnTe1qW/va2M62trfN7W57+9vgDne2n6dqDwR70+g+96wlsG5NWxrZ xr70rRkg6nrb+974zre+983vfvv73wAPuMAHTvCCG/zgTCQ3+B5t6z4j286YljeTZT1seL9b 4vNeo8aTUO4JUbwNkRK3yEdO8pKb/OQoT7nKxa3wE30c5FlaucxnTvOa2/zmOL+2r0u05z6z 4VFv/4RjzodO9KIb/ehF3zkJF/XGMCL96VCPutSnPu1Um5DpATgt1bfO9a57feVWv/qRmj4A bhtg5Wf/utpJnnaVt33tz56k2ClFdmprIQBnf7vZ717ovINR79bWu99Rzndvpx3w4f4F4qG9 +MD3nfFwdzYkA9FlDFSeW4egUt2njfjGX9vzeCc06CEverSbfPSG1zbqoy140q89lnv4NZcs v3AvaD7rTuf84w/vA9U/++5573222374vwuf+JtcffKdffzl4735fm+C8VmQfOpvW/DCf771 ea/8vz9e+8UPfvdtLvcAxr72yaV95seO+7LrvvSD9z62Af/2wY/f+aEPff/988//8Tc+/vGn f8XXf/D3bfu3fPsXgPO3ewVoffxHfrG0SWUTMzZTgdWDfrJyOrFDKq+DfgMUKFhTLvx0e1rH edIXfaU3f8BXgA+4gPIXgOGnf6onfSlofyyYf8iHgAaYgt6XgC34eb/wgCiIfyaXTUMCbRNY e6xiLYPChCDYNeRWNoyyM/0jhVwzhRXwLVd4NSsDhea3edLWeuKXfY73fT0of9dHgEEogwpY bfQHfWgogy9YfTTogL5HhDCIg/cnhit4gCRnhEJSdebHOJJyKEliiF3IJlbIhTXjJ0noLRq2 J1sYLVZjOOxXgmHIgPfHg3iIg90GgD/IhqH4fvj/F4NCSICo+Htmx4l56IdlqIMMSITXBoiB 2G0TyGVS8jJo03EdiIVaiIXAqD+RKIxX2IWWSHftZ3eayIluyHzV54mriHx+mIPDZ4bU6INz GIeu6ILaeIrbqIw3KIqyCG3ZdHK32Gi5uC266IjECIyUuIVQ+IvwGIxdkzXFmI5e2DBgyHqx SIMqWIfUB4CbeIrgx4Ob+IYOWH/Nh4bbd3x2WI2il311qH136HwTWXjkKEtgN4iEeI++2Ij0 mIG0szIkyYGFYzrgc0AamIhht4+R95IweXSg90hGd44nRIK5F4YYaYBrOHKKN5CfuJNF95My R5TZtkdSZ5NzR1TJGJNO//mUSIeUU6eUJYST7geVWJmVKyeVXEeVS8d+TaSVYjmW4caVX+eV I3R7ZLmWbIltfPSSaClCatmWdFmXm2SWcMmRVXkkCNeXfvmXgBmYghmYjzSYhvlEcRlCHbdx icGLszQijqaY7Cd1h1mZlnmZ/mYk9laYBqdJUJeEG7BsGQBx7pYEpHkCcwl1mLmarNmaA6CZ TrRHgYl7n5mY7IZxISBdojlnOECCQod0CceYuHiBT3YB2VZ2nvl0/OMPuombKrCbHGCVTxec wrlzzGWcF8BEtHltV2mOtvkAxNZzEWBrfpZs8GZXkAZxPSeeDlCex6Zf6OmcLdmUR0ed1fmI xf/ZAds5bdqZnNY2AEBZbR84mhVnbHo2afD5cO/2TemWacomn3Umcel5S7SHjJj4iuPIbfZ5 nyJYZhywn9LWn8dJCCg3oEpWoOg2noD2oPEmb9EVcRVXaeoWnhqAdReaoXGYo922ofcJWiEA otEmov+ZcKMIbkp3AX+WaRMnbEyaoi/Xnup5mu/ZpOlZo9IZi85oht/Go8IpVz/qnyGKnNW2 oS3oj9t2pBaQpAYKpUyaoKX5pA4ap7dpcTOaXE/iknI4fQ3Ze/YnkXtqaCH2IYUgIphhIuUH AkAKbUIaog8QRtRYpNSmcB74nvEpaRC6Z+WJoEg2oeZpZ+wpZu55cZv/Kp+mQlD0CYveCH8D eIY4yqVyMANSwFOH+gGJ+myLqqhEpZ3h9KgR+ZDSJqlpuSUumYPYyKqp2qqBihtDkxWSEAyQ IT+lIAjO6j6aYnvzRQLbqXiEdqu2qknSB6DM2I0CCqySiS3DapHhKJAA+YyAugK3oA3NA6/y ygdA8K7LEK/vOq8H0gzyGgpQwRUeWgL7uZPcamjemnzgapABGa5ISK4g1GynCn6rmqd5+n/M yKNQ0zx88a+vEQv2mq/AMgVc4K7xmrEtEZkCC6ZkGE5iGqQkyq7MmIfj2nLlygD7KIbPSHyg 2ImyiLH/yrEaO68kC7L4yq/5Wq/cMLT+urEz/wKkiFew20qQWkqxq4eL5Wqup9p6FMl9VOuQ XNuu9bqxJmuyKYO08Gq0HkuvZPGxJfuzTQumQdqyigqpnfiNDeuwHRRyEUt0XMq0bvu3vUA+ 1PovxYIUGbIVcUOoK1Krzga1uZSwdgeQvhptw5mb0Gm5pFoMa4KnzNeTJOeqHKoCjAuoo4t3 kLuR6DipYJa5KXC5ZNYlnJtzoBu6KFC6j2u7K1uiw6m6MCqqE6egK+qeEbqktdagmfpwL8pn miaaRha7ODe7tGsCtsuy01tzRdZHdXqbm8aixYubw7u8Dbq9yhuq3XsBzbu3Qwe90Yut/la9 NJeF5Za9Krq9cnpuS/8avrR2ng4nqkqqYW3Cst1ZdOq7viLwb+47c/67ui26unJKv2vKpvhL pRbHZ81Zof87dQFslxpck1Hnv5MqvyrawORLqt+rpuE7wk76wKm7cFRHwIjRwfCrauEppbDW u/zbcAtaa5zaasfbqZZabJHpmkI8xERcxEZ8xAMsOCbguhKCsi78xFbqxBrwqYZKMRt8xVic lXa6mGjCT1n8xWAMd1EsxU3ixWF8xmiclG8VsD8ixUj8xnAcx3I8x/fWAR1Wxm5Mx3q8x3zc x4bJbGyMI5cHxYR8TYGMJYdcyIqcT2QcJIm8yJAMJY8sq5McyZa8xY1cxZl8yZyMyYNMIpUy 3Mmi7MmfvCGhPMqobL4+2iHXmsqurCW0GMuynJ+vXMslMMu4LMu2vMuomcu+DEshkAAAIfkE BA8AAAAsTgBfAFQADwAAAzUIYNr+MMpJq4Xs6s17zF4ojg1Inmhlpmy7uDC7xnQ317h15/zX /5Qd8Ccc8opGHDJJWzJbCQAh+QQEDwAAACxOAF8ADwAPAAADIgi6zNZwvQgndbeZ/XjsEgWC HzCKZmptoeqsGRYrVlxnRgIAIfkEBA8AAAAsXABfABEADwAAAygIutxgLi4oI33mWqUrzOCU MVR3nVyDpo86vS0Jt+DI2Wzl6js/+48EACH5BAQPAAAALGoAXwARAA8AAAMnCLrcYC4uKCOV Js96p9ZKJm7g1YXPhjaQqTLtez5jLbqVM+c7l+sJACH5BAQPAAAALHkAXwAQAA8AAAMhCLrc 1pC9GCc0VmXH8f5WBnqisy0g9QGk1mpUFV8zV6MJACH5BAQPAAAALIgAXwAOAA8AAAMgCLq8 1lC92CZ1l1ltuoTWtH0VCHoY2Y1rmgEjFUczmAAAIfkEBA8AAAAslQBfABAADwAAAycIutzW kL0YJ3UXPsMV35I1gaLoAaBnomy5jO2LdvNHW9mZy7veGwkAIfkEBA8AAAAspABfAAEADwAA AwQIutwJADs= ------=_NextPart_000_0001_01C70A67.C49ED000-- From owner-ipdvb@erg.abdn.ac.uk Mon Nov 20 06:19:48 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm7Bk-0004xL-Sd for ipdvb-archive@ietf.org; Mon, 20 Nov 2006 06:19:48 -0500 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 1Gm7Bg-00062N-7v for ipdvb-archive@ietf.org; Mon, 20 Nov 2006 06:19:48 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAKAYJgg023506 for ; Mon, 20 Nov 2006 10:34:19 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAKAYJgB023505 for ipdvb-subscribed-users; Mon, 20 Nov 2006 10:34:19 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAKAY96W023487 for ; Mon, 20 Nov 2006 10:34:09 GMT Message-ID: <456184D5.3080102@erg.abdn.ac.uk> Date: Mon, 20 Nov 2006 10:35:01 +0000 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: Call for feedback: Security requirements for IETF IPDVB WG - Inputs 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Gorry Fairhurst wrote: > If you think this work is useful (should progress) please do email either > the ipdvb WG list or the WG Chair. Comments on this topic should be received > before 24th November 2006. > > --- > I have been forwarded an excerpt from the final report of the TTCP, C3I, Technical Panels 6 & 8, Workshop on Future Coalition Operational and Tactical IP Networking, held in September 2005. This report was prepared following a joint workshop on Miliatry IP networks, and included a detailed discussion of security issues (see attached). There was a delay in releasing these findings, but they now arrive at an appropriate time to allow dicussion on the above WG call. Please do send comments, to the ipdvb mailing list, Best wishes, Gorry Fairhurst <> http://www.erg.abdn.ac.uk/ip-dvb/docs/FCOTIPN%20IETF%20Recommendations%20v1.pdf From owner-ipdvb@erg.abdn.ac.uk Mon Nov 20 08:34:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9IX-0004SY-3L for ipdvb-archive@ietf.org; Mon, 20 Nov 2006 08:34:57 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm9IS-0005VG-AL for ipdvb-archive@ietf.org; Mon, 20 Nov 2006 08:34:57 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAKD8dRZ007657 for ; Mon, 20 Nov 2006 13:08:39 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAKD8d6q007656 for ipdvb-subscribed-users; Mon, 20 Nov 2006 13:08:39 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAKD8TQj007638 for ; Mon, 20 Nov 2006 13:08:29 GMT Message-ID: <4561A902.7040005@erg.abdn.ac.uk> Date: Mon, 20 Nov 2006 13:09:22 +0000 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: Call for feedback: Security requirements for IETF IPDVB WG - Inputs References: <456184D5.3080102@erg.abdn.ac.uk> <0D504DED-6861-4842-9B95-C0E18757BA2E@multicasttech.com> In-Reply-To: <0D504DED-6861-4842-9B95-C0E18757BA2E@multicasttech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 No - This has not been offered. Gorry Marshall Eubanks wrote: > Is the entire report available ? > > Regards > Marshall > > On Nov 20, 2006, at 5:35 AM, Gorry Fairhurst wrote: > >> Gorry Fairhurst wrote: >> >>> If you think this work is useful (should progress) please do email >>> either >>> the ipdvb WG list or the WG Chair. Comments on this topic should be >>> received >>> before 24th November 2006. >>> --- >> >> >> >> I have been forwarded an excerpt from the final report of the TTCP, >> C3I, Technical Panels 6 & 8, Workshop on Future Coalition Operational >> and Tactical IP Networking, held in September 2005. >> >> This report was prepared following a joint workshop on Miliatry IP >> networks, and included a detailed discussion of security issues (see >> attached). There was a delay in releasing these findings, but they >> now arrive at an appropriate time to allow dicussion on the above WG >> call. >> >> Please do send comments, to the ipdvb mailing list, >> >> Best wishes, >> >> Gorry Fairhurst >> >> <> >> http://www.erg.abdn.ac.uk/ip-dvb/docs/FCOTIPN%20IETF% >> 20Recommendations%20v1.pdf >> >> > > From owner-ipdvb@erg.abdn.ac.uk Mon Nov 20 08:37:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9KZ-0004g4-CV for ipdvb-archive@ietf.org; Mon, 20 Nov 2006 08:37:03 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm9KX-00067V-Uy for ipdvb-archive@ietf.org; Mon, 20 Nov 2006 08:37:03 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAKChvVx005098 for ; Mon, 20 Nov 2006 12:43:57 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAKChv6O005097 for ipdvb-subscribed-users; Mon, 20 Nov 2006 12:43:57 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAKChaLd005063 for ; Mon, 20 Nov 2006 12:43:38 GMT Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5514050 for ipdvb@erg.abdn.ac.uk; Mon, 20 Nov 2006 07:43:35 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <456184D5.3080102@erg.abdn.ac.uk> References: <456184D5.3080102@erg.abdn.ac.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D504DED-6861-4842-9B95-C0E18757BA2E@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: Call for feedback: Security requirements for IETF IPDVB WG - Inputs Date: Mon, 20 Nov 2006 07:41:20 -0500 To: ipdvb@erg.abdn.ac.uk X-Mailer: Apple Mail (2.752.2) X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Is the entire report available ? Regards Marshall On Nov 20, 2006, at 5:35 AM, Gorry Fairhurst wrote: > Gorry Fairhurst wrote: >> If you think this work is useful (should progress) please do email >> either >> the ipdvb WG list or the WG Chair. Comments on this topic should >> be received >> before 24th November 2006. >> --- > > > I have been forwarded an excerpt from the final report of the TTCP, > C3I, Technical Panels 6 & 8, Workshop on Future Coalition > Operational and Tactical IP Networking, held in September 2005. > > This report was prepared following a joint workshop on Miliatry IP > networks, and included a detailed discussion of security issues > (see attached). There was a delay in releasing these findings, but > they now arrive at an appropriate time to allow dicussion on the > above WG call. > > Please do send comments, to the ipdvb mailing list, > > Best wishes, > > Gorry Fairhurst > > <> > http://www.erg.abdn.ac.uk/ip-dvb/docs/FCOTIPN%20IETF% > 20Recommendations%20v1.pdf > > From espaciovacio.com@thekidsmall.com Mon Nov 20 12:58:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmDPj-0002fi-4G for ipdvb-archive@megatron.ietf.org; Mon, 20 Nov 2006 12:58:39 -0500 Received: from [80.97.207.77] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmDPh-0004VC-FR for ipdvb-archive@megatron.ietf.org; Mon, 20 Nov 2006 12:58:39 -0500 Message-ID: <000001c70ccd$70952500$0100007f@localhost> From: "Paul Kelly" To: Subject: Why be an average guy any longer Date: Mon, 20 Nov 2006 19:58:26 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C70CCD.70952500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2745.2800 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2745.2800 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C70CCD.70952500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C70CCD.70952500" ------=_NextPart_001_000E_01C70CCD.70952500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please view as original HTML. ------=_NextPart_001_000E_01C70CCD.70952500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
------=_NextPart_001_000E_01C70CCD.70952500-- ------=_NextPart_000_0001_01C70CCD.70952500 Content-Type: image/jpeg; name="img55.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAAAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAGxoaKR0pQSYmQUIvLy9CRz8+Pj9HR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHRwEdKSk0JjQ/KCg/Rz81P0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH R0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dHR0dH/8AAEQgATAJCAwEiAAIRAQMRAf/EAIkAAAID AQEAAAAAAAAAAAAAAAMEAQIFAAYBAQEBAQEAAAAAAAAAAAAAAAABAgMEEAACAQIEAgcFBAkE AgMAAAABAgARAyExEgRBUWFxodEiEwXwgTJSFJGxQmLB4fFygpLSIxWiM1PT4rOjJDQRAQEB AQADAQEBAAAAAAAAAAABESExQQISoVH/2gAMAwEAAhEDEQA/AN0ZRTdpUBuUaEq66gQeM6Tl YrKnTiKGhnTs5ojezXEt7ooY7tPg98zfCwe40WaFcxVtxb5iIVBEoZx3Fvn98obyHIypirQR hGxygjAVvAZy1lapWVumF2XiVhATujGCpHdxbpjEzAlG0wjtqECYWxZe82lBWRShm7sH1WxX hhAt6NepWmPu75fYKUBVswZieWq05MqJaaZTLSshripixpCiS0X+pt/NJ+ptfNIpmWEWG6tf N98NbvJc+E1kUWkmk6TMjqS1JBIAqcAIv9ZbyWrnkoJhTMGq1NII3bxFRaNOlhX7M4bbMLg1 jKRTLGggZe4eEHESpkTpEomROkQiZEiRAmVnSJUdKzpEo6VnSKwhzb+G2W6z7fZF7QwhydG3 qfl++JW95ZA+LsPdMNnKSJRL9u5grAmEmkUkS0iBWRJlWYLmaSo6RJkSjpEmBe8iGhOMILMv 1B6ACPhrj/AjHpPhHbMnfq4cBxpwmfq8ak6zyMJWWflLWLZu3FQZsaTk6N3Y2dFsVzOJjTWQ ZVCVOkG2TyD49qj74yh1Cc7L7dNnoEIox4y2qnEw+kTtIk6uwsbYYUhtAAl9MgyprkkXDLLB vnJ6PYv/AFTpb/rnTTKBOkTp6HEnuUodQ4xaabrrBBmYRQ0M6SsVVpo7ddNsViCrrYLzM1WN BJSEd4fDjlUV6ovvd3c2oD2ltm02CkZjrjd4+Ek8pjeqnRZs2/y6v5pj7b+Rdp6nut1dW0pV K1x01pQVlt36juNrc0XNF1SAQdNKgxb0S2WuOwzW2QOtsoP1lgb4RfwKF+yc2z63be5tG/bG goQHXhjkRKaWuYIC3UKy/pdhbW2e7fwS4V94XvMpa393e3lsWP7Nv8uYAm59ZGbNBubO9Suh vsMrs20MQ2FYX1C/e2V4C3cfSyhqNj7jNKy43FkbhEtm61dStlVc6Z9f3mX9p+WfcXzTRKse jGLHZXWbSFNeozrnrV8jSgFsdAj9+5vLe1D6lGlVLYkvRuJ7o/Z+YzruxvWhqZSBHbdxrGya 5aHj1AE8QtM/tifp2+um+tt21pcOllOWM1t1um2Ka7S2yhOmv4qjnzkv1sWTHn9q1+7eUWyx evtXo5zeutXcPoBbH8OPX2xP0/e3tzuVUnSmLELgMAc6Q3qO+OzPkWMGzdukyS4tmm6XRnba ctwMaZHkcDFtjbbc2DcW6/nY8cF5VHTz7pcPce1Za7jcYscqGgOU1PrWbDUErhbprgxWiEio B6oWU0671tfzV/lxmqkZm49U3O3uG02glTmFje13d+/a81nt211aRVK8K8DMDe3PNvO3NjN7 bWQ+1tKGQEFmYM3M4dk5Og/m32BNu5adlFdOilaSi3tQs3blAzKxY5YfhhrAt2bi2xpuPc1a iMgtK/qlNxuSloXbSW3VQARxXqWmXtlL4QcbkN8Cs/7okruC/wACO3umGPUd3ubiovhBYYDw 9sP6ne3iEVYaWr/t1pUZiNMO7q/VQrqymoNDxEB6jvL9hVeyw8q5XSNNCKffF9jfu37dy3eq wRdak5giU9WVqWrYHwoCesxRHpl+5evm5cYt5aM2P2fpm/snWzYXWQCcenPlML0uyy2bp4uU tr7zjG9xum2p8nbLruZM2Z6v1SehrNd1GoVqfut3SouqTpNQeRBH3zM3tu9a263PMfzTSuOG IxFOiB9O3F2+xs7jxppLVOYI6c5dMbTXFT4iB1yhvrTV4tPPSafdM/d7m7tSDat2irV0uufv yxi213+4a6Wu1bwnSi8WPQPeY1MbRuUFSrU/dMqLyt8FX/dFZgC9vjfzZGPPIDnTkBCbr1Hc XDoteEdFKk/rjTG7V/kbs75Q3gDQ1B5UNZl7vatZtardxzdQjXjgajh1QG23e+unyVYVoSC3 R0xpjbNwD4gVr8wp98qLmr4QzdSmn2xVLj7WyW3Y13S9VUmuQw6KZymzubjfMzXGZLa0GlMK k/oGZjTDjPp+IFRzIIH2yazD+t3O1usjE3UViCGxqJr0COyD4cCvUeHumpdSwSVOU6coqwHM iaZMeo3Tt9sWXMUpM23f3Z231Ada0LaNP4QaHH9UP681LAX5mkXF+n2ni4WlT+I4tOLqzbXq y3iE3CLQ/jXAjpmst8WS1u6cUOB5g5e+eT2u2bcXVtqPiOPQOJnpvUN6u0uEWl1XnpjnTCgp LKhjz2Pwo5H7sjzwpo6slfmGH2xW4L30hv3Xdbuen4QuNKaeqIenb+7duixdPmJcwIP6OqXT Gwb4Y6bYNxujL3mCYpbuLbuBbl66wBHBF/ZAb3cXLG3U2m0CumlOWZr1zJ9OttuL9dTKVUvq GeHX1xaSN1HFkspDBNR0mmFOuX89SaIC5/KKyUdLdprt649xDgNVB10p98Qsb+7vbvlWv7No YkrwUS/pMP63/wCN/sgbNx1tOLRCXU1O2pcx18Irvjethb21a4yNgcSxBHPjjGjdu/RNd3Ap cppHAlSRn2yWrjAu+o7i/gzHHgJt73a3LjBEUkW1VcsMBPPbRGuXkVRU6hn0YzX9U3G7tEan GlstGWGcikr+2uWfjBEN6WP72s5IGb7AYbY7h9xaupdOsIoZa8DWC2ZW2l5q400gcTU4090I 17as1qlKLShc0pyPTXlhnCULOXGb4r1jGn8a5xe24CEGmHjWvMYEfxDLph1c3DqQjVTDjp/8 jx+VekzM/jd/oyKXbUTkcfu0joH4jxPRGqRazcBJAy+Kny6s1PSDX3ERiszSKmUJlmMHxmGx Fg2zhwMIB4pB/wDrnSv/AFTptlE6ROnocExXcW6+Ie+MyM4gQ2+NwR9jF7VrRcJ4Uwh3mvbJ LdHwaRmaCZfrCs9/SowRQs1rKeYWuafNdXoF1AaQMmx9u2KXtnfuuXbSuo/MJj6u1uchb0/b i3aa87vbq2jwEY4VxrCLa2iHXR7zfnpTsj+321wJ5N1AV1V1Bxh0nGUs+JSMxUivRJJKtuAe p3GvWba4DVUnl0D3RT03baXdyzDQhPgNDwj2gX7YsMdNy3XQTkwPDugrVnc7a5qCE8DxBEmC TZsbtwD51xuFWWPWkXbI1tVZRbRiNVDi3SMJw1hfEq7ZDmcNZ6By/Ryl9ylwp5VlQEIA1Fhi oxwxrxhXmF2odgKmrH756LfU8q6MgzKg/hHfE7Wxv23VwFfSQaBhwjm8s3r9FVQigkmrDM4m EZXpu3QbhW+SrfYO+Nb2jWLat+Is595hdrtb1hy2kXAylaK44++dutvevsDRUVRpALCAv6ZY Gq4yDxBNI62h/UNibh+oC1JHjXOlOI5j9sNsbN/bFvCGDcQwwpX7ZO1F+yoFy2zBSSukiorm CKwrGs3DYOu34TNa43mXEu/8iVpyPRF22T3XNy4PJtk1Nadghg4uvqUUtoNKTU8s3wPK2zS6 z/8AHbP2mUvMVQkZwt2y6Ibe3t6g4H9zUvi7ZfqpGCTxmxepaby0tW20KNRZQTl7ooPT9yCD oy/MvfNN7RuNqfbksc/7g/qmdjSlm3aYncIVtjy9LDIBjx6oC/aO225RviZ+ykYazdfTbFry 7WoM3iU1p/FKb23f3NBpCKvzOOMikfTxW+GOSBm7IXfmiWkOenUf4sYXabW9ZcllDqy6TRhk ZXc7a/ffWQqDIAsJfaKbFK27h+crbHvOMF6i+q+3IYfZH9pavWEKm2H8WoHWtAaUxxib7G/c YsdNWxpqEBrZ2v8A66sTpXWbhP7uAlD6gS+jboFLtnzJOZh1s3TtjYYBGwCnUKNiTTrmfa2u 5tOrBDVT0U++QMepLoVQWZ2NdRPdkOOUBsvCt25yTT/Mf1Rje2L98hgFbSKFUPwnlLbSxftK wa2GVs1JGo/szxj0ey/qHh8u38qD7ZG0Jt2blxfiJVFP3wm42t++5uMFWvDUIbbbe6im06B1 LaqhwKHKvVKCW2u6vIuHUHVgrUxHXx9s5kvYu7ZgXXI+4zUus1m09y3iS+nV+WnD3zH85qhi TUGsDV3NwXUKWVdmuNqPhOEHZtfR43P91/CFH4QeJ6YNfVb4zIPuhLd9d2SjKFcKWVl6OcAP qL6rxXguAhNqRbs+YTcFX00Q04Tr1n63+7ap5lPGnVxEjbLuLVbZtF0bGhHHnWBe3trO4JKr dY8TqX9MKrF3ZqaQKLQ5+HnL3H0AedRAuK2UOZ5sR7dcpbLGrNgXNaSxKJCWBW4vtwgYztBV yeQlvhmeS3q3je3b+Y/eaQF4WK6Lj3WCYU8PDph96lx9wr2wG8umBIE64nlsrafLZ2oV1aqj nMR0CsFXPlWF8tSKs5+LTJvepKjE2VBY5uczwhSQLrKTpNy3pUnKszfodwh+A1B6JUPb9GWy DcYtcY4/KOgDL35xP05QL2un+2rN2U/THd5a3G4QYLqXEopxFfb9sHs7F6wSzqqIwoS/LjhJ 6Ad8B5dpD8ur+aU2SBLd5wMdIT+YxneWG3JF2x40A004inQZOzt7mwCNKopx1P8Ah6ZQD1ID wWSPCqjDpg9mi2rF5lGJ0r7icYzesLuf9p9dxM9WGvjVffw5dtNtbv2CytaZ0fBh+uBbS9lt Nlmqc1XH3zt3qO1C3CdTuc88MI6lsjwADbq35gbjdAPD7SeqA3lq/uSKqEC/M4jdGb6XYVL/ AJn/ABqzY9VP0wvqdvUtq2Tiq1PWc41tNtesM2pA6sKGjD2xlNztr99y7BVrkCwkCuyteTt7 r56iqD7zEbI1YjMzcSwyWGt3lAVaurBh8XAU6fbGee1m0x0yXw1L3rasNRRHkaZ9jFAeiMoa TzV6vR9TCRZDDgyudijmkCdymrTXGHZdQgGsA9MLMMC5hAm4KwTKwwEXbb6jVqmTVxr4f/HO g9P/AKaTp0c3TpBnT0vOmdInQJrKOGI8IJ6paQZUY97b3K1VGqfymWGzuUxVvsM0qVaFpGrj Ks7JmJ1q4ocMP1R5bBQUVTTqjC4GGC1EmmMy7tjczVvsMEdteUYG52zWZaQTGNMYj7e8T8Ln +Eyv0135H/lPdNczo0YrWL4ytv8AytBmzuP+N/5Gm2wlI0Y62dySB5bU/caOHZ3KYK1eox1P iEajVY1vbXdOrS4b90wXl7rEhHr1NjNpeMsFoJNGba21y4A1xXryIMdFpgKBT9kmyaErG5dM JmyzChU06ov/AI/of2901JMaYy/8f0P7e6d/jxyf2901JMmjL/xw5P7e6SPTxyb290buXXV9 IHh8Nf4mp8w+4wK7m4R+HGnDn5f5vz9GUaB/45eTe3uk/wCOXk3t7oZdwxKglQScQcPxEfNm aZDVjngZH1LaSRpfB8vy0A49NTjll0tAf8cv5/b3S3+PXk3t7ozavF3Kkj8WXCjUx8Xv+EQT bhwT8NBq4Hh5nT+TtjVSPSrVKktX3d0GdgfmeHO7agxX8XLGmmijS7YmvT+7IbcEEjUgAfTX l4ScfFz8PDI9QztAP8eB8Ose3VIPp4OJ1n26oZ9w6k0oVHGmB/t6/m/RlxjDXRoZ0IbSD05C XQkPT1HBoO7sAFJUNUD24Qx3b6ailfFXKma0/HQDxCuJpLfUvVgKVBoBh84X569ijpl1C29s XrqqyAlAoGmlCD1d0ttrlECXrDHTx8uv6IVbjE/KcKnl42XmeWFKiuZpJa/dUVrqwfL8hpxP 65loO7bt3VK2rDBjkdOinvNINNq+0UkAvdcacAdKg9POFa/cJILYDn+/pr8WPGuApLJfph4a 1FOnxlTTHkKwgX0RIGDBgMxO+lu/Nc7YW3uWamTE0wXpVj82YpxpCNeItq9QC2nPLHPiMs+o TWoXTaaDXSxPMiE8t/lP2GFS6zNQjDxY/utT9vu6gJtw4qcKAkfCcPGFzJAOFeUamO8p/lP2 GN7NCuosCMs4qL7GmRHhx62I4MeXPPssN0yJqqpFXrl+GlMDcWtRjhXhhJasil/Z+dcLMG9v dJtbFbR1AMT0/shL142yKU8Vc6dHNl585x3LA4gAVOPQLir7sCa8MjzESq67t/NFGBi/0DDJ njL321DRRk8OOfxMVz1D7j0wK7pyKnSMu1Wb5+OFCSM40D/x9MQWB5zvoKmramhfqmxpTBaj L5NXz1+wHr4zm3Lrnpzpl0uOLD5OfHjLoGdhjVdS9Ur9AT8RcxpbzsQKDE0r/Bqyrz5Eileg k1piyBmzIrh0xqEX2IYCilacpH0l0fjftmnIjRl/QfNqJ5yPoVHBvb3TSMBefQpMujBuqysQ qmg6DF2a4OHZGHfOLO057W8V81+XZBOMcZeso5qZNG3s/FaWOBZn+nNVNPIzUAnC+Xol4lcI TVKQV7VSq5yHk1qE7WJii+4+MUjdsl8QZemQ/wCHOsgkcIpV60zlTdKnEQZP9av9E6A83/06 p06OeIMicc509LzOnTp0Dp06dA6Da8yZqvb3wkhqUxygA+qao8K9vfHjdIGAmU1NQplWPGS4 s1V902VB298G26IGS9vfF7ldUhpZidUub9l/Cv8Aq/qnW98zCulP9X9UTvyu3yMvDpy5v2H4 U/1f1Rb/ACb/ACJ/r/rgL9YstK4ycOtO36k+sAon+r+uaX1Z+Ve3vnnG+MUzmwMo4dFtb1ix XSuH739UYbcsB8K9vfMq3/vGnIVjzZRxelbvqLW7g8KUPHxf1TTXck8B29881u+HObViukVz pJw6e+oPIdvfJ+oPIdvfFpMvDpjzzyHb3yfPPIdvfF5MnDpjzzyHb3zvPPIdvfASY4dH848h 298nzjyHb3xeTHDo/nHkO3vh7Laq9ESje2yMzcWCXm0iL+ceQ7e+M3qaTWISRaL5x5Dt753n HkO3vgZE1xno3nnkO3vkeeeQ7e+BkRw6N555Dt75H1B5Dt74GVl4dMfUHkO3vkfUHkO3vgJE cOmPqDyHb3yPqDyHb3xedHE6P9SeQ7e+d9SeQ7e+Lzo4dMfUnkvb3x5Xpa1n5azIM1rn+xh8 omfrGoAl4ngO3vl/NPIdvfFkyl5eHRfNPIdvfO848h298FIjh0bzjyHb3yPOPIdvfBTo4dF8 48h298jzjyHb3wU6XidF848h298jzjyHb3wU6OHRDcPITO39/StMMY7MX1CuocqSXws8lTcr AM1ZMpOTayylcZfhBCUP7C7ouaTk33z0Cms8rZ+MT01qtMZx+vLt8+BpM6TMtBFRxElbCH8s l6Si190sVYbU1waAu7UV8TGMdUE9ZQx5K8z/APn0+6dCf9M6bc3/2Q== ------=_NextPart_000_0001_01C70CCD.70952500 Content-Type: image/gif; name="view86.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhQgIiAaIAAAMPR+4AAL7X8P//+y9j/X9/f9TQyAAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQEyAAAACwAAAAAQgIiAQAD/yi63P4wykmrvTjrzbv/YCiOZGmeaKquSuCycOUG0Bzf jj3qeO//wKAwOCu+eCLkcKFkvkDNpSDaoUqv2Kx2qwF4vbVnw8ohA80h9E99YXPf8Lh89a0/ ojxj65kv7v1/YmOAgTRTfIIMRkd6Njp9eHqFYYuKgI+GTZCImWKSmG5zoqOkpQJ1qDmJf6yO nHush4atq5i0NKB3r5Wunb6yurPAka/DjLi9qr/JwMbIz7Cm0tPUcah2g4vQubnZsc2aid2V yk7Q5uDH35azkOW3sdrE6efMyaHV+fr7J9df797kFWpHbhMhc6AkyRLGDh2ShJwUNvwWjuCz T/IY3sJ4Sf+bM3z8QoocOcEfGG/liI0r1kwCr1WBKDkUBPHXBHfrKKpT5jElzIK1IsIkSbSo 0Qb+gilVWaxbSwrMss2Dh24hywg4n+o8J5VcwJ8cAeY8SrbsyFRK39mKGe/qWkttO9FbGrXl wbcTqaKce6gqlZUIJ6q7araw4aMZ7d596JWQRHY0O9rkWXdTV6wGZW6NPHmvxINW4w49TLq0 6dOoU6tezbq169ewY8ueTbu27du4c+vezbu379/AgwsfTry4cVEgMWu8kjzDYwzN4+CLfry6 iYouR1fNvnyNJ+1pwMsQL206eevoO6DlCTl8dzjUN8TXmnp++vtIrwUT5liy1Zr/CC3T036+ ZBbYf4oZZGBXBVqE3SQDcdYfgAwyxFFUj/X0HH4clmQSZRDucoxNjMHjn08XiSjgVlT5h9d2 9jzHTURx1dhLRVzd04iKfu10XoccmgQAiDs1hCFhM+UYlID88ehZkUdypZk7VkSZ4JUzvkel k3pZaR+QxgmpSmg1bfNdZx5ZWaGUAj3oTJJJ/sVSXV9ZhOWZ/xUJ0I1+MKbknwiCKSgEYg5i I484JToYnnttR5+bXjLqlWB4VgnlpYC6uaee60RqZ6CDhrpAUmPOleWVqOr4aV6OasrilquO xdebMsEKp16OPillp5iimquog65nKIomSmqsmbH2qNVa/66wSOuWstpKX4/1HLtQW9PWiK2f XY7YV7bAhjssSmn2yla5gBI41md+/skoPUO1m2xeCmU1YFiUgIbvZhYC9aW4AAe8BHX/Cmzw wYYh6dyPCDfssGkbLvzewxRXbPHFGGes8cYcd+zxxyEVLBYUDIPLgsggp2yKQDeVLDEJZmTl A8oq1zyEsPS6jBx4NJehs81Aa0GqrpCRuJilEAXY3p0ONuhu01Mt6Gmf8gZtNR0fEh2Nqltz 2q1cpmaKiLZhF7huUz72SnXau17tdgiFUtod13Kr9e6tMHrtlKe/nlqsnStVO/HbhGMQd4Di vJSi00vWKxSn0mpY6eTzBmpr5P8qRlz45hYcjqvfirc8N9vLUs6XtLRO6y+cmDPJ+esgDF33 of223aiRXL5KOtN4MzUZ3c/mDvvwGeCct9FmagsW2MGvmFDzzsZY+bW3Si+48oMTr70F3OYJ b5NIcxbhgXkKPuHTx+d7mWhrk6359vDn03P89Bc+f/342/x+/vz37///AAygADF2vy3QSSQF 3AFozvAz6EzqVzvLnhASCAMlkIGCWDhgyBqIAwxyj4Pj6QwE51DA5nhQPdgY2QVBuDIWktCF J4NhEmSoGe5Mo4Q/O+EGZJcrA/EpXseSkNMgxCClGVFV59PSAstXNGxl615HW9uCQpMvqIHo iFzyIRD/hYi4xymoaRECnxiVWKYxbnGMXRxiYyZkjayxqmwfUZ3pvoXEtFHGdXRcVO1w5YSz oQ1Z14qak7IEOq+lTpB/+1rXbNes5iEPe647USM1mDlI0qVFgUMcJiUYBM+VT3qHXBLeaPfG RjmFdeKbVQ3TF7gB5ex6qIPjo6ylwj/uTZSuQl0mW8e72Smnl7PcoyJ9BUwueNKCI2qfzHQn mR2ZMS1hHJ+amHhHjcDqQg9kpjNH2SZXRm95ZSSforZ5O13+kWnkTF00qwnMXM5xVt1T5xaO mbi2TTN9CHLnAuNJrVBOr59E890SY8nMUsaMlnd8or1Ip8/enZOgxTSZLP1Z/0vAITSeGswC D3NywHs6a5SyCqZBEeUWniEJop9cDkRj6apNiZBYCe1lR+vp0Eeu9J0h7ac5rUnTYcoMpUJL YTnRBj27MQJ7TzlpTxmqR7sZ1aVOVGWdjLaR0oHtRcMcFmAKyVSVHrWop6tkOlL1Vaz6rWxe RcYmAWpVqVIDmWD8SPiaiUarLu+K3qvjmc4Iqb2CL6feI2JeG1dXdY2QXZmkJrrUZ0Sy/m6N t3RQEwlkrsCyp7EL1RsbW6PDh3V2gAb7bMAUBtrhiXa0SyytalfLWtkM4LWwja1sZ0vb2tr2 trjNrW53y9ve+va3wA2ucIdL3OIa97jITa5yl8vc5v8GlwTOja50p0vd6lr3utjNrna3y13u hqC74A2veMdL3vKa97zoHW8HaNsh2a7GvSKBrynkazH2boC++MGvafSbD/7Owb8PA7AEZgsm AfvgJDcw8A0QvN7YTkPBByNwBiBcHApHQD8SYLADNMwCCysAw3Ab0gc8/GERj6oHJAYYiSUM BA2bmCQpzs+oXrxhGssYByRGMIc5sOMJO7h4DLbxCmIcLhZXwMgHDrJRiDzjJpf4JGjBhrCE KlQN5NjEOv7HjLUMZRFnOcunELICUjwkHW8Zy15Oc4NhyzEkT8DNOCgzls/c5C4zoMpLYHKJ nXxnNe/5w2H+s50DDYIrO3n/0Ij2M4e7rOUHkJnQpxC0ov183x9rDM4RwHQM5HziG//j05PO gp4h/eVBQ1rSqD71ml8L5BQmOtWmjrKYGfBoQofa1pS2sqUzpmlHj/oDij7zrV+NhVGDmNiq TrSre3wBQwdZ1rAedq4hUOtASzvSkWY2BX4tqF47wNt0qHO0o41nIRhbyMh28a0foO1t77oC sbYxsec9bV+zuXjixvWWn+wBbhfYw+BWAZqxTe9Ub+Hc7F63mdN9Yw4Y2uDX1rfE2y2AaodZ 4S+m+IDffbGAL8DjKMh4wSc+52JzHMiEWnaa093ocmPg4ZJ+dsuljGYuz/rjJy9Jw6ks8n7n nGIg/6+4v3m8c5pDvNFXGDo1lJ7hm4uA6TGA+n2CHnThSL0UV6dzh38eh6xbh+pVB47XRTF2 FHMdDmWvMNjTzhq2o/3s84U7F9xu9bWHvTd0n7vcSZH3p+9dxbV9eXoHT/jCG/7wiE+84oUr +MU7/vGQj7zkJ0/53Da+8pjPvOY3z/nOI/fyng+96EdP+tInHvSmT73qV8/61h8X9a6PfeUB EPkAyP721YX9bVHxWi/8tg7M/cLmfQ9b4ROX+LY1vnmBPwDe9x75tVW+85VrBNm6ILZFyG32 YVt9wl9DutCPLe2BO371Npu3yB9/+NFffuWuP/LMbz7t399b+ou//eMlvv/6n89/+/te//iX XNf3WrbHfQM4AAN4gLSVgAWIgA1oeOUXgMslgZmne9GHf9MXf/Enf8n3fxEofczngc+XfvPn gfbHXSTIgbMlfCQIgCBofBr4gieIXPQHgCpIWyIofzMYXAqIfQfIgLcFhAQ4A4c3f8VXgkfY fsp3gfp3gyCogjmog0d4gxy4g8RlgUx4f1pYher3gbsXhf0XgSMYgCLIgl24fF5Yg2AIhUoo hlzIhnA4XRvIf294gVBIhwK4fQTogAY4hEFYgD/oh4W3hNDnhm6Ig8VHh0q4hWfYfOLHiL2H h86FhVkoid/3fZK4go3Ie+tHiMBng5hIXimohor/GIJtqIlc+IlLSF2eeH8nOIdWCFzbB4gP 2H22ZYt9OIiOmIiu6IKvmH68GInBuH/CWIy7uIuHOInn93uNmInv94thGI2yZYrSuIblNYoU CIqbeIrTiITPuIrgx41b+IXduFwNyIB6mIva94CC6H0rOI3vWH/FuIjDOI+PWI/HSIHJRYnw WIqRCIzAmInd6I1nGJBlWJAliITGKF7YmIU5aIOOaJAEmYgQCX6WiIHiOIXCGIu9dY7s2IN8 6IMLeI7qOHhk2I/3iFuGGIzHmI/2yJIruZDMxY+92IYf2IJdOIdTiJMmmJNhqIpsyJGs6Hzg uJM3CYM4OYJSaIpFGXyr/9iC5ZiEA8lcuNh96diODtiDV4leniiDSaiPTLmUTHmUX5mQUqiD +vh5y8iVaUmDbfl4Qgl/tYd7iHeSxzddNLld0+d+TSl5e9l5bzl47EiXbGmTwdWX+7iWhLmY jNmYjkl4efmYkjmZlFmZV6iYlpmZmrmZnGlfFtCZoBmaoimZkTmapnmaEygkiImaz4WZrPma sGldgRmbulWatAmbs4leg+mXt1lctpmBZCmKcXmNPHl8bbmaetmKUrmcHXiUuXmLepiOWzlb 0jmdx/WcvemZR8Z+LImKxAl5D4mdHZhbwymHxBiDcOh/ClmeI8l9giiEICmSITmfziWe2fl3 Qv+3W+EHizcpli5IhVKZlGOIkGNolAlpn9e5nk1phl85oGVZoBCKlgjqW99olNKIgwrKnvIp n/C5m7n4g0RYn7oVis1Vg4eZXez5m/uJkVoYnkqZjWsYhTlJhgSpoODVhAAaoCxKhRJZhy5q nivqndZoocg4oUMYoiHZoX/YjrQooiPancE3e635mRRaiDsajZg4gxDJiTRqky5KoihKo3YY lBWZowepihp6mFYalRGKoUFaXNEZp0haW7iIle6nn/mokGeplF/YhFBZjXr6hGuqngS6k1O6 ncyokYr6jwKppYVqjdToo3raXRWKoYB6kag4pDoZXWu6qJ5qqePIgyX/aaf0uaTW56HGNZvK +ZLJiJKbmJJ3GKvGiKPNGI9FupECuVul6YXOiJHNWKtuKqlOiKUEyqAyWV37matiGYd+aogT +Y/AWqKYmqudOo7R6lseearU+ZG7GYikSoN4So8PKqF9io+zyovJKK7E2JKaiKPICKW66prN 6Ys9+ado6aB2yJMHyqf1+qybiqwxCJaBSpQCaob7Sq5Dqa8I+5SG6YpwKqe1OKdYeZXWeZ14 ipIyiZ3rKq4u2bHniqvHyqroCq+1Ka8maaTc6ZcoW5dzmXmqaqsZ+6Qg25Lq+pIf+64h27Ex ya68ZZs3+q/FBbR1KbRSCnmoCpcjaqVe2aYD/+mTBuuLDeqgBsu0TYum+OpbPnufWru1JFuE MHui4JW1XDu2vbmyydmwzGi2vmmyZNu2Y6u2sSm2bju3pgm3sCm3dJu3nWm3r4m3evu3lsm3 rOm3gLuYgmtdR+t4h2uxEMi3Krqg4IicVbq438mcwuWolDtcG6i0DluuVytcVdmtERufp6qA dQq2datcu9qqbBqqCTp6goqyO5imJXqesXuhmXqtskiSWTmYSCqEdNqk33q5l7ul/XmhYdmL ljuVDfuj9pqzh+pu+tmlGampMiqDjxq7B2uSTjipOhq1wImUAoqw4QiqwqqeZPqwwbut2Vqq 2jqfFUuhqHue5lqIMP+ZkhubfBHJqvQ7sxxrXKsblSn4kw7JohLZiTUah+k1sDn6ojtarcWa vQl7pXs6pNWorLxVp1oJv8K7vvA7vPJLfug5ruyajVP5ufBohBC6s8EJvcAVwFnKqwoswDPq vXtKrtpItJSKhxZsvEjpum94iZKbXKt6vb/4psRVndg3sfHbu76buBf7e+bLsyUcfVZMxe+o wiwssjf7emwrpDbKw7qrjbi7whJMuwBLjaQorDwqptaLxvUnjjH6lkgsqkzsg1tJutu6x0GL uiN7rBh4v/gYmEaYvzqriIKsllQ6vZcqxjfssF/qrOdrlgHpfWkIo/76qj0qozPspBA8qdX/ qqi6m8ElGZ8gqZWi654gLI9q+qP3Sr7Y26b/6g8DOrWS+rRw+7jBGcOPjLxc+p+pyKBQO4gv OJ4KW8Hi6581nMbO6ZN8uqgMu7K2uAgGGKJ5PLrcqschXLgAl3+Z+6mA+c3517KYJ86gSbgJ OsRpa87h9Zecx85UqXnwvJnozM32TJfzrJn1fM/87Hr5nJn73M8CnXr/bJkBPdAILXoFXZkH ndAOPXw7nKhJS54LHXhf/NCGS85Fu3i5Scjltbrie5xiKpwVrZL0apwmXdLzypzhm9IkDLpK jMfYvI6m28RRjF23G7Xz+KsqfMP/99EXXY4DPJ6Ny5ZArKYUfV60/xrGRGqpZTpc3hrTSgqd TArFrKyXkOixNPvH7mq7QL3IjDzUr0ywxanM7rysEUqw6UvAOizCTVvA4Buww/zK5MupBjyj TZ27VPtbpFvT79nB7cnB2nzV2lWzWGzYzgqDXatdKtq9oIrALRrBESmBxtrUeC3UlDzKxduj wfqmEEysjRyOkH2rdejUXg3VFBuxf73KwAvYxIuC+BuyiP3HsU1euhyqat26kVyFDezDkKq0 kdzWVQqga3zSbazXQgzHcZyRYnzEFAzTfi3THimx7HvKVk2eEc3FW42uhmyXWLxdjc2mxuud l1qGvX3G1OuPZFyf3lvcYRzKoN2u8yzWnv86u8/N16Xsoda9W/vdx4Vttcl8teEZ0i8dtkEN xAO8pdBso+b9jZk8rEEcwYGamrGqhg9+h5s84U8trZ1cq/AN4bTbvt/a36PKpCVOfgPtY0l7 zDFcw5nt4oUM2QqbvP16y4vblcbczM8clk+Lwuxd1shMwdH8sL9rlXN6zTJduteN3f2sa/Js zsrtlKWn0lAtzwJdaeUs3Ot8suoMnhpNeVTOmA6H0WROeqqp5WPrc2W+5mzeeYXW5nAe55AH XXJe53aOXq2V53q+53ze537+54Ae6II+6IRe6IZ+6IjOAhpXAouecCikanwGG2DQ6C436U7n ITCwY42e6F2wHpv/LgKf3nCQnnKjXuo1BmKkPg2W3jlOt+qPrujodumczmMDZ+opEOpNx+qY Dm+y3mfU4OoU0G7A3kaOPusm8GykhnQqJ3I9dmwzd3E3ZzwXt2df9memrulyxmilRu00Zukr 12d2ZnR8ZnTArm42B2bbbu0Dt+o8V27tPnN2UO7wXnO9HujIPm91VnKmNu7SVuupXmOA5upQ JnH/Du6H1nPWVmXnLmj5vu4I7/AJH+nqHmojZ3MJX+tghhQHv/HcbvERH/AlZ+z3zmnWnu9F J+rDnvLRHusyNuwff2FJgezJbvLFPvMt33My7+vs7u8cz+0vr2+g5vM0X/IAP/I6j/A//2/r iJ7x3k5z8e70Co/zUu/rMF/zPm/ul47tVF9qQV/zTJ8KRn/wTw/0LH9qO2/2alZmZH/0VA/u XS/0cA/toHbuuM7nzg7pX//2Vq/yaJ/rAM/2WB/sZX90f1/46A7xQ//yZ5/0BhfxfG9t2Zb2 Uy/xh8/2iY/tdF/vf671i8bzjN/2P//4BU/5nKZufQ/6kR5vhX/ycM/3Ye/4kl/sRv/4Tx/u k0/0lX/5JE/0oq70g671pDbzGB/yYj9uEt/7h/bxA6/6qF/y+75wYpbxir/707/7iz/tXk/x 62bzoT9p3T78/IZr1B/86378Sz/4y67tbp9y1v/s5m/wp976zP+P9WPP7/TO+xMv9nqv/tqO AACivOIenI6qBhuOMsutdWBIeddHmtU2ne31suVM1/aN5/rO9/4PDAqHxKLxiEwqh7Kls+mM SqfUqvWKzWq33CC0i0OBx+Sy+YxOq9e6L9vFjsvn9Lr9js/r9/y+/w8YKDhIWGh4iJiouMjY 6PgIGSk5SVlpeYmZqblJGODpafQJivPJaXqKmjokOrrKmlOqKjtLqxob2gqbW8u75AYE9Usk bARnRUx7W6RMutv7XNxRFCydhMxUXXV9pnzLGkDh/TohDl7yTT4OUSqa3u6ey3yuju4u8P4O rR+Wvf3jDywbFYBk8JUz2OqbuXzy6in/NHfv4bpxEidCnOdQIbyH8vZBImGsRMgTI1yk4BAD RZMQ0uCctADDBIsRKV/AXNFyQUycNT20sImyZwoosRBatLhwVNGlF8MlZLqRYbynSZvaIxdR KVWOHT06YgnUAlCaFXyS9MkzQ1kGIjGAsHm2Ldq1Yd0+sHszbgy0cfGWjXnyrmAOg2cwrXo0 K+KsSBMbpup0MWPH3bRanYwxMmXIXie9/PVZpwjRN83mtDGz2svSfFWLSU13ddi0c/+KJk13 7WqioNBB9W1ZcW9nmy9CLR7V6OPLlSWX6+wZd22ZoWNLJ8zS7s7Z2mF8gZ3bdO3q30dbL62B bXfBZ7dRBDd1/2nEyFrn13h+FT9mro41L/evX1fQKVIda+SZB15bgIV0Hk3lodcPbrBNKBCF rNmmnm4mucbDe81ZFh+IlyGXH2f7EdffVZmVCJF+A351nQwOIkjjhTPIeBpcr1VoXnhpWahj DUCOx95tHK6U43Ii0ldViE22aOJkyp1o3C6LuXjlcVS++FGMSfq1oAo4/vTabBrOJdtYYtCw HZgq+Xhmbn6h+YGaZCaJ0ZIbIVXlYVD+yWSAUXKU2EEI0WOigFwaUiBMxnj3pmyP7sQgdo5C esNIPOaUGkibUuramER2WpiZ/qWIWar9Nacin32q2BCikrka1akuLoprIgTlymuvvv++IdCv wg5L7Bm7Fotsssouy2yzzj4LbbTSTktttdZei2222m7LbbEkfQtuuOKOS2655p6Lbrrqrstu u+6+C2+88qrbbSUnFIBvvvriO2+//v4LcMACD0xwweTWS8m9AyzMMMP5GgxxxBJPTHHFFSMc nQIFNMwxvgMUYHHIIo9McskUX8FVyiqjiLGQF2zMMAEEOAyyyTbfjHPOOn87xco+/wx00Cvn SpLMRg8w8wAGGPBwuAsL/DRJUZ879c7iMmw11ANkLW8UQn8Ndtg+L1q00TMnvXTT4FbNLtsK uO32uHGTC/fWc/c7ddwNy701wHpznO7dXKObhMpIiI34zwP/3ouvzEhzzHTNa/ft7t/fCn45 5ehifQHnBuet+QmYY96u5W2HPvi6R/BXhaJSGL5P50gnfXTDTIse9dOeAw4A6L3v/XvwnIPe t+65F4+608Njfbzxvb8N/O+U874377hDLz30yx//vPHTb892+MgLz7303CN/ftZEpBwJ69Bo PLvZjtsuuQPeY++778HLnj35IdzvP9J1znx2K+D+tGdA/PWNAfrTX+a0h70Dno95E4yg6fhH vvE5T4Eb9F7ybAYE9l0CdrQAwMbMxjHISY5/+fueBMf3QAVKLYEZTF703gbBAGrOgRuM4P4c OEMflu+HNGyhBW1IveWxsIhMlCHX/3wgQk64TxUm3JrRllY7ht0OgU004hEnt0QuvrB/mxug DKvGQ/QJEYYHDOIYX1g9F3JQiTF04xh7iEfACXBkUNSILaZ4it4RAADymx/9vuhF/32xjs6r 4BwDB8YevrGNeVyj8iw5SUwq8np1lN0QG+lCILZxZzvwIzQIFUhCniCLhyTiHUOpRkp2MYGV lCTdIknDST7Nfk3MJCcbKEedpPGAvATjL2f5SgwK84M3K6U69oHKTVyAADBLYSsJSMDv7S6P GkyiGL24RyQSUZLW2+Y2cRe6OCoTfJps3g7Fp84als+bnmSj1XRQDyMUkgA/kNkO/GmGimhi mtW05sK2mP+6hCr0c8xcqOpukE8lALSf/NTBRLkRUUsozKBaXKFDPwrSd+0xpOJqRj4kWlGj CUClEJBfS82GA5euVKWFnCkFYFq4Z9rrZUvrqU996lGSCnWoRAUYRE+6hIkCdKkprahNLerU l0p1pvxk6lQPp9OMmXBfXFVbUb8K1rCmywZZ1WdTJ2BVqkb1qTm46FOdmtaaLgGpWhWrXe+K 14cqaURFSOtbo4pTtsZ0rStla1wJO1fXMeKnjG2sYx8L2chKdrKUraxlL4vZzGp2s5ztrGc/ e9n7KFYIfj3sVZc62Jai9aI0PatqnUDXSHR1trStrW1vi9vc6na3vO2tb38L3OD/Cne4xC0u vkTLV7OydLUwlSlzobpW1lYVsMuF7WgTwdHsane73O2ud78L3vCKd7zkLa95z4ve9IIXuY1w q1uzENtHKA209K2vfe+L3/zqd7/8/Sx7GeFexGIhvo2Yb38PjOAEK3jBDG7wZGlAYEE417la iPAi5ruwAjh4wxzusIc/3GEIX7dXFsbu0pSmYRCreMUsbrGLISvi5BKrxIjAMNNejOMc63jH /Z2BAUbsKyATwsYpxiwA+ntkHivZvknmb5OX3NihQUvIgyCyZEligCM/WbPfYqyWl7Zlym75 y/rFcmeTHObPgquyaWbzT9vcZiUDrSA0JmuE60wFKgvC/8qRTXOc3QzZJ//5sWNGMn4HfWYj c7bQjUU0i8M2Bpb1QNKPCSilTWwAFF/5zVkG8wUU7eUTdFrUl20ymj2tADD31NSlDvWpVZ3l T4961LImdawd3eg3y/rWr961mDnNa1VrOdUvlvKpunBpfMp4HpZedo1PfOM+c5rMsAa0TwXd 6WyDOtvUnnW1cb1qQmu728OGNavDDW7HYhvd1/b2toXd7nJXe8Fi62me/iucPx3EzrIKjqG2 0pRkN0bfT1KUngPB50CL+svrZjOWsf3qbZ963QzXtsN9ze2Ms9vc4d74Zhvu7lmn+9pdhrjF R37ZxH3CsfcW8Toacw+YJ0UXzP+eSKGqVHP72FzZ6di5fYaj8/9MIuHijjeviW3tjsPb4q1m dZdFzvTJhpnUZDY5x1Fda5Qr/eRcRzPKC11yrt9X5Z6I7Ipczo60w0ftQRdtzuvj87absu12 DofP6wN0fEeC6OqedtQtO3Wj//3XTs91xVvdbo5H3N0Rj7PWxb70yA++6B6vvNbJXvbNnj3G UhoOYkZrJSjdHedOqTvPK71zoLPs4IDge66NDnKpe3nVVf/4uCF/bsQrPfdW1zjkJy/trZP7 97IXPLxj79jE5Xfz//mNv6fi8tKnXvQ9l37QiRN6u+sc72vnNyVcP3vB2/riWT98rLmc+PHn HvCuXj//1XfvdWJjnP0kR/r757/p9Nf66JFFXI+PjXo/R31PYX2uQnADp3ZS4SeVsVdMchR5 x3lDB21FBmUVaIEsNmg/42HM5yys9wfgp2vjd2ZPV1/hsmAk+GEmiGRrlnIp02Ic2Cwe6Acg eIE1aIMcpjIvBoPMIoN9QIM3CIRBmF85qGM7uCw9yAfzlS9CyIRNWF9EqGRGqCxIuAcG5oRX iIWYtTIWuCIGMGUCZwhWmIVjSIY/BYUXKIXJQoV68DHG5YZvCIdxKIdzGIc/Q4d3uC9piCxr mAfq5Yd/CIiBKIiD6F2fwF0/Q4iJaE0t94XOdghiqGJ4KImTSIm8JQq0ZYfE/wWJIUYfQPBe ylUC1WUFomhdjhiGLxZUeZVXokASKiMwmcZiQucDn2hWM0CLU3CLWGWKhYBhHxOJ2aSIwSiM w8hRosAwKvNdrbaJHCaLZ/BeuRgF0IgLuzhkE/iLxIiN2YiNxpgy45Vp3QUysGhZFIhfzQhd cEVhNRBYNqVU06VWhlVdE7aOtuiOzNVU/iSNAChf1ghiIKON/wiQgrgy5iWOkhWOy/hY4ahf SkJRN+VabXVWLIWP7VhVU2Vaf3UDrUWPzyVgegcJP/h6iedZ/hiQJWmS5IWM51WQkXWQl7Ux j/dgjMgD0nVV6ohTF9mOoShT6ziPNFBagZWPMvmR/P8IbCG5dZxFkieplEuZXVzhhysJWS1J WfmiNDBpdgzZAzQpWBuJkV2Zkw5pk9KViziJjj+AZ7xIlJUnkke5WUnJlG/5limJXlCZkEeG kEBVUFUZglYZY9SolWPpWhMZkV+5WmhlkYHZkVTllWU5aXz4A17YBa5HblS3cNy2a+X3U24p iPXUXZyZRHApkHKpkncJVHZpkNZ0O8KneX35Ty4lkYB5k9M1mPuEjhRpm4mpkfZIm4nZid+X lpHXe7Q2b8PXWJoJiMDIXciZQsoJmublM+pFl44llQl5UPjSUwo5eCIIY6zJg2D4iL95bsFJ beIpndiEQ1JzOZ4JTxgUS57/xJnMiUY8BJ8l+RCDWJAsmDamGZVV+WnY+XfIx3LIRY0v4ph9 CJ4dR56mZmb2F2bGmT33A6EchU0UxEET6kHw+aAFZEB2M58A+Q2JuJJmdp36KZ16CWb+OW6p BqCNxW8DOiAFigd8t6DGx3iUx3QOyqG60z05ypwWuqER6jkIhKHLSaE52pzGqIhQOX/TWZxb Q3LhZ3mUdVQuCh0wegdEB3a0l6K3p5pHiaM72j3Cs6MG5aMZlKEURKTZlU0ZGqbNmY10mWZM ylgaBqBZypYB6pEzZqV2gKXA9mnxF3KUCaiZuaZG2qY8Cj4aGqFn6qN6BDxx9KMbOqZuKozR WZwk/1qcwKeaK8pYU0qlHnGWpwiL5MhhxmmkOlo95iOk6LROZuSeypRD5XROmUOpwWipc4qp c4qihCao4OapoKgFpBgHe8qnv9loKFhfplqry8qs3HWrhPqsWbarC/mrQxCUTnCtkUasdQCS CqaszQqu4apFpDmi0XprCGZSAgeUPflSsvmOiimYW1mYTFWPzdVa+9Su9yivLXoJ3Zpg3yqu Abus5pqfBKtguqBYP5laE3mYf1WRPsmw8IqR+PiuEUuvheVM3vmdo3qNAuux4Ro5uZWrG4iw y6awGemOpuVXNtmwhcmOFSlXarWyyqaxG7uE/dihH6uzJrkuBptgGQuRp//Fm4q5mF1pAxfZ shH7js84tA7Yr6hYhlHrYuS6YBkrYyeLsogpVTNLj/VKXQ1rsfWIsddaVpJAtQ22s2mrtikU izRLaesqrC6brw5Jm2HpsLY5r7KJtzLrtprQhpUIuIEruINLuIXrhh0SqjPZtIaQuNi1to8L uZH7h43ZuEfLrotQuRsrtZvLuUzYR5krRdtqoJ1LuqXLhZ8LupmQumhpuq3rujgWBHP3DKtr CIZru7eLu7mru3QoBNGUDGWrUaoovMNLvOsju38kui2jvLJwvKbQvMsLvXsIvJbwvNFrvXo6 vZIgUNfLvdKbUZTwvd0rvthbvYoQvuOLvsMSRYwrcL7p676/sr6HUL7vS79Bhnn3i7++W7/7 q4b567/3y78B3J3/S8Bf8wcJAAAh+QQEDwAAACx7AP8AVAAPAAADNTgD2v4wykmrhezqzXvM XiiODUieaGWmbLu4MLvGdDfXuHXn/Nf/lB3wJxzyikYcMklbMlsJACH5BAQPAAAALHsA/wAP AA8AAAMiOLrM0HC9CCd1t4H9eOwSBYLfMIpmam2h6qwZFitWXGdAAgAh+QQEDwAAACyJAP8A EQAPAAADKDi63AMuLigjfeBapSvM4JQxVHedXIOmjzq9LQm34MjZbOXqOz/7jwQAIfkEBA8A AAAslwD/ABEADwAAAyc4utwDLi4oI5Ugz3qn1kombuDVhc+GNpCpMu17PmMtupUz5zuX6wkA IfkEBA8AAAAspgD/ABAADwAAAyE4utzQkL0YJwRWZcfx/lYGeqKzLSD1DaTWalQVXzNXowkA IfkEBA8AAAAstQD/AA4ADwAAAyA4urzQUL3YJnWXWQ26hNa0fRUIehjZjWuaDSMVRzOYAAAh +QQEDwAAACzCAP8AEAAPAAADJzi63NCQvRgndRc+wBXfkjWBougNoGeibLmM7Yt280db2ZnL u94DCQAh+QQEDwAAACzRAP8AAQAPAAADBDi63AkAOw== ------=_NextPart_000_0001_01C70CCD.70952500-- From owner-ipdvb@erg.abdn.ac.uk Wed Nov 22 03:23:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnO0-0005HM-5X for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 03:23:16 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmnNx-00027b-KO for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 03:23:16 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAM85U78026022 for ; Wed, 22 Nov 2006 08:05:30 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAM85Ubh026021 for ipdvb-subscribed-users; Wed, 22 Nov 2006 08:05:30 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.32] (maxp9.dialup.abdn.ac.uk [139.133.201.168]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAM859Pe025923 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 22 Nov 2006 08:05:12 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 21 Nov 2006 17:56:50 +0000 Subject: ULE Security Requirements : NiTs on text From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: ULE Security Requirements : NiTs on text Thread-Index: AccNlmtPqg5EFHmJEduHnQAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id kAM85Uud026017 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id kAM85U78026022 X-Spam-Score: -2.4 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Dear authors, I have the following NiTs/Comments on the text. Best wishes, Gorry ---- Page 7: /(e.g. by an Encapsulation Gateway) or other device to/ /(e.g. by an Encapsulation Gateway or other device) to/ ^ -- /these messages are broadcasted/ ^^ /these messages are broadcast/ --- /is out of scope for ULE security/ -- [ID.ule.ext] describes a method where they could be encapsulated usin= g ULE, allowing ULE security methods to also be used in these cases. ---- /eliminates the need to consider/ -- Well you do need to consider them in this document, but securing these elements is an orthogonal issue... --- / The PID associated with an Elementary Stream can be modified / / The PID associated with an Elementary Stream can therefore be modified/ ^^^^^^^^^ --- /a passive threat. It includes/ /a passive threat. This includes/ ^^^^ ---- Section 3.2 -- perhaps a forward pointer to a later section that =B3masquerading and modification=B2 are more difficult on a specific link, than they are in t= he general internet, and will be described more in section 3. ---- /defines services for Internet Protocol (IP)/ /defines services for the Internet Protocol (IP)/ ^^^ --- /There is an extra overheads associated / /There is an extra transmission overhead associated / ^^^^^^^^^^^^^^^^^^^^^^ - is this what is meant? --- At the end of section 5, I would also like to say that any defined method must also be capable of operating with ULE extension headers - specifical= ly it should allow encryption of a compressed SNDU payload... --- / This method does not preclude the use of IPsec at L3 (or TLS [RFC4346= ] at L4)./ - True, but I would have preferred to be stronger and continued further = to state that IPsec and TLS can provide strong authentication of the end-points in the communication. This authentication is desirable = in many scenarios to ensure the information the information is being exchanged between the correct trusted entities. Layer 2 methods = can not provide this guarantee. - I=B9d also prefer to break the final para into two,the re-use of established techniques is desirable, but distinct from the advantages of IPsec/TLS, etc. ---- / 2 NPA address. In broadcast networks this can / / 2 NPA address. In broadcast networks this protection can / ^^^^^^^^^^ --- /Case 2 is likely to a lesser degree within certain network configuration= s./ - Can you provide one of two concrete examples? /Therefore case 3 is not considered further in this document. / - Is it therefore assumed that the MPEG-2 transmission equipment (multiplexors, etc) are secure? I think this was suggested on the list? --- From owner-ipdvb@erg.abdn.ac.uk Wed Nov 22 03:30:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmnUd-0007pT-VQ for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 03:30:07 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmnUb-0003DV-6d for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 03:30:07 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAM85cSR026044 for ; Wed, 22 Nov 2006 08:05:38 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAM85ctX026043 for ipdvb-subscribed-users; Wed, 22 Nov 2006 08:05:38 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [10.0.1.32] (maxp9.dialup.abdn.ac.uk [139.133.201.168]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAM859Pf025923 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 22 Nov 2006 08:05:19 GMT User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 21 Nov 2006 17:57:12 +0000 Subject: Comments on draft-cruickshank security requirements From: Gorry Fairhurst To: "ipdvb@erg.abdn.ac.uk" Message-ID: Thread-Topic: Comments on draft-cruickshank security requirements Thread-Index: AccNlnhstvIGFnmJEduHnQAKlc/qXg== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No X-MIME-Autoconverted: from quoted-printable to 8bit by erg.abdn.ac.uk id kAM85cQm026039 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id kAM85cSR026044 X-Spam-Score: -2.4 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 I have the following comments which I would like to discuss on the ipdvb mailing list. Gorry Fairhurst (as ipdvb WG Chair) --- Comments/Issues: 1) Are the scenarios OK? are they applicable to all deployments? with satellite, cable, S2, Terrestrial, ATSC, etc? 2) I think we need to tease out the work on what is meant by L2 authentication on pt-2-pt or pt-2-mpt links? Appropriate authentication methods must be determined... In Internet security =B3integrity=B2 is oft= en more important than =B3confidentiality=B2 - but for these links we suggest the converse is true - since authentication and e2e delivery checks are best provided at of above the IP Layers... Where do we judge what are the appropriate goals for level 2 authentication? 3) I didn't understand what you meant by: Page 9: /problematic in the case of broadcast networks such as MPEG-2 transmissio= n networks. / - why? - because of easy availability of receiver hardware and the wide geographical span of the networks... or other reasons? 4) I would like to see more references to methods used by DVB/MPEG-2 netw= ork architectures ... * How is the proposal positioned against technologies from say the IEEE (= for 802.14; 802.16). 5) Finally: Algorithm agility is required (crypto algorithms, hashes, bec= ome obsolete and need to be updated) for all IETF security mechanisms, this should be a clear & distinct requirement for the work this document proposes. ----------------------------------------------------------------- From owner-ipdvb@erg.abdn.ac.uk Wed Nov 22 05:48:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmpeo-0000WV-9K for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 05:48:46 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmpej-0002WV-Ru for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 05:48:46 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAMAUDlT012930 for ; Wed, 22 Nov 2006 10:30:13 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAMAUDfg012929 for ipdvb-subscribed-users; Wed, 22 Nov 2006 10:30:13 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAMATxT0012630 for ; Wed, 22 Nov 2006 10:29:59 GMT Message-ID: <45642702.3070101@erg.abdn.ac.uk> Date: Wed, 22 Nov 2006 10:31:30 +0000 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Updated implementors page Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Thank you, The following page has been updated: http://www.erg.abdn.ac.uk/ip-dvb/ipdvb-impl.html Best wishes, Gorry -------- Original Message -------- Subject: Re: any dvb vendor have implemented ule ? Date: Wed, 22 Nov 2006 10:04:00 +0800 (MYT) From: wcang@nav6.org To: Gorry Fairhurst Dear Gorry, Sorry for sending this email directly to you. Name of implementor: Network Research Group/Universiti Sains Malaysia URL: http://nrg.cs.usm.my/ule.htm Contact: Dr. Wan Tat Chee , Tan Chen Wei , Simon Teh Chee Hong , Ang Way Chuang ULE Gateway: DVB Master II FD-U PCI Cards ULE Receiver: Hauppage WinTV Nova-S PCI Target platform/OS: Linux Latest known rev: RFC 4326 Air-interface Tx: ASI MPEG TS output Implementation type: Prototype Thanks. Regards, Ang Way Chuang From owner-ipdvb@erg.abdn.ac.uk Wed Nov 22 08:58:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmscR-0007hw-H5 for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 08:58:31 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmscP-0004RR-VE for ipdvb-archive@ietf.org; Wed, 22 Nov 2006 08:58:31 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAMDfdwo003705 for ; Wed, 22 Nov 2006 13:41:39 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kAMDfd9a003704 for ipdvb-subscribed-users; Wed, 22 Nov 2006 13:41:39 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.159] (dhcp-207-159.erg.abdn.ac.uk [139.133.207.159]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kAMDfRmv003678; Wed, 22 Nov 2006 13:41:27 GMT Message-ID: <456453E5.3090304@erg.abdn.ac.uk> Date: Wed, 22 Nov 2006 13:43:01 +0000 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: Draft Minutes & Slides: ipdvb WG Meeting in San Diego 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c A draft copy of the proceedings for the last IETF meeeting has been uploaded to the URL below. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 This includes what I believe are the near-final copies of the notes for the ipdvb WG Meeting in San Diego. If you have any comments or any corrections are required to these materials, please do let us know. Best wishes, Gorry Fairhurst WG Chair From owner-ipdvb@erg.abdn.ac.uk Thu Nov 23 09:56:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnFzt-0003wi-Ta for ipdvb-archive@ietf.org; Thu, 23 Nov 2006 09:56:17 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnFzn-0001O2-EY for ipdvb-archive@ietf.org; Thu, 23 Nov 2006 09:56:16 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kANEXnTY011328 for ; Thu, 23 Nov 2006 14:33:49 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kANEXnZM011327 for ipdvb-subscribed-users; Thu, 23 Nov 2006 14:33:49 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [141.201.2.23]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kANEXXui011308 for ; Thu, 23 Nov 2006 14:33:33 GMT Received: from [141.201.123.148] (unknown [141.201.123.148]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 77FEC228109 for ; Thu, 23 Nov 2006 15:33:21 +0100 (CET) Message-ID: <4565B150.7080502@cosy.sbg.ac.at> Date: Thu, 23 Nov 2006 15:33:52 +0100 From: Michael Noisternig User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt] 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 X-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id kANEXnTY011328 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Not having got any response to my mail with comments on above mentioned=20 draft from the very authors, I hope to eventually get some feedback by=20 posting the mail on this list. Thank you, Michael -------- Original Message -------- Subject: Comments on draft-cruickshank-ipdvb-sec-req-04.txt Date: Mon, 20 Nov 2006 15:44:12 +0100 From: Michael Noisternig To: P.Pillai@Bradford.ac.uk, h.cruickshank@surrey.ac.uk,=20 S.Iyengar@surrey.ac.uk, Laurence.Duquerroy@space.alcatel.fr Dear security requirements draft authors, sorry for the delay in writing to you in response to the IETF67 meeting. I had originally raised several issues for the 03 revision of the security requirements on the ipdvb mailing list in mid-August. Unfortunately, I couldn't find any of them taken into account for the latest security requirements document, something I brought up in the Jabber forum of the IETF67 meeting where Prashant then suggested to re-send my comments directly to you, the authors of this draft. Below I am citing the relevant parts of my original mail and the one in response to Prashant's comments. Some further comments are placed in-between. > -------- Original Message -------- > Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-re= q-03.txt > Date: Mon, 14 Aug 2006 17:24:21 +0200 > From: Michael Noisternig > Reply-To: ipdvb@erg.abdn.ac.uk > To: ipdvb@erg.abdn.ac.uk > References: <1155561927.44e079c777a2c@webmail6.brad.ac.uk> >=20 > Hi Prashant, >=20 > thanks for your quick reply. See comments inline. >=20 > P.Pillai@Bradford.ac.uk wrote: >> Hi Michael, >=20 > >=20 >>> =A73.2, last paragraph: >>> - data integrity alone does not provide authentication >>> - the defence statement is oversimplifying and belongs to the >>> requirements section >>=20 >> Yes, Data integrity is different from data authentication, but the sam= e MAC can >> be used to provide both data integrity and data authentication. >=20 > Integrity of messages is automatically assured by their correct=20 > authentication, so yes, MACs provide both authentication and integrity.= =20 > But you are not speaking about MACs in that paragraph or section. A CRC= =20 > or any unkeyed hash provides integrity protection but is certainly not=20 > effective against active adverseries. Data integrity is often used to refer to the protection of data by accidental changes only, such as by CRCs or unkeyed hashes (message digests) in general. As such I'm not too happy with the use of the term data integrity in this document, and would generally prefer the term (message) authentication to explicitly mean protection against both accidental and incidental changes. Anyway, to section =A73.2: I think you should completely omit the last sentence for the following reasons: - the defense statement is oversimplifying in the following sense: + data integrity/authentication can detect unauthorized modification of messages, but can only partially help to prevent masquerading attacks + sequence numbers are just one (effective) example to counter replay attacks + there is no solution given how to prevent DoS attacks + the sentence reads like these are all the solutions to counter active attacks - =A73 is about analyzing threats, and not requirements, which are handle= d later in section =A74, and the sentence should be omitted/moved/merged th= ere >>> =A73.3, threat cases 2 and 3: >>> one can distinguish between two other cases: >>> (a) insider attacks, i.e. active attacks from adverseries in the know= of >>> certain keys >>> -> protection against this attack requires source authentication >>> (e.g. digitial signatures) >>=20 >> This is more part of key management techniques. An adversary (even if = it knows >> the keys) has to still over-ride the original transmission stream and = deliver a >> modified stream =96 this is Case 2 as described in the draft. >>> (b) outsider attacks, i.e. active attacks from outside of a VPN >>> -> in this case simple MACs are sufficient (i.e. group authentic= ation) >>=20 >> Note that the Secure ULE aims to secure only between the ULE encapsula= tion >> gateways and the ULE receivers. >=20 > Well, I speak about the case where a ULE receiver can act as a sender,=20 > i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared=20 > authentication key for MACs) acting as a sender can successfully forge=20 > messages, but not when digital signatures are used (case a). However, a= =20 > sender who does not know the MAC key (e.g. because he is not part of th= e=20 > VPN within the same ULE network) will not be able to forge messages=20 > (case b). >=20 > Note that even when there is only one ULE encapsulator an active=20 > adversary may invalidate the one-sender assumption, and so you again=20 > cannot detect forged messages for case a when MACs are used. Source authentication means corroborating the fact that a message comes from *one specific* sender. A simple MAC can only provide source authentication as long as it is guaranteed that there is only one sender! A one-sender assumption may easily be invalidated by a receiver acting as an active adversary (i.e. an ULE encapsulator). Another scenario is that of meshed networks... how do you know that a message really comes from device x and not y? You can't with simple MACs. An "insider attack" is a valid threat scenario. (Think of a disgruntled employee.) I am fully aware that insider attacks are more unlikely than attacks from outside a VPN (or virtual LAN) within the ULE network, and that most will be fine with group authentication (i.e. MACs). (And there are good other reasons why one would want to stick with MACs.) I was just mentioning another threat model that has to be considered, and in which MACs do not provide source authentication. (And I guess, you, the authors of this draft, have also considered that threat once because of mentioning TESLA later in section =A74.) Furthermore, I strongly believe that a security requirements document providing a threat analysis must consider *all* possible threats (within the (MPEG-2) network). >>> =A74: all the references to section 2 should be 3 >> Thanx, will modify these. >>> =A74, security requirements list: >>> - instead of "ULE source authentication is required..." should more >>> generally say "integrity protection and authentication is required...= " >> Yes, will change this >>=20 >>> - missing L2 ULE sender and receiver authentication (entitiy authenti= cation) >> This is part of the initial key exchange and authorisation phase =96 i= t is present >> in the requirements lists in section 4 >=20 > Well, it was just my impression, if you mention authorization separatel= y=20 > from key management, you should also mention entity authentication. >=20 >>=20 >> $4, other general requirements list: >> - might mention requirement for policy management >> - integrity of control messages (SI tables): as said before, what we >> want is authentication >=20 >>> =A74, security requirements case 2: >>> - MACs do NOT provide source authentication for cases 2 and 3 (subcas= e (a)) >> The MAC is used to make sure that the data has been sent by the correc= t source =96 >> hence provides source authentication. I am not sure why you say that i= t does not >> provide any source authentication. >=20 > Multiple senders. This is why you want TESLA. > (In multiple sender scenarios MACs can only provide group authenticatio= n.) As explained above, in scenarios where there are multiple senders (or potential other senders) MACs cannot provide source authentication. This is why I suggest to just say authentication. In comparison, digital signatures and TESLA _do_ provide source authentication! Maybe you could rewrite the offending phrase like this: "...new measures need to be implemented such as authentication using Message Authentication Codes, digital signatures, or TESLA [RFC4082]..." >=20 >>> - if mentioning TESLA should first speak of digital signatures >>> (btw, TESLA introduces further latencies at the receiver side and sti= ll >>> requires digital signatures (for signing the head of the hash chains)= ) >> TESLA is only mentioned as an option that may be possible. >=20 >> =A75, first paragraph, last sentence: >> ...impact on bandwidth? >>=20 >> =A75, last list item: >> I don't see how the issue of address preservation is of relevance >> to the ULE scenario. AFAIK address preservation is important for corre= ct=20 >> routing within multicast trees, but since in ULE networks data is simp= ly=20 >> sent from one L2 point to the next I don't understand the problem. >>=20 >> =A76.1, disadvantages: >> third item should probably mean "Encryption of the MAC/NPA address is=20 >> not permitted in MPE systems." >>=20 >> =A76.2: >> - references to section 2 should be 3 >> - information in first paragraph is redundant, i.e. already in the >> requirements section (section 4) >>=20 >> =A77, second paragraph: >> It should better read "There is an optional requirement for L2 >> authentication and integrity assurance as well as protection against >> insertion of other data into the ULE stream (i.e. replay attacks)." I'd be glad if you could shortly reply to each of my comments. Thank you very much in advance! Best regards, Michael From owner-ipdvb@erg.abdn.ac.uk Thu Nov 23 13:04:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIwF-00036l-4w for ipdvb-archive@ietf.org; Thu, 23 Nov 2006 13:04:43 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnIwD-00014U-51 for ipdvb-archive@ietf.org; Thu, 23 Nov 2006 13:04:43 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kANHlJbT028322 for ; Thu, 23 Nov 2006 17:47:19 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kANHlJH1028321 for ipdvb-subscribed-users; Thu, 23 Nov 2006 17:47:19 GMT 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 kANHl2ij028286 for ; Thu, 23 Nov 2006 17:47:02 GMT 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, 23 Nov 2006 17:46:58 +0000 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_01C70F27.5EF0823B" Subject: RE: ULE Security Requirements : NiTs on text Date: Thu, 23 Nov 2006 17:45:49 -0000 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD459@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: <018160DBE8D48349A0CABF4424C3DC21AAD459@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: ULE Security Requirements : NiTs on text Thread-Index: AccNlmtPqg5EFHmJEduHnQAKlc/qXgBkMruE From: To: X-OriginalArrivalTime: 23 Nov 2006 17:46:58.0033 (UTC) FILETIME=[5F4C5E10:01C70F27] 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a This is a multi-part message in MIME format. ------_=_NextPart_001_01C70F27.5EF0823B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gorry, Thanks for the Nits/Comments update. I will change them for the next versio= n (05). =20 Cheers Sunny =20 *********************************************************** Sunil Iyengar, Research Fellow, Networks Group, Centre For Communication And Systems Research(CCSR), School of Electronics, Computing & Mathematics, University Of Surrey, Guildford GU2 7XH, Surrey, England, United Kingdom. Office: +44 (0)1483 686008 *********************************************************** ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst Sent: Tue 21/11/2006 17:56 To: ipdvb@erg.abdn.ac.uk Subject: ULE Security Requirements : NiTs on text Dear authors, I have the following NiTs/Comments on the text. Best wishes, Gorry ---- Page 7: /(e.g. by an Encapsulation Gateway) or other device to/ /(e.g. by an Encapsulation Gateway or other device) to/ ^ -- /these messages are broadcasted/ ^^ /these messages are broadcast/ --- /is out of scope for ULE security/ -- [ID.ule.ext] describes a method where they could be encapsulated using ULE, allowing ULE security methods to also be used in these cases. ---- /eliminates the need to consider/ -- Well you do need to consider them in this document, but securing these elements is an orthogonal issue... --- / The PID associated with an Elementary Stream can be modified / / The PID associated with an Elementary Stream can therefore be modified/ ^^^^^^^^^ --- /a passive threat. It includes/ /a passive threat. This includes/ ^^^^ ---- Section 3.2 -- perhaps a forward pointer to a later section that =B3masquerading and modification=B2 are more difficult on a specific link, than they are in the general internet, and will be described more in section 3. ---- /defines services for Internet Protocol (IP)/ /defines services for the Internet Protocol (IP)/ ^^^ --- /There is an extra overheads associated / /There is an extra transmission overhead associated / ^^^^^^^^^^^^^^^^^^^^^^ - is this what is meant? --- At the end of section 5, I would also like to say that any defined method must also be capable of operating with ULE extension headers - specifically it should allow encryption of a compressed SNDU payload... --- / This method does not preclude the use of IPsec at L3 (or TLS [RFC4346] at L4)./ - True, but I would have preferred to be stronger and continued further to state that IPsec and TLS can provide strong authentication of the end-points in the communication. This authentication is desirable in many scenarios to ensure the information the information is being exchanged between the correct trusted entities. Layer 2 methods can not provide this guarantee. - I=B9d also prefer to break the final para into two,the re-use of established techniques is desirable, but distinct from the advantages of IPsec/TLS, etc. ---- / 2 NPA address. In broadcast networks this can / / 2 NPA address. In broadcast networks this protection can / ^^^^^^^^^^ --- /Case 2 is likely to a lesser degree within certain network configurations./ - Can you provide one of two concrete examples? /Therefore case 3 is not considered further in this document. / - Is it therefore assumed that the MPEG-2 transmission equipment (multiplexors, etc) are secure? I think this was suggested on the list? --- ------_=_NextPart_001_01C70F27.5EF0823B Content-Type: text/plain; name="msg-19534-271.txt" Content-Disposition: attachment; filename="msg-19534-271.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id kANHlJbT028322 Hi Gorry, Thanks for the Nits/Comments update. I will change them for the next vers= ion (05). =20 Cheers Sunny =20 *********************************************************** Sunil Iyengar, Research Fellow, Networks Group, Centre For Communication And Systems Research(CCSR), School of Electronics, Computing & Mathematics, University Of Surrey, Guildford GU2 7XH, Surrey, England, United Kingdom. Office: +44 (0)1483 686008 *********************************************************** ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst Sent: Tue 21/11/2006 17:56 To: ipdvb@erg.abdn.ac.uk Subject: ULE Security Requirements : NiTs on text Dear authors, I have the following NiTs/Comments on the text. Best wishes, Gorry ---- Page 7: /(e.g. by an Encapsulation Gateway) or other device to/ /(e.g. by an Encapsulation Gateway or other device) to/ ^ -- /these messages are broadcasted/ ^^ /these messages are broadcast/ --- /is out of scope for ULE security/ -- [ID.ule.ext] describes a method where they could be encapsulated usin= g ULE, allowing ULE security methods to also be used in these cases. ---- /eliminates the need to consider/ -- Well you do need to consider them in this document, but securing these elements is an orthogonal issue... --- / The PID associated with an Elementary Stream can be modified / / The PID associated with an Elementary Stream can therefore be modified/ ^^^^^^^^^ --- /a passive threat. It includes/ /a passive threat. This includes/ ^^^^ ---- Section 3.2 -- perhaps a forward pointer to a later section that =B3masquerading and modification=B2 are more difficult on a specific link, than they are in t= he general internet, and will be described more in section 3. ---- /defines services for Internet Protocol (IP)/ /defines services for the Internet Protocol (IP)/ ^^^ --- /There is an extra overheads associated / /There is an extra transmission overhead associated / ^^^^^^^^^^^^^^^^^^^^^^ - is this what is meant? --- At the end of section 5, I would also like to say that any defined method must also be capable of operating with ULE extension headers - specifical= ly it should allow encryption of a compressed SNDU payload... --- / This method does not preclude the use of IPsec at L3 (or TLS [RFC4346= ] at L4)./ - True, but I would have preferred to be stronger and continued further = to state that IPsec and TLS can provide strong authentication of the end-points in the communication. This authentication is desirable = in many scenarios to ensure the information the information is being exchanged between the correct trusted entities. Layer 2 methods = can not provide this guarantee. - I=B9d also prefer to break the final para into two,the re-use of established techniques is desirable, but distinct from the advantages of IPsec/TLS, etc. ---- / 2 NPA address. In broadcast networks this can / / 2 NPA address. In broadcast networks this protection can / ^^^^^^^^^^ --- /Case 2 is likely to a lesser degree within certain network configuration= s./ - Can you provide one of two concrete examples? /Therefore case 3 is not considered further in this document. / - Is it therefore assumed that the MPEG-2 transmission equipment (multiplexors, etc) are secure? I think this was suggested on the list? --- ------_=_NextPart_001_01C70F27.5EF0823B-- From owner-ipdvb@erg.abdn.ac.uk Thu Nov 23 13:06:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnIxh-0003bG-4F for ipdvb-archive@ietf.org; Thu, 23 Nov 2006 13:06:13 -0500 Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnIxg-0001pn-1V for ipdvb-archive@ietf.org; Thu, 23 Nov 2006 13:06:13 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id kANHjHqK028189 for ; Thu, 23 Nov 2006 17:45:17 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id kANHjHY7028188 for ipdvb-subscribed-users; Thu, 23 Nov 2006 17:45:17 GMT 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 kANHiwuW027947 for ; Thu, 23 Nov 2006 17:44:58 GMT 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, 23 Nov 2006 17:44:53 +0000 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_01C70F27.14D14281" Subject: RE: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt] Date: Thu, 23 Nov 2006 17:44:53 -0000 Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD458@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: <018160DBE8D48349A0CABF4424C3DC21AAD458@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt] Thread-Index: AccPF8u5WhC6agU1Rn+HIgzTqiPZwQADEo/E From: To: X-OriginalArrivalTime: 23 Nov 2006 17:44:53.0673 (UTC) FILETIME=[152C8990:01C70F27] 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-ERG-MailScanner-To: ipdvb-subscribed-users@dee.erg.abdn.ac.uk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc This is a multi-part message in MIME format. ------_=_NextPart_001_01C70F27.14D14281 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michael, Please find inline the response to your suggestions/ comments. Would like = to point out that this response is with draft version 04 in mind. All chang= es to be made and agreed will be done in the new rev and circulated on this= list. =20 Cheers Sunny ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of Michael Noisternig Sent: Thu 23/11/2006 14:33 To: ipdvb@erg.abdn.ac.uk Subject: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt] Not having got any response to my mail with comments on above mentioned draft from the very authors, I hope to eventually get some feedback by posting the mail on this list. // Sunny Sorry Michael for the delay to reply to your comments. Thank you, Michael -------- Original Message -------- Subject: Comments on draft-cruickshank-ipdvb-sec-req-04.txt Date: Mon, 20 Nov 2006 15:44:12 +0100 From: Michael Noisternig To: P.Pillai@Bradford.ac.uk, h.cruickshank@surrey.ac.uk, S.Iyengar@surrey.ac.uk, Laurence.Duquerroy@space.alcatel.fr Dear security requirements draft authors, sorry for the delay in writing to you in response to the IETF67 meeting. I had originally raised several issues for the 03 revision of the security requirements on the ipdvb mailing list in mid-August. Unfortunately, I couldn't find any of them taken into account for the latest security requirements document, something I brought up in the Jabber forum of the IETF67 meeting where Prashant then suggested to re-send my comments directly to you, the authors of this draft. Below I am citing the relevant parts of my original mail and the one in response to Prashant's comments. Some further comments are placed in-between. > -------- Original Message -------- > Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-= 03.txt > Date: Mon, 14 Aug 2006 17:24:21 +0200 > From: Michael Noisternig > Reply-To: ipdvb@erg.abdn.ac.uk > To: ipdvb@erg.abdn.ac.uk > References: <1155561927.44e079c777a2c@webmail6.brad.ac.uk> > > Hi Prashant, > > thanks for your quick reply. See comments inline. > > P.Pillai@Bradford.ac.uk wrote: >> Hi Michael, > > > >>> =A73.2, last paragraph: >>> - data integrity alone does not provide authentication >>> - the defence statement is oversimplifying and belongs to the >>> requirements section >> //Sunny //Agree with you on that and it ahs been removed from the the current draft= (ver 4). >> Yes, Data integrity is different from data authentication, but the same = MAC can >> be used to provide both data integrity and data authentication. > > Integrity of messages is automatically assured by their correct > authentication, so yes, MACs provide both authentication and integrity. > But you are not speaking about MACs in that paragraph or section. A CRC > or any unkeyed hash provides integrity protection but is certainly not > effective against active adverseries. Data integrity is often used to refer to the protection of data by accidental changes only, such as by CRCs or unkeyed hashes (message digests) in general. As such I'm not too happy with the use of the term data integrity in this document, and would generally prefer the term (message) authentication to explicitly mean protection against both accidental and incidental changes. // Agree that data integrity can be achieved with hashes and CRCs but stron= g cryptographic techinques are needed to avert active threats. Anyway, to section =A73.2: I think you should completely omit the last sentence for the following reasons: - the defense statement is oversimplifying in the following sense: + data integrity/authentication can detect unauthorized modification of messages, but can only partially help to prevent masquerading attacks + sequence numbers are just one (effective) example to counter replay attacks + there is no solution given how to prevent DoS attacks + the sentence reads like these are all the solutions to counter active attacks - =A73 is about analyzing threats, and not requirements, which are handled later in section =A74, and the sentence should be omitted/moved/merged there //Sunny I agree with you that tyhis might be one solution but not THE solution so w= ill omit it from the next version. >>> =A73.3, threat cases 2 and 3: >>> one can distinguish between two other cases: >>> (a) insider attacks, i.e. active attacks from adverseries in the know of >>> certain keys >>> -> protection against this attack requires source authentication >>> (e.g. digitial signatures) >> >> This is more part of key management techniques. An adversary (even if it= knows >> the keys) has to still over-ride the original transmission stream and de= liver a >> modified stream - this is Case 2 as described in the draft. >>> (b) outsider attacks, i.e. active attacks from outside of a VPN >>> -> in this case simple MACs are sufficient (i.e. group authenticat= ion) >> >> Note that the Secure ULE aims to secure only between the ULE encapsulati= on >> gateways and the ULE receivers. > > Well, I speak about the case where a ULE receiver can act as a sender, > i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared > authentication key for MACs) acting as a sender can successfully forge > messages, but not when digital signatures are used (case a). However, a > sender who does not know the MAC key (e.g. because he is not part of the > VPN within the same ULE network) will not be able to forge messages > (case b). > > Note that even when there is only one ULE encapsulator an active > adversary may invalidate the one-sender assumption, and so you again > cannot detect forged messages for case a when MACs are used. Source authentication means corroborating the fact that a message comes from *one specific* sender. A simple MAC can only provide source authentication as long as it is guaranteed that there is only one sender! A one-sender assumption may easily be invalidated by a receiver acting as an active adversary (i.e. an ULE encapsulator). Another scenario is that of meshed networks... how do you know that a message really comes from device x and not y? You can't with simple MACs. An "insider attack" is a valid threat scenario. (Think of a disgruntled employee.) I am fully aware that insider attacks are more unlikely than attacks from outside a VPN (or virtual LAN) within the ULE network, and that most will be fine with group authentication (i.e. MACs). (And there are good other reasons why one would want to stick with MACs.) I was just mentioning another threat model that has to be considered, and in which MACs do not provide source authentication. (And I guess, you, the authors of this draft, have also considered that threat once because of mentioning TESLA later in section =A74.) Furthermore, I strongly believe that a security requirements document providing a threat analysis must consider *all* possible threats (within the (MPEG-2) network). //Sunny Thanks for the discussions between Michael and George Gross. I think the s= ubcases should be included in the new rev to take care of all sub scenarios. =20 >>> =A74: all the references to section 2 should be 3 >> Thanx, will modify these. //Sunny // Done in version 4 of the draft >>> =A74, security requirements list: >>> - instead of "ULE source authentication is required..." should more >>> generally say "integrity protection and authentication is required..." >> Yes, will change this // Sunny Will change to "Integrity protection and authentication of the ULE source i= s required " >> >>> - missing L2 ULE sender and receiver authentication (entitiy authentica= tion) >> This is part of the initial key exchange and authorisation phase - it is= present >> in the requirements lists in section 4 > > Well, it was just my impression, if you mention authorization separately > from key management, you should also mention entity authentication. > /Sunny It does mention L2 Receiver authorisation . WIll change it to L2 entity aut= hentication (user authentication) and replace authorisation with authentica= tion. >> >> $4, other general requirements list: >> - might mention requirement for policy management >> - integrity of control messages (SI tables): as said before, what we >> want is authentication > //Sunny Agree with Policy management. Chenge to Authentication (not data intergrity but message authentication ) = of the control messages. >>> =A74, security requirements case 2: >>> - MACs do NOT provide source authentication for cases 2 and 3 (subcase = (a)) >> The MAC is used to make sure that the data has been sent by the correct = source - >> hence provides source authentication. I am not sure why you say that it = does not >> provide any source authentication. > > Multiple senders. This is why you want TESLA. > (In multiple sender scenarios MACs can only provide group authentication.) As explained above, in scenarios where there are multiple senders (or potential other senders) MACs cannot provide source authentication. This is why I suggest to just say authentication. In comparison, digital signatures and TESLA _do_ provide source authentication! Maybe you could rewrite the offending phrase like this: "...new measures need to be implemented such as authentication using Message Authentication Codes, digital signatures, or TESLA [RFC4082]..." =20 //Sunny Agree with you on rewriting the new phrase as mentioned :) > >>> - if mentioning TESLA should first speak of digital signatures >>> (btw, TESLA introduces further latencies at the receiver side and still >>> requires digital signatures (for signing the head of the hash chains)) >> TESLA is only mentioned as an option that may be possible. > >> =A75, first paragraph, last sentence: >> ...impact on bandwidth? // Done in rev 4 >> >> =A75, last list item: >> I don't see how the issue of address preservation is of relevance >> to the ULE scenario. AFAIK address preservation is important for correct >> routing within multicast trees, but since in ULE networks data is simply >> sent from one L2 point to the next I don't understand the problem. //Sunny // just trying to highlight the workaround in IPSec which is not needed for= ULE and hence trying to bring out the need (or strengthen the case) for UL= E. >> >> =A76.1, disadvantages: >> third item should probably mean "Encryption of the MAC/NPA address is >> not permitted in MPE systems." >> //Sunny Agreed=20 >> =A76.2: >> - references to section 2 should be 3 //Sunny Doner in rev 4 >> - information in first paragraph is redundant, i.e. already in the >> requirements section (section 4) >> //Sunny Remove the last sentence since its repeated. >> =A77, second paragraph: >> It should better read "There is an optional requirement for L2 >> authentication and integrity assurance as well as protection against >> insertion of other data into the ULE stream (i.e. replay attacks)." //Sunny Agreed I'd be glad if you could shortly reply to each of my comments. Thank you very much in advance! Best regards, Michael =20 Thanks for your useful comments. =20 Cheers Sunny ------_=_NextPart_001_01C70F27.14D14281 Content-Type: text/plain; name="msg-22704-191.txt" Content-Disposition: attachment; filename="msg-22704-191.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id kANHjHqK028189 Hi Michael, Please find inline the response to your suggestions/ comments. Would lik= e to point out that this response is with draft version 04 in mind. All c= hanges to be made and agreed will be done in the new rev and circulated o= n this list. =20 Cheers Sunny ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of Michael Noisternig Sent: Thu 23/11/2006 14:33 To: ipdvb@erg.abdn.ac.uk Subject: [Fwd: Comments on draft-cruickshank-ipdvb-sec-req-04.txt] Not having got any response to my mail with comments on above mentioned draft from the very authors, I hope to eventually get some feedback by posting the mail on this list. // Sunny Sorry Michael for the delay to reply to your comments. Thank you, Michael -------- Original Message -------- Subject: Comments on draft-cruickshank-ipdvb-sec-req-04.txt Date: Mon, 20 Nov 2006 15:44:12 +0100 From: Michael Noisternig To: P.Pillai@Bradford.ac.uk, h.cruickshank@surrey.ac.uk, S.Iyengar@surrey.ac.uk, Laurence.Duquerroy@space.alcatel.fr Dear security requirements draft authors, sorry for the delay in writing to you in response to the IETF67 meeting. I had originally raised several issues for the 03 revision of the security requirements on the ipdvb mailing list in mid-August. Unfortunately, I couldn't find any of them taken into account for the latest security requirements document, something I brought up in the Jabber forum of the IETF67 meeting where Prashant then suggested to re-send my comments directly to you, the authors of this draft. Below I am citing the relevant parts of my original mail and the one in response to Prashant's comments. Some further comments are placed in-between. > -------- Original Message -------- > Subject: Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-re= q-03.txt > Date: Mon, 14 Aug 2006 17:24:21 +0200 > From: Michael Noisternig > Reply-To: ipdvb@erg.abdn.ac.uk > To: ipdvb@erg.abdn.ac.uk > References: <1155561927.44e079c777a2c@webmail6.brad.ac.uk> > > Hi Prashant, > > thanks for your quick reply. See comments inline. > > P.Pillai@Bradford.ac.uk wrote: >> Hi Michael, > > > >>> =A73.2, last paragraph: >>> - data integrity alone does not provide authentication >>> - the defence statement is oversimplifying and belongs to the >>> requirements section >> //Sunny //Agree with you on that and it ahs been removed from the the current dra= ft (ver 4). >> Yes, Data integrity is different from data authentication, but the sam= e MAC can >> be used to provide both data integrity and data authentication. > > Integrity of messages is automatically assured by their correct > authentication, so yes, MACs provide both authentication and integrity. > But you are not speaking about MACs in that paragraph or section. A CRC > or any unkeyed hash provides integrity protection but is certainly not > effective against active adverseries. Data integrity is often used to refer to the protection of data by accidental changes only, such as by CRCs or unkeyed hashes (message digests) in general. As such I'm not too happy with the use of the term data integrity in this document, and would generally prefer the term (message) authentication to explicitly mean protection against both accidental and incidental changes. // Agree that data integrity can be achieved with hashes and CRCs but str= ong cryptographic techinques are needed to avert active threats. Anyway, to section =A73.2: I think you should completely omit the last sentence for the following reasons: - the defense statement is oversimplifying in the following sense: + data integrity/authentication can detect unauthorized modification of messages, but can only partially help to prevent masquerading attacks + sequence numbers are just one (effective) example to counter replay attacks + there is no solution given how to prevent DoS attacks + the sentence reads like these are all the solutions to counter active attacks - =A73 is about analyzing threats, and not requirements, which are handle= d later in section =A74, and the sentence should be omitted/moved/merged th= ere //Sunny I agree with you that tyhis might be one solution but not THE solution so= will omit it from the next version. >>> =A73.3, threat cases 2 and 3: >>> one can distinguish between two other cases: >>> (a) insider attacks, i.e. active attacks from adverseries in the know= of >>> certain keys >>> -> protection against this attack requires source authentication >>> (e.g. digitial signatures) >> >> This is more part of key management techniques. An adversary (even if = it knows >> the keys) has to still over-ride the original transmission stream and = deliver a >> modified stream - this is Case 2 as described in the draft. >>> (b) outsider attacks, i.e. active attacks from outside of a VPN >>> -> in this case simple MACs are sufficient (i.e. group authentic= ation) >> >> Note that the Secure ULE aims to secure only between the ULE encapsula= tion >> gateways and the ULE receivers. > > Well, I speak about the case where a ULE receiver can act as a sender, > i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared > authentication key for MACs) acting as a sender can successfully forge > messages, but not when digital signatures are used (case a). However, a > sender who does not know the MAC key (e.g. because he is not part of th= e > VPN within the same ULE network) will not be able to forge messages > (case b). > > Note that even when there is only one ULE encapsulator an active > adversary may invalidate the one-sender assumption, and so you again > cannot detect forged messages for case a when MACs are used. Source authentication means corroborating the fact that a message comes from *one specific* sender. A simple MAC can only provide source authentication as long as it is guaranteed that there is only one sender! A one-sender assumption may easily be invalidated by a receiver acting as an active adversary (i.e. an ULE encapsulator). Another scenario is that of meshed networks... how do you know that a message really comes from device x and not y? You can't with simple MACs. An "insider attack" is a valid threat scenario. (Think of a disgruntled employee.) I am fully aware that insider attacks are more unlikely than attacks from outside a VPN (or virtual LAN) within the ULE network, and that most will be fine with group authentication (i.e. MACs). (And there are good other reasons why one would want to stick with MACs.) I was just mentioning another threat model that has to be considered, and in which MACs do not provide source authentication. (And I guess, you, the authors of this draft, have also considered that threat once because of mentioning TESLA later in section =A74.) Furthermore, I strongly believe that a security requirements document providing a threat analysis must consider *all* possible threats (within the (MPEG-2) network). //Sunny Thanks for the discussions between Michael and George Gross. I think the= subcases should be included in the new rev to take care of all sub scena= rios. =20 >>> =A74: all the references to section 2 should be 3 >> Thanx, will modify these. //Sunny // Done in version 4 of the draft >>> =A74, security requirements list: >>> - instead of "ULE source authentication is required..." should more >>> generally say "integrity protection and authentication is required...= " >> Yes, will change this // Sunny Will change to "Integrity protection and authentication of the ULE source= is required " >> >>> - missing L2 ULE sender and receiver authentication (entitiy authenti= cation) >> This is part of the initial key exchange and authorisation phase - it = is present >> in the requirements lists in section 4 > > Well, it was just my impression, if you mention authorization separatel= y > from key management, you should also mention entity authentication. > /Sunny It does mention L2 Receiver authorisation . WIll change it to L2 entity a= uthentication (user authentication) and replace authorisation with authen= tication. >> >> $4, other general requirements list: >> - might mention requirement for policy management >> - integrity of control messages (SI tables): as said before, what we >> want is authentication > //Sunny Agree with Policy management. Chenge to Authentication (not data intergrity but message authentication = ) of the control messages. >>> =A74, security requirements case 2: >>> - MACs do NOT provide source authentication for cases 2 and 3 (subcas= e (a)) >> The MAC is used to make sure that the data has been sent by the correc= t source - >> hence provides source authentication. I am not sure why you say that i= t does not >> provide any source authentication. > > Multiple senders. This is why you want TESLA. > (In multiple sender scenarios MACs can only provide group authenticatio= n.) As explained above, in scenarios where there are multiple senders (or potential other senders) MACs cannot provide source authentication. This is why I suggest to just say authentication. In comparison, digital signatures and TESLA _do_ provide source authentication! Maybe you could rewrite the offending phrase like this: "...new measures need to be implemented such as authentication using Message Authentication Codes, digital signatures, or TESLA [RFC4082]..." =20 //Sunny Agree with you on rewriting the new phrase as mentioned :) > >>> - if mentioning TESLA should first speak of digital signatures >>> (btw, TESLA introduces further latencies at the receiver side and sti= ll >>> requires digital signatures (for signing the head of the hash chains)= ) >> TESLA is only mentioned as an option that may be possible. > >> =A75, first paragraph, last sentence: >> ...impact on bandwidth? // Done in rev 4 >> >> =A75, last list item: >> I don't see how the issue of address preservation is of relevance >> to the ULE scenario. AFAIK address preservation is important for corre= ct >> routing within multicast trees, but since in ULE networks data is simp= ly >> sent from one L2 point to the next I don't understand the problem. //Sunny // just trying to highlight the workaround in IPSec which is not needed f= or ULE and hence trying to bring out the need (or strengthen the case) fo= r ULE. >> >> =A76.1, disadvantages: >> third item should probably mean "Encryption of the MAC/NPA address is >> not permitted in MPE systems." >> //Sunny Agreed=20 >> =A76.2: >> - references to section 2 should be 3 //Sunny Doner in rev 4 >> - information in first paragraph is redundant, i.e. already in the >> requirements section (section 4) >> //Sunny Remove the last sentence since its repeated. >> =A77, second paragraph: >> It should better read "There is an optional requirement for L2 >> authentication and integrity assurance as well as protection against >> insertion of other data into the ULE stream (i.e. replay attacks)." //Sunny Agreed I'd be glad if you could shortly reply to each of my comments. Thank you very much in advance! Best regards, Michael =20 Thanks for your useful comments. =20 Cheers Sunny ------_=_NextPart_001_01C70F27.14D14281--