Re: New Internet Draft rev: draft-cruickshank-ipdvb-sec-02.txt (a few comments)

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

I have a few specific comments...

On 7/7/06 11:23, "George Gross" <gmgross@nac.net> wrote:

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

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

<SNIP>