From gorry at erg.abdn.ac.uk  Fri Sep  2 15:57:29 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 02 Sep 2005 15:57:29 +0100
Subject: 64th IETF - Vancouver, BC, Canada
Message-ID: <43186859.5010100@erg.abdn.ac.uk>


Just a note, to inform you that the IETF has opened registartion and hotel 
bookings for the coming IETF meeting held 6-11 November 2005 in Vancouver, BC, 
Canada. Details are at:

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

The ipdvb WG intends to meet at this meeting, although final timing of the 
ipdvb meeting in Agenda will not be confirmed until 17th October.

Other meeting deadlines are described:
http://www.ietf.org/meetings/cutoff_dates_64.html

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)



From marie at mjmontpetit.com  Fri Sep  2 17:33:02 2005
From: marie at mjmontpetit.com (Marie-Jose Montpetit)
Date: Fri,  2 Sep 2005 09:33:02 -0700
Subject: 64th IETF - Vancouver, BC, Canada
Message-ID: <20050902093302.ca5566c7162b3cfcb6c200079b757bd6.edfef20b6c.wbe@email.email.secureserver.net>

I'll try to go. This is NA I should have less problems.

/mjm

> -------- Original Message --------
> Subject: 64th IETF - Vancouver, BC, Canada
> From: Gorry Fairhurst <gorry at erg.abdn.ac.uk>
> Date: Fri, September 02, 2005 10:57 am
> To: ipdvb at erg.abdn.ac.uk
>
> Just a note, to inform you that the IETF has opened registartion and hotel
> bookings for the coming IETF meeting held 6-11 November 2005 in Vancouver, BC,
> Canada. Details are at:
>
> http://www.ietf.org/meetings/IETF-64.html
>
> The ipdvb WG intends to meet at this meeting, although final timing of the
> ipdvb meeting in Agenda will not be confirmed until 17th October.
>
> Other meeting deadlines are described:
> http://www.ietf.org/meetings/cutoff_dates_64.html
>
> Best wishes,
>
> Gorry Fairhurst
> (ipdvb WG Chair)



From emard at softhome.net  Sat Sep  3 12:32:49 2005
From: emard at softhome.net (emard at softhome.net)
Date: Sat, 3 Sep 2005 13:32:49 +0200
Subject: unsubscribe
Message-ID: <20050903113248.GA13737@tink>

unsubscribe


From harald.skinnemoen at nera.no  Mon Sep  5 14:09:06 2005
From: harald.skinnemoen at nera.no (Harald Skinnemoen)
Date: Mon, 5 Sep 2005 15:09:06 +0200
Subject: Harald Skinnemoen does not work for Nera anymore.
Message-ID: <OFD139CF10.B125C55B-ONC1257073.00483EB5-C1257073.00483EB5@nera.com.br>

An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20050905/3c6e33b7/attachment.html>

From H.Cruickshank at surrey.ac.uk  Tue Sep  6 17:59:44 2005
From: H.Cruickshank at surrey.ac.uk (H.Cruickshank)
Date: Tue, 6 Sep 2005 17:59:44 +0100
Subject: IP DVB security requirements - document
Message-ID: <C31D320295E23A4EBD131946F0FE1BB0A333C7@EVS-EC1-NODE1.surrey.ac.uk>

Hi,
 
Further to the comments in the last IP-DVB meeting in IETF-Paris, here
is the ULE security requirements draft.
 
Many thanks to Steve Bellovin input during the meeting.  Also many
thanks to Brian Weis (MSEC group) for his valuable input and comments
during the writing of this draft.  Finally, many thanks to Gorry for his
input and suggestions.
 
 
Any comments and input are very welcome.
 
Haitham (& all authors)

--

Dr. Haitham S. Cruickshank 

Lecturer

Communications Centre for Communication Systems Research (CCSR) 

School of Electronics, Computing and Mathematics 

University of Surrey, Guildford, Surrey GU2 7XH, UK 

Tel: +44 1483 686007 (indirect 689844) 

Fax: +44 1483 686011 

e-mail: H.Cruickshank at surrey.ac.uk 

http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
<http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/>  

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20050906/89ebeae0/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-cruickshank-ule-sec-req-00.txt
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20050906/89ebeae0/attachment.txt>

