From gmgross at nac.net Sat Jul 1 01:04:01 2006 From: gmgross at nac.net (George Gross) Date: Fri, 30 Jun 2006 20:04:01 -0400 (EDT) Subject: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) In-Reply-To: Message-ID: Hi Haitham and co-authors, I reviewed your draft, and from what I can tell, the proposed ULE security extension header fits the requirements in many regards. I do have a few comments and clarifications: 1) the sequence number processing steps described in section 2.3 omits mention of updating of the transmitter's ULE-SA sequence number state variable. 2) section 2.4 omits mention of updating the receiver's sequence number state variable's update procedure. your procedure implicitly assumes in order delivery of the SNDUs, which is different than IPsec. as you may recall, IPsec defines an algorithm with a sliding window for acceptable sequence numbers that handles out of order delivery. I would suggest should pointing out the ULE dependency on the FIFO delivery order. 3) In reading over your description of the ULE-SPD, it seemed to me that it really augments the RFC4301 SPD with at least a traffic selector for the NPA address, and also temporary NPA. you may wish to consider whether other ULE header fields (e.g. the type field) can also participate in the ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? this would be helpful to highlight in your intro about the ULE-SPD. 4) the focus of the document seems to be on the SNDU flow from the TS-Mux to the receiver(s). yet would not DVB-RCS require comparable security protections for the inverse SNDU traffic flow? in that case, does the inbound ULE-SPD within the TS-Mux need to know the source NPA address when decrypting a non-IP layer-3 PDU since it can't de-mux using the source IP address? 5) assuming there is a VLAN group within a DVB-RCS network, is there a distinct ULE SA with anti-replay state maintained by the TS-Mux SAD for each subscriber terminal within that VLAN? in other words, is there a ULE-SA per VLAN Group Speaker? 6) as mentioned in my earlier e-mail, I'm concerned about the 32-bit authenticator field length not being strong enough. BTW, in my earlier e-mail's list item #6, I mistakenly mixed up "TS packets" with SNDUs. plz disregard that statement. Clearly, there isn't a MAC computed per TS packet. 7) how would this S-ULE extension header encode a digital signature's data or handle TESLA for a multicast SNDU source authentication? I haven't thought this through entirely, but at first glance this seems like a possible feature for securing ARP or ND multicasts. A ULE-SA using this feature would have its own distinct ULE-SID allocated to it. It would be an example of when you might want more than one S-ULE extension header before the SNDU payload. br, George On Sat, 24 Jun 2006 H.Cruickshank at surrey.ac.uk wrote: > Dear ipdvb WG, > > Gorry has kindly submitted for our the Internet draft on security extensions to ULE(version 2) . > > This draft complements the ULE security requirements that was posted recently. The main focus of the security extension is defining the header format to carry secure data over ULE. > > We (the authors) feel this work fits well to the ipdvb current activity. Many security related issues such as key management and security algorithm are borrowed from existing work in IPsec and MSEC groups. The main focus of this draft is the ULE header format for security. > > Haitham > > ---- > 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/ > > ________________________________ > > From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] > Sent: Fri 23/06/2006 09:11 > To: Internet-Drafts Administrator > Cc: Cruickshank HS Dr (CCSR) > Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) > > > > > On behalf of the authors, I wish to submit the enclosed draft: > > Security Extension for Unidirectional Lightweight Encapsulation > Protocol > > Best wishes, > > Gorry > > > > > > From H.Cruickshank at surrey.ac.uk Mon Jul 3 16:02:28 2006 From: H.Cruickshank at surrey.ac.uk (H.Cruickshank at surrey.ac.uk) Date: Mon, 3 Jul 2006 16:02:28 +0100 Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Message-ID: Hi George, Many thanks for your comments and they are much appreciated since you are an active member of MSEC group. See responses in-line: ---- 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/ -----Original Message----- From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On Behalf Of George Gross Sent: 30 June 2006 18:37 To: ipdvb at erg.abdn.ac.uk Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Hi Haitham and co-authors, since your ULE security requirements draft cites both GSAKMP and IPsec, I thought it merited a closer look. In parallel, I've also been looking at the ULE security extension header draft too, but I will comment on that in a separate e-mail. First off, let me qualify what I'm about to say, as my understanding of the IPDVB architecture is still imperfect. I'm coming from a MSEC perspective, and I'll need to verify some of my assumptions along the way, so please let know if I'm off the mark... ASSUMPTIONS: Viewed from 10,000 feet (or perhaps even better from a geosynchronous orbit ;o) the IPDVB network can be characterized a point to multi-point layer-2 network topology, which may or may not be capable of satellite based bi-directional Internet communication. In any case, terrestrial Internet UDLR communications will be available when the satellite link is one-way. Haitham : That is Correct Peer-to-peer communications between the subscribers is possible only via the MPEG Transmission Stream Multiplexor acting a layer-2 relay (or layer-3 router). The service model presented to each subscriber is effectively a private Layer-2 virtual Ethernet LAN. In the simplest topology, the VLAN has only two MAC station addresses: a Service Provider's edge router interface and the individual subscriber's DVB terminal. In a corporate setting, the VLAN would have a closed group of MAC station addresses, at least one of which would be an IP router. In this VLAN configuration, it is possible to send a layer-2 frame multicast from a MAC station to all other MAC stations on the same VLAN (i.e. MPEG-TS-Mux duplicates and issues the multicast on behalf of the subscriber terminal). It is also possible to send a unicast layer-2 frame between any two subscriber MAC stations belonging to the VLAN via the MPEG-TS-Mux. In other words, the VLAN maps into a secure group. Haitham: Correct QUESTIONS: If the above set of assumptions are accurate, then I have the following comments and questions about the IPDVB security requirements. 1) The IPDVB security requirements talk about "address hiding", but really that security service is better described as "identity protection using a pseudonym MAC address". Please add some words to that effect. I agree that this is a valuable service to provide for IPDVB. Haitham: Yes, that is a good suggestion. We will do that. However, it does raise some questions in my mind: a. what conditions would trigger the pseudonym MAC address to change? policy defined lifetime? or is it quasi-permanent (i.e. changes only at node reboot)? if the TS-Mux reboots, do the pseudonym MAC addresses change? Haitham: Policy defined lifetime. b. when a node's pseudonym MAC address changes, do all parties communicating with that node's MAC station have to go through address resolution again? how do they detect this event? c. doesn't this problem suggest the requirement that the pseudonym MAC address transitions be made transparent to all of the in the progress communications? Haitham: We agree and we will add this requirement. 2) no where in the document is there a requirement expressed for group SA re-keying (e.g. LKH). I would expect that policy would be set to periodically change the VLAN's SA keys (or after X kilo-bytes sent per key). also, VLAN membership changes would imply a requirement for forward/backward secrecy. Haitham: We assume that this is part of the key management system, which is independent of the ULE security extensions . For example, if GSAKMP is used, then rekey messages are transmitted as IP traffic over ULE. 3) the requierements were not precise about the definition of source authentication. Clearly for pair-wise SA then a MAC is sufficient. For groups, you would need to say whether group authentication or individual source authentication is required. if the answer is both mechanisms, would the requirements ask for per packet choice of that mechanism? Haitham: pair-wise SA and group SA are enough for MPEG transmission systems. 4) section 3 does not use the MUST and SHOULD keywords as often as I would have expected. then again, as a requierements document I don't know if that kind of normative language is necessary. what do people in the IPFVB WG think? Haitham: I will leave this to somebody else. 5) Scenario 1 on page 8 says "ULE MAC address hiding should be provided...". Does that mean that a solution that didn't offer that feature would still be compliant? i.e. "should" is not the same as "must" or "MUST". Haitham: I agree. Thanks. 6) Authentication costs bandwidth, which is at a premium on the satellite link. Would it not be more bandwidth efficient to do authentication at each layer-2 frame PDU boundary rather than for each 184 byte long SNDU unit within that frame? ?Haitham: I agree about the cost bandwidth. Our target for authentications is ULE source (encapsulator). 7) I noticed that the authentication MAC field in your proposed security extension header is 32 bits long, whereas the minimum used with HMAC-SHA1 in the IPsec suite is 96 bits. In terms of cryptographic strength, 32 bits is weak. So I think a rationale for the 32-bit MAC would in order somewhere in this document. Haitham: I agree about the 32-MAC. We will change it. 8) the requirements should indicate whether 64-bit sequence numbers are to be supported (or not) as RFC4301 does define this capability. Haitham: OK we will add that. 9) it was not clear to me (being an IPDVB newbie) at what granularity does the Packet Identifier (PID) get assigned? is there one allocated to each Service Provider? BTW, that acronym is very loaded, usually in other circles it is interpreted to mean "protocol identifier". I would suggest a new acronym. how about "Transport Stream Logical Channel" (TSLC)? Haitham: PID stands for Packet ID. It is a well known term in the MPEG transmission networks. Regarding IP packet, one PID can be used to transport one or several IP flows. for example you can use a single PID to form a VPN over MPEG transmission network. 10) ESP allows padding to deliberately lengthen the payload, with the intent of protecting against traffic analysis. IPDVB may not want to provide that service, but since this document refers to IPsec as its model, in general it would useful to systematically say what subset is being required for this feature or any other that IPsec offers. Haitham: OK we will analyse this. Again bandwidth has a price here. 11) it would be useful to enumerate what pre-configured or out of band installed parameters are assumed to be known to the subscriber terminal about its layer-2 environment, versus what parameters are discovered or setup by protocols. for example, I would expect certain trust anchor public keys would have to be pre-placed on the subscriber terminal. Haitham: OK, will do. hth, George On Wed, 21 Jun 2006, Gorry Fairhurst wrote: > 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-02.txt > Pages : 16 > Date : 2006-6-20 > > 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. This work is intended as a work item of the > ipdvb WG, and contributions are sought from the IETF on this topic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-02 > .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-02.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-02.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. > .txt> > > From gorry at erg.abdn.ac.uk Mon Jul 3 16:04:31 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Mon, 03 Jul 2006 16:04:31 +0100 Subject: Agenda for meeting on MONDAY, July 10, 2006 . Message-ID: The ipdvb WG will meet next week at 1520-1720 (Afternoon Session II) on MONDAY, July 10, 2006 at IETF-66: http://www.ietf.org/meetings/IETF-66.html The agenda for the ipdvb meeting is at: http://www3.ietf.org/proceedings/06jul/agenda/ipdvb.txt * IMPLEMENTORS of ULE please note that time has been allocated to report on the current status of implementation of the ULE Encapsulator or Receiver. If you would like to present (or wish the Chair to present for you) 1 or 2 slides on this topic (especially on implementation experience and the currently implemented Spec), please send these to the WG Chair in advance of the meeting. * All other presenters please send me copies of your slides to upload by Thursday this week - ahead of the meeting, to allow remote participants to be able to read and follow them. Best wishes, Gorry Fairhurst (ipdvb WG Chair) From marie at mjmontpetit.com Mon Jul 3 16:42:54 2006 From: marie at mjmontpetit.com (Marie-Jose Montpetit) Date: Mon, 03 Jul 2006 08:42:54 -0700 Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Message-ID: <20060703084254.ca5566c7162b3cfcb6c200079b757bd6.297b9211d4.wbe@email.secureserver.net> Do we want to limit the assumptions to the satellite link? In my opinion it limits the scope of the work even if essentially ULE is for satellites. /mjm > -------- Original Message -------- > Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt > From: H.Cruickshank at surrey.ac.uk > Date: Mon, July 03, 2006 11:02 am > To: , > > Hi George, > > Many thanks for your comments and they are much appreciated since you > are an active member of MSEC group. See responses in-line: > > > ---- > > 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/ > > > > -----Original Message----- > From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On > Behalf Of George Gross > Sent: 30 June 2006 18:37 > To: ipdvb at erg.abdn.ac.uk > Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt > > Hi Haitham and co-authors, > > since your ULE security requirements draft cites both GSAKMP and IPsec, > I thought it merited a closer look. In parallel, I've also been looking > at the ULE security extension header draft too, but I will comment on > that in a separate e-mail. > > First off, let me qualify what I'm about to say, as my understanding of > the IPDVB architecture is still imperfect. I'm coming from a MSEC > perspective, and I'll need to verify some of my assumptions along the > way, so please let know if I'm off the mark... > > ASSUMPTIONS: > > Viewed from 10,000 feet (or perhaps even better from a geosynchronous > orbit ;o) the IPDVB network can be characterized a point to multi-point > layer-2 network topology, which may or may not be capable of satellite > based bi-directional Internet communication. In any case, terrestrial > Internet UDLR communications will be available when the satellite link > is one-way. > Haitham : That is Correct > > Peer-to-peer communications between the subscribers is possible only via > the MPEG Transmission Stream Multiplexor acting a layer-2 relay (or > layer-3 router). > > The service model presented to each subscriber is effectively a private > Layer-2 virtual Ethernet LAN. In the simplest topology, the VLAN has > only two MAC station addresses: a Service Provider's edge router > interface and the individual subscriber's DVB terminal. In a corporate > setting, the VLAN would have a closed group of MAC station addresses, at > least one of which would be an IP router. In this VLAN configuration, it > is possible to send a layer-2 frame multicast from a MAC station to all > other MAC stations on the same VLAN (i.e. MPEG-TS-Mux duplicates and > issues the multicast on behalf of the subscriber terminal). It is also > possible to send a unicast > layer-2 frame between any two subscriber MAC stations belonging to the > VLAN via the MPEG-TS-Mux. In other words, the VLAN maps into a secure > group. > Haitham: Correct > > QUESTIONS: > > If the above set of assumptions are accurate, then I have the following > comments and questions about the IPDVB security requirements. > > 1) The IPDVB security requirements talk about "address hiding", but > really that security service is better described as "identity protection > using a pseudonym MAC address". Please add some words to that effect. I > agree that this is a valuable service to provide for IPDVB. > > Haitham: Yes, that is a good suggestion. We will do that. > However, it does raise some questions in my mind: > > a. what conditions would trigger the pseudonym MAC address to change? > policy defined lifetime? or is it quasi-permanent (i.e. changes only at > node reboot)? if the TS-Mux reboots, do the pseudonym MAC addresses > change? > Haitham: Policy defined lifetime. > > b. when a node's pseudonym MAC address changes, do all parties > communicating with that node's MAC station have to go through address > resolution again? how do they detect this event? > > c. doesn't this problem suggest the requirement that the pseudonym MAC > address transitions be made transparent to all of the in the progress > communications? > Haitham: We agree and we will add this requirement. > > 2) no where in the document is there a requirement expressed for group > SA re-keying (e.g. LKH). I would expect that policy would be set to > periodically change the VLAN's SA keys (or after X kilo-bytes sent per > key). also, VLAN membership changes would imply a requirement for > forward/backward secrecy. > Haitham: We assume that this is part of the key management system, > which is independent of the ULE security extensions . For example, if > GSAKMP is used, then rekey messages are transmitted as IP traffic over > ULE. > > 3) the requierements were not precise about the definition of source > authentication. Clearly for pair-wise SA then a MAC is sufficient. For > groups, you would need to say whether group authentication or individual > source authentication is required. if the answer is both mechanisms, > would the requirements ask for per packet choice of that mechanism? > Haitham: pair-wise SA and group SA are enough for MPEG transmission > systems. > > 4) section 3 does not use the MUST and SHOULD keywords as often as I > would have expected. then again, as a requierements document I don't > know if that kind of normative language is necessary. what do people in > the IPFVB WG think? > Haitham: I will leave this to somebody else. > > 5) Scenario 1 on page 8 says "ULE MAC address hiding should be > provided...". Does that mean that a solution that didn't offer that > feature would still be compliant? i.e. "should" is not the same as > "must" > or "MUST". > Haitham: I agree. Thanks. > > 6) Authentication costs bandwidth, which is at a premium on the > satellite link. Would it not be more bandwidth efficient to do > authentication at each layer-2 frame PDU boundary rather than for each > 184 byte long SNDU unit within that frame? > ?Haitham: I agree about the cost bandwidth. Our target for > authentications is ULE source (encapsulator). > > 7) I noticed that the authentication MAC field in your proposed security > extension header is 32 bits long, whereas the minimum used with > HMAC-SHA1 in the IPsec suite is 96 bits. In terms of cryptographic > strength, 32 bits is weak. So I think a rationale for the 32-bit MAC > would in order somewhere in this document. > Haitham: I agree about the 32-MAC. We will change it. > > 8) the requirements should indicate whether 64-bit sequence numbers are > to be supported (or not) as RFC4301 does define this capability. > Haitham: OK we will add that. > > 9) it was not clear to me (being an IPDVB newbie) at what granularity > does the Packet Identifier (PID) get assigned? is there one allocated to > each Service Provider? BTW, that acronym is very loaded, usually in > other circles it is interpreted to mean "protocol identifier". I would > suggest a new acronym. how about "Transport Stream Logical Channel" > (TSLC)? > Haitham: PID stands for Packet ID. It is a well known term in the MPEG > transmission networks. Regarding IP packet, one PID can be used to > transport one or several IP flows. for example you can use a single PID > to form a VPN over MPEG transmission network. > > 10) ESP allows padding to deliberately lengthen the payload, with the > intent of protecting against traffic analysis. IPDVB may not want to > provide that service, but since this document refers to IPsec as its > model, in general it would useful to systematically say what subset is > being required for this feature or any other that IPsec offers. > Haitham: OK we will analyse this. Again bandwidth has a price here. > > 11) it would be useful to enumerate what pre-configured or out of band > installed parameters are assumed to be known to the subscriber terminal > about its layer-2 environment, versus what parameters are discovered or > setup by protocols. for example, I would expect certain trust anchor > public keys would have to be pre-placed on the subscriber terminal. > Haitham: OK, will do. > > > > hth, > > George > > On Wed, 21 Jun 2006, Gorry Fairhurst wrote: > > > 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-02.txt > > Pages : 16 > > Date : 2006-6-20 > > > > 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. This work is intended as a work item of the > > ipdvb WG, and contributions are sought from the IETF on this topic. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-02 > > .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-02.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-02.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. > > > .txt> > > > > From gorry at erg.abdn.ac.uk Tue Jul 4 10:08:28 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 04 Jul 2006 10:08:28 +0100 Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt In-Reply-To: <20060703084254.ca5566c7162b3cfcb6c200079b757bd6.297b9211d4.wbe@email.secureserver.net> References: <20060703084254.ca5566c7162b3cfcb6c200079b757bd6.297b9211d4.wbe@email.secureserver.net> Message-ID: <44AA300C.3010907@erg.abdn.ac.uk> Indeed Marie-Jose, Satellite links are important and good examples of usage (given that this is one of very few standards that are applicable to point-to-point/wide-area satellite networking). HOWEVER, I agree that the scope MUST be applicable to all transmission media where IP services can be provided - terrestrial, cable, mobile broadcast, etc. I think it would be good to be clear where specific requirement comes from, and identify whether each requirement results from: Wireless transmission (e.g. ease of intercept); Satellite (e.g. additional delay); Asymmetry (e.g. uni-directional routing) Flat/broadcast toplogy (e.g. large number of systems) etc Gorry Marie-Jose Montpetit wrote: > Do we want to limit the assumptions to the satellite link? In my opinion > it limits the scope of the work even if essentially ULE is for > satellites. > > /mjm > > >>-------- Original Message -------- >>Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt >>From: H.Cruickshank at surrey.ac.uk >>Date: Mon, July 03, 2006 11:02 am >>To: , >> >>Hi George, >> >>Many thanks for your comments and they are much appreciated since you >>are an active member of MSEC group. See responses in-line: >> >> >>---- >> >>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/ >> >> >> >>-----Original Message----- >>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] On >>Behalf Of George Gross >>Sent: 30 June 2006 18:37 >>To: ipdvb at erg.abdn.ac.uk >>Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt >> >>Hi Haitham and co-authors, >> >>since your ULE security requirements draft cites both GSAKMP and IPsec, >>I thought it merited a closer look. In parallel, I've also been looking >>at the ULE security extension header draft too, but I will comment on >>that in a separate e-mail. >> >>First off, let me qualify what I'm about to say, as my understanding of >>the IPDVB architecture is still imperfect. I'm coming from a MSEC >>perspective, and I'll need to verify some of my assumptions along the >>way, so please let know if I'm off the mark... >> >>ASSUMPTIONS: >> >>Viewed from 10,000 feet (or perhaps even better from a geosynchronous >>orbit ;o) the IPDVB network can be characterized a point to multi-point >>layer-2 network topology, which may or may not be capable of satellite >>based bi-directional Internet communication. In any case, terrestrial >>Internet UDLR communications will be available when the satellite link >>is one-way. >>Haitham : That is Correct >> >>Peer-to-peer communications between the subscribers is possible only via >>the MPEG Transmission Stream Multiplexor acting a layer-2 relay (or >>layer-3 router). >> >>The service model presented to each subscriber is effectively a private >>Layer-2 virtual Ethernet LAN. In the simplest topology, the VLAN has >>only two MAC station addresses: a Service Provider's edge router >>interface and the individual subscriber's DVB terminal. In a corporate >>setting, the VLAN would have a closed group of MAC station addresses, at >>least one of which would be an IP router. In this VLAN configuration, it >>is possible to send a layer-2 frame multicast from a MAC station to all >>other MAC stations on the same VLAN (i.e. MPEG-TS-Mux duplicates and >>issues the multicast on behalf of the subscriber terminal). It is also >>possible to send a unicast >>layer-2 frame between any two subscriber MAC stations belonging to the >>VLAN via the MPEG-TS-Mux. In other words, the VLAN maps into a secure >>group. >>Haitham: Correct >> >>QUESTIONS: >> >>If the above set of assumptions are accurate, then I have the following >>comments and questions about the IPDVB security requirements. >> >>1) The IPDVB security requirements talk about "address hiding", but >>really that security service is better described as "identity protection >>using a pseudonym MAC address". Please add some words to that effect. I >>agree that this is a valuable service to provide for IPDVB. >> >>Haitham: Yes, that is a good suggestion. We will do that. >>However, it does raise some questions in my mind: >> >>a. what conditions would trigger the pseudonym MAC address to change? >>policy defined lifetime? or is it quasi-permanent (i.e. changes only at >>node reboot)? if the TS-Mux reboots, do the pseudonym MAC addresses >>change? >>Haitham: Policy defined lifetime. >> >>b. when a node's pseudonym MAC address changes, do all parties >>communicating with that node's MAC station have to go through address >>resolution again? how do they detect this event? >> >>c. doesn't this problem suggest the requirement that the pseudonym MAC >>address transitions be made transparent to all of the in the progress >>communications? >>Haitham: We agree and we will add this requirement. >> >>2) no where in the document is there a requirement expressed for group >>SA re-keying (e.g. LKH). I would expect that policy would be set to >>periodically change the VLAN's SA keys (or after X kilo-bytes sent per >>key). also, VLAN membership changes would imply a requirement for >>forward/backward secrecy. >>Haitham: We assume that this is part of the key management system, >>which is independent of the ULE security extensions . For example, if >>GSAKMP is used, then rekey messages are transmitted as IP traffic over >>ULE. >> >>3) the requierements were not precise about the definition of source >>authentication. Clearly for pair-wise SA then a MAC is sufficient. For >>groups, you would need to say whether group authentication or individual >>source authentication is required. if the answer is both mechanisms, >>would the requirements ask for per packet choice of that mechanism? >>Haitham: pair-wise SA and group SA are enough for MPEG transmission >>systems. >> >>4) section 3 does not use the MUST and SHOULD keywords as often as I >>would have expected. then again, as a requierements document I don't >>know if that kind of normative language is necessary. what do people in >>the IPFVB WG think? >>Haitham: I will leave this to somebody else. >> >>5) Scenario 1 on page 8 says "ULE MAC address hiding should be >>provided...". Does that mean that a solution that didn't offer that >>feature would still be compliant? i.e. "should" is not the same as >>"must" >>or "MUST". >>Haitham: I agree. Thanks. >> >>6) Authentication costs bandwidth, which is at a premium on the >>satellite link. Would it not be more bandwidth efficient to do >>authentication at each layer-2 frame PDU boundary rather than for each >>184 byte long SNDU unit within that frame? >>?Haitham: I agree about the cost bandwidth. Our target for >>authentications is ULE source (encapsulator). >> >>7) I noticed that the authentication MAC field in your proposed security >>extension header is 32 bits long, whereas the minimum used with >>HMAC-SHA1 in the IPsec suite is 96 bits. In terms of cryptographic >>strength, 32 bits is weak. So I think a rationale for the 32-bit MAC >>would in order somewhere in this document. >>Haitham: I agree about the 32-MAC. We will change it. >> >>8) the requirements should indicate whether 64-bit sequence numbers are >>to be supported (or not) as RFC4301 does define this capability. >>Haitham: OK we will add that. >> >>9) it was not clear to me (being an IPDVB newbie) at what granularity >>does the Packet Identifier (PID) get assigned? is there one allocated to >>each Service Provider? BTW, that acronym is very loaded, usually in >>other circles it is interpreted to mean "protocol identifier". I would >>suggest a new acronym. how about "Transport Stream Logical Channel" >>(TSLC)? >>Haitham: PID stands for Packet ID. It is a well known term in the MPEG >>transmission networks. Regarding IP packet, one PID can be used to >>transport one or several IP flows. for example you can use a single PID >>to form a VPN over MPEG transmission network. >> >>10) ESP allows padding to deliberately lengthen the payload, with the >>intent of protecting against traffic analysis. IPDVB may not want to >>provide that service, but since this document refers to IPsec as its >>model, in general it would useful to systematically say what subset is >>being required for this feature or any other that IPsec offers. >>Haitham: OK we will analyse this. Again bandwidth has a price here. >> >>11) it would be useful to enumerate what pre-configured or out of band >>installed parameters are assumed to be known to the subscriber terminal >>about its layer-2 environment, versus what parameters are discovered or >>setup by protocols. for example, I would expect certain trust anchor >>public keys would have to be pre-placed on the subscriber terminal. >>Haitham: OK, will do. >> >> >> >>hth, >> >> George >> >> On Wed, 21 Jun 2006, Gorry Fairhurst wrote: >> >> >>>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-02.txt >>> Pages : 16 >>> Date : 2006-6-20 >>> >>>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. This work is intended as a work item of the >>>ipdvb WG, and contributions are sought from the IETF on this topic. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-02 >>>.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-02.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-02.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. >>>>>.txt> >>> >>> > > From H.Cruickshank at surrey.ac.uk Tue Jul 4 16:44:20 2006 From: H.Cruickshank at surrey.ac.uk (H.Cruickshank at surrey.ac.uk) Date: Tue, 4 Jul 2006 16:44:20 +0100 Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Message-ID: OK Gorry, I agree with your comments and we will include your suggestions in the next version. Thanks. Haitham ---- 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/ -----Original Message----- From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] Sent: 04 July 2006 10:08 To: ipdvb at erg.abdn.ac.uk Cc: gmgross at nac.net; Cruickshank HS Dr (CCSR) Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt Indeed Marie-Jose, Satellite links are important and good examples of usage (given that this is one of very few standards that are applicable to point-to-point/wide-area satellite networking). HOWEVER, I agree that the scope MUST be applicable to all transmission media where IP services can be provided - terrestrial, cable, mobile broadcast, etc. I think it would be good to be clear where specific requirement comes from, and identify whether each requirement results from: Wireless transmission (e.g. ease of intercept); Satellite (e.g. additional delay); Asymmetry (e.g. uni-directional routing) Flat/broadcast toplogy (e.g. large number of systems) etc Gorry Marie-Jose Montpetit wrote: > Do we want to limit the assumptions to the satellite link? In my > opinion it limits the scope of the work even if essentially ULE is for > satellites. > > /mjm > > >>-------- Original Message -------- >>Subject: RE: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt >>From: H.Cruickshank at surrey.ac.uk >>Date: Mon, July 03, 2006 11:02 am >>To: , >> >>Hi George, >> >>Many thanks for your comments and they are much appreciated since you >>are an active member of MSEC group. See responses in-line: >> >> >>---- >> >>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/ >> >> >> >>-----Original Message----- >>From: owner-ipdvb at erg.abdn.ac.uk [mailto:owner-ipdvb at erg.abdn.ac.uk] >>On Behalf Of George Gross >>Sent: 30 June 2006 18:37 >>To: ipdvb at erg.abdn.ac.uk >>Subject: Re: I-D ACTION:draft-cruickshank-ipdvb-sec-req-02.txt >> >>Hi Haitham and co-authors, >> >>since your ULE security requirements draft cites both GSAKMP and >>IPsec, I thought it merited a closer look. In parallel, I've also been >>looking at the ULE security extension header draft too, but I will >>comment on that in a separate e-mail. >> >>First off, let me qualify what I'm about to say, as my understanding >>of the IPDVB architecture is still imperfect. I'm coming from a MSEC >>perspective, and I'll need to verify some of my assumptions along the >>way, so please let know if I'm off the mark... >> >>ASSUMPTIONS: >> >>Viewed from 10,000 feet (or perhaps even better from a geosynchronous >>orbit ;o) the IPDVB network can be characterized a point to >>multi-point >>layer-2 network topology, which may or may not be capable of satellite >>based bi-directional Internet communication. In any case, terrestrial >>Internet UDLR communications will be available when the satellite link >>is one-way. >>Haitham : That is Correct >> >>Peer-to-peer communications between the subscribers is possible only >>via the MPEG Transmission Stream Multiplexor acting a layer-2 relay >>(or >>layer-3 router). >> >>The service model presented to each subscriber is effectively a >>private >>Layer-2 virtual Ethernet LAN. In the simplest topology, the VLAN has >>only two MAC station addresses: a Service Provider's edge router >>interface and the individual subscriber's DVB terminal. In a corporate >>setting, the VLAN would have a closed group of MAC station addresses, >>at least one of which would be an IP router. In this VLAN >>configuration, it is possible to send a layer-2 frame multicast from a >>MAC station to all other MAC stations on the same VLAN (i.e. >>MPEG-TS-Mux duplicates and issues the multicast on behalf of the >>subscriber terminal). It is also possible to send a unicast >>layer-2 frame between any two subscriber MAC stations belonging to the >>VLAN via the MPEG-TS-Mux. In other words, the VLAN maps into a secure >>group. >>Haitham: Correct >> >>QUESTIONS: >> >>If the above set of assumptions are accurate, then I have the >>following comments and questions about the IPDVB security requirements. >> >>1) The IPDVB security requirements talk about "address hiding", but >>really that security service is better described as "identity >>protection using a pseudonym MAC address". Please add some words to >>that effect. I agree that this is a valuable service to provide for IPDVB. >> >>Haitham: Yes, that is a good suggestion. We will do that. >>However, it does raise some questions in my mind: >> >>a. what conditions would trigger the pseudonym MAC address to change? >>policy defined lifetime? or is it quasi-permanent (i.e. changes only >>at node reboot)? if the TS-Mux reboots, do the pseudonym MAC addresses >>change? >>Haitham: Policy defined lifetime. >> >>b. when a node's pseudonym MAC address changes, do all parties >>communicating with that node's MAC station have to go through address >>resolution again? how do they detect this event? >> >>c. doesn't this problem suggest the requirement that the pseudonym MAC >>address transitions be made transparent to all of the in the progress >>communications? >>Haitham: We agree and we will add this requirement. >> >>2) no where in the document is there a requirement expressed for group >>SA re-keying (e.g. LKH). I would expect that policy would be set to >>periodically change the VLAN's SA keys (or after X kilo-bytes sent per >>key). also, VLAN membership changes would imply a requirement for >>forward/backward secrecy. >>Haitham: We assume that this is part of the key management system, >>which is independent of the ULE security extensions . For example, if >>GSAKMP is used, then rekey messages are transmitted as IP traffic over >>ULE. >> >>3) the requierements were not precise about the definition of source >>authentication. Clearly for pair-wise SA then a MAC is sufficient. For >>groups, you would need to say whether group authentication or >>individual source authentication is required. if the answer is both >>mechanisms, would the requirements ask for per packet choice of that mechanism? >>Haitham: pair-wise SA and group SA are enough for MPEG transmission >>systems. >> >>4) section 3 does not use the MUST and SHOULD keywords as often as I >>would have expected. then again, as a requierements document I don't >>know if that kind of normative language is necessary. what do people >>in the IPFVB WG think? >>Haitham: I will leave this to somebody else. >> >>5) Scenario 1 on page 8 says "ULE MAC address hiding should be >>provided...". Does that mean that a solution that didn't offer that >>feature would still be compliant? i.e. "should" is not the same as >>"must" >>or "MUST". >>Haitham: I agree. Thanks. >> >>6) Authentication costs bandwidth, which is at a premium on the >>satellite link. Would it not be more bandwidth efficient to do >>authentication at each layer-2 frame PDU boundary rather than for each >>184 byte long SNDU unit within that frame? >>?Haitham: I agree about the cost bandwidth. Our target for >>authentications is ULE source (encapsulator). >> >>7) I noticed that the authentication MAC field in your proposed >>security extension header is 32 bits long, whereas the minimum used >>with >>HMAC-SHA1 in the IPsec suite is 96 bits. In terms of cryptographic >>strength, 32 bits is weak. So I think a rationale for the 32-bit MAC >>would in order somewhere in this document. >>Haitham: I agree about the 32-MAC. We will change it. >> >>8) the requirements should indicate whether 64-bit sequence numbers >>are to be supported (or not) as RFC4301 does define this capability. >>Haitham: OK we will add that. >> >>9) it was not clear to me (being an IPDVB newbie) at what granularity >>does the Packet Identifier (PID) get assigned? is there one allocated >>to each Service Provider? BTW, that acronym is very loaded, usually in >>other circles it is interpreted to mean "protocol identifier". I would >>suggest a new acronym. how about "Transport Stream Logical Channel" >>(TSLC)? >>Haitham: PID stands for Packet ID. It is a well known term in the >>MPEG transmission networks. Regarding IP packet, one PID can be used >>to transport one or several IP flows. for example you can use a single >>PID to form a VPN over MPEG transmission network. >> >>10) ESP allows padding to deliberately lengthen the payload, with the >>intent of protecting against traffic analysis. IPDVB may not want to >>provide that service, but since this document refers to IPsec as its >>model, in general it would useful to systematically say what subset is >>being required for this feature or any other that IPsec offers. >>Haitham: OK we will analyse this. Again bandwidth has a price here. >> >>11) it would be useful to enumerate what pre-configured or out of band >>installed parameters are assumed to be known to the subscriber >>terminal about its layer-2 environment, versus what parameters are >>discovered or setup by protocols. for example, I would expect certain >>trust anchor public keys would have to be pre-placed on the subscriber terminal. >>Haitham: OK, will do. >> >> >> >>hth, >> >> George >> >> On Wed, 21 Jun 2006, Gorry Fairhurst wrote: >> >> >>>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-02.txt >>> Pages : 16 >>> Date : 2006-6-20 >>> >>>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. This work is intended as a work item of the >>>ipdvb WG, and contributions are sought from the IETF on this topic. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-0 >>>2 >>>.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-02.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-02.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. >>>>>2 >>>.txt> >>> >>> > > From gmgross at nac.net Thu Jul 6 13:09:51 2006 From: gmgross at nac.net (George Gross) Date: Thu, 6 Jul 2006 08:09:51 -0400 (EDT) Subject: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt In-Reply-To: <44A27543.3080504@erg.abdn.ac.uk> Message-ID: Hi Gorry, first off, a question about this draft: I'm assuming it is planned for "informational RFC" status, correct? just checking, since there are no MUST/SHOULD ;o) in section 8, the "Security Considerations" should mention that when the optional IPDVB SNDU security mechanisms are present, ARP and ND security becomes nearly at rough parity with a private wireless LAN. The ARP or ND multicast transmissions will be accepted only from those peer DVB terminals that share a common group encryption and common group authentication key provided by SNDU key management. Whereas, without that optional ULE security extension, security is dependent on the Adversary not cracking into the DVB satellite receiver terminal to eavesdrop on the ARP or ND packets addressed to any other DVB terminal in the satellite network. If a DVB terminal is cracked open, then the Adversary could then issue bogus ARP or ND packets, masquerading as a legitimate peer in the ARP or ND protocols. there would also need to be an informational reference added to point at the IPDVB ULE security extension draft (which I'm assuming will become a proposed standard RFC someday). hth, George On Wed, 28 Jun 2006, Gorry Fairhurst wrote: > This note starts the ipdvb WG Last Call for comments for the WG document > named below: > > draft-ietf-ipdvb-ar-04.txt > http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > > This last call will end on 18th July 2006. > > The period of this last call has been extended because it also includes > the week of the IETF meeting. > > You are asked to read the draft and send any issues, comments, or > corrections to this mailing list. The WGLC procedure is the last chance > for this working group to modify/correct this. > > Please do forward any comments to the ipdvb list. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) > From S.Iyengar at surrey.ac.uk Fri Jul 7 15:59:45 2006 From: S.Iyengar at surrey.ac.uk (S.Iyengar at surrey.ac.uk) Date: Fri, 7 Jul 2006 15:59:45 +0100 Subject: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) Message-ID: <018160DBE8D48349A0CABF4424C3DC21AAD3BC@EVS-EC1-NODE1.surrey.ac.uk> Hi George, Thanks for the comments and suggestions. Please find our response to them inline: ________________________________ From: owner-ipdvb at erg.abdn.ac.uk on behalf of George Gross Sent: Sat 01/07/2006 01:04 To: ipdvb at erg.abdn.ac.uk Subject: Re: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) Hi Haitham and co-authors, I reviewed your draft, and from what I can tell, the proposed ULE security extension header fits the requirements in many regards. I do have a few comments and clarifications: 1) the sequence number processing steps described in section 2.3 omits mention of updating of the transmitter's ULE-SA sequence number state variable. //Sunny You are right and will update it. 2) section 2.4 omits mention of updating the receiver's sequence number state variable's update procedure. your procedure implicitly assumes in order delivery of the SNDUs, which is different than IPsec. as you may recall, IPsec defines an algorithm with a sliding window for acceptable sequence numbers that handles out of order delivery. I would suggest should pointing out the ULE dependency on the FIFO delivery order. //Sunny You are right and will update it. Regarding the order delivery, unlike IPSec, MPEG2 networks do not need sliding window for acceptable seq. numbers and hence will point of dependency of ULE on FIFO order. 3) In reading over your description of the ULE-SPD, it seemed to me that it really augments the RFC4301 SPD with at least a traffic selector for the NPA address, and also temporary NPA. you may wish to consider whether other ULE header fields (e.g. the type field) can also participate in the ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? this would be helpful to highlight in your intro about the ULE-SPD. //Sunny Because the security is between the encapsulators and receievers, only the NPA address along with the ULE-SID should be enough as selectors for the databases. Dont intend to evaluate the IP v46 header fields. Will try to clarify this. 4) the focus of the document seems to be on the SNDU flow from the TS-Mux to the receiver(s). yet would not DVB-RCS require comparable security protections for the inverse SNDU traffic flow? //Sunny For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS security on the key management and the DVB-RCS specs. in that case, does the inbound ULE-SPD within the TS-Mux need to know the source NPA address when decrypting a non-IP layer-3 PDU since it can't de-mux using the source IP address? //Sunny Not an Issue. Will be communicated by the Key Management if present. 5) assuming there is a VLAN group within a DVB-RCS network, is there a distinct ULE SA with anti-replay state maintained by the TS-Mux SAD for each subscriber terminal within that VLAN? in other words, is there a ULE-SA per VLAN Group Speaker? // This is the same issue as in IPSec. Will follow the same solution as proposed in the MSec group. 6) as mentioned in my earlier e-mail, I'm concerned about the 32-bit authenticator field length not being strong enough. BTW, in my earlier e-mail's list item #6, I mistakenly mixed up "TS packets" with SNDUs. plz disregard that statement. Clearly, there isn't a MAC computed per TS packet. //I agree with that and it should at least be 16 bytes. Wll change that. Disregarded your previous statement :) 7) how would this S-ULE extension header encode a digital signature's data or handle TESLA for a multicast SNDU source authentication? I haven't thought this through entirely, but at first glance this seems like a possible feature for securing ARP or ND multicasts. A ULE-SA using this feature would have its own distinct ULE-SID allocated to it. It would be an example of when you might want more than one S-ULE extension header before the SNDU payload. //Sunny We thought of the same thing i.e. use an source authentication protocol like tesla applied over many packets as oppposed to per packet as an example. I havent thought this through ourself but at first glance looks like it might need a separate ULE-SID. Hope that helps and will incorporate all the suggestions in the next revision. Thanks for your detailed comments BR Sunny and Haitham br, George On Sat, 24 Jun 2006 H.Cruickshank at surrey.ac.uk wrote: > Dear ipdvb WG, > > Gorry has kindly submitted for our the Internet draft on security extensions to ULE(version 2) . > > This draft complements the ULE security requirements that was posted recently. The main focus of the security extension is defining the header format to carry secure data over ULE. > > We (the authors) feel this work fits well to the ipdvb current activity. Many security related issues such as key management and security algorithm are borrowed from existing work in IPsec and MSEC groups. The main focus of this draft is the ULE header format for security. > > Haitham > > ---- > 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/ > > ________________________________ > > From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] > Sent: Fri 23/06/2006 09:11 > To: Internet-Drafts Administrator > Cc: Cruickshank HS Dr (CCSR) > Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) > > > > > On behalf of the authors, I wish to submit the enclosed draft: > > Security Extension for Unidirectional Lightweight Encapsulation > Protocol > > Best wishes, > > Gorry > > > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msg-4233-341.txt URL: From gmgross at nac.net Fri Jul 7 16:23:49 2006 From: gmgross at nac.net (George Gross) Date: Fri, 7 Jul 2006 11:23:49 -0400 (EDT) Subject: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) In-Reply-To: <018160DBE8D48349A0CABF4424C3DC21AAD3BC@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: Hi Sunny, On Fri, 7 Jul 2006 S.Iyengar at surrey.ac.uk wrote: > 3) In reading over your description of the ULE-SPD, it seemed to me that > it really augments the RFC4301 SPD with at least a traffic selector for > the NPA address, and also temporary NPA. you may wish to consider whether > other ULE header fields (e.g. the type field) can also participate in the > ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate > IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? > this would be helpful to highlight in your intro about the ULE-SPD. > > //Sunny > > Because the security is between the encapsulators and receievers, only > the NPA address along with the ULE-SID should be enough as selectors > for the databases. Dont intend to evaluate the IP v46 header fields. > Will try to clarify this. Q: so what you are saying is that ULE can not select its encryption policy on the basis of per IP source/destination traffic flow? Q: for that matter, what about SPD selecting policy on the basis of source MAC/destination MAC traffic flows? Q: does the TS-Mux have the ability to enforce DISCARD or BYPASS policy on specified SNDU flows? Also, I'd especially recommend that you clarify the SPD interaction with the "D" bit set to '1' as described in RFC 4326 section 4.1. In that case, there is implicit SNDU fragmentation re-assembly state maintained by the SPD/SAD receiver, correct? After the SAD processing decrypts the payload, the IPsec model does policy checking against the inbound SPD-S to confirm compliance (see RFC4301 section 4.4.1 top of page 25). When the "D" flag is '1', there is no NPA present, so this special handling by the ULE SPD must be documented. some other IPsec SPD/SAD model related things you'll need to consider: a. need to talk about how is the ULE PAD used? b. do you support Populate From Packet (PFP) processing? c. do you qualify inbound SAD multicast packet processing by the 2-tuple {destination NPA, ULE SA-ID} ? d. TS maximum transmission unit size impact on PDU processing by SPD (i.e. fragmentation interactions). As a general guideline, I'd recommend that you examine RFC 4301 section by section, and decide what the ULE SPD/SAD/PAD interpretation is, then add that text to the ULE security extension document. in most cases I'd expect you'll describe a subset of IPsec processing, but in any case that subset needs to be said. > > 4) the focus of the document seems to be on the SNDU flow from the TS-Mux > to the receiver(s). yet would not DVB-RCS require comparable security > protections for the inverse SNDU traffic flow? > > > //Sunny > > For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS > security on the key management and the DVB-RCS specs. Not sure I understand, are you saying that the ULE receiver terminal's SPD/SAD/PAD does not participate in its uplink security management? > > > in that case, does the inbound ULE-SPD within the TS-Mux need to know the > source NPA address when decrypting a non-IP layer-3 PDU since it can't > de-mux using the source IP address? > > //Sunny > > Not an Issue. Will be communicated by the Key Management if present. > > 5) assuming there is a VLAN group within a DVB-RCS network, is there a > distinct ULE SA with anti-replay state maintained by the TS-Mux SAD for > each subscriber terminal within that VLAN? in other words, is there a > ULE-SA per VLAN Group Speaker? > > > // This is the same issue as in IPSec. Will follow the same solution as proposed in the MSec group. At this point in time, the MSEC IPsec extensions draft has not put a stake in the ground on this topic. It is recognized that maintaining state at each Group Receiver for each Group Speaker does not scale. But what is the minimum number that a group MUST suport? 1? 16? more than that? in the context of the IPDVB work, I'd suggest nominating a number, and see what folks say... > 7) how would this S-ULE extension header encode a digital signature's data > or handle TESLA for a multicast SNDU source authentication? I haven't > thought this through entirely, but at first glance this seems like a > possible feature for securing ARP or ND multicasts. A ULE-SA using this > feature would have its own distinct ULE-SID allocated to it. It would be > an example of when you might want more than one S-ULE extension header > before the SNDU payload. > > //Sunny > > We thought of the same thing i.e. use an source authentication > protocol like tesla applied over many packets as oppposed to per > packet as an example. I havent thought this through ourself but at > first glance looks like it might need a separate ULE-SID. Makes sense. Probably need to find a few use cases that could benefit from this feature as a way of deciding how it works. e.g. sending any of the MPEG control table contents comes to mind. > > > > Hope that helps and will incorporate all the suggestions in the next revision. > > Thanks for your detailed comments u-r-welcome ;o) I'll be off-net until Sunday, C-U at Montreal br, George > > > > BR > > Sunny and Haitham > > > > br, > George > > On Sat, 24 Jun 2006 H.Cruickshank at surrey.ac.uk wrote: > > > Dear ipdvb WG, > > > > Gorry has kindly submitted for our the Internet draft on security extensions to ULE(version 2) . > > > > This draft complements the ULE security requirements that was posted recently. The main focus of the security extension is defining the header format to carry secure data over ULE. > > > > We (the authors) feel this work fits well to the ipdvb current activity. Many security related issues such as key management and security algorithm are borrowed from existing work in IPsec and MSEC groups. The main focus of this draft is the ULE header format for security. > > > > Haitham > > > > ---- > > 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/ > > > > ________________________________ > > > > From: Gorry Fairhurst [mailto:gorry at erg.abdn.ac.uk] > > Sent: Fri 23/06/2006 09:11 > > To: Internet-Drafts Administrator > > Cc: Cruickshank HS Dr (CCSR) > > Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed) > > > > > > > > > > On behalf of the authors, I wish to submit the enclosed draft: > > > > Security Extension for Unidirectional Lightweight Encapsulation > > Protocol > > > > Best wishes, > > > > Gorry > > > > > > > > > > > > > > > > From gorry at erg.abdn.ac.uk Fri Jul 7 16:38:24 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Fri, 07 Jul 2006 11:38:24 -0400 Subject: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt In-Reply-To: Message-ID: On 6/7/06 13:09, "George Gross" wrote: > Hi Gorry, > > first off, a question about this draft: I'm assuming it is planned for > "informational RFC" status, correct? > Yes. > just checking, since there are no MUST/SHOULD ;o) > Good question, let's discuss this in the ipdvb WG meeting: I can see there are places were more formal language could be used, even in an Informational document. > > in section 8, the "Security Considerations" should mention that when the > optional IPDVB SNDU security mechanisms are present, ARP and ND security > becomes nearly at rough parity with a private wireless LAN. The ARP or ND > multicast transmissions will be accepted only from those peer DVB > terminals that share a common group encryption and common group > authentication key provided by SNDU key management. > > Whereas, without that optional ULE security extension, security is > dependent on the Adversary not cracking into the DVB satellite receiver > terminal to eavesdrop on the ARP or ND packets addressed to any other DVB > terminal in the satellite network. If a DVB terminal is cracked open, then > the Adversary could then issue bogus ARP or ND packets, masquerading as a > legitimate peer in the ARP or ND protocols. > OK, that seems a reasonable addition. The current text says: There are known security issues relating to the use of unsecured address resolution [RFC3756]. Readers are also referred to the known security issues when mapping IP addresses to MAC/NPA addresses using ARP [RFC826] and ND [RFC2461]. It is recommended that AR protocols support authentication of the source of AR messages and the integrity of the AR information, this avoids known security vulnerabilities resulting from insertion of unauthorised AR messages within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] may be used in place of ND. This defines security mechanisms that can protect AR. Does the following additional paragraph capture this?: AR protocols can also be protected by the use of L2 security methods (e.g. Encryption of the ULE SNDU [ID-IPDVB-SEC]). When these methods are used, the security of ARP and ND can be comparable to that of a private LAN: A Receiver will only accept ARP or ND transmissions from the set of peer senders that share a common group encryption and common group authentication key provided by the L2 key management. Add Informative Reference: [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, draft-cruickshank-ipdvb-sec-req-xx.txt. > there would also need to be an informational reference added to point at > the IPDVB ULE security extension draft (which I'm assuming will become a > proposed standard RFC someday). > Would the requirements (INFO) be sufficient (this one is a milestone listed on the Charter page)? > hth, > George > > On Wed, 28 Jun 2006, Gorry Fairhurst wrote: > >> This note starts the ipdvb WG Last Call for comments for the WG document >> named below: >> >> draft-ietf-ipdvb-ar-04.txt >> http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ >> >> This last call will end on 18th July 2006. >> >> The period of this last call has been extended because it also includes >> the week of the IETF meeting. >> >> You are asked to read the draft and send any issues, comments, or >> corrections to this mailing list. The WGLC procedure is the last chance >> for this working group to modify/correct this. >> >> Please do forward any comments to the ipdvb list. >> >> Best wishes, >> >> Gorry Fairhurst >> (ipdvb WG Chair) >> > From gorry at erg.abdn.ac.uk Sat Jul 8 10:36:36 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Sat, 08 Jul 2006 05:36:36 -0400 Subject: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (a few comments) In-Reply-To: Message-ID: I have a few specific comments... On 7/7/06 11:23, "George Gross" wrote: > Hi Sunny, > > On Fri, 7 Jul 2006 S.Iyengar at surrey.ac.uk wrote: > > >> 3) In reading over your description of the ULE-SPD, it seemed to me that >> it really augments the RFC4301 SPD with at least a traffic selector for >> the NPA address, and also temporary NPA. you may wish to consider whether >> other ULE header fields (e.g. the type field) can also participate in the >> ULE-SPD. also not explicitly mentioned is that the ULE-SPD does evaluate >> IP-v4 header fields or IP-v6 header fields beyond the ULE header, correct? >> this would be helpful to highlight in your intro about the ULE-SPD. >> >> //Sunny >> >> Because the security is between the encapsulators and receievers, only >> the NPA address along with the ULE-SID should be enough as selectors >> for the databases. Dont intend to evaluate the IP v46 header fields. >> Will try to clarify this. > > Q: so what you are saying is that ULE can not select its encryption policy > on the basis of per IP source/destination traffic flow? > > Q: for that matter, what about SPD selecting policy on the basis of source > MAC/destination MAC traffic flows? > If you have bridging mode, you also have the possibility of using the MAC source and destination (assuming the bridging extension header is placed before the ULE security header). If the Type field in the ULE security header is not encrypted (should it be?) then you could also use this in policy selection? >> 4) the focus of the document seems to be on the SNDU flow from the TS-Mux >> to the receiver(s). yet would not DVB-RCS require comparable security >> protections for the inverse SNDU traffic flow? >> >> >> //Sunny >> >> For inverse flow it can be either ATM or MPEG. Will leave the DVB-RCS >> security on the key management and the DVB-RCS specs. > > Not sure I understand, are you saying that the ULE receiver terminal's > SPD/SAD/PAD does not participate in its uplink security management? > If you have bi-directional connectivity (i.e. ULE were to be used in both directions, then it would seem sensible to allow ULE security in both directions). From gmgross at nac.net Mon Jul 17 23:47:22 2006 From: gmgross at nac.net (George Gross) Date: Mon, 17 Jul 2006 18:47:22 -0400 (EDT) Subject: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt In-Reply-To: Message-ID: Hi Gorry, your proposed change to the security considerations text (see below) would do just fine.... hth, George On Fri, 7 Jul 2006, Gorry Fairhurst wrote: > On 6/7/06 13:09, "George Gross" wrote: > > > Hi Gorry, > > > > first off, a question about this draft: I'm assuming it is planned for > > "informational RFC" status, correct? > > > Yes. > > > just checking, since there are no MUST/SHOULD ;o) > > > Good question, let's discuss this in the ipdvb WG meeting: I can see there > are places were more formal language could be used, even in an Informational > document. > > > > in section 8, the "Security Considerations" should mention that when the > > optional IPDVB SNDU security mechanisms are present, ARP and ND security > > becomes nearly at rough parity with a private wireless LAN. The ARP or ND > > multicast transmissions will be accepted only from those peer DVB > > terminals that share a common group encryption and common group > > authentication key provided by SNDU key management. > > > > Whereas, without that optional ULE security extension, security is > > dependent on the Adversary not cracking into the DVB satellite receiver > > terminal to eavesdrop on the ARP or ND packets addressed to any other DVB > > terminal in the satellite network. If a DVB terminal is cracked open, then > > the Adversary could then issue bogus ARP or ND packets, masquerading as a > > legitimate peer in the ARP or ND protocols. > > > OK, that seems a reasonable addition. The current text says: > > There are known security issues relating to the use of unsecured > address resolution [RFC3756]. Readers are also referred to the > known security issues when mapping IP addresses to MAC/NPA addresses > using ARP [RFC826] and ND [RFC2461]. It is recommended that AR > protocols support authentication of the source of AR messages and > the integrity of the AR information, this avoids known security > vulnerabilities resulting from insertion of unauthorised AR messages > within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] > may be used in place of ND. This defines security mechanisms that > can protect AR. > > Does the following additional paragraph capture this?: > > AR protocols can also be protected by the use of L2 security methods > (e.g. Encryption of the ULE SNDU [ID-IPDVB-SEC]). When these methods > are used, the security of ARP and ND can be comparable to that of > a private LAN: A Receiver will only accept ARP or ND transmissions from > the set of peer senders that share a common group encryption and > common group authentication key provided by the L2 key management. > > Add Informative Reference: > > [ID-IPDVB-SEC] H.Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security > requirements for the Unidirectional Lightweight Encapsulation (ULE) > protocol", Work in Progress, draft-cruickshank-ipdvb-sec-req-xx.txt. > > > there would also need to be an informational reference added to point at > > the IPDVB ULE security extension draft (which I'm assuming will become a > > proposed standard RFC someday). > > > Would the requirements (INFO) be sufficient (this one is a milestone listed > on the Charter page)? > > > hth, > > George > > > > On Wed, 28 Jun 2006, Gorry Fairhurst wrote: > > > >> This note starts the ipdvb WG Last Call for comments for the WG document > >> named below: > >> > >> draft-ietf-ipdvb-ar-04.txt > >> http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > >> > >> This last call will end on 18th July 2006. > >> > >> The period of this last call has been extended because it also includes > >> the week of the IETF meeting. > >> > >> You are asked to read the draft and send any issues, comments, or > >> corrections to this mailing list. The WGLC procedure is the last chance > >> for this working group to modify/correct this. > >> > >> Please do forward any comments to the ipdvb list. > >> > >> Best wishes, > >> > >> Gorry Fairhurst > >> (ipdvb WG Chair) > >> > > > > From gorry at erg.abdn.ac.uk Tue Jul 18 10:21:06 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 18 Jul 2006 10:21:06 +0100 Subject: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt Message-ID: <44BCA802.6030409@erg.abdn.ac.uk> As WG Chair: draft-ietf-ipdvb-ar-04.txt http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ The WGLC for the above ID is due to end. Please ensure that you send an email to the ipdvb list if there are ANY issues which you think may require further discussion or any comments/corrections. It would also be most useful to email, if you have read the document and have no comments (or just minor corrections). Gorry Fairhurst (IPDVB WG CHAIR) From gorry at erg.abdn.ac.uk Tue Jul 18 10:48:19 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Tue, 18 Jul 2006 10:48:19 +0100 Subject: Updated text for draft-ietf-ipdvb-ar-04.txt Message-ID: <44BCAE63.3050102@erg.abdn.ac.uk> After discussion with an author of [ID-ND-PROXY], the following changes are requested... In section 5.4, draft -04 says: "Equivalent methods could provide IPv6 AR. Procedures for intercepting ND messages are defined in [ID-ND-PROXY]. To perform an AR Server function, the AR information must also be cached. Interactions with SEND are described in [ID-SP-ND]." 1) Add text following this on consistency issue: "The consistency of the cache also needs to be considered when the network topology changes (e.g. IP mobility) or there is intermittent connectivity. In these cases old (stale) information can result in IP packets being directed to an invalid L2 address. Methods also need to provided purge stale AR data from the cache." 2) Replace [ID-ND-PROXY] with citation to [RFC4389] Gorry Fairhurst (as Author) ipdvb From gorry at erg.abdn.ac.uk Wed Jul 19 14:41:08 2006 From: gorry at erg.abdn.ac.uk (Gorry Fairhurst) Date: Wed, 19 Jul 2006 14:41:08 +0100 Subject: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt In-Reply-To: <44BDFE2F.28009.16EE09F3@rupert.ecotel.demon.co.uk> References: <44BDFE2F.28009.16EE09F3@rupert.ecotel.demon.co.uk> Message-ID: <44BE3674.60208@erg.abdn.ac.uk> Thanks Rupert, That was very useful to have your comments. You spotted several thing athat I've now fixed in the new version of the document, which we'll submit next week, after any further comments. Detailed edits in-line. Gorry (as author) Rupert Goodings wrote: > Gorry and all, > > Sorry for late reply. Usual excuses apply(^2) ;-) > > As requested some comments on draft-ietf-ipdvb-ar-04.txt. > > > Generally I think the document is in good shape and provides > a useful introduction to the problems. My earlier major comments > about being clearer on the purpose of the document seem to have been > resolved. > > I have spotted a few editorial nits on rereading. Mostly minor (see below for > details) but I did notice several <> (suggesting more > inputs wanted) in Section 5. I think these can be deleted...but it does > suggest that a V05 would be useful mainly to clean up that section. > > best regards > > Rupert Goodings > Ecotel Ltd/ ETSI WG-BSM Chairman > > ==DETAILED EDITORIALS > > Section 2 and general > Sections 3 &4 use of "MAC Address" which is not defined in Section 2; in > preference to "NPA" which is defined. > Suggest adding MAC Address to Section 2 OK, defined this as: MAC Address: A 6 byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA). > Also suggest using "NPA/MAC Address" in sections 3 and 4. > To be consistent with RFC4326, NPA = ULA address indicated by the D-bit, whereas MAC means IEEE-style address. I've reworked the text to make this clearer. Also made all "NPA/MAC" into "MAC/NPA". Also note a mistake to section (iii) which was confusing about L2 multicast addressess, thsi now reads: " (iii) IP and other protocols may view sets of L3 multicast addresses as link-local. This may produce unexpected results if frames with the corresponding multicast L2 addresses are distributed to systems in a different L3 network or multicast scope (see sections 3.2 and 5.6)" > > Section 2&3 (nit) > All ULE to section 2 > Correct ULE longhand in section 3. > Can you explain which line this problem occurs in? > > Section 3: > (Nit+) The wording of the first requirement could be improved: > replace "A scalable and efficient transmission" > with two points: > "A scalable architecture" > "Efficient use of messages to minimise transmission overheads" > [assuming that is what you mean :-)] > Proposed new text: A scalable architecture that may support large numbers of systems within the MPEG-2 network [RFC4259]. A method for transmission of AR information from an AR Server to clients that minimise the transmission cost (link local multicast, is preferable to subnet broadcast). > > Section 3: > (Nit) Use "context/scope" terminology consistently. Reqs uses "scope"; > following para uses "context" [both words are OK for me]. > Done, scope now used in section 3. > Section 4.1.1; 3rd para > Is this para really discussing AR? The phrase "receive L2 information and > allocate an IP address" seems to be implying RAR instead? > Yes, I think the focus is DHCP as a method to populate the AR cache. > Some rewording may be needed. > [For info, ETSI BSM propose to avoid RAR in satellite context]. > DHCP is at least used in some cable systems and systems using UDLR. > > Section 4.2.4 > (nit) StrengthS /each has their strength/ > > Section 4.3. > Inconsistent use of language: > Title uses "resolution of TS Logical Channels" > body uses "address resolution for TS streams" OK, adjusted text. > [I prefer a hybrid "address resolution for TS Logical Channels"] > Agreed, changed title. > > Section 5: > I assume the <> lines will be deleted? > Also incomplete section xx reference. > I can not find these in rev -04, if you know where theyt are, let me know. > > Section 5.4. 2nd para > Might be better to add a few words as indicated by <<>> below > "follows normal practice for <> IEEE <<802>> > MAC Addresses. > Added: (mapping the IP address to the L2 address) > > ==END > > > Date sent: Tue, 18 Jul 2006 10:21:06 +0100 > From: Gorry Fairhurst > Organization: University of Aberdeen, UK > To: ipdvb at erg.abdn.ac.uk > Subject: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt > Send reply to: ipdvb at erg.abdn.ac.uk > > >>As WG Chair: >> >>draft-ietf-ipdvb-ar-04.txt >>http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ >> >>The WGLC for the above ID is due to end. Please ensure that you send an >>email to the ipdvb list if there are ANY issues which you think may >>require further discussion or any comments/corrections. >> >>It would also be most useful to email, if you have read the document and >>have no comments (or just minor corrections). >> >>Gorry Fairhurst >>(IPDVB WG CHAIR) >> >> >> >> >> >> >> >> > > > > > From stiemerling at netlab.nec.de Tue Jul 25 08:49:05 2006 From: stiemerling at netlab.nec.de (Martin Stiemerling) Date: Tue, 25 Jul 2006 09:49:05 +0200 Subject: Working Group Last Call (WGLC): draft-ietf-ipdvb-ar-04.txt In-Reply-To: <44A27543.3080504@erg.abdn.ac.uk> References: <44A27543.3080504@erg.abdn.ac.uk> Message-ID: <3E832950-2E98-42DF-93DD-DA8D99A02299@netlab.nec.de> Hi all, The draft is fine with me. My comments from -03 have been fixed. Thanks Martin Am 28.06.2006 um 14:25 schrieb Gorry Fairhurst: > This note starts the ipdvb WG Last Call for comments for the WG > document > named below: > > draft-ietf-ipdvb-ar-04.txt > http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > > This last call will end on 18th July 2006. > > The period of this last call has been extended because it also > includes the week of the IETF meeting. > > You are asked to read the draft and send any issues, comments, or > corrections to this mailing list. The WGLC procedure is the last > chance for this working group to modify/correct this. > > Please do forward any comments to the ipdvb list. > > Best wishes, > > Gorry Fairhurst > (ipdvb WG Chair) From P.Pillai at Bradford.ac.uk Tue Jul 25 09:51:14 2006 From: P.Pillai at Bradford.ac.uk (P.Pillai at Bradford.ac.uk) Date: Tue, 25 Jul 2006 09:51:14 +0100 Subject: WGLC Reminder: draft-ietf-ipdvb-ar-04.txt In-Reply-To: <44BCA802.6030409@erg.abdn.ac.uk> Message-ID: <1153817473.44c5db820007a@webmail6.brad.ac.uk> Hi, The document seems to be in good shape. It is fine with me. Regards Prashant Pillai Quoting Gorry Fairhurst : > > As WG Chair: > > draft-ietf-ipdvb-ar-04.txt > http://tools.ietf.org/wg/ipdvb/draft-ietf-ipdvb-ar/ > > The WGLC for the above ID is due to end. Please ensure that you send an > email to the ipdvb list if there are ANY issues which you think may > require further discussion or any comments/corrections. > > It would also be most useful to email, if you have read the document and > have no comments (or just minor corrections). > > Gorry Fairhurst > (IPDVB WG CHAIR) > > > > > > > > > -- Prashant Pillai Research Assistant School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom Phone: 0044-1274-233720 email: p.pillai at bradford.ac.uk ------------------------------------------------------------ This mail sent through IMP: http://webmail.brad.ac.uk To report misuse from this email address forward the message and full headers to misuse at bradford.ac.uk ------------------------------------------------------------