TESLA I-D update + change in the EXT_AUTH format

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