From gorry at erg.abdn.ac.uk  Mon Sep 12 15:09:51 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 12 Sep 2005 15:09:51 +0100
Subject: Status update 12th September 2005.
Message-ID: <43258C2F.4070007@erg.abdn.ac.uk>

I'm pleased to announce the following two WG I-Ds are now approved and are 
awaiting action by the RFC-Editor:
draft-ietf-ipdvb-ar
draft-ietf-ipdvb-arch

Some of you may have noticed that we have tidied the ipdvb web site. The new 
web pages also include a link to the ipdvb status page maintained by the IETF at:
http://tools.ietf.org/wg/ipdvb/

The proceedings for the ipdvb WG meeting in Paris are now available on-line at:
https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=63

I am expecting new I-Ds for the following documents to be published in the 
next few weeks:
draft-ietf-ipdvb-ar (updated)
draft-cantillo-ipdvb-s2encaps (updated)
draft-cruickshank-ipdvb-sec-req (new I-D)


Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)




From gorry at erg.abdn.ac.uk  Thu Sep 15 09:20:07 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Thu, 15 Sep 2005 09:20:07 +0100
Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-00.txt@erg.abdn.ac.uk
Message-ID: <43292EB7.20508@erg.abdn.ac.uk>

A New Internet-Draft is available from the on-line Internet-Drafts directories.


         Title           : Security requirements for the Unidirectional
                           Lightweight Encapsulation (ULE) protocol
         Author(s)       : H. Cruickshank, et al.
         Filename        : draft-cruickshank-ipdvb-sec-req-00.txt
         Pages           :
         Date            : 2005-9-14

    This document provides a threat analysis and derives security
    requirements for MPEG-2 transmission links using the Unidirectional
    Lightweight Encapsulation (ULE).  It also provides the motivation
    for ULE link level security.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-cruickshank-ipdvb-sec-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
         mailserv at ietf.org.
In the body type:
         "FILE /internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt".

NOTE:   The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility.  To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command.  To decode the response(s), you will need "munpack" or
         a MIME-compliant mail reader.  Different MIME-compliant mail readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been split
         up into multiple messages), so check your local documentation on
         how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt>




From gorry at erg.abdn.ac.uk  Thu Sep 15 09:19:24 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Thu, 15 Sep 2005 09:19:24 +0100
Subject: I-D ACTION:draft-ietf-ipdvb-ar-01.txt
Message-ID: <43292E8C.4020800@erg.abdn.ac.uk>


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP over DVB Working Group of the IETF.

         Title           : Address Resolution for IP datagrams over MPEG-2 
networks
         Author(s)       : G. Fairhurst, M. Montpetit
         Filename        : draft-ietf-ipdvb-ar-01.txt
         Pages           : 0
         Date            : 2005-9-14

    This document describes the process of binding/associating IPv4/IPv6
    addresses with MPEG-2 Transport Streams (TS). This procedure is
    known as Address Resolution (AR), or Neighbour Discovery (ND). Such
    address resolution complements the higher layer resource discovery
    tools that are used to advertise IP sessions.

    In MPEG-2 networks, an IP address must be associated with a Packet
    ID (PID) and a specific Transmission Multiplex. The document reviews
    current methods. It also describes the interaction with well-known
    protocols for address management including DHCP, ARP, and NDP, and
    provides guidance on usage.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-ipdvb-ar-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
         mailserv at ietf.org.
In the body type:
         "FILE /internet-drafts/draft-ietf-ipdvb-ar-01.txt".

NOTE:   The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility.  To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command.  To decode the response(s), you will need "munpack" or
         a MIME-compliant mail reader.  Different MIME-compliant mail readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been split
         up into multiple messages), so check your local documentation on
         how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-01.txt>




From bnocker at cosy.sbg.ac.at  Fri Sep 16 08:44:37 2005
From: bnocker at cosy.sbg.ac.at (Bernhard Collini-Nocker)
Date: Fri, 16 Sep 2005 09:44:37 +0200
Subject: Adding ULE into a network already using MPE...
In-Reply-To: <BF1796BA.35CC%gorry@erg.abdn.ac.uk>
References: <BF1796BA.35CC%gorry@erg.abdn.ac.uk>
Message-ID: <432A77E5.1030301@cosy.sbg.ac.at>

Just came across that (again), and am adding a few thoughts on the 
autodetection of MPE/ULE.

