From gorry at erg.abdn.ac.uk Sun Jul 5 08:20:10 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sun, 05 Jul 2009 08:20:10 +0100 Subject: draft-noisternig-ipdvb-sec-ext-00.txt In-Reply-To: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> Message-ID: <4A50542A.20001@erg.abdn.ac.uk> Thanks for this new draft. It is good to see progress on this draft, I have a number of comments on the draft, and some editorial NiTs that I shall send separately. best wishes, Gorry --- Abstract: /The extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses a similar extension header mechanism./ - Is it possible to say this extension header *is* applicable to GSE? --- Para 2 of introduction: /(e.g., satellite mesh systems with on-board processing)./ - As far as I know, this is a property of any mesh network. If so, this could be shortened to /satellite mesh systems/ --- Para 3 of introduction: /This allows them to be used independently and in parallel, and any network layer protocol like IP (even with Ethernet bridging) may be used with the security extension./ - Is it also possible to be used for signaling information? --- Para 5 of introduction: /may benefit from IETF key management protocols, / - It could be worth saying the simplest method is to use pre-shared keys, and this may be appropriate in some important use-cases. --- Page 6 states: /More importantly, from a security point of view, temporary addresses do not provide adequate identity protection, as a passive adversary may easily link different SNDUs to the same connection. Also, a procedure to allocate temporary addresses is required such that they are unique in the system. Hence it is proposed to encrypt the destination address/ - I found this confusing. Does this text need to be in the current draft or could it be moved to a change log or appendix? --- Section 5.8 /It is RECOMMENDED that it has a default size of 12 octets./ - I'm confused by the RFC-2119 keyword here. Does this define a 12 byte default? (it could) Or does this recommend something for which there may be a good reason to make exceptions... I think I do not understand. --- Section 5.8 - What would you suggest for use with GSE, would you also suggest the ISI value was included? --- Section 6 /for multicast settings, for other scenarios of group communication, and also for unidirectional links, where the SPI value has to be centrally selected by a group controller/ - Can you elaborate or remove the following text, currently I do not understand these additional cases: /for other scenarios of group communication/ - Does it have to be centrally selected? - This implies a need for automated key management. ... or is it sufficient to be known at both ends, and hence a pre-shared value could alternatively be used with a static configuration. --- Section 6 / an SAD should only store references to SAs, and reference/ ^^^^^^ - Does this need to be /SHOULD/ i.e. is there a protocol interoperability issue, if other approaches are used? --- Section 6 / This document always requires separate SPs to be defined for incoming and outgoing data, and in turn allows SAs to be shared across several devices, supporting both unidirectional links and group communication./ - These seem like requirements, can this be written using MUST and MAY? --- /The GCKS must be contacted by a device which cannot find an SA for a matching SP, and when the SP does not define a static SID and default key data in its first set of Security Parameters./ - This seems to imply there is always a GCKS? - Should this be prefixed by /When a GCKS is configured, the GCKS must be.../ --- The standards language should be tightened: /must default to the first entry in the list/ ^^^^ - MUST? --- Section 6.3: /the SNDU data must be/ ^^^^ - MUST? --- / and this event should be logged as an invalid/ ^^^^^^ - SHOULD? --- /it must be set up as / ^^^^ - MUST? --- /the device should postpone transmission, or discard the data./ - device, is this the "sender"? - is there a MUST or SHOULD here and in the following sentence? --- /If no new SA is available, a transmitter may still use the current SA during its full lifetime. After that, it must discard the data, and this event should be logged./ - is there a MUST or SHOULD here? --- Point 4. /If the SA requests identity protection, the destination NPA address is omitted from the base header, setting the base header's D bit to 1./ - This seems to be optional, as described earlier. --- /the SNDU is discarded silently./ - /MUST be silently discarded/? --- References: There is a Downref: A Normative reference to Informational RFC 5458. Reference 4 should be informational, since the standard can not rely on an informational draft. === - It would be really helpful to see an appendix (that may be removed by the RFC Editor) that keeps a change log of what has changed in the draft revision. In this case, it would be useful if the authors could provide some inherited history from the drafts that contributed to this combined draft - so that other people reviewing this can see where the work came from. From gorry at erg.abdn.ac.uk Sun Jul 5 09:01:37 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sun, 05 Jul 2009 09:01:37 +0100 Subject: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) In-Reply-To: <4A50542A.20001@erg.abdn.ac.uk> References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> <4A50542A.20001@erg.abdn.ac.uk> Message-ID: <4A505DE1.80009@erg.abdn.ac.uk> Authors, I dent some comments and questions on the draft in a previous email. This email contains a few minor comments on editorial issues, that may improve the next version of this draft. Best wishes, Gorry --- /Another feature provided is called identity protection./ - This reads oddly, I suggest something like: /The method also provides identity protection./ --- /processing continues as usually/ - this should be /continues with the usual processing/, although it would be better to also cite a reference to indicate what this is. --- /On securing the ULE SNDUs, security is provided at the link layer as opposed to existing higher-layer mechanisms like IPsec [8] or TLS [11]. This allows them to be used in/ - This reads oddly. Is it possible to say something like: /This document provides security for ULE SNDUs at the link layer, iin contrast to higher-layer mechanisms, such as IPsec [8] or TLS [11]. This design allows higher-layer mechanisms to be used in/ --- /The security extension may use and benefit f/ - This isn't quite so, you would would need to update these mechanisms, a forward reference to the appropriate section where this is discussed. --- /The ULE security extension is designed to cope with both bi- directional and unidirectional links, as well as unicast and multicast settings./ - Could you replace /to cope with/ by /for/ - This would be a good place to identify the framework [RFC 4259] --- Please add abbreviations: GSE VPN SID etc. --- /Some of the main security services (mandatory or optional) that the security extension for ULE aims to provide are:/ - delete /aims to provide/? and say /provides/? --- /even if it got hold of the transmitted data./ ^^^^^^^^^^^^^^^ - Can you rephrase in more formal English? --- /arguably the most important step on providing/ - Is it possible to say something like: /an important step in providing/ --- /While one solution for this is to use temporary addresses.... - is this text needed? (see other comments). --- Page 6: /digital signatures, may be used in order to assure source/ - I misread this. I don't think this talks about ordering, and so it would be better in this case to remove /in order/. --- / will not be able to derive a correct one./ ^^^^^^^^^^^^^^^^^^^^^^^ - True, it will be statistically hard, bit not impossible. --- Page 7: /received data is recent/ ^^^^^^^^^ - could this be better phrased? --- Page 8: /After the ULE base header, the security extension header follows./ - May be better as: /The security extension header follows the ULE base header./ --- Page 11: / In order to support shared SAs permitting bi-directional communication, an SAD should/ - May be better as: / To support shared SAs for bi-directional communication, an SAD should/ --- / Each set of Security Parameters contains information about:/ - May be better as: / Each set of Security Parameters contains:/ ---- /no security services at all,/ ^^^^^^ - delete /at all/? --- /Note that we do not describe/ - better, perhaps as: /This document does not describe/ --- /, as this is regarded implementation specific details./ - better, perhaps as: /. This is regarded as implementation-specific detail./ --- Section 7.3: / Such protocol should/ ^ - insert /a/. --- /Link-level security is commonly used in broadcast/radio links to supplement end-to-end security, and may not be treated as a substitute./ - A substitute for what? --- /A device may receive data from different MPEG-2 multiplexes, which both may allocate PID values independently./ - cite reference to another RFC? --- References: Some references are uncited, e.g. [5]. It may be helpful to consider citing [10] and [4] as informational background to issues they consider. These are already published and citing them where appropriate would help the reader understand issues that have already been discussed. --- Finally, The following word appears in several place: /Illegitimate/ This has some additional meanings that are not intended here - could you replace by unauthoried or unintended or something similar? From gorry at erg.abdn.ac.uk Mon Jul 6 21:42:46 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 06 Jul 2009 21:42:46 +0100 Subject: IPDVB Provisional Agenda (IETF-75) Message-ID: <4A5261C6.6050408@erg.abdn.ac.uk> Can I remind the group that if people think the ipdvb working group should continue, then they need to tell Martin and me some important topics that need to be addressed - please send email to us or the list. If anyone would like to use a few slides to talk about topics that are important, please let me know, and we can allocate some agenda time. The provisional agenda is at: http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt Best wishes, Gorry Fairhurst (ipdvb Chair) From cabo at tzi.org Mon Jul 6 23:03:13 2009 From: cabo at tzi.org (Carsten Bormann) Date: Tue, 7 Jul 2009 00:03:13 +0200 Subject: IPDVB Provisional Agenda (IETF-75) In-Reply-To: <4A5261C6.6050408@erg.abdn.ac.uk> References: <4A5261C6.6050408@erg.abdn.ac.uk> Message-ID: <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> Sorry about focusing on some other drafts. I can talk about about ROHC for IPDVB. Please give me 15 minutes. I won't have a draft by then -- only two hours left now :-) But I can send an overview to the list before the meeting. I should also say that we have been trying to get a ROHC hallway meeting going; I don't know its current status. IPDVB would fit in there well. Gruesse, Carsten From gorry at erg.abdn.ac.uk Tue Jul 7 07:01:04 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 07 Jul 2009 07:01:04 +0100 Subject: IPDVB Provisional Agenda (IETF-75) In-Reply-To: <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> References: <4A5261C6.6050408@erg.abdn.ac.uk> <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> Message-ID: <4A52E4A0.50509@erg.abdn.ac.uk> Carsten Bormann wrote: > Sorry about focusing on some other drafts. > > I can talk about about ROHC for IPDVB. > Please give me 15 minutes. > I won't have a draft by then -- only two hours left now :-) > But I can send an overview to the list before the meeting. > > I should also say that we have been trying to get a ROHC hallway meeting > going; I don't know its current status. IPDVB would fit in there well. > > Gruesse, Carsten > > Thanks Carsten, It would be good to discuss ROHC over DVB. I've provisionally allocated 15 minutes, we may need to review this if there are more presenters, but for the moment this is fine. Best wishes, Gorry From bnocker at cosy.sbg.ac.at Tue Jul 7 08:00:08 2009 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Tue, 07 Jul 2009 09:00:08 +0200 Subject: IPDVB Provisional Agenda (IETF-75) In-Reply-To: <4A5261C6.6050408@erg.abdn.ac.uk> References: <4A5261C6.6050408@erg.abdn.ac.uk> Message-ID: <4A52F278.8010902@cosy.sbg.ac.at> Dear all, in my opinion there is a need to get rid of the transport stream encapsulated PSI/SI sections/tables in the second generation DVB systems for signaling purposes, especially in those cases where only Generic Stream Encapsulation is being used. Essentially there are two kinds of signaling, one for physical link and network properties, and the other one for services. The latter one is well addressed by all those parties interested in AV/TV/... over IP, whereas the first one is still delt with so-called backward compatibility mode (so TS encapsulated signaling sections). Although ULE/GSE provide an extension header for carrying TS packets, this is a suboptimal choice given that any kind of signaling shall support unidirectional mode of operation and boot strapping of rx-only devices. This is not to propose a solution rather than to point out that there is standardisation work needed in this area. Whether it fits in the ipdvb agenda is to be discussed. Best wishes, Bernhard Gorry Fairhurst schrieb: > > Can I remind the group that if people think the ipdvb working group > should continue, then they need to tell Martin and me some important > topics that need to be addressed - please send email to us or the list. > > If anyone would like to use a few slides to talk about topics that are > important, please let me know, and we can allocate some agenda time. > > The provisional agenda is at: > > http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt > > Best wishes, > > Gorry Fairhurst > (ipdvb Chair) > From cedric.baudoin at thalesaleniaspace.com Tue Jul 7 10:36:33 2009 From: cedric.baudoin at thalesaleniaspace.com (cedric.baudoin at thalesaleniaspace.com) Date: Tue, 7 Jul 2009 11:36:33 +0200 Subject: =?ISO-8859-1?Q?R=E9f=2E_=3A_Re=3A_IPDVB_Provisional_Agenda_=28IETF-75=29?= In-Reply-To: <4A52F278.8010902@cosy.sbg.ac.at> Message-ID: Hi all This is a really important topic. I do agree that a complete revamp of the signaling is a key point if we want to improve the interoperability and to address "all IP satcom systems" (or at least IP friendly ;-) ) Best regards C?dric Baudoin Bernhard Collini-Nocker Pour : ipdvb at erg.abdn.ac.uk Objet : Re: IPDVB Provisional Agenda (IETF-75) Envoy? par : owner-ipdvb at erg. abdn.ac.uk 07/07/2009 09:00 Veuillez r?pondre ? ipdvb Dear all, in my opinion there is a need to get rid of the transport stream encapsulated PSI/SI sections/tables in the second generation DVB systems for signaling purposes, especially in those cases where only Generic Stream Encapsulation is being used. Essentially there are two kinds of signaling, one for physical link and network properties, and the other one for services. The latter one is well addressed by all those parties interested in AV/TV/... over IP, whereas the first one is still delt with so-called backward compatibility mode (so TS encapsulated signaling sections). Although ULE/GSE provide an extension header for carrying TS packets, this is a suboptimal choice given that any kind of signaling shall support unidirectional mode of operation and boot strapping of rx-only devices. This is not to propose a solution rather than to point out that there is standardisation work needed in this area. Whether it fits in the ipdvb agenda is to be discussed. Best wishes, Bernhard Gorry Fairhurst schrieb: > > Can I remind the group that if people think the ipdvb working group > should continue, then they need to tell Martin and me some important > topics that need to be addressed - please send email to us or the list. > > If anyone would like to use a few slides to talk about topics that are > important, please let me know, and we can allocate some agenda time. > > The provisional agenda is at: > > http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt > > Best wishes, > > Gorry Fairhurst > (ipdvb Chair) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic01006.gif Type: image/gif Size: 1255 bytes Desc: not available URL: From marie at mjmontpetit.com Tue Jul 7 12:18:53 2009 From: marie at mjmontpetit.com (Marie-Jose Montpetit) Date: Tue, 7 Jul 2009 07:18:53 -0400 Subject: =?ISO-8859-1?Q?Re:_R=E9f._:_Re:_IPDVB_Provisional_Agenda_=28IETF?= =?ISO-8859-1?Q?-75=29?= In-Reply-To: References: Message-ID: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> Do you mean a complete revamp like in clean slate or just accepting that satellite networks are "just another network" and adopt something done elsewhere in 3GPP or TISPAN? /mjm On Jul 7, 2009, at 5:36 AM, cedric.baudoin at thalesaleniaspace.com wrote: > Hi all > > This is a really important topic. I do agree that a complete revamp > of the signaling is a key point if we want to improve the > interoperability and to address "all IP satcom systems" (or at least > IP friendly ;-) ) > > Best regards > > C?dric Baudoin > > Bernhard Collini-Nocker > > > > > Bernhard Collini-Nocker > Envoy? par : owner-ipdvb at erg.abdn.ac.uk > 07/07/2009 09:00 > Veuillez r?pondre ? ipdvb > > > > Pour : ipdvb at erg.abdn.ac.uk > cc : > Objet : Re: IPDVB Provisional Agenda (IETF-75) > > > Dear all, > > in my opinion there is a need to get rid of the transport stream > encapsulated PSI/SI sections/tables in the second generation DVB > systems > for signaling purposes, especially in those cases where only Generic > Stream Encapsulation is being used. Essentially there are two kinds of > signaling, one for physical link and network properties, and the other > one for services. The latter one is well addressed by all those > parties > interested in AV/TV/... over IP, whereas the first one is still delt > with so-called backward compatibility mode (so TS encapsulated > signaling > sections). Although ULE/GSE provide an extension header for carrying > TS > packets, this is a suboptimal choice given that any kind of signaling > shall support unidirectional mode of operation and boot strapping of > rx-only devices. > > This is not to propose a solution rather than to point out that > there is > standardisation work needed in this area. Whether it fits in the ipdvb > agenda is to be discussed. > > Best wishes, > Bernhard > > Gorry Fairhurst schrieb: > > > > Can I remind the group that if people think the ipdvb working group > > should continue, then they need to tell Martin and me some important > > topics that need to be addressed - please send email to us or the > list. > > > > If anyone would like to use a few slides to talk about topics that > are > > important, please let me know, and we can allocate some agenda time. > > > > The provisional agenda is at: > > > > http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt > > > > Best wishes, > > > > Gorry Fairhurst > > (ipdvb Chair) > > > > > > > > > Marie-Jose Montpetit marie at mjmontpetit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic01006.gif Type: image/gif Size: 1255 bytes Desc: not available URL: From bnocker at cosy.sbg.ac.at Tue Jul 7 14:25:59 2009 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Tue, 7 Jul 2009 15:25:59 +0200 (CEST) Subject: =?ISO-8859-1?Q?Re:_R=E9f._:_Re:_IPDVB_Provisional_Agenda_=28IETF?= =?ISO-8859-1?Q?-75=29?= In-Reply-To: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> References: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> Message-ID: On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: > Do you mean a complete revamp like in clean slate or just accepting that > satellite networks are "just another network" and adopt something done > elsewhere in 3GPP or TISPAN? Perhaps I miss an important detail, but do 3GPP or TISPAN deal with and/or support rx-only devices and boot-strapping of those? > /mjm --Bernhard > On Jul 7, 2009, at 5:36 AM, cedric.baudoin at thalesaleniaspace.com wrote: > >> Hi all >> >> This is a really important topic. I do agree that a complete revamp of the >> signaling is a key point if we want to improve the interoperability and to >> address "all IP satcom systems" (or at least IP friendly ;-) ) >> >> Best regards >> >> C?dric Baudoin >> >> Bernhard Collini-Nocker >> >> >> >> >> Bernhard Collini-Nocker >> Envoy? par : owner-ipdvb at erg.abdn.ac.uk >> 07/07/2009 09:00 >> Veuillez r?pondre ? ipdvb >> >> >> >> Pour : ipdvb at erg.abdn.ac.uk >> cc : Objet : Re: IPDVB Provisional Agenda (IETF-75) >> >> >> Dear all, >> >> in my opinion there is a need to get rid of the transport stream >> encapsulated PSI/SI sections/tables in the second generation DVB systems >> for signaling purposes, especially in those cases where only Generic >> Stream Encapsulation is being used. Essentially there are two kinds of >> signaling, one for physical link and network properties, and the other >> one for services. The latter one is well addressed by all those parties >> interested in AV/TV/... over IP, whereas the first one is still delt >> with so-called backward compatibility mode (so TS encapsulated signaling >> sections). Although ULE/GSE provide an extension header for carrying TS >> packets, this is a suboptimal choice given that any kind of signaling >> shall support unidirectional mode of operation and boot strapping of >> rx-only devices. >> >> This is not to propose a solution rather than to point out that there is >> standardisation work needed in this area. Whether it fits in the ipdvb >> agenda is to be discussed. >> >> Best wishes, >> Bernhard >> >> Gorry Fairhurst schrieb: >>> >>> Can I remind the group that if people think the ipdvb working group >>> should continue, then they need to tell Martin and me some important >>> topics that need to be addressed - please send email to us or the list. >>> >>> If anyone would like to use a few slides to talk about topics that are >>> important, please let me know, and we can allocate some agenda time. >>> >>> The provisional agenda is at: >>> >>> http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt >>> >>> Best wishes, >>> >>> Gorry Fairhurst >>> (ipdvb Chair) >>> >> >> >> >> >> >> >> > > Marie-Jose Montpetit > marie at mjmontpetit.com > > > From marie at mjmontpetit.com Tue Jul 7 14:57:58 2009 From: marie at mjmontpetit.com (Marie-Jose Montpetit) Date: Tue, 7 Jul 2009 09:57:58 -0400 Subject: =?ISO-8859-1?Q?Re:_R=E9f._:_Re:_IPDVB_Provisional_Agenda_=28IETF?= =?ISO-8859-1?Q?-75=29?= In-Reply-To: References: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> Message-ID: <2FA3A0D1-0767-4B7A-8411-AD68A0D46D8B@mjmontpetit.com> No but they support all the rest of the ground infrastructure... I am just saying there are valuable approaches we do not need to re-invent. /mjm On Jul 7, 2009, at 9:25 AM, Bernhard Collini-Nocker wrote: > On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: >> Do you mean a complete revamp like in clean slate or just accepting >> that satellite networks are "just another network" and adopt >> something done elsewhere in 3GPP or TISPAN? > > Perhaps I miss an important detail, but do 3GPP or TISPAN deal with > and/or support rx-only devices and boot-strapping of those? > >> /mjm > > --Bernhard > >> On Jul 7, 2009, at 5:36 AM, cedric.baudoin at thalesaleniaspace.com >> wrote: >> >>> Hi all >>> This is a really important topic. I do agree that a complete >>> revamp of the signaling is a key point if we want to improve the >>> interoperability and to address "all IP satcom systems" (or at >>> least IP friendly ;-) ) >>> Best regards >>> C?dric Baudoin >>> Bernhard Collini-Nocker >>> >>> >>> Bernhard Collini-Nocker >>> Envoy? par : owner-ipdvb at erg.abdn.ac.uk >>> 07/07/2009 09:00 >>> Veuillez r?pondre ? ipdvb >>> >>> Pour : ipdvb at erg.abdn.ac.uk >>> cc : Objet : Re: IPDVB Provisional Agenda (IETF-75) >>> Dear all, >>> in my opinion there is a need to get rid of the transport stream >>> encapsulated PSI/SI sections/tables in the second generation DVB >>> systems >>> for signaling purposes, especially in those cases where only Generic >>> Stream Encapsulation is being used. Essentially there are two >>> kinds of >>> signaling, one for physical link and network properties, and the >>> other >>> one for services. The latter one is well addressed by all those >>> parties >>> interested in AV/TV/... over IP, whereas the first one is still delt >>> with so-called backward compatibility mode (so TS encapsulated >>> signaling >>> sections). Although ULE/GSE provide an extension header for >>> carrying TS >>> packets, this is a suboptimal choice given that any kind of >>> signaling >>> shall support unidirectional mode of operation and boot strapping of >>> rx-only devices. >>> This is not to propose a solution rather than to point out that >>> there is >>> standardisation work needed in this area. Whether it fits in the >>> ipdvb >>> agenda is to be discussed. >>> Best wishes, >>> Bernhard >>> Gorry Fairhurst schrieb: >>>> Can I remind the group that if people think the ipdvb working group >>>> should continue, then they need to tell Martin and me some >>>> important >>>> topics that need to be addressed - please send email to us or the >>>> list. >>>> If anyone would like to use a few slides to talk about topics >>>> that are >>>> important, please let me know, and we can allocate some agenda >>>> time. >>>> The provisional agenda is at: >>>> http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt >>>> Best wishes, >>>> Gorry Fairhurst >>>> (ipdvb Chair) >> >> Marie-Jose Montpetit >> marie at mjmontpetit.com >> >> >> Marie-Jose Montpetit marie at mjmontpetit.com From bnocker at cosy.sbg.ac.at Tue Jul 7 16:11:16 2009 From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker) Date: Tue, 7 Jul 2009 17:11:16 +0200 (CEST) Subject: =?ISO-8859-1?Q?Re:_R=E9f._:_Re:_IPDVB_Provisional_Agenda_=28IETF?= =?ISO-8859-1?Q?-75=29?= In-Reply-To: <2FA3A0D1-0767-4B7A-8411-AD68A0D46D8B@mjmontpetit.com> References: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> <2FA3A0D1-0767-4B7A-8411-AD68A0D46D8B@mjmontpetit.com> Message-ID: Sure, the scope should be well-defined such that there is little or no overlap. On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: > No but they support all the rest of the ground infrastructure... I am just > saying there are valuable approaches we do not need to re-invent. > > /mjm > On Jul 7, 2009, at 9:25 AM, Bernhard Collini-Nocker wrote: > >> On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: >>> Do you mean a complete revamp like in clean slate or just accepting that >>> satellite networks are "just another network" and adopt something done >>> elsewhere in 3GPP or TISPAN? >> >> Perhaps I miss an important detail, but do 3GPP or TISPAN deal with and/or >> support rx-only devices and boot-strapping of those? >> >>> /mjm >> >> --Bernhard >> >>> On Jul 7, 2009, at 5:36 AM, cedric.baudoin at thalesaleniaspace.com wrote: >>> >>>> Hi all >>>> This is a really important topic. I do agree that a complete revamp of >>>> the signaling is a key point if we want to improve the interoperability >>>> and to address "all IP satcom systems" (or at least IP friendly ;-) ) >>>> Best regards >>>> C?dric Baudoin >>>> Bernhard Collini-Nocker >>>> >>>> >>>> Bernhard Collini-Nocker >>>> Envoy? par : owner-ipdvb at erg.abdn.ac.uk >>>> 07/07/2009 09:00 >>>> Veuillez r?pondre ? ipdvb >>>> >>>> Pour : ipdvb at erg.abdn.ac.uk >>>> cc : Objet : Re: IPDVB Provisional Agenda (IETF-75) >>>> Dear all, >>>> in my opinion there is a need to get rid of the transport stream >>>> encapsulated PSI/SI sections/tables in the second generation DVB systems >>>> for signaling purposes, especially in those cases where only Generic >>>> Stream Encapsulation is being used. Essentially there are two kinds of >>>> signaling, one for physical link and network properties, and the other >>>> one for services. The latter one is well addressed by all those parties >>>> interested in AV/TV/... over IP, whereas the first one is still delt >>>> with so-called backward compatibility mode (so TS encapsulated signaling >>>> sections). Although ULE/GSE provide an extension header for carrying TS >>>> packets, this is a suboptimal choice given that any kind of signaling >>>> shall support unidirectional mode of operation and boot strapping of >>>> rx-only devices. >>>> This is not to propose a solution rather than to point out that there is >>>> standardisation work needed in this area. Whether it fits in the ipdvb >>>> agenda is to be discussed. >>>> Best wishes, >>>> Bernhard >>>> Gorry Fairhurst schrieb: >>>>> Can I remind the group that if people think the ipdvb working group >>>>> should continue, then they need to tell Martin and me some important >>>>> topics that need to be addressed - please send email to us or the list. >>>>> If anyone would like to use a few slides to talk about topics that are >>>>> important, please let me know, and we can allocate some agenda time. >>>>> The provisional agenda is at: >>>>> http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt >>>>> Best wishes, >>>>> Gorry Fairhurst >>>>> (ipdvb Chair) >>> >>> Marie-Jose Montpetit >>> marie at mjmontpetit.com >>> >>> >>> > > Marie-Jose Montpetit > marie at mjmontpetit.com > > > From ana.yun at gmail.com Thu Jul 9 08:26:21 2009 From: ana.yun at gmail.com (Ana Yun) Date: Thu, 9 Jul 2009 09:26:21 +0200 Subject: =?ISO-8859-1?Q?Re=3A_R=E9f=2E_=3A_Re=3A_IPDVB_Provisional_Agenda_=28IETF=2D75=29?= In-Reply-To: References: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> <2FA3A0D1-0767-4B7A-8411-AD68A0D46D8B@mjmontpetit.com> Message-ID: <12a215a90907090026t502aea00hfc6f5c9d28869259@mail.gmail.com> Dear all, In or understanding there are two concepts. - The convergence to a global IP network, the NGN concept. For this we can take inputs from3GPP, ITU or TISPAN. - PSI/SI signalling over IP. How we could move all dvb signalling over IP Kind regards, Ana 2009/7/7 Bernhard Collini-Nocker > Sure, the scope should be well-defined such that there is little or no > overlap. > > > On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: > >> No but they support all the rest of the ground infrastructure... I am just >> saying there are valuable approaches we do not need to re-invent. >> >> /mjm >> On Jul 7, 2009, at 9:25 AM, Bernhard Collini-Nocker wrote: >> >> On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: >>> >>>> Do you mean a complete revamp like in clean slate or just accepting that >>>> satellite networks are "just another network" and adopt something done >>>> elsewhere in 3GPP or TISPAN? >>>> >>> >>> Perhaps I miss an important detail, but do 3GPP or TISPAN deal with >>> and/or support rx-only devices and boot-strapping of those? >>> >>> /mjm >>>> >>> >>> --Bernhard >>> >>> On Jul 7, 2009, at 5:36 AM, cedric.baudoin at thalesaleniaspace.com wrote: >>>> >>>> Hi all >>>>> This is a really important topic. I do agree that a complete revamp of >>>>> the signaling is a key point if we want to improve the interoperability and >>>>> to address "all IP satcom systems" (or at least IP friendly ;-) ) >>>>> Best regards >>>>> C?dric Baudoin >>>>> Bernhard Collini-Nocker >>>>> >>>>> >>>>> Bernhard Collini-Nocker >>>>> Envoy? par : owner-ipdvb at erg.abdn.ac.uk >>>>> 07/07/2009 09:00 >>>>> Veuillez r?pondre ? ipdvb >>>>> >>>>> Pour : ipdvb at erg.abdn.ac.uk >>>>> cc : Objet : Re: IPDVB Provisional Agenda (IETF-75) >>>>> Dear all, >>>>> in my opinion there is a need to get rid of the transport stream >>>>> encapsulated PSI/SI sections/tables in the second generation DVB >>>>> systems >>>>> for signaling purposes, especially in those cases where only Generic >>>>> Stream Encapsulation is being used. Essentially there are two kinds of >>>>> signaling, one for physical link and network properties, and the other >>>>> one for services. The latter one is well addressed by all those parties >>>>> interested in AV/TV/... over IP, whereas the first one is still delt >>>>> with so-called backward compatibility mode (so TS encapsulated >>>>> signaling >>>>> sections). Although ULE/GSE provide an extension header for carrying TS >>>>> packets, this is a suboptimal choice given that any kind of signaling >>>>> shall support unidirectional mode of operation and boot strapping of >>>>> rx-only devices. >>>>> This is not to propose a solution rather than to point out that there >>>>> is >>>>> standardisation work needed in this area. Whether it fits in the ipdvb >>>>> agenda is to be discussed. >>>>> Best wishes, >>>>> Bernhard >>>>> Gorry Fairhurst schrieb: >>>>> >>>>>> Can I remind the group that if people think the ipdvb working group >>>>>> should continue, then they need to tell Martin and me some important >>>>>> topics that need to be addressed - please send email to us or the >>>>>> list. >>>>>> If anyone would like to use a few slides to talk about topics that are >>>>>> important, please let me know, and we can allocate some agenda time. >>>>>> The provisional agenda is at: >>>>>> http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt >>>>>> Best wishes, >>>>>> Gorry Fairhurst >>>>>> (ipdvb Chair) >>>>>> >>>>> >>>> Marie-Jose Montpetit >>>> marie at mjmontpetit.com >>>> >>>> >>>> >>>> >> Marie-Jose Montpetit >> marie at mjmontpetit.com >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marie at mjmontpetit.com Thu Jul 9 10:40:29 2009 From: marie at mjmontpetit.com (Marie-Jose Montpetit) Date: Thu, 9 Jul 2009 05:40:29 -0400 Subject: =?ISO-8859-1?Q?Re:_R=E9f._:_Re:_IPDVB_Provisional_Agenda_=28IETF?= =?ISO-8859-1?Q?-75=29?= In-Reply-To: <12a215a90907090026t502aea00hfc6f5c9d28869259@mail.gmail.com> References: <0145E0FE-D6F9-449A-AA3E-CFA1B4CF00C7@mjmontpetit.com> <2FA3A0D1-0767-4B7A-8411-AD68A0D46D8B@mjmontpetit.com> <12a215a90907090026t502aea00hfc6f5c9d28869259@mail.gmail.com> Message-ID: <0A2AE7AD-C041-4F02-9E18-520D4D2D1894@mjmontpetit.com> I agree... On Jul 9, 2009, at 3:26 AM, Ana Yun wrote: > Dear all, > > In or understanding there are two concepts. > - The convergence to a global IP network, the NGN concept. For this > we can take inputs from3GPP, ITU or TISPAN. > - PSI/SI signalling over IP. How we could move all dvb signalling > over IP > > > Kind regards, > Ana > > 2009/7/7 Bernhard Collini-Nocker > Sure, the scope should be well-defined such that there is little or > no overlap. > > > On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: > No but they support all the rest of the ground infrastructure... I > am just saying there are valuable approaches we do not need to re- > invent. > > /mjm > On Jul 7, 2009, at 9:25 AM, Bernhard Collini-Nocker wrote: > > On Tue, 7 Jul 2009, Marie-Jose Montpetit wrote: > Do you mean a complete revamp like in clean slate or just accepting > that satellite networks are "just another network" and adopt > something done elsewhere in 3GPP or TISPAN? > > Perhaps I miss an important detail, but do 3GPP or TISPAN deal with > and/or support rx-only devices and boot-strapping of those? > > /mjm > > --Bernhard > > On Jul 7, 2009, at 5:36 AM, cedric.baudoin at thalesaleniaspace.com > wrote: > > Hi all > This is a really important topic. I do agree that a complete revamp > of the signaling is a key point if we want to improve the > interoperability and to address "all IP satcom systems" (or at least > IP friendly ;-) ) > Best regards > C?dric Baudoin > Bernhard Collini-Nocker > > > Bernhard Collini-Nocker > Envoy? par : owner-ipdvb at erg.abdn.ac.uk > 07/07/2009 09:00 > Veuillez r?pondre ? ipdvb > > Pour : ipdvb at erg.abdn.ac.uk > cc : Objet : Re: IPDVB Provisional Agenda (IETF-75) > Dear all, > in my opinion there is a need to get rid of the transport stream > encapsulated PSI/SI sections/tables in the second generation DVB > systems > for signaling purposes, especially in those cases where only Generic > Stream Encapsulation is being used. Essentially there are two kinds of > signaling, one for physical link and network properties, and the other > one for services. The latter one is well addressed by all those > parties > interested in AV/TV/... over IP, whereas the first one is still delt > with so-called backward compatibility mode (so TS encapsulated > signaling > sections). Although ULE/GSE provide an extension header for carrying > TS > packets, this is a suboptimal choice given that any kind of signaling > shall support unidirectional mode of operation and boot strapping of > rx-only devices. > This is not to propose a solution rather than to point out that > there is > standardisation work needed in this area. Whether it fits in the ipdvb > agenda is to be discussed. > Best wishes, > Bernhard > Gorry Fairhurst schrieb: > Can I remind the group that if people think the ipdvb working group > should continue, then they need to tell Martin and me some important > topics that need to be addressed - please send email to us or the > list. > If anyone would like to use a few slides to talk about topics that are > important, please let me know, and we can allocate some agenda time. > The provisional agenda is at: > http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt > Best wishes, > Gorry Fairhurst > (ipdvb Chair) > > Marie-Jose Montpetit > marie at mjmontpetit.com > > > > > Marie-Jose Montpetit > marie at mjmontpetit.com > > > Marie-Jose Montpetit marie at mjmontpetit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnoist at cosy.sbg.ac.at Fri Jul 10 14:56:06 2009 From: mnoist at cosy.sbg.ac.at (Michael Noisternig) Date: Fri, 10 Jul 2009 15:56:06 +0200 Subject: draft-noisternig-ipdvb-sec-ext-00.txt In-Reply-To: <4A50542A.20001@erg.abdn.ac.uk> References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> <4A50542A.20001@erg.abdn.ac.uk> Message-ID: <4A574876.9010108@cosy.sbg.ac.at> Hi Gorry, many thanks for reviewing the draft. Please see some questions/comments inline. Michael Gorry Fairhurst schrieb: > Thanks for this new draft. It is good to see progress on this draft, I > have a number of comments on the draft, and some editorial NiTs that I > shall send separately. > > best wishes, > > Gorry > --- > > Abstract: > /The extension may be easily adapted to the Generic Stream Encapsulation > (GSE) protocol, which uses a similar extension header mechanism./ > - Is it possible to say this extension header *is* applicable to GSE? Well, the extension /header/ is directly applicable to GSE, but the processing described in the document has to be adapted, such as replacing PID by ISI, and taking the 3-byte label into account. So I'd prefer saying 'it may be easily adapted'. > --- > Para 2 of introduction: > /(e.g., satellite mesh systems with on-board processing)./ > - As far as I know, this is a property of any mesh network. If so, this > could be shortened to /satellite mesh systems/ Ok. > --- > Para 3 of introduction: > /This allows them to be used independently and in parallel, and > any network layer protocol like IP (even with Ethernet bridging) may > be used with the security extension./ > - Is it also possible to be used for signaling information? I'm not sure what you mean. Are you asking whether the extension can secure L2 signalling information? If so, we may add something like: 'Link-layer signalling information may be protected as well.' > --- > Para 5 of introduction: > /may benefit from IETF key management protocols, / > - It could be worth saying the simplest method is to use pre-shared > keys, and this may be appropriate in some important use-cases. Agreed. > --- > Page 6 states: > /More importantly, from a > security point of view, temporary addresses do not provide > adequate identity protection, as a passive adversary may easily > link different SNDUs to the same connection. Also, a procedure to > allocate temporary addresses is required such that they are unique > in the system. Hence it is proposed to encrypt the destination > address/ > - I found this confusing. Does this text need to be in the current draft > or could it be moved to a change log or appendix? I was also wondering. We will discuss that. > --- > Section 5.8 > /It is RECOMMENDED that it has a default size of 12 octets./ > - I'm confused by the RFC-2119 keyword here. Does this define a 12 byte > default? (it could) Or does this recommend something for which there may > be a good reason to make exceptions... I think I do not understand. This is left over from the old draft. It suggests MAC sizes to comply to the de-facto standard IPsec MAC sizes of 96 bits. However, given that we allow other authentication mechanisms (e.g., TESLA), and we do not define any algorithms in the document, I will remove the sentence. > --- > Section 5.8 > - What would you suggest for use with GSE, would you also suggest the > ISI value was included? Yes, for GSE we would take the ISI. I'm not sure whether we should point this out since we are primarily defining for ULE, and in the introduction/abstract we are saying that the extension may be /adapated/ to GSE. > --- > Section 6 > /for multicast settings, for other > scenarios of group communication, and also for unidirectional links, > where the SPI value has to be centrally selected by a group > controller/ > - Can you elaborate or remove the following text, currently I do not > understand these additional cases: /for other scenarios of group > communication/ I will replace with 'multi-sender shared SA scenarios'. It should be more clear in this wording since that is used below. > - Does it have to be centrally selected? - This implies a need for > automated key management. ... or is it sufficient to be known at both Yes, this is talking about automated key management. I will clarify this. > ends, and hence a pre-shared value could alternatively be used with a > static configuration. > --- > Section 6 > / an SAD should only store references to SAs, and reference/ > ^^^^^^ > - Does this need to be /SHOULD/ i.e. is there a protocol > interoperability issue, if other approaches are used? Hm, the intention was to rather say duplication efforts could be avoided if references are stored. I will rephrase to 'To support shared SAs permitting bi-directional communication and avoid the effort of duplicating SAs, an SAD may store references to SAs, and reference bi-directional SAs in both the incoming and outgoing SAD.' > --- > Section 6 > / This document always requires > separate SPs to be defined for incoming and outgoing data, and in > turn allows SAs to be shared across several devices, supporting both > unidirectional links and group communication./ > - These seem like requirements, can this be written using MUST and MAY? These are kinda requirements. An implementation may 'optimise' certain configurations, and e.g. define a bi-directional SP where appropriate. The point is that the behaviour to the outside must comply. So I suggest not using RFC2119 keywords (for now). > --- > /The GCKS must be contacted by a device which > cannot find an SA for a matching SP, and when the SP does not > define a static SID and default key data in its first set of > Security Parameters./ > - This seems to imply there is always a GCKS? > - Should this be prefixed by /When a GCKS is configured, the GCKS must > be.../ Agreed. > --- > > The standards language should be tightened: > > /must default to the first entry in the list/ > ^^^^ > - MUST? Agreed. These RFC2119 keywords got "lost" in copying to a paper and back. > --- > Point 4. > /If the SA requests > identity protection, the destination NPA address is omitted > from the base header, setting the base header's D bit to 1./ > - This seems to be optional, as described earlier. I suggest concluding the sentence with '(though another label may be re-inserted, see section 5.2)'. > --- > References: > > There is a Downref: A Normative reference to Informational RFC 5458. > Reference 4 should be informational, since the standard can not rely on > an informational draft. Right. Will correct this. > > === > > - It would be really helpful to see an appendix (that may be removed by > the RFC Editor) that keeps a change log of what has changed in the draft > revision. In this case, it would be useful if the authors could provide > some inherited history from the drafts that contributed to this combined > draft - so that other people reviewing this can see where the work came > from. > > > > > > > From mnoist at cosy.sbg.ac.at Fri Jul 10 14:57:00 2009 From: mnoist at cosy.sbg.ac.at (Michael Noisternig) Date: Fri, 10 Jul 2009 15:57:00 +0200 Subject: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) In-Reply-To: <4A505DE1.80009@erg.abdn.ac.uk> References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> <4A50542A.20001@erg.abdn.ac.uk> <4A505DE1.80009@erg.abdn.ac.uk> Message-ID: <4A5748AC.8070402@cosy.sbg.ac.at> Hi Gorry, thanks again. Please see a few comments inline. Michael Gorry Fairhurst schrieb: > > Authors, I dent some comments and questions on the draft in a previous > email. This email contains a few minor comments on editorial issues, > that may improve the next version of this draft. > > Best wishes, > > Gorry > > --- > /Another feature provided is called identity protection./ > - This reads oddly, I suggest something like: > /The method also provides identity protection./ The problem was that 'identity protection' normally refers to something else. How about "The extension also supports what is called 'identity protection' in this specification."? Any better suggestion? > --- > /processing continues as usually/ > - this should be /continues with the usual processing/, although it > would be better to also cite a reference to indicate what this is. > > --- > /On securing the ULE SNDUs, security is provided at the link layer as > opposed to existing higher-layer mechanisms like IPsec [8] or TLS > [11]. This allows them to be used in/ > - This reads oddly. Is it possible to say something like: > /This document provides security for ULE SNDUs at the link layer, iin > contrast to higher-layer mechanisms, such as IPsec [8] or TLS > [11]. This design allows higher-layer mechanisms to be used in/ > --- > /The security extension may use and benefit f/ > - This isn't quite so, you would would need to update these mechanisms, > a forward reference to the appropriate section where this is discussed. I agree. We may remove that, and instead add the following paragraph after the one talking about the processing: "Key management protocols assuming similar processing functionality, such as the MSEC Group Domain of Interpretation (GDOI) [9] and the Group Secure Association Key Management Protocol (GSAKMP) [7], may be adapted for the ULE scenario. Simple configurations are supported using manual keying (i.e., pre-shared keys)." Is this more clear, should we still provide a forward reference? > --- > /The ULE security extension is designed to cope with both bi- > directional and unidirectional links, as well as unicast and > multicast settings./ > - Could you replace /to cope with/ by /for/ > - This would be a good place to identify the framework [RFC 4259] > --- > Please add abbreviations: > GSE > VPN > SID > etc. > --- > /Some of the main security services > (mandatory or optional) that the security extension for ULE aims to > provide are:/ > - delete /aims to provide/? and say /provides/? > --- > /even if it got hold of the transmitted data./ > ^^^^^^^^^^^^^^^ > - Can you rephrase in more formal English? > --- > /arguably the most important step on providing/ > - Is it possible to say something like: > /an important step in providing/ > --- > /While one > solution for this is to use temporary addresses.... > - is this text needed? (see other comments). > --- > Page 6: > /digital signatures, may be used in order to assure source/ > - I misread this. I don't think this talks about ordering, and so it > would be better in this case to remove /in order/. > --- > / will not be able to derive a correct one./ > ^^^^^^^^^^^^^^^^^^^^^^^ > - True, it will be statistically hard, bit not impossible. ...will unlikely be able to derive a correct one. Or we might introduce (in)feasibility. ;) > --- > Page 7: > /received data is recent/ > ^^^^^^^^^ > - could this be better phrased? ...fresh? > --- > Page 8: > /After the ULE base header, the security extension header follows./ > - May be better as: > /The security extension header follows the ULE base header./ > --- > Page 11: > / In order to support > shared SAs permitting bi-directional communication, an SAD should/ > - May be better as: > / To support shared SAs for bi-directional communication, an SAD should/ > --- > / Each set of Security Parameters contains information about:/ > - May be better as: > / Each set of Security Parameters contains:/ > ---- > /no security services at all,/ > ^^^^^^ > - delete /at all/? > --- > /Note that we do not describe/ > - better, perhaps as: > /This document does not describe/ > --- > /, as this is regarded implementation specific details./ > - better, perhaps as: > /. This is regarded as implementation-specific detail./ > --- > Section 7.3: > / Such protocol should/ > ^ > - insert /a/. > --- > /Link-level security is commonly used in broadcast/radio links to > supplement end-to-end security, and may not be treated as a > substitute./ > - A substitute for what? > --- > /A device may receive data from different MPEG-2 > multiplexes, which both may allocate PID values independently./ > - cite reference to another RFC? > > --- > References: > > Some references are uncited, e.g. [5]. > > It may be helpful to consider citing [10] and [4] as informational > background to issues they consider. These are already published and > citing them where appropriate would help the reader understand issues > that have already been discussed. > > --- > > Finally, > The following word appears in several place: /Illegitimate/ This has > some additional meanings that are not intended here - could you replace > by unauthoried or unintended or something similar? I agree with all other suggestions. From gorry at erg.abdn.ac.uk Sat Jul 11 21:16:10 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sat, 11 Jul 2009 21:16:10 +0100 Subject: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) In-Reply-To: <4A5748AC.8070402@cosy.sbg.ac.at> References: <1244702672.4a30a7d0b5839@webmail.brad.ac.uk> <4A50542A.20001@erg.abdn.ac.uk> <4A505DE1.80009@erg.abdn.ac.uk> <4A5748AC.8070402@cosy.sbg.ac.at> Message-ID: <4A58F30A.3030807@erg.abdn.ac.uk> See in-line, Gorry Michael Noisternig wrote: > Hi Gorry, > > thanks again. Please see a few comments inline. > > Michael > > Gorry Fairhurst schrieb: >> >> Authors, I dent some comments and questions on the draft in a previous >> email. This email contains a few minor comments on editorial issues, >> that may improve the next version of this draft. >> >> Best wishes, >> >> Gorry >> >> --- >> /Another feature provided is called identity protection./ >> - This reads oddly, I suggest something like: >> /The method also provides identity protection./ > > The problem was that 'identity protection' normally refers to something > else. How about > "The extension also supports what is called 'identity protection' in > this specification."? > Any better suggestion? > Sounds fine to me. >> --- >> /processing continues as usually/ >> - this should be /continues with the usual processing/, although it >> would be better to also cite a reference to indicate what this is. >> >> --- >> /On securing the ULE SNDUs, security is provided at the link layer as >> opposed to existing higher-layer mechanisms like IPsec [8] or TLS >> [11]. This allows them to be used in/ >> - This reads oddly. Is it possible to say something like: >> /This document provides security for ULE SNDUs at the link layer, iin >> contrast to higher-layer mechanisms, such as IPsec [8] or TLS >> [11]. This design allows higher-layer mechanisms to be used in/ >> --- >> /The security extension may use and benefit f/ >> - This isn't quite so, you would would need to update these >> mechanisms, a forward reference to the appropriate section where this >> is discussed. > > I agree. We may remove that, and instead add the following paragraph > after the one talking about the processing: > > "Key management protocols assuming similar processing functionality, > such as the MSEC Group Domain of Interpretation (GDOI) [9] and the Group > Secure Association Key Management Protocol (GSAKMP) [7], may be adapted > for the ULE scenario. Simple configurations are supported using manual > keying (i.e., pre-shared keys)." > > Is this more clear, should we still provide a forward reference? > Also seems good. >> --- >> /The ULE security extension is designed to cope with both bi- >> directional and unidirectional links, as well as unicast and >> multicast settings./ >> - Could you replace /to cope with/ by /for/ >> - This would be a good place to identify the framework [RFC 4259] >> --- >> Please add abbreviations: >> GSE >> VPN >> SID >> etc. >> --- >> /Some of the main security services >> (mandatory or optional) that the security extension for ULE aims to >> provide are:/ >> - delete /aims to provide/? and say /provides/? >> --- >> /even if it got hold of the transmitted data./ >> ^^^^^^^^^^^^^^^ >> - Can you rephrase in more formal English? >> --- >> /arguably the most important step on providing/ >> - Is it possible to say something like: >> /an important step in providing/ >> --- >> /While one >> solution for this is to use temporary addresses.... >> - is this text needed? (see other comments). >> --- >> Page 6: >> /digital signatures, may be used in order to assure source/ >> - I misread this. I don't think this talks about ordering, and so it >> would be better in this case to remove /in order/. >> --- >> / will not be able to derive a correct one./ >> ^^^^^^^^^^^^^^^^^^^^^^^ >> - True, it will be statistically hard, bit not impossible. > > ...will unlikely be able to derive a correct one. > That would be OK. > Or we might introduce (in)feasibility. ;) > >> --- >> Page 7: >> /received data is recent/ >> ^^^^^^^^^ >> - could this be better phrased? > > ...fresh? > I'm not sure what would be best. I think I'd expect within a specified time interval. or "recently received", or something >> --- >> Page 8: >> /After the ULE base header, the security extension header follows./ >> - May be better as: >> /The security extension header follows the ULE base header./ >> --- >> Page 11: >> / In order to support >> shared SAs permitting bi-directional communication, an SAD should/ >> - May be better as: >> / To support shared SAs for bi-directional communication, an SAD should/ >> --- >> / Each set of Security Parameters contains information about:/ >> - May be better as: >> / Each set of Security Parameters contains:/ >> ---- >> /no security services at all,/ >> ^^^^^^ >> - delete /at all/? >> --- >> /Note that we do not describe/ >> - better, perhaps as: >> /This document does not describe/ >> --- >> /, as this is regarded implementation specific details./ >> - better, perhaps as: >> /. This is regarded as implementation-specific detail./ >> --- >> Section 7.3: >> / Such protocol should/ >> ^ >> - insert /a/. >> --- >> /Link-level security is commonly used in broadcast/radio links to >> supplement end-to-end security, and may not be treated as a >> substitute./ >> - A substitute for what? >> --- >> /A device may receive data from different MPEG-2 >> multiplexes, which both may allocate PID values independently./ >> - cite reference to another RFC? >> >> --- >> References: >> >> Some references are uncited, e.g. [5]. >> >> It may be helpful to consider citing [10] and [4] as informational >> background to issues they consider. These are already published and >> citing them where appropriate would help the reader understand issues >> that have already been discussed. >> >> --- >> >> Finally, >> The following word appears in several place: /Illegitimate/ This has >> some additional meanings that are not intended here - could you >> replace by unauthoried or unintended or something similar? > > I agree with all other suggestions. > > From mnoist at cosy.sbg.ac.at Mon Jul 13 19:21:49 2009 From: mnoist at cosy.sbg.ac.at (Michael Noisternig) Date: Mon, 13 Jul 2009 20:21:49 +0200 Subject: [Fwd: New Version Notification for draft-noisternig-ipdvb-sec-ext-01] Message-ID: <4A5B7B3D.6010209@cosy.sbg.ac.at> Dear all, please see enclosed the notification message for an update of our ULE security extension draft based on Gorry's comments. Thanks again! Michael -------------- next part -------------- An embedded message was scrubbed... From: IETF I-D Submission Tool Subject: New Version Notification for draft-noisternig-ipdvb-sec-ext-01 Date: Mon, 13 Jul 2009 08:43:50 -0700 (PDT) Size: 3023 URL: From cabo at tzi.org Mon Jul 13 21:43:09 2009 From: cabo at tzi.org (Carsten Bormann) Date: Mon, 13 Jul 2009 22:43:09 +0200 Subject: IPDVB Provisional Agenda (IETF-75) In-Reply-To: <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> References: <4A5261C6.6050408@erg.abdn.ac.uk> <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> Message-ID: <86EA1C81-D636-47DA-8E33-593F2E7D2328@tzi.org> On Jul 7, 2009, at 00:03, Carsten Bormann wrote: > I can talk about about ROHC for IPDVB. I also wrote a draft for that: http://u.nu/36fj > A new version of I-D, draft-bormann-rohc-over-802-02.txt has been > successfuly submitted by Carsten Bormann and posted to the IETF > repository. > > Filename: draft-bormann-rohc-over-802 > Revision: 02 > Title: Robust Header Compression (ROHC) over 802 networks > Creation_date: 2009-07-13 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > Various proposals have been submitted to the ROHC working group for > enabling the use of ROHC [RFC3095] header compression over Ethernet, > 802.11 and other 802-based links. > Previous proposals generally suffered from a lack of systems > perspective on 802 networks. The present document attempts to supply > some systems perspective and provides a rough outline for a solution. (Yes, this is about ROHC for IPDVB, as well as other 802 and 802-like networks.) Gruesse, Carsten From wcang at nav6.org Wed Jul 15 03:20:36 2009 From: wcang at nav6.org (Ang Way Chuang) Date: Wed, 15 Jul 2009 10:20:36 +0800 Subject: Session audio streaming during the 75th IETF meeting Message-ID: <4A5D3CF4.2010406@nav6.org> Hi all, Is there any going to be any session audio streaming for ipdvb WG during the 75th IETF meeting. I can't find any links to that in the IETF website? Thanks Regards, Ang Way Chuang From gorry at erg.abdn.ac.uk Wed Jul 15 08:17:04 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Wed, 15 Jul 2009 08:17:04 +0100 Subject: IETF 75 - Early Bird Cutoff and Social Event Message-ID: <4A5D8270.3030700@erg.abdn.ac.uk> Please see the announcement below, Best wishes, Gorry --- 75th IETF Meeting Stockholm, Sweden July 26-31, 2009 Host: .SE EARLY-BIRD REGISTRATION Early-Bird registration cutoff is Friday, July 17 at 17:00 PT (24:00 UTC). After that time, the registration fee will increase by $150 USD to $785 USD. Online registration for the IETF meeting is at: http://www.ietf.org/meetings/75/ LOCAL MAPS The link below is a map showing the area around the conference venue as well as the location of other IETF events: http://maps.google.com/maps/ms?ie=UTF8&hl=en&oe=UTF8&msa=0&msid=100589894371058605953.00046436ad89be4d84d44&ll=59.334579,18.058927&spn=0.007792,0.01929&z=16 This link is to a map showing areas with restaurants close the meeting venue as well as recommendations by .SE (blue marked streets show areas with a lot of lunch restaurants): http://maps.google.com/maps/ms?ie=UTF8&hl=en&oe=UTF8&msa=0&msid=103783640006729987431.00046e305ddb5a62781e9&ll=59.334596,18.061112&spn=0.031168,0.077162&z=14 SOCIAL EVENT Where: Vasa Museum (http://www.vasamuseet.se/InEnglish/about.aspx) When: Tuesday, July 28, 2009 Time: 7:00pm - 11:00pm Host: .SE The Vasa Museum is the most visited museum in Scandinavia. The Vasa is the world's only surviving 17th-century ship and one of the foremost tourist sights in the world. More information and Social Registration: http://www.ietf.org/meetings/75/social-event.html Note: You must be registered for IETF 75 to purchase a Social Ticket. Only 12 days until the Stockholm IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/75/ From gorry at erg.abdn.ac.uk Wed Jul 15 08:42:39 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Wed, 15 Jul 2009 08:42:39 +0100 Subject: IPDVB Provisional Agenda (IETF-75) In-Reply-To: <86EA1C81-D636-47DA-8E33-593F2E7D2328@tzi.org> References: <4A5261C6.6050408@erg.abdn.ac.uk> <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> <86EA1C81-D636-47DA-8E33-593F2E7D2328@tzi.org> Message-ID: <4A5D886F.6010009@erg.abdn.ac.uk> Carsten, I think the new draft could be applicable to IPDVB and I have updated the Agenda to allow time to discuss this. Could people on the IPDVB mailing list please review this and provide comments to this mailing list or at the meeting, Best wishes, Gorry The new agenda is at: http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt Carsten Bormann wrote: > On Jul 7, 2009, at 00:03, Carsten Bormann wrote: > >> I can talk about about ROHC for IPDVB. > > I also wrote a draft for that: http://u.nu/36fj > >> A new version of I-D, draft-bormann-rohc-over-802-02.txt has been >> successfuly submitted by Carsten Bormann and posted to the IETF >> repository. >> >> Filename: draft-bormann-rohc-over-802 >> Revision: 02 >> Title: Robust Header Compression (ROHC) over 802 networks >> Creation_date: 2009-07-13 >> WG ID: Independent Submission >> Number_of_pages: 15 >> >> Abstract: >> Various proposals have been submitted to the ROHC working group for >> enabling the use of ROHC [RFC3095] header compression over Ethernet, >> 802.11 and other 802-based links. >> Previous proposals generally suffered from a lack of systems >> perspective on 802 networks. The present document attempts to supply >> some systems perspective and provides a rough outline for a solution. > > (Yes, this is about ROHC for IPDVB, as well as other 802 and 802-like > networks.) > > Gruesse, Carsten > > From ipdvb.archive at usa.net Wed Jul 15 08:57:35 2009 From: ipdvb.archive at usa.net (ipdvb.archive at usa.net) Date: Wed, 15 Jul 2009 08:57:35 +0100 (BST) Subject: from Adolph. ($889/week) Message-ID: <200907150757.n6F7vZWe015817@erg.abdn.ac.uk> An HTML attachment was scrubbed... URL: From gorry at erg.abdn.ac.uk Thu Jul 16 08:34:25 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 16 Jul 2009 08:34:25 +0100 Subject: Session audio streaming during the 75th IETF meeting In-Reply-To: <4A5D3CF4.2010406@nav6.org> References: <4A5D3CF4.2010406@nav6.org> Message-ID: <4A5ED801.2020500@erg.abdn.ac.uk> Ang Way Chuang wrote: > Hi all, > > Is there any going to be any session audio streaming for ipdvb WG > during the 75th IETF meeting. I can't find any links to that in the IETF > website? > > Thanks > > Regards, > Ang Way Chuang > > I'll post information, if I can find some. Best wishes, Gorry From gorry at erg.abdn.ac.uk Thu Jul 16 08:33:35 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 16 Jul 2009 08:33:35 +0100 Subject: IPv6 over unidirectional links? Message-ID: <4A5ED7CF.20503@erg.abdn.ac.uk> Here is an off-list thread that Bernhard introduced on the use of IPv6 autoconfiguration with unidirectional links. More thoughts would be welcome. Gorry >>> Bernhard Collini-Nocker wrote: >>>> >>>> Dear Gorry, >>>> >>>> I?d like to add a point that I have raised a few times in the >>>> past years without too much feedback/support: there is in my >>>> opinion an issue with unidirectional >>>> links and IPv6 (neighbourhood discovery) addressing of >>>> rx-only network adapters. >>>> >>>> --Bernhard >> >> Hi Gorry, >> >> Gorry Fairhurst schrieb: >>> >>> Here is what I recall: this is to do with IPv6 autoconf when >>> you can't do DAD, NUD, etc. Is that right? >>> >> right, it is all kind of tricky when the link is not per se >> bidirectional. The impacts may in many cases be neglectible, >> but there may corner cases. >>> >>> I don't recall what you proposed to do in this case though, >>> because on a unidirectional link, I'd expect the sender ND >>> cache to be pre-populated with IPv6 addresses (since ND/SEND >>> could not be used to query this). So is it right that the remote >>> endpoints just rely on RA's to find their own on-net prefix >>> and configure their IPv6 addresses without being able to >>> validate their uniqueness (is this an issue though? >>> - in receive-only applications, the endpoints never send >>> with this prefix anyway). Maybe I have misunderstood? >> >> Well, my concern was/is that in an environment, where >> destination IP addresses of rx-only devices are non-unique, >> but are used as identifiers this might cause problems. >> Also, some mechanisms of IPv6 might fail in what case such an >> interface might be unavailable? Actually there are both >> operational and conceptual aspects in that problematic. >>> >>> If we need work in this space, we'd need to decide if this >>> were a 6man or ipdvb issue - but there is certainly no harm >>> discussing this in ipdvb. >> >> I guess so. >> >> --Bernhard >> From gorry at erg.abdn.ac.uk Thu Jul 16 11:50:57 2009 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Thu, 16 Jul 2009 11:50:57 +0100 Subject: Open Mic section at end of ipdvb meeting - call for Ideas Message-ID: <4A5F0611.20901@erg.abdn.ac.uk> There will be an open-mic session at the end of the next ipdvb meeting, to explore whether the group has a desire to start work on new topics that do not fall within the current milestones and charter. Here is my current list of topics, extracted from the mailing list discussions, please feel free to suggest additions, changes, or offer comments via the list. This discussion will be used to determine the next steps for the group. Best wishes, Gorry Fairhurst (ipdvb Chair) --- Higher Layer Functions: Content location (services over link aka PSI/SI in DVB)* Provisioning/Management (COPS, SIP, netconf, etc) Lower Layer Functions: Header Compression Layer 2 security Link-related signaling (parameter setting, QoS, connectivity) IPv6 autoconfig procedure for unidirectional links Stream location (L2 AR for physical link/network properties)* L2 signaling security MIBs * Base specifications by DVB From H.Cruickshank at surrey.ac.uk Fri Jul 17 14:16:50 2009 From: H.Cruickshank at surrey.ac.uk (H.Cruickshank at surrey.ac.uk) Date: Fri, 17 Jul 2009 14:16:50 +0100 Subject: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) In-Reply-To: Message-ID: <225B6337E699484095DA8EE02A5063B59769FA@EVS-EC1-NODE1.surrey.ac.uk> Many thanks Ana for your comments, See replies in-line: ---- Dr. Haitham S. Cruickshank Lecturer Communications Centre for Communication Systems Research (CCSR) BA Building, Room E11 School of Electronics, Computing and Mathematics University of Surrey, Guildford, UK, GU2 7XH Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank at surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ ________________________________ From: ana.yungarcia at thalesaleniaspace.com [mailto:ana.yungarcia at thalesaleniaspace.com] Sent: 17 July 2009 08:05 To: ipdvb at erg.abdn.ac.uk Cc: gorry at erg.abdn.ac.uk; Cruickshank HS Dr (CCSR); P.Pillai at bradford.ac.uk Subject: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) Dear authors, Nice initiative looking for security over ULE. In fact, link layer security for DVB systems is becoming more and more an issue. Haitham: Thanks. One question about the security key management, have we thought how to perform it over DVB-RCS systems with different topologies? Star systems with a central HUB seems to be an easy scenario, but what about mesh scenarios, who will handle the security keys? Is there going to be a pair of share keys per pair of terminals communicating with each other or there will be a different criteria as maybe per MAC connection between terminals? Haitham: This draft does not address the key management issue. It only focuses on the security extension header format for ULE. The key management can be viewed as an independent issue from the topic of this draft. But it is an important issue. What protocol and what messages will be used for the security key management? DVB-RCS security systems does cover the star topology configuration, but not yet the mesh case. If we believe that in this case we could use GDOI or GSAKMP protocols, in our understanding, it will be another exercise to check how these two protocols really solve the problem of security key management in the different mesh scenarios. Haitham: Yes GSAKMP, GDOI or others can be used to solve the key management issues. Other comments: - Section 8. Security considerations "Increasing sequence numbers could be linked to a single connection." Are we referring to IP connections or link layer connections? Haitham: It relates to link layer connection. - Broadcasting DVB systems use MPEG formatting. But DVB-RCS star transparent systems, mostly use ATM formatting and only optionally MPEG formatting. Using the PID value to identify the source can always be applied to the user terminal in RCS systems. But in a star transparent configuration, the HUB will receive ATM cells, Does it have any impact? Haitham: In this draft we did not address the ATM cell transmissions. I am not sure if there is a demand for using ATM. Kind regards, Ana ========================= Ana YUN GARCIA Satellite Networks Manager Thales Alenia Space Espa?a tel. +34 91 807 78 21 www.thalesaleniaspace.com ========================= From mnoist at cosy.sbg.ac.at Fri Jul 17 16:57:26 2009 From: mnoist at cosy.sbg.ac.at (Michael Noisternig) Date: Fri, 17 Jul 2009 17:57:26 +0200 Subject: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) In-Reply-To: <225B6337E699484095DA8EE02A5063B59769FA@EVS-EC1-NODE1.surrey.ac.uk> References: <225B6337E699484095DA8EE02A5063B59769FA@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <4A609F66.5040908@cosy.sbg.ac.at> Thanks again, Ana, for your review. Please see my replies inline. I hope I understood your questions correctly. Michael H.Cruickshank at surrey.ac.uk schrieb: > Many thanks Ana for your comments, > > See replies in-line: > > ---- > Dr. Haitham S. Cruickshank > Lecturer > Communications Centre for Communication Systems Research (CCSR) > BA Building, Room E11 > School of Electronics, Computing and Mathematics > University of Surrey, Guildford, UK, GU2 7XH > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank at surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > ________________________________ > > From: ana.yungarcia at thalesaleniaspace.com [mailto:ana.yungarcia at thalesaleniaspace.com] > Sent: 17 July 2009 08:05 > To: ipdvb at erg.abdn.ac.uk > Cc: gorry at erg.abdn.ac.uk; Cruickshank HS Dr (CCSR); P.Pillai at bradford.ac.uk > Subject: Re: draft-noisternig-ipdvb-sec-ext-00.txt (Editorial NiTs) > > > > Dear authors, > > Nice initiative looking for security over ULE. In fact, link layer security for DVB systems is becoming more and more an issue. > Haitham: Thanks. > > One question about the security key management, have we thought how to perform it over DVB-RCS systems with different topologies? > Star systems with a central HUB seems to be an easy scenario, but what about mesh scenarios, who will handle the security keys? > Is there going to be a pair of share keys per pair of terminals communicating with each other or there will be a different criteria as maybe per > MAC connection between terminals? Meshed networks require DVB-RCS to carry MPEG/ULE, otherwise ULE security won't be possible. Then, the link endpoints (terminals) maintain the security keys. These may be set up using manual keying in the form of pre-shared keys, either per link (pair of terminals) each or one key for all terminals. Keys may be set up automatically using some key management protocol. Then, for traditional bi-directional unicast communication, it's the link end-points that negotiate and hold the security keys. Key management for secure groups requires a designated Group Controller and Key Server (GCKS) that is reponsible for maintaining the secure group and issuing the keys. This is partly addressed in the processing section. However, a key management protocol is intended to be specified separately, in order to allow a clear separation and flexiblity between the key management and the extension header specification. > > Haitham: This draft does not address the key management issue. It only focuses on the security extension header format for ULE. The key management can be viewed as an independent issue from the topic of this draft. But it is an important issue. > > > What protocol and what messages will be used for the security key management? DVB-RCS security systems does cover the star > topology configuration, but not yet the mesh case. If we believe that in this case we could use GDOI or GSAKMP protocols, > in our understanding, it will be another exercise to check how these two protocols really solve the problem of security key management in the different mesh scenarios. Key management is not specified in this document. GDOI and GSAKMP may very well be some good candidates to adapt for group key management. This is to be defined independently. > > Haitham: Yes GSAKMP, GDOI or others can be used to solve the key management issues. > > Other comments: > > - Section 8. Security considerations > "Increasing sequence numbers could be linked to a single connection." > Are we referring to IP connections or link layer connections? > > Haitham: It relates to link layer connection. > > - Broadcasting DVB systems use MPEG formatting. But DVB-RCS star transparent systems, mostly use ATM formatting and only optionally MPEG formatting. Using the PID value to identify the source can always be applied to the user terminal in RCS systems. But in a star transparent configuration, the HUB will receive ATM cells, Does it have any impact? We only consider the ULE link in the document. If ATM is used on the return channel, then the ULE link is between the hub and a terminal, and the hub is the source. > > Haitham: In this draft we did not address the ATM cell transmissions. I am not sure if there is a demand for using ATM. > > > Kind regards, > > Ana > > > > > ========================= > Ana YUN GARCIA > Satellite Networks Manager > Thales Alenia Space Espa?a > tel. +34 91 807 78 21 > www.thalesaleniaspace.com > ========================= From wcang at nav6.org Sat Jul 18 08:32:54 2009 From: wcang at nav6.org (Ang Way Chuang) Date: Sat, 18 Jul 2009 15:32:54 +0800 Subject: IPDVB Provisional Agenda (IETF-75) In-Reply-To: <4A5D886F.6010009@erg.abdn.ac.uk> References: <4A5261C6.6050408@erg.abdn.ac.uk> <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> <86EA1C81-D636-47DA-8E33-593F2E7D2328@tzi.org> <4A5D886F.6010009@erg.abdn.ac.uk> Message-ID: <4A617AA6.8080506@nav6.org> Hi Carsten, I don't know the negotiation very well. If I don't misinterpret the draft, the negotiation would be something like this: R=1 (what I can decompress) sender <------------------------------ receiver R=2 (I will send using these params) sender -------------------------------------> receiver R=4 (I too will send ROHC using these params) sender <------------------------------------- receiver Wrong? I'm not sure how ROHC will work properly with multicast. Regards, Ang Way Chuang Gorry Fairhurst wrote: > > Carsten, > > I think the new draft could be applicable to IPDVB and I have updated > the Agenda to allow time to discuss this. Could people on the IPDVB > mailing list please review this and provide comments to this mailing > list or at the meeting, > > Best wishes, > > Gorry > > The new agenda is at: > http://www.ietf.org/proceedings/09jul/agenda/ipdvb.txt > > Carsten Bormann wrote: >> On Jul 7, 2009, at 00:03, Carsten Bormann wrote: >> >>> I can talk about about ROHC for IPDVB. >> >> I also wrote a draft for that: http://u.nu/36fj >> >>> A new version of I-D, draft-bormann-rohc-over-802-02.txt has been >>> successfuly submitted by Carsten Bormann and posted to the IETF >>> repository. >>> >>> Filename: draft-bormann-rohc-over-802 >>> Revision: 02 >>> Title: Robust Header Compression (ROHC) over 802 networks >>> Creation_date: 2009-07-13 >>> WG ID: Independent Submission >>> Number_of_pages: 15 >>> >>> Abstract: >>> Various proposals have been submitted to the ROHC working group for >>> enabling the use of ROHC [RFC3095] header compression over Ethernet, >>> 802.11 and other 802-based links. >>> Previous proposals generally suffered from a lack of systems >>> perspective on 802 networks. The present document attempts to supply >>> some systems perspective and provides a rough outline for a solution. >> >> (Yes, this is about ROHC for IPDVB, as well as other 802 and 802-like >> networks.) >> >> Gruesse, Carsten >> >> > From cabo at tzi.org Sat Jul 18 09:31:55 2009 From: cabo at tzi.org (Carsten Bormann) Date: Sat, 18 Jul 2009 10:31:55 +0200 Subject: ROHC-over-802 (was: Re: IPDVB Provisional Agenda (IETF-75)) In-Reply-To: <4A617AA6.8080506@nav6.org> References: <4A5261C6.6050408@erg.abdn.ac.uk> <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> <86EA1C81-D636-47DA-8E33-593F2E7D2328@tzi.org> <4A5D886F.6010009@erg.abdn.ac.uk> <4A617AA6.8080506@nav6.org> Message-ID: > R=1 (what I can decompress) > sender <------------------------------ receiver > R=2 (I will send using these params) > sender -------------------------------------> receiver > R=4 (I too will send ROHC using these params) > sender <------------------------------------- receiver Correct, that is what I'm proposing for the bidirectional case (e.g., two devices connected by some form of bridged Ethernet/WLAN combination). (The sender might then occasionally transmit R=4 packets based on a NUD-like algorithm.) > I'm not sure how ROHC will work properly with multicast. That is the other case with R=6 at the end of section 6 (penultimate paragraph). If the sender does not have direct information about the ROHC capabilities from its peer (which it would get based on negotiation packets with R=1 and R=4), the R=6 case allows setting up the compression based on some out-of-band information (such as configuration or some other negotiation protocol). See the caveats in that paragraph. Gruesse, Carsten From wcang at nav6.org Mon Jul 27 10:54:21 2009 From: wcang at nav6.org (Ang Way Chuang) Date: Mon, 27 Jul 2009 17:54:21 +0800 Subject: Session audio streaming during the 75th IETF meeting In-Reply-To: <4A5ED801.2020500@erg.abdn.ac.uk> References: <4A5D3CF4.2010406@nav6.org> <4A5ED801.2020500@erg.abdn.ac.uk> Message-ID: <4A6D794D.1090505@nav6.org> Gorry Fairhurst wrote: > Ang Way Chuang wrote: >> Hi all, >> >> Is there any going to be any session audio streaming for ipdvb WG >> during the 75th IETF meeting. I can't find any links to that in the >> IETF website? >> >> Thanks >> >> Regards, >> Ang Way Chuang >> >> > I'll post information, if I can find some. Got it. http://feed.verilan.com/ietf/stream03.m3u > > Best wishes, > > Gorry > From cedric.baudoin at thalesaleniaspace.com Thu Jul 30 16:05:29 2009 From: cedric.baudoin at thalesaleniaspace.com (cedric.baudoin at thalesaleniaspace.com) Date: Thu, 30 Jul 2009 17:05:29 +0200 Subject: New GPL ROHC stack Message-ID: Dear all, We are proud to announce the release of an updated version of the GPL ROHC stack. In the frame of a project involving the french space agency (CNES), Thales Alenia Space (TAS) and Viveris Technologies (+ some internal work from TAS and a collaboration between TAS and Viveris), various new features have been added to the GPL stack initially developped by Martin Juhlin (rohc.net). This includes mainly: - RTP profile - IPv6 support - tunneling support - new improved packet classifier - test and statistics tool to analyze the ROHC behavior - non regression tool - standalone library in user space - context reset, fixed packet sizes, (basic) list compression support - uncompressed profile now working - various bug corrections and code cleanup (See attached file: Compliance.rtf) Moreover, a new branch will bee created with several performance enhancements (leading to a dramatic reduction of the processing time per packet), as well as the support of constant IP-ID (?3.3 RFC 3843), that are currently under development. The site will be hosted by launchpad : https://launchpad.net/rohc (In principle, the site will be available in few days, thanks to Didier Barvaux) Please feel free to comment or contribute to the code. Hope this will help to develop a completely free and compliant ROHC implementation a+ C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Compliance.rtf Type: application/rtf Size: 52966 bytes Desc: not available URL: From wcang at nav6.org Thu Jul 30 17:25:07 2009 From: wcang at nav6.org (Ang Way Chuang) Date: Fri, 31 Jul 2009 00:25:07 +0800 Subject: New GPL ROHC stack In-Reply-To: References: Message-ID: <4A71C963.8060902@nav6.org> Thanks, buddy. I shall grab it once it is available. cedric.baudoin at thalesaleniaspace.com wrote: > Dear all, > > We are proud to announce the release of an updated version of the GPL > ROHC stack. > In the frame of a project involving the french space agency (CNES), > Thales Alenia Space (TAS) and Viveris Technologies (+ some internal work > from TAS and a collaboration between TAS and Viveris), various new > features have been added to the GPL stack initially developped by Martin > Juhlin (rohc.net). > This includes mainly: > - RTP profile > - IPv6 support > - tunneling support > - new improved packet classifier > - test and statistics tool to analyze the ROHC behavior > - non regression tool > - standalone library in user space > - context reset, fixed packet sizes, (basic) list compression support > - uncompressed profile now working > - various bug corrections and code cleanup > > /(See attached file: Compliance.rtf)/ > > Moreover, a new branch will bee created with several performance > enhancements (leading to a dramatic reduction of the processing time per > packet), as well as the support of constant IP-ID (?3.3 RFC 3843), that > are currently under development. > > The site will be hosted by launchpad : https://launchpad.net/rohc > > (In principle, the site will be available in few days, thanks to Didier > Barvaux) > > Please feel free to comment or contribute to the code. Hope this will > help to develop a completely free and compliant ROHC implementation > > a+ > C?dric > > > >