Subject: RE: [MSEC] new TESLA draft

From: Mark Baugher <[email-masked]>
Date: Fri, 05 Apr 2002 08:51:15 -0800

Ran is on extended travel and does not have regular Internet access.  I 
think you are referring to draft-perrig-msec-tesla-intro-00.txt.  I have 
copied the other authors on your note in case they are not receiving mail 
from msec.  I'll take a swag at addressing your points below and invite the 
other authors to contribute as well.

At 05:12 PM 4/5/2002 +0200, LANIEPCE Sylvie FTRD/DMI/CAE wrote:

>Hi,
>
>Regarding Ran's TESLA layer placement question, here are some 
>comments/questions (debate welcome):
>
>I was wondering about the relevance of a msec gateway. Basically, the msec 
>gateway would operate as a boundary between an unsecured network (where 
>the data coming from the source are protected by msec) and a safe network 
>(an intranet for example, where fewer security protections are needed). 
>Note that this scenario could be efficient in terms of key management, as 
>the gateway could act in replacement of many receivers located within the 
>safe network.

I have seen IP multicast configurations similar to this for satellite where 
the IP security serves a function that is analogous to a conditional access 
system that links, say, corporate networks to the satellite WAN.

>So, in this case where data security treatments are externalized from the 
>receivers, within a gateway, it seems to me that it would be better, for 
>performance and cost reasons, to provide these security treatments at IP 
>layer, instead of crossing all the gateway TCP/IP stack up to the 
>application layer.

Security is end-to-end and I think a better security solution is end-to-end 
rather than using what is essentially a firewall.  A packet-filtering 
firewall typically operates on the IP or transport headers, but an 
application firewall operates at the application layer at the cost of 
increased complexity of the middle box.  That being said, I understand your 
point but think that TESLA is better suited to the application layer since 
there is so much buffering that is needed.

>I have the feeling (not that easy to demonstrate) that performing MSec 
>treatments at IP layer is efficient if you opt for possibly externalized 
>(from members, both sender and receiver) msec functionalities . This 
>question probably goes with the relevance of outsourced msec 
>functionalities (data treatment and also key management).

I don't understand your points.

>On the source side, could msec perform some sort of traffic analysis 
>protection (hiding source IP@ ?) if implemented at IP layer ?

I think an IP-in-IP tunnel will do this.  I think this is independent of 
the issue of putting TESLA in the IP layer.

>Are there any cases where application layer placement could give access to 
>selectors not available at other lower layers, in order to apply different 
>security treatments to different types of data within a given application ?

I can imagine, for example, using an RTP SSRC as a selector, which is not 
visible at the IP or transport layer.

>Would TESLA be one source authentication solution among others for 
>MESP/AMESP or would MESP/AMESP stick to TESLA ?

I believe this is so.

>Ran, I do not clearly understand why you mention a TCP hypothesis, since 
>multicast goes with UDP. See TESLA draft, section 5 (drawbacks attached to 
>TCP delays) ?

I don't know.

Mark

>I am not especially pushing hard IP layer placement, I am just letting you 
>know what I can think about (and my analysis is probably (too much) 
>influenced by the IPSec model, altought any AESP...). I am interested 
>in  considering, understanding and analyzing any argument in favour of an 
>application layer placement.
>
>In addition, I am keen to look at msec also considering in details :
>- the security services msec can provide in real applications
>- the opportunities for an ISP to provide msec related functionalities
>in order to take into account their impacts (if any) on msec design. Any 
>opinion on that subject ?
>
>Hope this helps
>
>Regards
>Sylvie
>France Telecom R&D - DMI/SIR
>
>-----Message d'origine-----
>De : Ran Canetti 
>[<mailto:[email-masked]>mailto:[email-masked]]
>Envoye : samedi 2 mars 2002 16:08
>A : [email-masked]
>Objet : [MSEC] new TESLA draft
>
>
>
>[Co-chair hat off]
>
>Folks,
>
>Please take a look at the following new I-D:
>
><http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt>http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt 
>
>
>It provides a general algorithmic/informational presentation of the TESLA
>source authentication mechanism. (This is an updated version of the
>irtf-smug draft from a year ago.)
>
>While you read, please keep in mind the following issue. Our planned next
>step is to write a standards-track draft describing how to implement
>TESLA in a specific scenario. The question is: how to go about it?
>In particular, should we first implement TESLA in the application layer
>or in the IP layer? There are advantages to each option (they are discussed
>in the draft). We would like to get the WG feedback on the draft in general
>and on this question in particular.
>
>Thanks,
>
>Ran
>
>_______________________________________________
>msec mailing list
>[email-masked]
><http://www.pairlist.net/mailman/listinfo/msec>http://www.pairlist.net/mailman/listinfo/msec 
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 05 Apr 2002 13:54:19 -0500

Mark Baugher wrote:

> <deleted text>

The first one!  MESP/AMESP should support source authentication schemes 
other than TESLA as well.

cheers,
Lakshminath

>
>
>> Ran, I do not clearly understand why you mention a TCP hypothesis, 
>> since multicast goes with UDP. See TESLA draft, section 5 (drawbacks 
>> attached to TCP delays) ?
>
>
> I don't know.
>
> Mark
>
>
>> I am not especially pushing hard IP layer placement, I am just 
>> letting you know what I can think about (and my analysis is probably 
>> (too much) influenced by the IPSec model, altought any AESP...). I am 
>> interested in  considering, understanding and analyzing any argument 
>> in favour of an application layer placement.
>>
>> in order to take into account their impacts (if any) on msec design. 
>> Any opinion on that subject ?
>>
>> Hope this helps
>>
>> Regards
>> Sylvie
>> De : Ran Canetti [ mailto:[email-masked] ]
>> http://search.ietf.org/internet-drafts/draft-perrig-msec-tesla-intro-00.txt 
>>
>>
>> http://www.pairlist.net/mailman/listinfo/msec 
>

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Fri, 05 Apr 2002 10:48:01 -0800

yes, I was unclear:  A/MESP would of course support a variety of source 
authentication mechanisms.

thanks, Mark
At 01:54 PM 4/5/2002 -0500, Lakshminath Dondeti wrote:

>>>multicast goes with UDP. See TESLA draft, section 5 (drawbacks attached 
>>>to TCP delays) ?
>>
>>
>>I don't know.
>>
>>Mark
>>
>>
>>>I am not especially pushing hard IP layer placement, I am just letting 
>>>you know what I can think about (and my analysis is probably (too much) 
>>>in  considering, understanding and analyzing any argument in favour of 
>>>an application layer placement.
>>>