Gorry Fairhurst wrote:
> There ways to do this I can think of three, and I think John you are asking
> about C?
> A) You could parse the SI/PSI signalling (if any) and extract the
> information from there.
> B) You could configure it (out of band) or using IP
> configuration/resolution, etc.
> C) I once worked through an "auto-detect mode", where you knew the PID but
> didn't know the type of encapsulation.
> 
> ----
> 
> The basic rule is only one type of encapsulation is allowed for a single
> PID. So how can you find out which is used?
> 
> I note there is a reasonably strong CRC there in the ULE framing, and you
> can easily extract framing alignment to the TS from the PUSI setting in the
> TS header:
> 
> (i) Supposing your receiver starts as unconfigured.
> 
> (ii) The receiver looks for a PUSI setting and extracts the PP value.

Before extracting PP the value of AFC field could be checked as well. If 
adaptation field is present, it is clearly not ULE.

> (iii) It then tries reassembly of the first section as a ULE packet. If it
> succeeds with a valid CRC-32 and Length, it is probably safe to assume this
> is ULE.

One could do probably a little better than this in looking the first 
byte of the Length field, which might be a valid table_id and 
consequently would very unlikely be part of a reasonable ULE Length. If 
not cheking this some many TS cells would have to be read and skipped 
until the potential ULE SNDU is captured and the CRC fails.

> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being aware the
> integrity check is interpreted in more than one way in MPE). The MPE start
> code is also another "hint" that this may not be ULE, but this value *could*
> appear as the start of a ULE field - (Note one needs to be aware that MPE
> and ATSC use different start values).
> 
> (v) You could (probably should!!!) verify the next few SNDUs to increase
> your confidence, as in any alignment algorithm.  It would also be wise to
> re-initialise the detection if you suffer an alignment failure. This could
> be a result of a change of mutliplexing policy.
> 
> Note: This is orthogonal to the generation of SI/PSI tables used to control
> the TS multiplexing layer itself. If you use a transport stream multiplexor
> as a part of your L2 MPEG transmission network, this may need the SI/PSI to
> allow the PID to reach the Receiver.
> 
> Thoughts?

It is a nice exercise to think about an auto-detection mode, maybe it is 
even worth to continue thinking about it...

> Gorry

Bernhard

> On 3/8/05 8:39 pm, "John Border" <border at hns.com> wrote:
> 
>>    I was thinking along those lines.  The sender associates the
>>encapsulation method with a particular PID and "knows" (via AR) which
>>PID to use to send to a particular receiver.  Receivers which only
>>understand MPE only use MPE PIDs.  Receivers which understand ULE and
>>MPE determine which method is being used by which PID is being
>>received.  (I think the ULE capable receivers will still need to support
>>MPE for multicast traffic that is shared with "older" terminals.)
>>
>>    I was wondering if there is a way for the receiver to look at the
>>header and determine if it is ULE or MPE on the fly.  I haven't taken a
>>close look at it yet.  But, I suspect that it is not reliably possible...
>>
>>John
>>
>>
>>Marie-Jose Montpetit wrote:
>>
>>
>>>I think this is one thing that could be solved by some of the
>>>configuration work that was started where you could associate a PID to
>>>an encapsulation. You may not want to ignore the new encapsulation.
>>>
>>>Marie-Jose
>>>
>>> 
>>>
>>>
>>>>-------- Original Message --------
>>>>Subject: RE: Adding ULE into a network already using MPE...
>>>>From: "Allison, Art" <AAllison at nab.org>
>>>>Date: Wed, August 03, 2005 2:05 pm
>>>>To: <ipdvb at erg.abdn.ac.uk>
>>>>
>>>>Use of the MRD will enable a device on a MPEG-2 network that does not
>>>>understand that MRD's signaling/meaning to ignore the new encapsulation.
>>>>
>>>>
>>>>Of course if the existing network just used private data with out
>>>>signaling what it was, a problem may exist.
>>>>__________________
>>>>Art Allison
>>>>Director, Advanced Engineering
>>>>NAB Science & Technology
>>>>1771 N St NW, Washington DC 20036
>>>>202 429 5418
>>>>-----Original Message-----
>>>>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk]
>>>>Sent: Wednesday, August 03, 2005 11:32 AM
>>>>To: ipdvb at erg.abdn.ac.uk
>>>>Subject: Adding ULE into a network already using MPE...
>>>>
>>>>
>>>>   Has anyone looked at the operational problems associated with adding
>>>>ULE use to a network which has some deployed terminals which only
>>>>understand MPE?
>>>>
>>>>
>>>>John
>>>>   
>>>>
>>>
>>> 
>>>
>>
>>
> 
> 



