[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed)
Hi George,
Thanks for the comments and suggestions. Please find our response to them inline:
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of George Gross
Sent: Sat 01/07/2006 01:04
To: ipdvb@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@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@surrey.ac.uk
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
>
> ________________________________
>
> From: Gorry Fairhurst [mailto:gorry@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 <draft-cruickshank-ipdvb-sec-02.txt>
>
> Best wishes,
>
> Gorry
>
>
>
>
>
>
Hi George,
Thanks for the comments and suggestions. Please find our response to them inline:
________________________________
From: owner-ipdvb@erg.abdn.ac.uk on behalf of George Gross
Sent: Sat 01/07/2006 01:04
To: ipdvb@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@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@surrey.ac.uk
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
>
> ________________________________
>
> From: Gorry Fairhurst [mailto:gorry@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 <draft-cruickshank-ipdvb-sec-02.txt>
>
> Best wishes,
>
> Gorry
>
>
>
>
>
>