Re: ULE Extension Header Thoughts - Security

[Haitham Cruickshank <H.Cruickshank@eim.surrey.ac.uk>]

Hi All,

Further to Gorry's request about the security issue here is the reply from my
colleague Sunil Iyengar (Sunny)
re: http://www.erg.abdn.ac.uk/ip-dvb/archive/msg00731.html

 >>> Hilmar Linder:
 >>> o) Does it make sense to define the header types 0x002 and 0x003 as
 >>> mandatory encryption header (section 2.1). As different encryptions
 >>> require different extension headers we should probably only
 >>> define that the next-layer-header types should be larger than
 >>> 0x001 and smaller than 0x0100.

 >> Gorry:
 >> Any chance I can get a quick security view on this query....
 >>
 >> My thoughts were that the encryption algorithm, use of padding,
 >> etc were normally negotiated as a part of the key exchange process
 >> - therefore you don't need to define separate link formats for
 >> each encryption format.
 >>


//Sunny:
You are right that all the parameters for the encryption process are
negotiated via key exchange mechanisms or policy mechanisms. There is
always a tendency to separate key management (negotiation ) with link
formats.

 >>> Hilmar Linder:
 >>> o) How many different encryption schemes do we expect to
 >>> support with the ULE extension headers? Is the type range
 >>> allocated sufficiently large?

 >>> Any other thoughts?


 >> Gorry:
 >> My take was:
 >> When a new encryption algorithm is introduced, the
 >> link still marks the packet as "encrypted", but negotiates
 >> a different type of encryption.  This does not require an extra
 >> link frame type, only a new key exchange format.

// Sunny:
If a new encryption algorithm is used, then a key exchange is done prior
to its usage. This does not require a different link type, only marking
of the packet as "encrypted" is sufficient.

When a packet is received it knows which algorithm is being used and the
parameters and hence one does not have to include it in the link type
only to indicate that it is encrypted.

Moreover, it is necessary to have the Odd and Even type of encryption
header fields because of the rekey.

Hope that answers the question.

Cheers
Sunny

--
Dr. Haitham S. Cruickshank

Senior Research Fellow
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/