From gorry at erg.abdn.ac.uk  Fri Sep 16 09:12:03 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 16 Sep 2005 09:12:03 +0100
Subject: Adding ULE into a network already using MPE...
In-Reply-To: <432A77E5.1030301@cosy.sbg.ac.at>
References: <BF1796BA.35CC%gorry@erg.abdn.ac.uk> <432A77E5.1030301@cosy.sbg.ac.at>
Message-ID: <432A7E53.3030204@erg.abdn.ac.uk>

A few comments in-line.

Bernhard Collini-Nocker wrote:

> Just came across that (again), and am adding a few thoughts on the 
> autodetection of MPE/ULE.
> 
> Gorry Fairhurst wrote:
> 
>> There ways to do this I can think of three, and I think John you are 
>> asking
>> about C?
>> A) You could parse the SI/PSI signalling (if any) and extract the
>> information from there.
>> B) You could configure it (out of band) or using IP
>> configuration/resolution, etc.
>> C) I once worked through an "auto-detect mode", where you knew the PID 
>> but
>> didn't know the type of encapsulation.
>>
>> ----
>>
>> The basic rule is only one type of encapsulation is allowed for a single
>> PID. So how can you find out which is used?
>>
>> I note there is a reasonably strong CRC there in the ULE framing, and you
>> can easily extract framing alignment to the TS from the PUSI setting 
>> in the
>> TS header:
>>
>> (i) Supposing your receiver starts as unconfigured.
>>
>> (ii) The receiver looks for a PUSI setting and extracts the PP value.
> 
> 
> Before extracting PP the value of AFC field could be checked as well. If 
> adaptation field is present, it is clearly not ULE.
> 
True - but there was at least two people said they would have liked AFC 
support (although it's not in the standard for ULE), and so I'd hate to close 
the door on this more, so maybe I'd urge that we ignore AFC.

>> (iii) It then tries reassembly of the first section as a ULE packet. 
>> If it
>> succeeds with a valid CRC-32 and Length, it is probably safe to assume 
>> this
>> is ULE.
> 
> 
> One could do probably a little better than this in looking the first 
> byte of the Length field, which might be a valid table_id and 
> consequently would very unlikely be part of a reasonable ULE Length. If 
> not cheking this some many TS cells would have to be read and skipped 
> until the potential ULE SNDU is captured and the CRC fails.
> 
Agreed, this could also be a good "hint".

>> (iv) If the CRC fails, it tries a DSM-CC section reassembly (being 
>> aware the
>> integrity check is interpreted in more than one way in MPE). The MPE 
>> start
>> code is also another "hint" that this may not be ULE, but this value 
>> *could*
>> appear as the start of a ULE field - (Note one needs to be aware that MPE
>> and ATSC use different start values).
>>
>> (v) You could (probably should!!!) verify the next few SNDUs to increase
>> your confidence, as in any alignment algorithm.  It would also be wise to
>> re-initialise the detection if you suffer an alignment failure. This 
>> could
>> be a result of a change of mutliplexing policy.
>>
>> Note: This is orthogonal to the generation of SI/PSI tables used to 
>> control
>> the TS multiplexing layer itself. If you use a transport stream 
>> multiplexor
>> as a part of your L2 MPEG transmission network, this may need the 
>> SI/PSI to
>> allow the PID to reach the Receiver.
>>
>> Thoughts?
> 
> 
> It is a nice exercise to think about an auto-detection mode, maybe it is 
> even worth to continue thinking about it...
> 

Perhaps there are some useful applications of this, the one that comes to my 
mind is that it is a useful tool for decoding bitstreams for analysis (aka 
ethereal).

>> Gorry
> 
> 
> Bernhard
> 
>> On 3/8/05 8:39 pm, "John Border" <border at hns.com> wrote:
>>
>>>    I was thinking along those lines.  The sender associates the
>>> encapsulation method with a particular PID and "knows" (via AR) which
>>> PID to use to send to a particular receiver.  Receivers which only
>>> understand MPE only use MPE PIDs.  Receivers which understand ULE and
>>> MPE determine which method is being used by which PID is being
>>> received.  (I think the ULE capable receivers will still need to support
>>> MPE for multicast traffic that is shared with "older" terminals.)
>>>
>>>    I was wondering if there is a way for the receiver to look at the
>>> header and determine if it is ULE or MPE on the fly.  I haven't taken a
>>> close look at it yet.  But, I suspect that it is not reliably 
>>> possible...
>>>
>>> John
>>>
>>>
>>> Marie-Jose Montpetit wrote:
>>>
>>>
>>>> I think this is one thing that could be solved by some of the
>>>> configuration work that was started where you could associate a PID to
>>>> an encapsulation. You may not want to ignore the new encapsulation.
>>>>
>>>> Marie-Jose
>>>>
>>>>
>>>>
>>>>
>>>>> -------- Original Message --------
>>>>> Subject: RE: Adding ULE into a network already using MPE...
>>>>> From: "Allison, Art" <AAllison at nab.org>
>>>>> Date: Wed, August 03, 2005 2:05 pm
>>>>> To: <ipdvb at erg.abdn.ac.uk>
>>>>>
>>>>> Use of the MRD will enable a device on a MPEG-2 network that does not
>>>>> understand that MRD's signaling/meaning to ignore the new 
>>>>> encapsulation.
>>>>>
>>>>>
>>>>> Of course if the existing network just used private data with out
>>>>> signaling what it was, a problem may exist.
>>>>> __________________
>>>>> Art Allison
>>>>> Director, Advanced Engineering
>>>>> NAB Science & Technology
>>>>> 1771 N St NW, Washington DC 20036
>>>>> 202 429 5418
>>>>> -----Original Message-----
>>>>> From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk]
>>>>> Sent: Wednesday, August 03, 2005 11:32 AM
>>>>> To: ipdvb at erg.abdn.ac.uk
>>>>> Subject: Adding ULE into a network already using MPE...
>>>>>
>>>>>
>>>>>   Has anyone looked at the operational problems associated with adding
>>>>> ULE use to a network which has some deployed terminals which only
>>>>> understand MPE?
>>>>>
>>>>>
>>>>> John
>>>>>  
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 



