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

From: <[email-masked]>
Date: Fri, 7 Jul 2006 15:59:45 +0100

Hi George,
Thanks for the comments and suggestions. Please find our response to them inline:

________________________________

From: [email-masked] on behalf of George Gross
Sent: Sat 01/07/2006 01:04
To: [email-masked]
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 [email-masked] 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: [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, 7 Jul 2006 11:23:49 -0400 (EDT)

Hi Sunny,

On Fri, 7 Jul 2006 [email-masked] wrote:

<snip>
> 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.

> 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?

> // 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...

<snip>
> 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.

> Thanks for your detailed comments

u-r-welcome ;o)

I'll be off-net until Sunday, C-U@Montreal

br,
	George

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 08 Jul 2006 05:36:36 -0400

I have a few specific comments...

> 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?

<SNIP>

> 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). 

<SNIP>