Subject: FW: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (enclosed)

From: <[email-masked]>
Date: Sat, 24 Jun 2006 09:24:10 +0100

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: [email-masked] 
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

________________________________

From: Gorry Fairhurst [mailto:[email-masked]]
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

---

From: George Gross <[email-masked]>
Date: Fri, 30 Jun 2006 20:04:01 -0400 (EDT)

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