From gorry at erg.abdn.ac.uk  Mon Sep 19 19:17:33 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Mon, 19 Sep 2005 19:17:33 +0100
Subject: Draft Agenda fro the 64th IETF - Vancouver, BC, Canada
Message-ID: <432F00BD.7070100@erg.abdn.ac.uk>


The Sixty-fourth IETF meeting will be held 6-11 November 2005. Please find 
below, the Draft Agenda foir the next ipdvb WG meeting. Please send any 
additions/corrections to me.

Please also do let me know if you intend to submit a *NEW* I-D on a subject 
covered by the ipdvb Charter.

Best wishes,

Gorry Fairhurst

-----

IP over Digital Video Broadcast (IPDVB) WG

1. Agenda Bashing (10 minutes) - Chair
       * Agenda changes
       * Election of Scribe for Proceedings
       * Jabber Scribe

2. Document Status (5 minutes) - Chair
       * Updated milestones.
       * Documents in Last Call - None.
       * Documents in IESG Review - None.
       * Documents in RFC Editor Queue:
         draft-ietf-ipdvb-ule-06 (Proposed Standard)
         draft-ietf-ipdvb-arch-04 (Informational)
       * Published RFCs - None.

3. Address Resolution (15 minutes) - M-J Montpetit
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-01.txt
       * L2 Resolution
       * L3 Resolution: ND, UDLR, etc.
       * Contributions required

4. IP Address Configuration for ipdvb (10 minutes) - M Stiemerling
http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-01.txt
       * Future directions for this draft

5.  ULE Security Requirements (20 minutes) - Haitham Cruikshank
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt
  -00
       * Requirements and threat analysis
       * Contributions required

6. ULE Security Extension (10 minutes) - Haitham Cruikshank
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-00.txt
       * Security Header Extension proposal
       * Appropriateness of the technique

7. IP Encapsulation for DVB-S.2 (20 minutes) - Jerome Lacan
http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-00.txt
       * Requirements and scenarios
       * Future directions for this draft

8. A.O.B.


Archive: http://www.erg.abdn.ac.uk/ipdvb/archive

