IETF-66 IP over DVB (IPDVB) WG Session
WG Chair: Gorry Fairhurst (GF)
Note Taker: Martin Striemerling

Overview and agenda bashing
Document Status & WG Milestones
	2 RFCs published, one active working group draft.
	Several individual drafts, one up for WG adoption.

Address Resolution Mechanisms (draft-ietf-ipdvb-ar-04.txt)
Marie-Jose Montpetit
	This document is currently in WG last call, which closes July 18th.
	Marie-Jose explained the purpose of the draft, specifically that it 
	documents how existing techniques should be used and what parameters 
	need to be tuned.
	There had been two revisions since the last IETF (-03 and -04).
	The document title has been updated to reflect that this describes 
	how to use existing IETF mechanisms. The introduction and conclusions 
	now also reflect this. A few new comments had been received on 
	revision 4, but this now seems stable and ready for publication.

	WG Chair: How many people have read the latest version? (four hands)

	GF: The document is in WGLC (extended, because the close date was near to 
	the IETF meeting). Are there any comments or feedback?
	George Gross (GG): The comments that I submitted on revision 3 have been 	
	addressed.  The draft looks fine.  It may be wise to check the list of 
	security threads for security considerations seem to be described in this 
	document: DoS, man-in-middle, etc.
	WG Chair: This document is still open for comments and suggestions. Please 
	read and send comments to the authors/list.

ULE Security Requirements (draft-cruickshank-ipdvb-sec-req-02.txt) 
Haitham Cruickshank
	The document sets out security requirements for MPEG-2 transmission links,
	and defines scenarios with passive and active threats. Key management is 
	now clearly separated from the encapsulation format. This draft follows 
	many comments from the mailing list on what is protected, secure signaling,
	confidentiality, integrity, and L2 authentication. The draft is submitted 
	in response to the WG  milestone on security requirements for IP/MPEG-2 
	Transport Stream (ULE). A new draft will be submitted a week after the 
	IETF, and the authors would like to see this adopted by the WG.

	WG Chair: How many have read this version? (Three)
	WG Chair: Of those who have read it, should this be a WG work item? (Yes)
	GG: It is self-evident that something is needed for this problem, and 
	probably should be informational. The security threat model is a good step 
	in the correct direction.

	GG: Was it your intent to have the concept of a virtual LAN? 
	This was talked about on the list, is this just L2? 
	What selectors could be used to choose how to encrypt the packet you have? 
	This needs to be clarified.
	Haitham Cruickshank (HC): There are two parameters: the security ID and the 
	MAC addresses (Destination and Source). If no MAC addresses (D=1), the 
	Security ID must be unique, otherwise a unique MAC address are needed. This 
	will be looked at in more detail to see if there are other identifiers that 
	could be used.
	GG: Choosing the security ID is the main method. This is a sort of 
	compression. 		
	Do you share Security IDs across different NPA I-Ds? 
	HC: This scenario needs to be identified. Multiple sources would need 
	specific cases.
	GG: Probably trust people in your group, you do not need replay detection.
	HC: It depends upon non-group members who may replay.
	GG: Not so, you are either a member or a non-member.

	GF: Is Bridging-mode supported?
	HC: Yes, it would transport both IP and non-IP.
	GF: Is the Bridging header of ULE also to be matched in the  security
	policy data base?
	HC: The current proposal is to use the NPA address, which would also work 
	with the destination/NPA address in bridging. 	

	GF: What thoughts are there on how to assure interoperability between 
	systems when there could be a range of cryptos in use?
	HC: For the requirements we do not need to define cryptos, etc but we  
	coulddefine profiles for the protocol that specify some required cryptos 
	to ensure interoperability.

	GG: Authentication is an important issue in IPsec: What methods are you  
	using to authenticate the end points in this architecture?
	HC: The authentication of L2 endpoints is included. The security properties 
	are different from L3 entities, where the addresses are bound to end-hosts.
	GG: Should we profile certificates as well?
	HC: Yes - this is good.

	GG: Can I check: This I-D gives requirements for the header extension 
	for ULE, and not for the key management. Is that correct?
	HC: This is requirements for networks implementing ULE. The next draft is 
	about defining these mechanisms for ULE.
	GG: OK. So I am trying to understand key management requirements, for 
 	example re-keying a group.
	HC: This in the next document, which speaks about key management. But 
	we would like to keep key management algorithms as an orthogonal issue.
	GG: For the extension header this seems right. I see key management 
 	requirements as something that has to fall under that umbrella and needs 
	to be specified in a document somewhere.
	GF: I think this document has to provide a convincing case that L2 
	security can be done, it is useful for IP and then set a framework for 
	transporting this. This WG is not in the security area, and is not the 
	right place to work on key management. If there are requirements on key 
	management, or constraints, that stem from this work, then I think they 
	should be in the requirements document.
	GG: We need to see the large picture. There are requirements for key 
	management. Is this to be another document (e.g. in MSEC), developed in 
	another body, a re-charter of this group at some time in the future?
	GF: This group is here to develop and maintain the ULE Spec. That does not
	include setting up new key management infrastructures.

	GF: Some networks already have key managements (of some form). Although 
	encryption is not necessarily in the way that Internet access would expect, 
	(e.g. designed for conditional access). If the IETF were to do L2 key
	management, I think it should come from MSEC or another security area WG.
	GG: I do not see MSEC working group stepping up to this role.
	GF: Agreed. So I'd like to see requirements, but probably no specific 
	protocol.
	HC: So, if existing L2 key management systems exist, we have the 
	requirements. I think exisiting key management of MSEC WG could be used.
	Mark Townsley (AD): How much of Layer 2 are we defining here in the IETF 
	and how much expertise do we have, not just on key management, but on
	security in general? 
	When I look at the Charter, I do not see where the security mechanisms
	are. Some other people in the security area share this. I think we need
	to step-back and understand what we need to define here. 
	One thing I noted was that Margaret Wasserman (former AD) was promised
	a threat analysis spec. Was a threat analysis document written?
	HC: Yes, the threat analysis is in this I-D.
	MT: OK. So, you will probably be seeing some comments on this. 
	GF: OK. So a motivation was to define a header extension format and the 
	type field (IANA assignments). The next presentations show how this may 
	be envisioned using a ULE extension header.
	MT: Some very fundamental questions: this is an IP working group and
	why can you not do it with IPSEC? Is that in the document?	
	HC: Yes, it is.
	MT: I'm still not sure it is in the Charter.

