Subject: [Rmt] TESLA I-D update + change in the EXT_AUTH format

From: Vincent Roca <[email-masked]>
Date: Tue, 06 Mar 2007 13:03:45 +0100

Hello everybody,

A few points:

1- FYI we updated the TESLA I-D (which expired in the mean-time):

http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-01.txt

2- I think we should update the LCT document, section 5.2.1, when
describing EXT_AUTH, HET=1. It is said that:
         The format of this Header Extension and its processing is
         outside the scope of this document and is to be communicated
         out-of-band as part of the session description.

I don't agree for the following reason.
There are several ways to perform packet content integrity verification
and packet sender authentication. One solution is to digitally sign the
packet, another one is to use TESLA (and other techniques exist)...

I believe we should require (i.e. say in LCT I-D) that the EXT_AUTH
Header Extension Content field starts with a reserved "authentication
scheme identifier" field (4 bits are sufficient). I don't think we need
to reserve the identifier values in the LCT I-D since it could be done
in the I-D that specifies an authentication scheme (e.g. TESLA I-D),
as we do with FEC Enc IDs (or maybe we can do an exception for digital
signatures).

The proposed EXT_AUTH format would be:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   HET (=1)    |      HEL      |SchemID|                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                       +
     ~           Authentication scheme specific content              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"Scheme ID" (Authentication Scheme Identifier) field (4 bits):

       The "Scheme ID" identifies the packet sender authentication scheme.

3- The same remark applies to the NORM PI I-D where this EXT_AUTH header
extension also applies. Here it is even more obvious to have
this extra "authentication scheme identifier" field as several different
authentication schemes would be required for a given NORM session.
Indeed, TESLA only applies to the sender->receiver(s) stream), not to
the feedback packets sent by receivers...

What do you think (in particular Mark/Brian)?

Cheers,

   Vincent

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Brian Adamson <[email-masked]>
Date: Wed, 7 Mar 2007 15:31:24 -0500

A draft agenda for the IETF 68 RMT WG Meeting has been posted to:

http://www.ietf.org/proceedings/07mar/agenda/rmt.txt

Please let Lorenzo or I know if anything was missed or needs to be 
added.  For those providing presentations, if you can provide them 
prior to the meeting, I can post them to the "Meeting Materials" page 
for access to remote participants.

best regards,

-- 
Brian

Brian Adamson
<[email-masked]>