Other related drafts:
http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt
http://www.ietf.org/internet-drafts/draft-montpetit-ipdvb-config-00.txt
http://www.ietf.org/internet-drafts/draft-miloucheva-udlr-mipv6-00.txt

----




From gorry at erg.abdn.ac.uk  Tue Sep 20 10:15:56 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Tue, 20 Sep 2005 10:15:56 +0100
Subject: New web pages and milestones for ipdvb
Message-ID: <432FD34C.1090702@erg.abdn.ac.uk>


I've updated the web pages for the ipdvb WG at:

http://www.erg.abdn.ac.uk/ip-dvb/
http://www.ietf.org/html.charters/ipdvb-charter.html

Specifically, this includes a URL to the newly approved milestones for the 
ipdvb WG, following discussion with our AD after the last IETF meeting in 
Paris. There are two changes:

* Repositioning of milestones to allow more time to discuss AR requirements 
and issues, prior to protocol specification.

* I am pleased to announce the addition of new milestones to define security 
REQUIREMENTS (for INFORMATIONAL RFC) - the aim being to understand the 
security issues, threats, concerns, and to give guidance on usage to support 
IP. This new milestone does not presume any decision on whether to progress 
specific security-related extensions to protocols within the WG.


Gorry



From gorry at erg.abdn.ac.uk  Tue Sep 20 10:18:06 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Tue, 20 Sep 2005 10:18:06 +0100
Subject: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt
In-Reply-To: <43292EB7.20508@erg.abdn.ac.uk>
References: <43292EB7.20508@erg.abdn.ac.uk>
Message-ID: <432FD3CE.50805@erg.abdn.ac.uk>


This draft raises several issues, and seems to me to be a good start, at a 
document that would be useful to this WG. I'd like to get more opinions on 
what the document does say, and what it does not, so that we can understand 
whether this fits the needs of this WG. Can I encourage people to read thsi 
and send comments to the list?

I have some comments below, to start this process:

Section 1.1:
-----
1) In 1.1 it is may also be worth stating that the service to be protected is 
the stream (TS Logical Channel) that is between the Encapsulation Gateway and 
Receiver. This stream is identified at the Gateway and Receiver by a unique 
PID value associated with the stream (although at the two ends of the link may 
have differing values, since this can be and is modified in the MPEG2
Transmission Network).
-----
2) It also could perhaps be staring that although a number of components 
operate within the network. For the IP network service, they do not modify the 
packet payload.
-----


Section 2: Threats
-----
3) I wonder if there are any thoughts on the different "Access to the Channel" 
related to the set of scenarios in section 3.1 of draft-ietf-ipdvb-arch-xx.txt.

- Specifically do people see different threats being important in TV-oriented 
networks that are contribution/broadcast carrying IP data and networks that 
are more IP-oriented (with smaller transmit hubs/power)? - I do.

- In broadcast networks, it is probably hard to access the ground network at
the transmitter (or the contribution feed, in a digital TV scenario). It is
therefore hard to modify the traffic sent on the broadcast up-link (from the
modulator to the headend/satellite/mast) which would impact all receivers -
this typically requires access to facilities and/or a large transmit power
(as in Captain Midnight [Ref]).

- In contrast, access to the air-interface of specific receivers is much
easier. The signal at a Receiver is often much weaker (due to path
propagation loss). This could potentially be jammed/replayed/over-loaded
with another signal (e.g. A transmitter injecting a signal into the
side-lobe of a satellite receive antenna).

- DoS, traffic analysis, and other networking threats are more significant
for IP-data than TV services, where the potential damage from malicous
manipulation is greater. ETC....

-----
4) I would like to have seen some discussion of the impact of 
modified/corrupted/forged signalling information on the Receiver.

It is usually hard to inject different traffic or modify existing TS Packets
within a stream, but through configuration of the (re)multiplexor, access to
the physical media (e.g. connections between components), etc it is possible
to replace a Stream with a different stream.

This could also arise on the broadcast physical link (e.g. An unauthorised
high-power transmitter overriding the intended transmission). However, note
that the transmissions are normally continuous (rather than the discrete
bursts, e.g. Used in 802.11, WiMAX). To successfully inject new/replacement
traffic requires the physical layer FEC/modulation to be acquired by the
Receiver. L2 signalling (MPEG2 SI) also needs to be consistent with the TS
packets being sent.  However, the current specifications for MPEG-2 [....]
do not specify a method for authentication (or encryption) of the L2
signalling information.