ULE Security Extensions (draft-ppillai-ipdvb-sule-00.txt) 
Prashant Pillai
	This draft was written to help explore the requirements. Issues that
	need to be explored include how large a HMAC is valuable, and when it 
	is needed.

	GF: There was a comment on the list that equipment relied on a CRC 
	for framing and replacing this with a HMAC was a problem.	
	PP: The new spec (next talk) preserves the CRC, it does not modify 
	the ULE  framing, but adds a Security MAC to the fields.
	GF: Are you intending to continue this individual draft?
	PP: No, we are not continuing the individual draft, but have teamed up 
	with the authors of the other security protocol document.	

ULE security extensions (draft-cruickshank-ipdvb-sec-02.txt) 
Haitham Cruickshank
	There had been discussion on the list. TESLA provides some interesting 	
	possibilities to provide source authentication of the L2 stream, which 
	may be in a future draft. The authors plan to implement a spec by the 
        end of the year and would welcome inputs. This document needs to await 
        for further discussions that arise from the requirement document.

DVB-S2 Encapsulation - DVB-TM/GBS activities (no I-D) 
Gorry on behalf of Axel Jahn.
	A short presentation was made to set the context for DVB-S2 on a proposed 
	encapsulation format for the new physical layer that has been defined.  
	Therequirements for this work took RFC 4259 as one of its inputs. Action
	is required by the DVB-TM to progress the described work.

Requirements for IP encap for DVB-S2 (draft-cantillo-ipdvb-s2encaps-03.txt) 
Juan Cantillo
	There has been a change of focus from defining the link protocol, and 
	now more on the provision of the IP service. A future version will need 
	to reflect the protocols that will emerge from DVB. There would need to 
	be work on security and QoS.

	JC: What can be done to reflect the interest in DVB-S2 within the WG?
	Joerg Ott (JO): May be you could factor-out QoS from the basic framing, 
	and something similar for security?
	Bernhard Collini-Nocker (BCN) via Jabber: Do the differences between 
	DVB-S and DVB-S2 justify the work in ipdvb?
	GF: There are two things: Should the S2 link have similar encapsulation 
	interfaces to that presented by ULE? This could promote the development 
	of common IP-oriented extensions and possibly a common encryption suite? 
	Second, the S2 interface seems to present a very rich feature set to IP 
	that needs to be understood. I do not yet know if that means we have to 
	do work here. I do not yet know.
	BCN: In other words, is DVB-S2 so much different from DVB-S and MPEG-2 TS 
	based ipdvb that it would more ask for a IPoverS2 or IPoverVCM?
	GF: This depends on the way it is going to go, we don;t yet know this.

ULE Extension formats for DVB-S2 (draft-fairhurst-ipdvb-s2-gule-04.txt) 
Gorry Fairhurst
	This short draft seeks to define two extensions common for GSE (for S2) 
	and ULE to optimise performance.

	JO: Why is the length field only 15 bits?
	GF: Because it was in ULE.
	JO: Do you want to keep this for compatability?
	GF: We made the decision in ULE to take one bit for a flag.
	GF: 32kbytes chunks are big enough, it seems foolish to collect lots of 
	small fragments and build a really large compound packet (i.e. 64k, 16b).
	HC: We talked on the list about how we could secure MPEG signaling. This 
	is hard for ULE, since they not sent on the same Stream. Using this 
	extension it seems you could secure signalling messages.
	GF: This seems to provide a way to secure SI messages over the link, 
	if you had ULE security.

	GF: The charter describes only MPEG-2 TS. Should we be asking to extend 
	this to cover DVB-S2 here? or leave it to ETSI and DVB? Is there interest 
	and energy for this work here?
	Peter Tomsu: I am strictly for doing this work in the working group here, 
	doing the IP work elsewhere may result in a different outcome.

	WG Chair asked for a Hum indicating this is useful for this WG to do 
	(Loud Hum).
	WG Chair called a Hum for people who thought this was not relevant or may 
	not yet be ready (None).

	Marie-Jose ? (not MJM!): There was much interest in IP transport 
	using GSE. The presentation was for S2 only. Could this also be used in DVB-H? 
	Is this a step to replace DVB-H?
	JC: I think the idea is to replace MPEG-2 TS rather than MPE.
	GF: There has been ideas in DVB on a second generation system. The way in 
	which MPE is used in DVB-H is somewhat different. I do not know what the 
	long-term plan is in DVB, and that is really a question to take to the 
	DVB Forum, rather than for here.

Implementation status feedback, Gorry Fairhurst
	No implementor here in this session.

Session closed at 4:56pm.