AW: Réf. : Re: Encryption control of SNDU

["Fritsche Wolfgang" <Fritsche@iabg.de>]

> -----Ursprüngliche Nachricht-----
> Von: owner-ip-dvb@erg.abdn.ac.uk 
> [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von 
> alain.ritoux@6wind.com
> Gesendet: Freitag, 27. Februar 2004 08:25
> Betreff: Re: Réf. : Re: Encryption control of SNDU
> 
> 
> 
> Dear Laurent and all,
> 
> Not being a satcom expert I cannot argue the L2 security 
> details, but I do understanf your concern. But some precision 
> need to be done about the IPsec "drawbacks" paragraph
> 
> Laurent.Claverotte@space.alcatel.fr wrote:
> 
> > ... snip
> > 
> > 2. Solutions comparison
> > 
> > ... snip
> > - IPSec has lot of drawbacks :  it is not a L2 solution, it is an
> > end-to-end technology, it can interfere with the end-to-end security
> > solution, it can interfere with satellite techniques (PEP), 
> it does not
> > provide encryption of  multicast flows and it generates 
> many overheads and
> > number of signaling messages!!!!!! Lots of comparison studies and
> > simulations have been performed by Alcatel leading to reject this
> > solution!!
> 
> * It is not an L2 solution :
> well, some might see it a a plus.  end of religious debate ;-)
> 
> * its is an end-to-end technology
> No, It can support end-to-end security (I mean host-to-host), 
> but the tunnel mode is available for security gateways, hence 
> allowing securisation of part of the total path. for exemple 
> between the DVB sender, and the DVB receiver (even if it is a 
> host and not a router it can behave as a security gateway for 
> himself).
> 
> * it can interfere with end-to-end security solution
> ??? I don't understand the argument :
> It is a solution, that works at IP level, in both end-to-end 
> model or gateway-to-gateway model. Both models can be used 
> simultaneously, while working over a secure L2, for 
> transporting SSL ... I see no contradiction.
> 
> * it can interfere with satellite techniques (PEP)
> Could you elaborate, because all it does it take an IP packet 
> and generate one other IP packet. How can satellite technique 
> interfere without messing into IP level?

If it interferes with PEPs depends on the architecture, that is the position of the IPsec functionality relatively to the PEPs.

> 
> * multicast :
> Indeed it does not protect multicast yet, but work is in 
> progress. if there is an easy solution to key distribution, 
> the msec IETF wg should be informed

Multicast security without key management should work already with most IPsec implementations (they should not differ between IP unicast and IP Multicast destination address of an SA, and the spec also doesn't exlude this).

Multicast key management is in the cycle of standardisation, and has already been demonstrated as prototype (Haitham and Logica have done this within an ESA project, making using GSAKMP light).

Cheers,

Wolfgang

> 
> * it generates overhead :
> Yes there is overhead, but I don't really see fields in 
> AH/ESP that are unncessary.
> 
> * many signalling messages :
> I thnk you refer here to IKE. Of course some messages are 
> exchanged for key negociation, but I think it is the price 
> for dynamic keying. L2 securisation with dynamic keying will 
> allso generate messages exchanges. Anyway, those exchanges 
> are done for each IPsec tunnel, and once done have generated 
> key whose lifetime can be chosen (in term of duration and/or 
> tarfic volume), so the overhead relatively to the global 
> volume should be quite small.
> 
> Are those Alcatel comparison studies and/or simulations 
> available somewhere, could be interesting.
> 
> Regards.
> Alain.
> -- 
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
> 
>