- Could we try to define some security properties of the signalling plane (I'd 
be happy to contribute some starting text)?

- Perhaps this should also be identified as an assumption/issue in the 
Security Considerations section?
-----


Hope that helps,

Gorry





From gorry at erg.abdn.ac.uk  Fri Sep 30 12:00:20 2005
From: gorry at erg.abdn.ac.uk (Gorry Fairhurst)
Date: Fri, 30 Sep 2005 12:00:20 +0100
Subject: ipdvb WG Agenda: Sixty-fourth IETF,  6-11 November 2005.
Message-ID: <433D1AC4.7050905@erg.abdn.ac.uk>

Here is the Agenda for the ipdvb WG meeting on 6-11 November 2005.

Best wishes,

Gorry Fairhurst
(ipdvb WG Chair)

-----

IP over Digital Video Broadcast (IPDVB) WG
Internet Area
ipdvb WG Chair: Gorry Fairhurst gorry at erg.abdn.ac.uk

1. Agenda Bashing (10 minutes) - Chair
       * Agenda changes
       * Election of Scribe for Proceedings
       * Jabber Scribe

2. Document Status (5 minutes) - Chair
       * Updated milestones.
       * Documents in Last Call - None.
       * Documents in IESG Review - None.
       * Documents in RFC Editor Queue:
         draft-ietf-ipdvb-ule-06 (Proposed Standard)
         draft-ietf-ipdvb-arch-04 (Informational)
       * Published RFCs - None.

3. Address Resolution (15 minutes) - M-J Montpetit
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-ar-01.txt
       * L2 Resolution: MPEG signaling.
       * Non-IETF ULE Code-points (ATSC, SMPTE).
       * L3 Resolution: ND, UDLR, etc.
       * Contributions required.

4. IP Address Configuration for ipdvb (10 minutes) - Martin Stiemerling
http://www.ietf.org/internet-drafts/draft-stiemerling-ipdvb-config-01.txt
       * Future directions for this draft

5.  ULE Security Requirements (20 minutes) - Haitham Cruikshank
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt
       * Requirements and threat analysis.
       * Contributions required.

6. ULE Security Extension (5 minutes) - Haitham Cruikshank
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-00.txt
       * Update on document plans.

7. IP Encapsulation for DVB-S.2 (20 minutes) - Juan Cantillo
http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-01.txt
       * Requirements and scenarios.
       * Future directions for this draft.

8. ULE Implementation Status (10 minutes) - Chair/Various
       * Current status of implementations.

9. A.O.B.


Archive: http://www.erg.abdn.ac.uk/ipdvb/archive

Other related drafts:
http://www.ietf.org/internet-drafts/draft-bormann-rohc-over-802-01.txt
http://www.ietf.org/internet-drafts/draft-montpetit-ipdvb-config-00.txt
http://www.ietf.org/internet-drafts/draft-miloucheva-udlr-mipv6-00.txt

----






From juan.cantillo at ensica.fr  Fri Sep 30 12:49:41 2005
From: juan.cantillo at ensica.fr (Juan Cantillo)
Date: Fri, 30 Sep 2005 13:49:41 +0200
Subject: IP over DVB-S2 requirements draft
References: <Pine.LNX.4.44.0508041312300.1494-100000@maw-laptop.comm.ad.roke.co.uk>
Message-ID: <000c01c5c5b5$0b3767a0$877a36c1@DrCerebro>

Re: Non-IP Protocol SupportDear all,

Following the 63th meeting discussions, we have produced a brand-new version of our document concerning the IP/DVB-S2 issues. The I-D "draft-cantillo-ipdvb-s2encaps-01.txt" si bnow available online at: 

http://www.ietf.org/internet-drafts/draft-cantillo-ipdvb-s2encaps-01.txt

We look forward to discussing the draft together in Vancouver. Of course, we warmly encourage you to take a look at it from now; comments, questions and remarks are most welcome via @.

Best regards,

-----------------------------------------------------------------------
Juan CANTILLO - SatComs PhD. Researcher
Tel +33 6 23 54 59 65- Fax  +33 5 61 61 86 88
ENST/TeSA/ENSICA/AAS, Toulouse, FR


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20050930/c040cd9c/attachment.html>

