RE: Comments on draft-cruickshank security requirements

[<S.Iyengar@surrey.ac.uk>]

Hi All,
Please find my comments 
 
Cheers
Sunny
 
 

________________________________

From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
Sent: Tue 21/11/2006 17:57
To: ipdvb@erg.abdn.ac.uk
Subject: Comments on draft-cruickshank security requirements




I have the following comments which I would like to discuss on the ipdvb
mailing list.

Gorry Fairhurst
(as ipdvb WG Chair)

---

Comments/Issues:

1) Are the scenarios OK? are they applicable to all deployments?  with
satellite, cable, S2, Terrestrial, ATSC, etc?

//Sunny

//Yes it reflects in th enew draft i.e. in the threat scenarios which have been expanded


2) I think we need to tease out the work on what is meant by L2
authentication on pt-2-pt or pt-2-mpt links? Appropriate authentication
methods must be determined... In Internet security ³integrity² is often more
important than ³confidentiality² - but for these links we suggest the
converse is true - since authentication and e2e delivery checks are best
provided at of above the IP Layers... Where do we judge what are the
appropriate goals for level 2 authentication?


//Sunny

//I think it has been clarified in the new draft (hopefully)



3) I didn't understand what you meant by:
Page 9:
/problematic in the case of broadcast networks such as MPEG-2 transmission
networks. /
- why? - because of easy availability of receiver hardware and the wide
geographical span of the networks... or other reasons?

//Sunny

//Yes thats what we were trying to say. Anyway changed it to be more precise


4) I would like to see more references to methods used by DVB/MPEG-2 network
architectures ...
* How is the proposal positioned against technologies from say the IEEE (for
802.14; 802.16).

 

//Sunny

//Any suggestions ?????



5) Finally: Algorithm agility is required (crypto algorithms, hashes, become
obsolete and need to be updated) for all IETF security mechanisms, this
should be a clear & distinct requirement for the work this document
proposes.


//Sunny

//Agree and has been added to the new draft
-----------------------------------------------------------------



Cheers

Sunny






Hi All,
Please find my comments 
 
Cheers
Sunny
 
 

________________________________

From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst
Sent: Tue 21/11/2006 17:57
To: ipdvb@erg.abdn.ac.uk
Subject: Comments on draft-cruickshank security requirements




I have the following comments which I would like to discuss on the ipdvb
mailing list.

Gorry Fairhurst
(as ipdvb WG Chair)

---

Comments/Issues:

1) Are the scenarios OK? are they applicable to all deployments?  with
satellite, cable, S2, Terrestrial, ATSC, etc?

//Sunny

//Yes it reflects in th enew draft i.e. in the threat scenarios which have been expanded


2) I think we need to tease out the work on what is meant by L2
authentication on pt-2-pt or pt-2-mpt links? Appropriate authentication
methods must be determined... In Internet security ³integrity² is often more
important than ³confidentiality² - but for these links we suggest the
converse is true - since authentication and e2e delivery checks are best
provided at of above the IP Layers... Where do we judge what are the
appropriate goals for level 2 authentication?


//Sunny

//I think it has been clarified in the new draft (hopefully)



3) I didn't understand what you meant by:
Page 9:
/problematic in the case of broadcast networks such as MPEG-2 transmission
networks. /
- why? - because of easy availability of receiver hardware and the wide
geographical span of the networks... or other reasons?

//Sunny

//Yes thats what we were trying to say. Anyway changed it to be more precise


4) I would like to see more references to methods used by DVB/MPEG-2 network
architectures ...
* How is the proposal positioned against technologies from say the IEEE (for
802.14; 802.16).

 

//Sunny

//Any suggestions ?????



5) Finally: Algorithm agility is required (crypto algorithms, hashes, become
obsolete and need to be updated) for all IETF security mechanisms, this
should be a clear & distinct requirement for the work this document
proposes.


//Sunny

//Agree and has been added to the new draft
-----------------------------------------------------------------



Cheers

Sunny