From owner-ipdvb@erg.abdn.ac.uk Tue Jan 03 08:20:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etm52-0003Hk-FH for ipdvb-archive@megatron.ietf.org; Tue, 03 Jan 2006 08:20:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22503 for ; Tue, 3 Jan 2006 08:18:45 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtmAI-0002gV-La for ipdvb-archive@ietf.org; Tue, 03 Jan 2006 08:25:28 -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 k03CmMM8002275 for ; Tue, 3 Jan 2006 12:48:22 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k03CmMZ7002274 for ipdvb-subscribed-users; Tue, 3 Jan 2006 12:48:22 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k03CmFAX002257 for ; Tue, 3 Jan 2006 12:48:15 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k03CmEmT005056 for ; Tue, 3 Jan 2006 12:48:14 GMT Received: from bradford.ac.uk (bismuth.cen.brad.ac.uk [143.53.238.79]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k03CmEVb005530 for ; Tue, 3 Jan 2006 12:48:14 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail7.brad.ac.uk (IMP) with HTTP for ; Tue, 03 Jan 2006 12:48:14 +0000 Message-ID: <1136292494.43ba728e4b297@webmail7.brad.ac.uk> Date: Tue, 03 Jan 2006 12:48:14 +0000 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk Subject: MAC/NPA question MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k03CmMM8002275 X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Hi Gorry, I would be grateful if you could help me with the following doubts relate= d to the MAC/NPA address: =95 Section 4.5 in the ULE RFC states that the destination address field = is optional. What is the main reason that drives it? Is it only because ther= e is a higher layer address (e.g. IP address) that can be used for filtering? =95 Is this destination address the MAC address (i.e. the actual physical= hardware address) of the DVB receiver or is any address that is used at layer 2 fo= r identification (i.e. this address can be generated dynamically)? =95 The section also states that =93the destination address would be pres= ent for Unicast IP packets destined to routers that are sent using the shared lin= k (i.e. where the same link connects multiple receivers)=94. Which link is = being referred to here? =95 Does the above case refer to two IP routers connected to a same DVB r= eceiver? Even in this case the DVB receiver would de-capsulated the IP datagram fr= om the ULE packet and could then encapsulate it into an Ethernet frame with the = source Ethernet address being that of the DVB receiver. And an ARP cache can be maintained in the DVB receiver which can used to get the destination MAC address of the router. =95 Am I right in saying that the destination address would not be presen= t in most of the cases (so maybe default case) but would be present for some except= ional cases? Regards Prashant P.S. HAPPY NEW YEAR to all. --=20 Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Tue Jan 03 09:28:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etn9U-0002pH-6j for ipdvb-archive@megatron.ietf.org; Tue, 03 Jan 2006 09:28:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29755 for ; Tue, 3 Jan 2006 09:27:26 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtnEm-0004qN-Ck for ipdvb-archive@ietf.org; Tue, 03 Jan 2006 09:34: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 k03EHgu4007972 for ; Tue, 3 Jan 2006 14:17:42 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k03EHgMm007971 for ipdvb-subscribed-users; Tue, 3 Jan 2006 14:17:42 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k03EHZu0007954 for ; Tue, 3 Jan 2006 14:17:35 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k03EHYho014518; Tue, 3 Jan 2006 14:17:34 GMT Received: from bradford.ac.uk (thallium.cen.brad.ac.uk [143.53.238.78]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k03EHYiZ012582; Tue, 3 Jan 2006 14:17:34 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Tue, 03 Jan 2006 14:17:34 +0000 Message-ID: <1136297854.43ba877e4dde8@webmail6.brad.ac.uk> Date: Tue, 03 Jan 2006 14:17:34 +0000 From: P.Pillai@Bradford.ac.uk To: H.Cruickshank@surrey.ac.uk Cc: ipdvb@erg.abdn.ac.uk Subject: Comments on draft-cruickshank-ipdvb-sec-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k03EHgu4007972 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Hi Haitham, I had a few comments on the document. - What is the main reason to have a temporary MAC/NPA address in the ULE= SID? Is it to prevent traffic analysis? - Section 2.2 of the draft says that =93if the MAC/NPA address is encrypt= ed, then the key management system is responsible for generating this temporary MA= C/NPA address=94. How is this temporary MAC/NPA address generated if not encryp= ted? Also why will this temporary address be even needed if it was not encrypt= ed? It would then just form an extension to the already open destination NPA add= ress, which could still be used for traffic analysis. - This temporary MAC/NPA address seems to be more like a shared secret be= tween the ends than an address, especially because it can be encrypted along wi= th the payload. - Though the text in section 2.2 mentions that the ULE type filed should = be present to define the type of payload carried, but this is not reflected = in the figures. The Figure 1 and 2 should show this type filed to be consistent = with Figure8 of the ULE RFC. Regards Prashant --=20 Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Tue Jan 03 10:17:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etnui-00068h-DO for ipdvb-archive@megatron.ietf.org; Tue, 03 Jan 2006 10:17:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04738 for ; Tue, 3 Jan 2006 10:16:14 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eto00-0006LX-4h for ipdvb-archive@ietf.org; Tue, 03 Jan 2006 10:22: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 k03F3DVZ010990 for ; Tue, 3 Jan 2006 15:03:13 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k03F3DNQ010989 for ipdvb-subscribed-users; Tue, 3 Jan 2006 15:03: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 clyde.ses-astra.com (clyde.ses-astra.com [213.169.104.55]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k03F36HX010971 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 3 Jan 2006 15:03:06 GMT Received: from marge.gen.btz.aia.lu (marge.gen.btz.aia.lu [193.168.96.8]) by clyde.ses-astra.com (8.12.10/8.12.10) with ESMTP id k03F367B009652 for ; Tue, 3 Jan 2006 16:03:06 +0100 (CET) Subject: Joel Grotz is out of office. From: Joel.Grotz@ses-astra.com To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Tue, 3 Jan 2006 16:03:04 +0100 X-MIMETrack: Serialize by Router on marge/BTZ(Release 6.5.4|March 27, 2005) at 03/01/2006 16:03:06 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 I will be out of the office starting 24/12/2005 and will not return until 09/01/2006. If required, I will respond to your message when I return to office. For urgent matters, please contact either: Jens.Krause@ses-astra.com or Jean-Pierre.Choffray@ses-astra.com Best Regards, Joel Grotz SES ASTRA -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. From owner-ipdvb@erg.abdn.ac.uk Wed Jan 04 02:29:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu35n-0004xu-LG for ipdvb-archive@megatron.ietf.org; Wed, 04 Jan 2006 02:29:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21166 for ; Wed, 4 Jan 2006 02:28:40 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu3BE-00041B-BL for ipdvb-archive@ietf.org; Wed, 04 Jan 2006 02:35:32 -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 k04720Uw013129 for ; Wed, 4 Jan 2006 07:02:00 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k047204d013127 for ipdvb-subscribed-users; Wed, 4 Jan 2006 07:02:00 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 k0471oRv013110 for ; Wed, 4 Jan 2006 07:01:50 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id CA39722812B for ; Wed, 4 Jan 2006 08:00:15 +0100 (CET) Message-ID: <43BB72D9.9050509@cosy.sbg.ac.at> Date: Wed, 04 Jan 2006 08:01:45 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: MAC/NPA question References: <1136292494.43ba728e4b297@webmail7.brad.ac.uk> In-Reply-To: <1136292494.43ba728e4b297@webmail7.brad.ac.uk> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=windows-1252 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k04720Uw013129 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Hello Prashant, let me try to answer yuor questions. P.Pillai@Bradford.ac.uk wrote: > Hi Gorry, >=20 > I would be grateful if you could help me with the following doubts rela= ted to > the MAC/NPA address: >=20 > =95 Section 4.5 in the ULE RFC states that the destination address fiel= d is > optional. What is the main reason that drives it? Is it only because th= ere is a > higher layer address (e.g. IP address) that can be used for filtering? Yes, especially for IP-multicast packets this avoids redundant information in the ULE SNDU. In all other cases routers will filter on IP addresses rather anyhow. > =95 Is this destination address the MAC address (i.e. the actual physic= al hardware > address) of the DVB receiver or is any address that is used at layer 2 = for > identification (i.e. this address can be generated dynamically)? This likely depends on implementation. In many/most cases the "actual physical hardware" address will be an IEEE 802 MAC address (even registered) but it may well be another "actual phsyical hardware address" or a software configurable one. > =95 The section also states that =93the destination address would be pr= esent for > Unicast IP packets destined to routers that are sent using the shared l= ink > (i.e. where the same link connects multiple receivers)=94. Which link i= s being > referred to here? The RFC actually says that "the SNDU destination Adress Field MUST be carried for IP unicast destined to routers that are sent using shared links...". Take as an example a SkyPlex system, where all contributing DVB (SCPC or TDMA) uplinks are multiplexed on-board of the satellite into one single downstream and, hence, each router (both DVB-TX and DVB-RX) "sees" each other. In that case a receiving router cannot decide upon the IP address to whom the packet is being routed, so the presence of a destination address field refers to the right router. Rather than filtering (for in end-hosts) this is actually an addressing issue here. > =95 Does the above case refer to two IP routers connected to a same DVB= receiver? Clearly no. See above example. > Even in this case the DVB receiver would de-capsulated the IP datagram = from the > ULE packet and could then encapsulate it into an Ethernet frame with th= e source > Ethernet address being that of the DVB receiver. And an ARP cache can b= e > maintained in the DVB receiver which can used to get the destination MA= C > address of the router. As explained above the issue is neither ARP nor source address filtering. > =95 Am I right in saying that the destination address would not be pres= ent in most > of the cases (so maybe default case) but would be present for some exce= ptional > cases? This is more a question of taste, network topology, transmitter and receiver capabilities, and concrete operational issues/constraints. I personally would agree, also because PID filtering can be used to "segment" DVB links and perform hardware filtering. > Regards > Prashant Regards, Bernhard > P.S. HAPPY NEW YEAR to all. PS: HNY as well. From owner-ipdvb@erg.abdn.ac.uk Wed Jan 04 10:04:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuABF-0002ER-Jc for ipdvb-archive@megatron.ietf.org; Wed, 04 Jan 2006 10:04:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11493 for ; Wed, 4 Jan 2006 10:02:47 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuAGk-0003JQ-8h for ipdvb-archive@ietf.org; Wed, 04 Jan 2006 10:09: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 k04EsJ6d016998 for ; Wed, 4 Jan 2006 14:54:19 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k04EsJmQ016997 for ipdvb-subscribed-users; Wed, 4 Jan 2006 14:54: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 hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k04EsBnr016977 for ; Wed, 4 Jan 2006 14:54:11 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k04EsA1V003335 for ; Wed, 4 Jan 2006 14:54:10 GMT Received: from bradford.ac.uk (thallium.cen.brad.ac.uk [143.53.238.78]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k04EsAHl004779 for ; Wed, 4 Jan 2006 14:54:10 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Wed, 04 Jan 2006 14:54:10 +0000 Message-ID: <1136386450.43bbe1923f605@webmail6.brad.ac.uk> Date: Wed, 04 Jan 2006 14:54:10 +0000 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk Subject: Re: MAC/NPA question In-Reply-To: <43BB72D9.9050509@cosy.sbg.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k04EsJ6d016998 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Hi Bernhard Thank you very much for your prompt reply. So Am I correct in saying that the destination MAC/NPA address in mainly required for on-board processing systems so that the data (between 2 receivers)can be directly routed from the satellite itself, instead of fi= rst sending it to the ground hub and then to the other receiver? Regards Prashant Quoting Bernhard Collini-Nocker : > Hello Prashant, > > let me try to answer yuor questions. > > P.Pillai@Bradford.ac.uk wrote: > > Hi Gorry, > > > > I would be grateful if you could help me with the following doubts re= lated > to > > the MAC/NPA address: > > > > =95 Section 4.5 in the ULE RFC states that the destination address fi= eld is > > optional. What is the main reason that drives it? Is it only because = there > is a > > higher layer address (e.g. IP address) that can be used for filtering= ? > > Yes, especially for IP-multicast packets this avoids redundant > information in the ULE SNDU. In all other cases routers will filter on > IP addresses rather anyhow. > > > =95 Is this destination address the MAC address (i.e. the actual phys= ical > hardware > > address) of the DVB receiver or is any address that is used at layer = 2 for > > identification (i.e. this address can be generated dynamically)? > > This likely depends on implementation. In many/most cases the "actual > physical hardware" address will be an IEEE 802 MAC address (even > registered) but it may well be another "actual phsyical hardware > address" or a software configurable one. > > > =95 The section also states that =93the destination address would be = present > for > > Unicast IP packets destined to routers that are sent using the shared= link > > (i.e. where the same link connects multiple receivers)=94. Which link= is > being > > referred to here? > > > The RFC actually says that "the SNDU destination Adress Field MUST be > carried for IP unicast destined to routers that are sent using shared > links...". > Take as an example a SkyPlex system, where all contributing DVB (SCPC o= r > TDMA) uplinks are multiplexed on-board of the satellite into one single > downstream and, hence, each router (both DVB-TX and DVB-RX) "sees" each > other. In that case a receiving router cannot decide upon the IP addres= s > to whom the packet is being routed, so the presence of a destination > address field refers to the right router. Rather than filtering (for in > end-hosts) this is actually an addressing issue here. > > > =95 Does the above case refer to two IP routers connected to a same D= VB > receiver? > > Clearly no. See above example. > > > Even in this case the DVB receiver would de-capsulated the IP datagra= m from > the > > ULE packet and could then encapsulate it into an Ethernet frame with = the > source > > Ethernet address being that of the DVB receiver. And an ARP cache can= be > > maintained in the DVB receiver which can used to get the destination = MAC > > address of the router. > > As explained above the issue is neither ARP nor source address filterin= g. > > > =95 Am I right in saying that the destination address would not be pr= esent in > most > > of the cases (so maybe default case) but would be present for some > exceptional > > cases? > > This is more a question of taste, network topology, transmitter and > receiver capabilities, and concrete operational issues/constraints. I > personally would agree, also because PID filtering can be used to > "segment" DVB links and perform hardware filtering. > > > Regards > > Prashant > > Regards, > Bernhard > > > P.S. HAPPY NEW YEAR to all. > > PS: HNY as well. > > --=20 Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Thu Jan 05 02:16:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuPMc-0004Rm-8k for ipdvb-archive@megatron.ietf.org; Thu, 05 Jan 2006 02:16:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04329 for ; Thu, 5 Jan 2006 02:15:30 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuPSF-0006Zm-N8 for ipdvb-archive@ietf.org; Thu, 05 Jan 2006 02:22: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 k056sPem021562 for ; Thu, 5 Jan 2006 06:54:25 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k056sPvL021561 for ipdvb-subscribed-users; Thu, 5 Jan 2006 06:54:25 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 k056sFoQ021531 for ; Thu, 5 Jan 2006 06:54:15 GMT Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 1CDF7228165 for ; Thu, 5 Jan 2006 07:52:36 +0100 (CET) Message-ID: <43BCC291.3050502@cosy.sbg.ac.at> Date: Thu, 05 Jan 2006 07:54:09 +0100 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: MAC/NPA question References: <1136386450.43bbe1923f605@webmail6.brad.ac.uk> In-Reply-To: <1136386450.43bbe1923f605@webmail6.brad.ac.uk> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=windows-1252 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k056sPem021562 X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Hello Prashant, P.Pillai@Bradford.ac.uk wrote: > Hi Bernhard >=20 > Thank you very much for your prompt reply. >=20 > So Am I correct in saying that the destination MAC/NPA address in mainl= y > required for on-board processing systems so that the data (between 2 certainly NO. "Taste" cannot easily and objectively be described as good or bad. There are other good reasons to have/use a Destination Address, such as filtering. But, there is no such "mainly required for". What one can say is that the Destination Address can be used for addressing and filtering purposes and there are special cases where it use is mandatory. > receivers)can be directly routed from the satellite itself, instead of = first > sending it to the ground hub and then to the other receiver? The issue here is less whether the routing is on-board or not but the multiplexing of TS streams and layer 2 destination addressing. > Regards > Prashant Regards, Bernhard >=20 > Quoting Bernhard Collini-Nocker : >=20 >=20 >>Hello Prashant, >> >>let me try to answer yuor questions. >> >>P.Pillai@Bradford.ac.uk wrote: >> >>>Hi Gorry, >>> >>>I would be grateful if you could help me with the following doubts rel= ated >> >>to >> >>>the MAC/NPA address: >>> >>>=95 Section 4.5 in the ULE RFC states that the destination address fie= ld is >>>optional. What is the main reason that drives it? Is it only because t= here >> >>is a >> >>>higher layer address (e.g. IP address) that can be used for filtering? >> >>Yes, especially for IP-multicast packets this avoids redundant >>information in the ULE SNDU. In all other cases routers will filter on >>IP addresses rather anyhow. >> >> >>>=95 Is this destination address the MAC address (i.e. the actual physi= cal >> >>hardware >> >>>address) of the DVB receiver or is any address that is used at layer 2= for >>>identification (i.e. this address can be generated dynamically)? >> >>This likely depends on implementation. In many/most cases the "actual >>physical hardware" address will be an IEEE 802 MAC address (even >>registered) but it may well be another "actual phsyical hardware >>address" or a software configurable one. >> >> >>>=95 The section also states that =93the destination address would be p= resent >> >>for >> >>>Unicast IP packets destined to routers that are sent using the shared = link >>>(i.e. where the same link connects multiple receivers)=94. Which link = is >> >>being >> >>>referred to here? >> >> >>The RFC actually says that "the SNDU destination Adress Field MUST be >>carried for IP unicast destined to routers that are sent using shared >>links...". >>Take as an example a SkyPlex system, where all contributing DVB (SCPC o= r >>TDMA) uplinks are multiplexed on-board of the satellite into one single >>downstream and, hence, each router (both DVB-TX and DVB-RX) "sees" each >>other. In that case a receiving router cannot decide upon the IP addres= s >>to whom the packet is being routed, so the presence of a destination >>address field refers to the right router. Rather than filtering (for in >>end-hosts) this is actually an addressing issue here. >> >> >>>=95 Does the above case refer to two IP routers connected to a same DV= B >> >>receiver? >> >>Clearly no. See above example. >> >> >>>Even in this case the DVB receiver would de-capsulated the IP datagram= from >> >>the >> >>>ULE packet and could then encapsulate it into an Ethernet frame with t= he >> >>source >> >>>Ethernet address being that of the DVB receiver. And an ARP cache can = be >>>maintained in the DVB receiver which can used to get the destination M= AC >>>address of the router. >> >>As explained above the issue is neither ARP nor source address filterin= g. >> >> >>>=95 Am I right in saying that the destination address would not be pre= sent in >> >>most >> >>>of the cases (so maybe default case) but would be present for some >> >>exceptional >> >>>cases? >> >>This is more a question of taste, network topology, transmitter and >>receiver capabilities, and concrete operational issues/constraints. I >>personally would agree, also because PID filtering can be used to >>"segment" DVB links and perform hardware filtering. >> >> >>>Regards >>>Prashant >> >>Regards, >>Bernhard >> >> >>>P.S. HAPPY NEW YEAR to all. >> >>PS: HNY as well. >> >> >=20 >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Thu Jan 05 05:23:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuSHD-0006aG-Fh for ipdvb-archive@megatron.ietf.org; Thu, 05 Jan 2006 05:23:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22334 for ; Thu, 5 Jan 2006 05:22:08 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuSMr-00044P-G0 for ipdvb-archive@ietf.org; Thu, 05 Jan 2006 05:29:15 -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 k05A1gVJ004099 for ; Thu, 5 Jan 2006 10:01:42 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k05A1gMC004098 for ipdvb-subscribed-users; Thu, 5 Jan 2006 10:01:42 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.153] (dhcp-207-153.erg.abdn.ac.uk [139.133.207.153]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k05A1bFh004082 for ; Thu, 5 Jan 2006 10:01:37 GMT Message-ID: <43BCEE82.3030405@erg.abdn.ac.uk> Date: Thu, 05 Jan 2006 10:01:38 +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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Subject: RFC RFC4326 on Unidirectional Lightweight Encapsulation (ULE) 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: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Here is a copy of a new RFC announcement for those who may have missed it over the vacation! Thanks to all who contributed text, comments and help with making this happen. Best wishes, Gorry Fairhurst (IETF ipdvb WG Chair) ---- A new Request for Comments is now available in online RFC libraries. RFC 4326 Title: Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) Author(s): G. Fairhurst, B. Collini-Nocker Status: Standards Track Date: December 2005 Mailbox: gorry at erg.abdn.ac.uk, bnocker at cosy.sbg.ac.at Pages: 42 Characters: 95422 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipdvb-ule-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4326.txt The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. This document is a product of the IP Over DVB Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. From owner-ipdvb@erg.abdn.ac.uk Thu Jan 05 05:55:26 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuSmE-00010X-6S for ipdvb-archive@megatron.ietf.org; Thu, 05 Jan 2006 05:55:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25561 for ; Thu, 5 Jan 2006 05:54:11 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuSrt-00051g-N8 for ipdvb-archive@ietf.org; Thu, 05 Jan 2006 06:01:18 -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 k05AUaF1006308 for ; Thu, 5 Jan 2006 10:30:36 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k05AUaBr006307 for ipdvb-subscribed-users; Thu, 5 Jan 2006 10:30:36 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.153] (dhcp-207-153.erg.abdn.ac.uk [139.133.207.153]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k05AUW17006291 for ; Thu, 5 Jan 2006 10:30:32 GMT Message-ID: <43BCF548.9030909@erg.abdn.ac.uk> Date: Thu, 05 Jan 2006 10:30:32 +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: MAC/NPA question References: <1136386450.43bbe1923f605@webmail6.brad.ac.uk> In-Reply-To: <1136386450.43bbe1923f605@webmail6.brad.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k05AUaF1006308 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: quoted-printable See comments in-line. P.Pillai@Bradford.ac.uk wrote: > Hi Bernhard >=20 > Thank you very much for your prompt reply. >=20 > So Am I correct in saying that the destination MAC/NPA address in mainl= y > required for on-board processing systems so that the data (between 2 > receivers)can be directly routed from the satellite itself, instead of = first > sending it to the ground hub and then to the other receiver? >=20 > Regards > Prashant >=20 Traditional MPEG delivery networks (cabled, wireless, whatever) will=20 most usually use a MAC/NPA address to filter the packets that they wish=20 to receive - discriminatling those destined to other receivers that will=20 be filtered in hardware/software/firmware below the IP-level. The mode D=3D0, in which the address is present is specified as the=20 default. RFC4326 states: An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other SNDUs MAY be sent with a D-bit value of 0 or 1. The default method SHOULD use a D-bit value of 0 (see section 4.5). However, when the network segment connected to a Receiver is not=20 connected to other networks - i.e. it is a stub network (common in many=20 current scenarios), the D=3D1 option may be safely used. For multicast,=20 D=3D1 is always "safe". Choice then becomes one of optimisation of resour= ces. So far, I haven't seen a detailed examination of the options for the=20 satellite OBP case. Gorry >=20 > Quoting Bernhard Collini-Nocker : >=20 >=20 >>Hello Prashant, >> >>let me try to answer yuor questions. >> >>P.Pillai@Bradford.ac.uk wrote: >> >>>Hi Gorry, >>> >>>I would be grateful if you could help me with the following doubts rel= ated >> >>to >> >>>the MAC/NPA address: >>> >>>=95 Section 4.5 in the ULE RFC states that the destination address fie= ld is >>>optional. What is the main reason that drives it? Is it only because t= here >> >>is a >> >>>higher layer address (e.g. IP address) that can be used for filtering? >> >>Yes, especially for IP-multicast packets this avoids redundant >>information in the ULE SNDU. In all other cases routers will filter on >>IP addresses rather anyhow. >> >> >>>=95 Is this destination address the MAC address (i.e. the actual physi= cal >> >>hardware >> >>>address) of the DVB receiver or is any address that is used at layer 2= for >>>identification (i.e. this address can be generated dynamically)? >> >>This likely depends on implementation. In many/most cases the "actual >>physical hardware" address will be an IEEE 802 MAC address (even >>registered) but it may well be another "actual phsyical hardware >>address" or a software configurable one. >> >> >>>=95 The section also states that =93the destination address would be p= resent >> >>for >> >>>Unicast IP packets destined to routers that are sent using the shared = link >>>(i.e. where the same link connects multiple receivers)=94. Which link = is >> >>being >> >>>referred to here? >> >> >>The RFC actually says that "the SNDU destination Adress Field MUST be >>carried for IP unicast destined to routers that are sent using shared >>links...". >>Take as an example a SkyPlex system, where all contributing DVB (SCPC o= r >>TDMA) uplinks are multiplexed on-board of the satellite into one single >>downstream and, hence, each router (both DVB-TX and DVB-RX) "sees" each >>other. In that case a receiving router cannot decide upon the IP addres= s >>to whom the packet is being routed, so the presence of a destination >>address field refers to the right router. Rather than filtering (for in >>end-hosts) this is actually an addressing issue here. >> >> >>>=95 Does the above case refer to two IP routers connected to a same DV= B >> >>receiver? >> >>Clearly no. See above example. >> >> >>>Even in this case the DVB receiver would de-capsulated the IP datagram= from >> >>the >> >>>ULE packet and could then encapsulate it into an Ethernet frame with t= he >> >>source >> >>>Ethernet address being that of the DVB receiver. And an ARP cache can = be >>>maintained in the DVB receiver which can used to get the destination M= AC >>>address of the router. >> >>As explained above the issue is neither ARP nor source address filterin= g. >> >> >>>=95 Am I right in saying that the destination address would not be pre= sent in >> >>most >> >>>of the cases (so maybe default case) but would be present for some >> >>exceptional >> >>>cases? >> >>This is more a question of taste, network topology, transmitter and >>receiver capabilities, and concrete operational issues/constraints. I >>personally would agree, also because PID filtering can be used to >>"segment" DVB links and perform hardware filtering. >> >> >>>Regards >>>Prashant >> >>Regards, >>Bernhard >> >> >>>P.S. HAPPY NEW YEAR to all. >> >>PS: HNY as well. >> >> >=20 >=20 >=20 From owner-ipdvb@erg.abdn.ac.uk Tue Jan 10 05:23:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwGec-0002O1-AE for ipdvb-archive@megatron.ietf.org; Tue, 10 Jan 2006 05:23:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19612 for ; Tue, 10 Jan 2006 05:21:43 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwGlG-0003uu-HT for ipdvb-archive@ietf.org; Tue, 10 Jan 2006 05:29: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 k0AA4h5J020032 for ; Tue, 10 Jan 2006 10:04:43 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0AA4hpK020031 for ipdvb-subscribed-users; Tue, 10 Jan 2006 10:04:43 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0AA4ca3020013 for ; Tue, 10 Jan 2006 10:04:38 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0AA4aT1021872 for ; Tue, 10 Jan 2006 10:04:36 GMT Received: from bradford.ac.uk (bismuth.cen.brad.ac.uk [143.53.238.79]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0AA4a7Z024666 for ; Tue, 10 Jan 2006 10:04:36 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail7.brad.ac.uk (IMP) with HTTP for ; Tue, 10 Jan 2006 10:04:36 +0000 Message-ID: <1136887476.43c386b45b30a@webmail7.brad.ac.uk> Date: Tue, 10 Jan 2006 10:04:36 +0000 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk Subject: Typo errors in draft-cruickshank-ipdvb-sec-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id k0AA4h5J020032 X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Hi Haitham, - In Section 2.1, 3rd paragraph: "Another issue is key space there is a n= eed for two database two databases for the...." : This sentence needs to be rephr= ased. Also I don=92t think the two databases addresses any problem with key spa= ce. - If we adopt Also your second option of KeyID and 23-bit MAC/NPA address= would not really remain consistent with the IPSEC SPD/SAD architecture. Do you = think we should explain more about the databases, especially the change (if any= ) from the IPSEC databases? -In Figure 1 and Figure 2, the Length field should no be 2B, it should be= 15 bits Regards Prashant --=20 Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Tue Jan 10 05:48:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwH3i-0008F7-9l for ipdvb-archive@megatron.ietf.org; Tue, 10 Jan 2006 05:48:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21139 for ; Tue, 10 Jan 2006 05:47:38 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHAN-0004dS-AB for ipdvb-archive@ietf.org; Tue, 10 Jan 2006 05:55:52 -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 k0AAdZcQ022504 for ; Tue, 10 Jan 2006 10:39:35 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0AAdZqL022503 for ipdvb-subscribed-users; Tue, 10 Jan 2006 10:39: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 hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0AAdTZD022484; Tue, 10 Jan 2006 10:39:29 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0AAdSVW026426; Tue, 10 Jan 2006 10:39:28 GMT Received: from bradford.ac.uk (bismuth.cen.brad.ac.uk [143.53.238.79]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0AAdSkr029042; Tue, 10 Jan 2006 10:39:28 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail7.brad.ac.uk (IMP) with HTTP for ; Tue, 10 Jan 2006 10:39:28 +0000 Message-ID: <1136889568.43c38ee04aa86@webmail7.brad.ac.uk> Date: Tue, 10 Jan 2006 10:39:28 +0000 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk Cc: Gorry Fairhurst Subject: Network Access Control In-Reply-To: <43BCF548.9030909@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 8bit Hi Gorry, As mentioned in some of the emails before, I think we should look into the network access control methods for the IP services over DVB systems. Though RCST authentication and key exchange mechanisms have been defined by DVB, but authentication of the users behind the RCST may also be important. This may be especially required by the service provider depending on their business models. Do you think it is worthwhile to look into this issue? RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be used for authentication of user terminals. The RCST would have to be a RADIUS Client forwarding the authentication requests to the DVB gateways in the NCC. The DVB gateways act as RADIIUS proxies which further forward the requests to an AAA server. The AAA server would have user profiles. DIAMETER (over TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex protocol with larger overheads as compared to RADIUS, one of its main advantage is its support for mobility. Interaction of these with the RCS security could be an issue say when different users connected to the same RCST (maybe in a cyber cafe) join different multicast groups at different times and the new keys have to be sent to the RCST. The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point for the security services to be provided. But this draft seems to be very specific for securing the ULE packets. Maybe a new ID could address the network access control issue, what do you think? Regards Prashant -- Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Mon Jan 16 07:04:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyT6C-0008Bx-Di for ipdvb-archive@megatron.ietf.org; Mon, 16 Jan 2006 07:04:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06857 for ; Mon, 16 Jan 2006 07:03:12 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyTE6-000625-BR for ipdvb-archive@ietf.org; Mon, 16 Jan 2006 07:12:47 -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 k0GBowtH016334 for ; Mon, 16 Jan 2006 11:50:58 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0GBoweH016333 for ipdvb-subscribed-users; Mon, 16 Jan 2006 11:50: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 k0GBoN0j016300; Mon, 16 Jan 2006 11:50:23 GMT Message-ID: <43CB887B.6050907@erg.abdn.ac.uk> Date: Mon, 16 Jan 2006 11:50:19 +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: P.Pillai@Bradford.ac.uk CC: ipdvb@erg.abdn.ac.uk, "H.Cruickshank" , Stephane Combes , "S.Iyengar" Subject: Re: Network Access Control References: <1136889568.43c38ee04aa86@webmail7.brad.ac.uk> In-Reply-To: <1136889568.43c38ee04aa86@webmail7.brad.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit It is good to hear from you. The security requirements document would certainly benefit from additional contributions. I'll cc this to the authors, and hope they can add their own respones to mine. I'd encourage you to send any contributions you can to the security requirements I-D (to this list), that would be good to start security work. I note that you mention DVB-RCS, examples using a specific technology are always welceome, but please do bear in mind that the document would need to be applicable to a range of MPEG-2 based transmission systems. If you have other thoughts that could be captured on specific topics, it would be worth trying to first set those out in an email, and if you can find others from the group to work on this, a new I-D would be the easiest way to bring the topic to the attention of others. Best wishes, Gorry P.Pillai@Bradford.ac.uk wrote: > Hi Gorry, > > As mentioned in some of the emails before, I think we should look into the > network access control methods for the IP services over DVB systems. Though > RCST authentication and key exchange mechanisms have been defined by DVB, but > authentication of the users behind the RCST may also be important. This may be > especially required by the service provider depending on their business models. > Do you think it is worthwhile to look into this issue? > > RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be used > for authentication of user terminals. The RCST would have to be a RADIUS Client > forwarding the authentication requests to the DVB gateways in the NCC. The DVB > gateways act as RADIIUS proxies which further forward the requests to an AAA > server. The AAA server would have user profiles. DIAMETER (over > TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex > protocol with larger overheads as compared to RADIUS, one of its main advantage > is its support for mobility. > > Interaction of these with the RCS security could be an issue say when different > users connected to the same RCST (maybe in a cyber cafe) join different > multicast groups at different times and the new keys have to be sent to the > RCST. > > The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point for > the security services to be provided. But this draft seems to be very specific > for securing the ULE packets. Maybe a new ID could address the network access > control issue, what do you think? > > Regards > Prashant > > From owner-ipdvb@erg.abdn.ac.uk Wed Jan 18 20:09:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOIy-0005Ye-Gb for ipdvb-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27506 for ; Wed, 18 Jan 2006 20:08:10 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzORP-0007C4-Ej for ipdvb-archive@ietf.org; Wed, 18 Jan 2006 20:18:19 -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 k0J0lXcN009066 for ; Thu, 19 Jan 2006 00:47:33 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0J0lXi8009065 for ipdvb-subscribed-users; Thu, 19 Jan 2006 00:47:33 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0J0lPXk009046; Thu, 19 Jan 2006 00:47:26 GMT Received: from [192.168.1.106] ([151.199.26.24]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0ITB00M20E70P766@vms040.mailsrvcs.net>; Wed, 18 Jan 2006 18:47:24 -0600 (CST) Date: Wed, 18 Jan 2006 19:47:27 -0500 From: Marie-Jose Montpetit Subject: Re: Network Access Control In-reply-to: <1136889568.43c38ee04aa86@webmail7.brad.ac.uk> To: ipdvb@erg.abdn.ac.uk Cc: Gorry Fairhurst Message-id: <43CEE19F.5000403@mjmontpetit.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <1136889568.43c38ee04aa86@webmail7.brad.ac.uk> User-Agent: Thunderbird 1.5 (Macintosh/20051201) X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit P.Pillai@Bradford.ac.uk wrote: > Hi Gorry, > > As mentioned in some of the emails before, I think we should look into the > network access control methods for the IP services over DVB systems. Though > RCST authentication and key exchange mechanisms have been defined by DVB, but > authentication of the users behind the RCST may also be important. This may be > especially required by the service provider depending on their business models. > Do you think it is worthwhile to look into this issue? > > RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be used > for authentication of user terminals. The RCST would have to be a RADIUS Client > forwarding the authentication requests to the DVB gateways in the NCC. The DVB > gateways act as RADIIUS proxies which further forward the requests to an AAA > server. The AAA server would have user profiles. DIAMETER (over > TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex > protocol with larger overheads as compared to RADIUS, one of its main advantage > is its support for mobility. > > Interaction of these with the RCS security could be an issue say when different > users connected to the same RCST (maybe in a cyber cafe) join different > multicast groups at different times and the new keys have to be sent to the > RCST. > > The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point for > the security services to be provided. But this draft seems to be very specific > for securing the ULE packets. Maybe a new ID could address the network access > control issue, what do you think? > > Regards > Prashant > > > Took me a while to respond to this. We have been looking at configuration for a while using SIP based mechanisms like other groups have done. I would link NAC to this. What do you think? /mjm From owner-ipdvb@erg.abdn.ac.uk Wed Jan 18 22:11:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzQCY-0005zO-9G for ipdvb-archive@megatron.ietf.org; Wed, 18 Jan 2006 22:11:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11267 for ; Wed, 18 Jan 2006 22:09:39 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzQKx-0004R8-4p for ipdvb-archive@ietf.org; Wed, 18 Jan 2006 22:19:50 -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 k0J31Rcf018939 for ; Thu, 19 Jan 2006 03:01:27 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0J31R1X018938 for ipdvb-subscribed-users; Thu, 19 Jan 2006 03:01:27 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from notesmta.nera.no (notesmta.nera.no [194.19.8.41]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0J31FpT018866 for ; Thu, 19 Jan 2006 03:01:15 GMT Subject: ! New email for Harald Skinnemoen From: Harald Skinnemoen To: ipdvb@erg.abdn.ac.uk Message-ID: Date: Thu, 19 Jan 2006 04:01:08 +0100 X-MIMETrack: Serialize by Router on NotesMTA/NERA(Release 6.5.3FP1|December 15, 2004) at 2006-01-19 04:01:15 MIME-Version: 1.0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3

I will be out of the office starting 2005-11-03 and will not return until 2006-10-31.

Dear Friends and Academic and Business contacts,

I am moving on to venture my own, new business, and my Nera email address
will soon stop working. I therefore now have a new email address.

However, in order to try and loose some spam on the way there is an
intermediate address to use. Please resend you message to

skinnemoen.nera@gmail.com

and I will reply to your email and give you the correct address to use for
the future.

My GSM number will remain the same as before.

If your email is about NERA Business, please resend to sn@nera.no.

Med best regards,

Dr. Harald Skinnemoen
Managing Director
AnsuR Technologies AS From owner-ipdvb@erg.abdn.ac.uk Thu Jan 19 04:06:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzVka-0001rf-EM for ipdvb-archive@megatron.ietf.org; Thu, 19 Jan 2006 04:06:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02733 for ; Thu, 19 Jan 2006 04:05:09 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzVt5-0006uU-Ay for ipdvb-archive@ietf.org; Thu, 19 Jan 2006 04:15:24 -0500 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0J8pgCs012776 for ; Thu, 19 Jan 2006 08:51:42 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0J8pgbo012775 for ipdvb-subscribed-users; Thu, 19 Jan 2006 08:51:42 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0J8pZ0c012756; Thu, 19 Jan 2006 08:51:35 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0J8pYkK018777; Thu, 19 Jan 2006 08:51:34 GMT Received: from bradford.ac.uk (bismuth.cen.brad.ac.uk [143.53.238.79]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0J8pXOh025828; Thu, 19 Jan 2006 08:51:33 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail7.brad.ac.uk (IMP) with HTTP for ; Thu, 19 Jan 2006 08:51:33 +0000 Message-ID: <1137660693.43cf531580301@webmail7.brad.ac.uk> Date: Thu, 19 Jan 2006 08:51:33 +0000 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk, Marie-Jose Montpetit Cc: Gorry Fairhurst Subject: Re: Network Access Control In-Reply-To: <43CEE19F.5000403@mjmontpetit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 8bit Hi Marie-Jose I have worked with SIP before, and it can provide some very interesting features that may be used here. I am not sure of your approach here though...are you looking into using SIP from user terminal to DVB gateway/Hub (acting as a SIP server or maybe a SIP proxy) for setting up MPEG2 sessions? In this case SIP 200 OK message after authorisation should initiate the rekeying mechanisms. What about setting up multicast sessions - IGMP with SIP? Access control could be used along with this when SIP Invites are sent. We would still need a backend DIAMETER server and interaction between the SIP and DIAMETER servers. There is I-D for diameter application for SIP (draft-ietf-aaa-diameter-sip-app-10) that may be useful. Are you working on an ID for this SIP approach? I would like to contribute something on the access control issues. Regards Prashant Quoting Marie-Jose Montpetit : > P.Pillai@Bradford.ac.uk wrote: > > Hi Gorry, > > > > As mentioned in some of the emails before, I think we should look into the > > network access control methods for the IP services over DVB systems. Though > > RCST authentication and key exchange mechanisms have been defined by DVB, > but > > authentication of the users behind the RCST may also be important. This may > be > > especially required by the service provider depending on their business > models. > > Do you think it is worthwhile to look into this issue? > > > > RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be > used > > for authentication of user terminals. The RCST would have to be a RADIUS > Client > > forwarding the authentication requests to the DVB gateways in the NCC. The > DVB > > gateways act as RADIIUS proxies which further forward the requests to an > AAA > > server. The AAA server would have user profiles. DIAMETER (over > > TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex > > protocol with larger overheads as compared to RADIUS, one of its main > advantage > > is its support for mobility. > > > > Interaction of these with the RCS security could be an issue say when > different > > users connected to the same RCST (maybe in a cyber cafe) join different > > multicast groups at different times and the new keys have to be sent to the > > RCST. > > > > The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point > for > > the security services to be provided. But this draft seems to be very > specific > > for securing the ULE packets. Maybe a new ID could address the network > access > > control issue, what do you think? > > > > Regards > > Prashant > > > > > > > Took me a while to respond to this. We have been looking at > configuration for a while using SIP based mechanisms like other groups > have done. I would link NAC to this. What do you think? > > /mjm > -- Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Thu Jan 19 08:35:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzZwl-0005AR-M5 for ipdvb-archive@megatron.ietf.org; Thu, 19 Jan 2006 08:35:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23028 for ; Thu, 19 Jan 2006 08:34:01 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eza5H-0007ni-QD for ipdvb-archive@ietf.org; Thu, 19 Jan 2006 08:44:17 -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 k0JD71GP001803 for ; Thu, 19 Jan 2006 13:07:01 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0JD71WQ001802 for ipdvb-subscribed-users; Thu, 19 Jan 2006 13:07:01 GMT X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73]) by erg.abdn.ac.uk (8.13.4/8.13.4) with SMTP id k0JD6psp001772 for ; Thu, 19 Jan 2006 13:06:52 GMT Received: (qmail 24525 invoked from network); 19 Jan 2006 13:06:45 -0000 Received: from unknown (HELO gem-wbe03.mesa1.secureserver.net) (64.202.189.35) by smtpout03-03.mesa1.secureserver.net with SMTP; 19 Jan 2006 13:06:45 -0000 Received: (qmail 19506 invoked by uid 99); 19 Jan 2006 13:06:45 -0000 Date: Thu, 19 Jan 2006 06:06:45 -0700 From: Marie-Jose Montpetit Subject: RE: Network Access Control To: ipdvb@erg.abdn.ac.uk Message-ID: <20060119060645.ca5566c7162b3cfcb6c200079b757bd6.d2d88db423.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Originating-IP: 136.182.2.222 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Yes it would be to setup sessions, get addresses, verify authorization etc. I have a now expired draft that did something to start some work and I would not mind reviving it and adding to it. It was part of the "address resolution" part of the charter but getting an address implies a lot of underlying things including access control these days. /mjm > -------- Original Message -------- > Subject: Re: Network Access Control > From: P.Pillai@Bradford.ac.uk > Date: Thu, January 19, 2006 3:51 am > To: ipdvb@erg.abdn.ac.uk, Marie-Jose Montpetit > Cc: Gorry Fairhurst > > Hi Marie-Jose > > I have worked with SIP before, and it can provide some very interesting features > that may be used here. I am not sure of your approach here though...are you > looking into using SIP from user terminal to DVB gateway/Hub (acting as a SIP > server or maybe a SIP proxy) for setting up MPEG2 sessions? In this case SIP 200 > OK message after authorisation should initiate the rekeying mechanisms. What > about setting up multicast sessions - IGMP with SIP? > > Access control could be used along with this when SIP Invites are sent. We would > still need a backend DIAMETER server and interaction between the SIP and > DIAMETER servers. There is I-D for diameter application for SIP > (draft-ietf-aaa-diameter-sip-app-10) that may be useful. > > Are you working on an ID for this SIP approach? I would like to contribute > something on the access control issues. > > Regards > Prashant > > Quoting Marie-Jose Montpetit : > > > P.Pillai@Bradford.ac.uk wrote: > > > Hi Gorry, > > > > > > As mentioned in some of the emails before, I think we should look into the > > > network access control methods for the IP services over DVB systems. Though > > > RCST authentication and key exchange mechanisms have been defined by DVB, > > but > > > authentication of the users behind the RCST may also be important. This may > > be > > > especially required by the service provider depending on their business > > models. > > > Do you think it is worthwhile to look into this issue? > > > > > > RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be > > used > > > for authentication of user terminals. The RCST would have to be a RADIUS > > Client > > > forwarding the authentication requests to the DVB gateways in the NCC. The > > DVB > > > gateways act as RADIIUS proxies which further forward the requests to an > > AAA > > > server. The AAA server would have user profiles. DIAMETER (over > > > TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex > > > protocol with larger overheads as compared to RADIUS, one of its main > > advantage > > > is its support for mobility. > > > > > > Interaction of these with the RCS security could be an issue say when > > different > > > users connected to the same RCST (maybe in a cyber cafe) join different > > > multicast groups at different times and the new keys have to be sent to the > > > RCST. > > > > > > The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point > > for > > > the security services to be provided. But this draft seems to be very > > specific > > > for securing the ULE packets. Maybe a new ID could address the network > > access > > > control issue, what do you think? > > > > > > Regards > > > Prashant > > > > > > > > > > > Took me a while to respond to this. We have been looking at > > configuration for a while using SIP based mechanisms like other groups > > have done. I would link NAC to this. What do you think? > > > > /mjm > > > > > -- > Prashant Pillai > Research Assistant > School of Engineering, Design and Technology > University of Bradford > Bradford, BD7 1DP > West Yorkshire > United Kingdom > Phone: 0044-1274-233720 > email: p.pillai@bradford.ac.uk > ------------------------------------------------------------ > This mail sent through IMP: http://webmail.brad.ac.uk > To report misuse from this email address forward the message > and full headers to misuse@bradford.ac.uk > ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Thu Jan 19 13:53:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeuE-0004PO-MX for ipdvb-archive@megatron.ietf.org; Thu, 19 Jan 2006 13:53:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16021 for ; Thu, 19 Jan 2006 13:51:44 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezf2n-0001M8-TC for ipdvb-archive@ietf.org; Thu, 19 Jan 2006 14:02: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 k0JIbSVL025319 for ; Thu, 19 Jan 2006 18:37:28 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0JIbSfo025318 for ipdvb-subscribed-users; Thu, 19 Jan 2006 18:37: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 hydrogen.cen.brad.ac.uk (hydrogen.cen.brad.ac.uk [143.53.238.3]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0JIbBCp025299 for ; Thu, 19 Jan 2006 18:37:11 GMT Received: from radon.cen.brad.ac.uk (radon.cen.brad.ac.uk [143.53.238.18]) by hydrogen.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0JIbAst004954; Thu, 19 Jan 2006 18:37:11 GMT Received: from bradford.ac.uk (thallium.cen.brad.ac.uk [143.53.238.78]) by radon.cen.brad.ac.uk (8.13.4/8.13.4) with ESMTP id k0JIbAFd028901; Thu, 19 Jan 2006 18:37:10 GMT Received: from d20307.inf.brad.ac.uk (d20307.inf.brad.ac.uk [143.53.31.49]) by webmail6.brad.ac.uk (IMP) with HTTP for ; Thu, 19 Jan 2006 18:37:10 +0000 Message-ID: <1137695830.43cfdc560be3a@webmail6.brad.ac.uk> Date: Thu, 19 Jan 2006 18:37:10 +0000 From: P.Pillai@Bradford.ac.uk To: ipdvb@erg.abdn.ac.uk, Marie-Jose Montpetit Subject: RE: Network Access Control In-Reply-To: <20060119060645.ca5566c7162b3cfcb6c200079b757bd6.d2d88db423.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.7 X-UOBWebMail-Version: IMP3.2.3/TURBA1.2/HORDE2.2.5 X-Originating-IP: 143.53.31.49 X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.3 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 8bit Hi Marie-Jose We could definitely revive the draft. I would be very interested to contribute to it. What is the procedure to go forward? Regards Prashant Quoting Marie-Jose Montpetit : > Yes it would be to setup sessions, get addresses, verify authorization > etc. I have a now expired draft that did something to start some work > and I would not mind reviving it and adding to it. It was part of the > "address resolution" part of the charter but getting an address implies > a lot of underlying things including access control these days. > > /mjm > > > -------- Original Message -------- > > Subject: Re: Network Access Control > > From: P.Pillai@Bradford.ac.uk > > Date: Thu, January 19, 2006 3:51 am > > To: ipdvb@erg.abdn.ac.uk, Marie-Jose Montpetit > > Cc: Gorry Fairhurst > > > > Hi Marie-Jose > > > > I have worked with SIP before, and it can provide some very interesting > features > > that may be used here. I am not sure of your approach here though...are you > > looking into using SIP from user terminal to DVB gateway/Hub (acting as a > SIP > > server or maybe a SIP proxy) for setting up MPEG2 sessions? In this case > SIP 200 > > OK message after authorisation should initiate the rekeying mechanisms. > What > > about setting up multicast sessions - IGMP with SIP? > > > > Access control could be used along with this when SIP Invites are sent. We > would > > still need a backend DIAMETER server and interaction between the SIP and > > DIAMETER servers. There is I-D for diameter application for SIP > > (draft-ietf-aaa-diameter-sip-app-10) that may be useful. > > > > Are you working on an ID for this SIP approach? I would like to contribute > > something on the access control issues. > > > > Regards > > Prashant > > > > Quoting Marie-Jose Montpetit : > > > > > P.Pillai@Bradford.ac.uk wrote: > > > > Hi Gorry, > > > > > > > > As mentioned in some of the emails before, I think we should look into > the > > > > network access control methods for the IP services over DVB systems. > Though > > > > RCST authentication and key exchange mechanisms have been defined by > DVB, > > > but > > > > authentication of the users behind the RCST may also be important. This > may > > > be > > > > especially required by the service provider depending on their business > > > models. > > > > Do you think it is worthwhile to look into this issue? > > > > > > > > RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that > could be > > > used > > > > for authentication of user terminals. The RCST would have to be a > RADIUS > > > Client > > > > forwarding the authentication requests to the DVB gateways in the NCC. > The > > > DVB > > > > gateways act as RADIIUS proxies which further forward the requests to > an > > > AAA > > > > server. The AAA server would have user profiles. DIAMETER (over > > > > TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex > > > > protocol with larger overheads as compared to RADIUS, one of its main > > > advantage > > > > is its support for mobility. > > > > > > > > Interaction of these with the RCS security could be an issue say when > > > different > > > > users connected to the same RCST (maybe in a cyber cafe) join different > > > > multicast groups at different times and the new keys have to be sent to > the > > > > RCST. > > > > > > > > The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting > point > > > for > > > > the security services to be provided. But this draft seems to be very > > > specific > > > > for securing the ULE packets. Maybe a new ID could address the network > > > access > > > > control issue, what do you think? > > > > > > > > Regards > > > > Prashant > > > > > > > > > > > > > > > Took me a while to respond to this. We have been looking at > > > configuration for a while using SIP based mechanisms like other groups > > > have done. I would link NAC to this. What do you think? > > > > > > /mjm > > > > > > > > > -- > > Prashant Pillai > > Research Assistant > > School of Engineering, Design and Technology > > University of Bradford > > Bradford, BD7 1DP > > West Yorkshire > > United Kingdom > > Phone: 0044-1274-233720 > > email: p.pillai@bradford.ac.uk > > ------------------------------------------------------------ > > This mail sent through IMP: http://webmail.brad.ac.uk > > To report misuse from this email address forward the message > > and full headers to misuse@bradford.ac.uk > > ------------------------------------------------------------ > > -- Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai@bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse@bradford.ac.uk ------------------------------------------------------------ From owner-ipdvb@erg.abdn.ac.uk Wed Jan 25 06:22:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1ijn-0001K9-HQ for ipdvb-archive@megatron.ietf.org; Wed, 25 Jan 2006 06:22:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02084 for ; Wed, 25 Jan 2006 06:21:25 -0500 (EST) Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1itM-0004UN-IE for ipdvb-archive@ietf.org; Wed, 25 Jan 2006 06:32:59 -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 k0PAxdoq013234 for ; Wed, 25 Jan 2006 10:59:39 GMT Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k0PAxdnb013233 for ipdvb-subscribed-users; Wed, 25 Jan 2006 10:59: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 uproxy.gmail.com (uproxy.gmail.com [66.249.92.193]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k0PAxT80013214 for ; Wed, 25 Jan 2006 10:59:29 GMT Received: by uproxy.gmail.com with SMTP id m2so117176ugc for ; Wed, 25 Jan 2006 02:59:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:to:cc:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:from; b=LiEPEe/mpyxN5M3cLs9zrZm3xxf/P/7wokIcchLqsfFn9sYEs5fhpyzdz9c5r5OQjo8/QEkzXgLUdpUeUfJ+KrRlZMbNncX/zV75xXeLxr7QRDp6xqQvV/4RSG5dXhNYFgDR+jtGo/qLPoiMJWrj6lDrmsN4036WbG220Ah2fno= Received: by 10.66.222.2 with SMTP id u2mr237662ugg; Wed, 25 Jan 2006 02:59:27 -0800 (PST) Received: from Aceraspire ( [217.167.116.122]) by mx.gmail.com with ESMTP id q40sm344519ugc.2006.01.25.02.59.26; Wed, 25 Jan 2006 02:59:27 -0800 (PST) Message-ID: <014701c6219e$68a37510$7a74a7d9@Aceraspire> To: Cc: "ETSI_BSM" Subject: ETSI BSM New drafts of TS's Date: Wed, 25 Jan 2006 10:59:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 From: robert X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Dear All, The following new draft documents are available on the ETSI BSM (Broadband Satellite Multimedia) page at http://portal.etsi.org/STFs/SES/STF283.asp: 1) Address Management at SI-SAP 2) QoS Functional Architecture 3) General Security Architecture. These have been generated through the work of task force STF283. Your comments on these would be much appreciated by contacting myself or the names given on the Web page. Best Regards Rob Mort