From fvieira at sunaut.uab.es  Fri Sep 30 16:39:50 2005
From: fvieira at sunaut.uab.es (Fausto Vieira)
Date: Fri, 30 Sep 2005 17:39:50 +0200
Subject: IP over DVB-S2 early structure
In-Reply-To: <000c01c5c5b5$0b3767a0$877a36c1@DrCerebro>
References:  <Pine.LNX.4.44.0508041312300.1494-100000@maw-laptop.comm.ad.roke.co.uk>
 <000c01c5c5b5$0b3767a0$877a36c1@DrCerebro>
Message-ID: <433D5C46.7030909@sunaut.uab.es>

Some ideas for encapsulation protocol of IP over DVB-S2. This is not in 
a draft structure because it is still an idea and I have never done a 
IETF draft. No security support is described yet.

------------------------------------------

The frames should fit the exact size of the BBFRAME DATAFIELD.

The structure would be something like:

HEADER+OPTIONAL_FIELDS+PAYLOAD+PADDING+OPTIONAL_CRC

or for multiple packet encapsulation:

HEADER+OPTIONAL_FIELDS+PAYLOAD+MINI_HEADER+PADDING+OPTIONAL_CRC

The HEADER should consist of:

ID - Required to determine encapsulation protocol

VERSION - Required for future versions on the protocol

ENCAP_PROTO - Network layer protocol ID: IPv4 unicast, IPv4 multicast, 
IPv6 unicast, IPv6 multicast, IPv4/IPv6 compressed datagrams, other 
(specified in optional field

MULTI_PACKETS - True if more than one packet in the encapsulation frame

MAC_FIELDS - MAC addresses present for this packet. Four possible 
values: No MAC addresses, Destination only MAC address, Source only MAC 
address, Source and Destination MAC address

FRAG_STATUS - Four possible values: NO - packet not fragmented, BEGIN - 
packet is fragmented and starts in this frame, CONTINUED - The start of 
the packet was in a past frame and it will continue in a future frame

OTHER_FIELDS - Defines if a next_field+field_data kind of structure is 
present in this frame

CRC_CHECK - Exists CRC field in the end of the frame. Four possible 
values: NO, CRC8, CRC16, CRC32

This would be the fixed header. According to the options in the header, 
possible fields may follow the header:

If ENCAP_PROTO is not native, this field would specify the protocol with 
a ETHER_TYPE field.

If MAC_FIELDS is different from NO, then one or two MAC addresses will 
follow according to the value of the MAC_fields

If FRAG_STATUS is not NO, then a FRAG_ID number is inserted here in 
other to send several fragmented packets in non-consecutive frames.

If MULTI_PACKETS is true then offset field is inserted here to inform 
the decoder where to jump to process next packet. From the information 
sent to this point, the decoder probably knows if the packet is meant 
for it.

If OTHER_FIELDS is true then a sequence of NEXT_FIELD+FIELD_DATA is 
inserted here.

After these fields, the payload itself would be inserted here.

PAYLOAD

After the PAYLOAD, another packet may be present, but if not jump to 
PADDING section. MULTI_PACKETS must be true for this to be allowed.

The other packets present in the frame do not require the same header 
information. These packets could be preceded by the following:

MINI_HEADER:

ENCAP_PROTO+MAC_FIELDS+FRAG_STATUS+MULTI_PACKETS+OTHER_FIELDS

The sequence of optional fields should follow according to the MINI_HEADER.
After these fields, the payload itself would be inserted here.

PAYLOAD

After the PAYLOAD, another packet may be present, but if not jump to 
PADDING section. MULTI_PACKETS must be true for this to be allowed.

PADDING - even with multiple packets and fragmentation in one frame, 
these may not fit perfectly inside the frame and therefore some padding 
could be required.

OPTIONAL_CRC - This field could be mandatory for some payload. CRC 
checks could be chosen according to the free space in the frame that 
would be otherwise wasted on padding.






-- 
Fausto Vieira
Researcher
Dpt. Telecomunicaci? i d'Enginyeria de Sistemes
ETSE - UNIVERSITAT AUT?NOMA DE BARCELONA
Campus Universitari, s/n
08193 Bellatera Barcelona SPAIN
Phone :(34) 935813843
Fax   :(34) 935814031