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

[George Gross <gmgross@nac.net>]

Hi Sunny,

On Fri, 7 Jul 2006 S.Iyengar@surrey.ac.uk wrote:

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

<snip>
> 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@Montreal

br,
	George
>
>
>
> 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
> >
> >
> >
> >
> >
> >
>
>
>
>