RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt

[canetti <[e-mail]>]

Mike,

If we can design a TESLA standard that's workable for RMT and is also
useful elsewhere then all the better ofcourse. I'm also ok with
splitting the document if it ends up being clearer.

What do the authors think?

Ran


On Fri, 5 Aug 2005, Michael Luby wrote:

> Ran,
> I agree with you, an application may want to use TESLA authentication even
> if it isn't using encryption (or it is using a completely different form of
> encryption that is outside the scope of GDOI, GSAKMP, MIKEY, etc.).  This
> isn't particular to ALC or NORM though, and it seems like such a
> light-weight bootstrapping TESLA protocol that does not require such key
> establishment protocols would be a good independent working group item for
> MSEC to tackle.  Since it is not particular to ALC or NORM and has wider
> applicability, it would be good to do this work once in one place instead of
> repeating it again and again.  In general, the proposed application of TESLA
> to ALC and NORM could be broken up into a couple of nice MSEC building
> blocks, since there are no idiosyncracies of ALC or NORM that would require
> customization of TESLA to those protocols.  Then, there could be a very
> short RMT docs that describe the few specifics of how to apply those MSEC
> protocols to ALC and NORM and there would be little/no worries about the
> overall correctness of the protocols, since all the security work would be
> done in MSEC.
> Mike
>
>
> > -----Original Message-----
> > From: canetti [mailto:[e-mail]]
> > Sent: Thursday, August 04, 2005 9:51 PM
> > To: George Gross
> > Cc: Michael Luby; [e-mail]; [e-mail];
> > Rmt@ietf. org
> > Subject: RE: [MSEC] Re: [Rmt] Comments on TESLA source authentication in
> > theALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt
> >
> >
> > George,
> >
> > Sorry for the delayed response.
> >
> > Regarding where the NORM/ALS/TESLA draft should be advanced - as you've
> > seen in the minutes, the feeling in both WGs and ofthe ADs was that the
> > draft should be discussed in both WGs, and that the last call should be
> > done in both. Hope that will make both you and Mike happy.
> >
> > Regarding the need for group key establishment protocol (such as GDOI,
> > GSAKMP, MIKEY, etc): All I was saying is that, in the context of RMT, an
> > application might want to use TESLA *even if* it is not interested in
> > encrypting the contents. In such cases there is no need to run a
> > full-fledged key establishment protocol. Thus it makes sense to
> > develop a method for bootstrapping TESLA that does not require
> > such key establishment protocols. (Ofcourse, if the application does wish
> > to use encryption, then it might as well run an MSEC key establishement
> > protocol.)
> >
> > Note that the bootstrapping of TESLA does not require transmitting any
> > secret information between the sender and a receiver. In fact, all the
> > bootstrapping information can in principle be posted on some public
> > website for anyone to download. (the only part that requires interaction
> > is the time synchronization, and even this need not be secret.)
> >
> > Best,
> >
> > Ran
> >
> >
> >  Mon, 1 Aug 2005, George Gross wrote:
> >
> > > Hi Ran,
> > >
> > > I tend to agree with Michael Luby's assessment, that the nature of the
> > > NORM/ALC/TESLA proposal really seems more closely aligned with our MSEC
> > > working group charter, and particularly the TESLA/ESP work item. The
> > > question becomes: are we interested in standardizing a secure multicast
> > > transport layer protocol analogous to TLS in the unicast world?
> > or is the
> > > secure multicast protocol stack better served by a TESLA ESP
> > standard for
> > > the Internet layer?
> > >
> > > You also outlined in a prior e-mail some previously unidentified
> > > requirements about NORM/ALC TESLA, which merits a follow up observation:
> > >
> > > > > btw, George, there is considerable difference between the key setup
> > > > > stage for TESLA alone (ie, for message authentication alone) and >
> > > > > session setup using GSAKMP and other group key agreement protocols.
> > > > > In particular, in the former there is no need to authenticate the
> > > > > receiver, and there is no need to setup a group key.
> > >
> > > I am not convinced that the requirements are as simple as your statement
> > > above would led us to believe. In effect, you are assuming that all
> > > NORM/ALC TESLA groups *must* have a fixed security policy that
> > admits all
> > > candidate group members and does not use group traffic encryption (i.e.
> > > a no-op GM authorization policy and null encryption). WHile there may
> > > exist a subset of NORM applications that fit that low security
> > profile, it
> > > is not pausible to say all multicast applications would have such
> > > requirements.
> > >
> > > Even for the narrow case described in the NORM/ALC TESLA draft, in order
> > > to validate the Group Speaker's signature on the TESLA
> > bootstrap data, the
> > > Group Member needs to have:
> > >
> > > 1. a validated certificate chain from the Group Speaker to one of the
> > > group's trust anchor certificates.
> > >
> > > 2. for each group, a keyring of one or more trust anchor certificates.
> > >
> > > 3. a group security policy database indexed by Group Speaker identity,
> > > that can discriminate between authorized Group Speakers and bogus
> > > impostors.
> > >
> > > 4. a group security policy database that describes the authorized set of
> > > reference timing sources (e.g. timestamp authorities, such that
> > one could
> > > audit the Group Speaker's asserted timestamp).
> > >
> > > 5. some kind of anti-replay mechanism to protect the TESLA bootstrap
> > > exchange.
> > >
> > > The first four items require per group receiver endpoint security policy
> > > configuration that best scales for a large group when using a group key
> > > management protocol. i.e. like as can be expressed using the
> > GSAKMP policy
> > > token or an equivalent mechanism in other MSEC protocols.
> > >
> > > Given the above, it seems to me that NORM/ALC TESLA already needs many
> > > features that come with a full fledged group key management protocol
> > > exchange.
> > >
> > > br,
> > > 	George
> > >
> > >
> > > On Mon, 1 Aug 2005, canetti wrote:
> > >
> > > >
> > > >
> > > > On Mon, 1 Aug 2005, Michael Luby wrote:
> > > >
> > > > > I'm not understanding something.  Why is it appropriate to
> > do TESLA-SRTP in
> > > > > MSEC but TESLA-ALC/NORM in RMT?
> > > >
> > > > because the feeling was that we do have sufficient expertise
> > on SRTP in
> > > > MSEC (Mark Baugher is a cocauthor of both SRTP and TESLA-SRTP).
> > > >
> > > > Lets indeed discuss this issue at RMT and MSEC this week and
> > see what the
> > > > feelings are. In any case, this clearly should be a joint venture.
> > > >
> > > > >
> > > > > I'm pretty skeptical of doing this work in RMT, since the
> > expertise is just
> > > > > not there for security and since this draft adds a lot of
> > stuff that seems
> > > > > pretty generic and should be inherent MSEC work, and since
> > the security
> > > > > expert and one of the inventors of TESLA has himself
> > described below that
> > > > > TESLA is a relatively complex and delicate protocol.
> > > >
> > > > I guess this skepticism is natural, in the same way that I'm skeptical
> > > > about developing in MSEC a protocol that would interoperate with other
> > > > RMT protocol. But see below.
> > > >
> > > > >
> > > > > I would really prefer as much of the basic work to be done
> > in MSEC as
> > > > > possible (like the initial bootstrapping to let the
> > receivers have an
> > > > > estimate and delta of the current time at the sender when
> > there are a lot of
> > > > > receivers, which seems pretty generic to me, given that I
> > understand MSEC to
> > > > > mean Multicast SECurity and multicast generally implies
> > lots of receivers),
> > > > > and it still seems to me too much is being done in this
> > draft and not enough
> > > > > of the basic work has been done in MSEC (assuming that the
> > work described in
> > > > > the initial draft that seems to be new has not been done in MSEC).
> > > >
> > > > Practially all these details (bootstrapping, etc) are essentially a
> > > > repetition of the description in RFC 4082. It's ok to repeat
> > (since this
> > > > is going to be standards-track), but as I remarked in the
> > previous mail it
> > > > should be made explicit that all the details are taken from
> > 4082 (and say
> > > > explicitly if there is deviation)
> > > >
> > > > >
> > > > > As a side-remark: I'm a bit disappointed with the approach
> > that MSEC seems
> > > > > to be taking on TESLA, only doing work for an "Informational" RFC,
> > > > > especially for something that involves a relatively complex
> > and delicate
> > > > > protocol that is non-trivial to understand and implement
> > securely.  An
> > > > > "Informational" RFC is a good starting point, but if it is
> > delicate and easy
> > > > > to get wrong, it seems like there would be some more
> > rock-solid protocol
> > > > > descriptions in a "Standards" track that are developed as
> > well, at least for
> > > > > all the common cases and some of the basic parts of the protocol.
> > > >
> > > > Well, careful reading may prevent disappointments... :)
> > > >
> > > > The plan is to have not one but (at least) two concrete,
> > standards track
> > > > documents: TESLA-SRTP is one, and the future TESLA-ESP is another.
> > > >
> > > > Ran
> > > >
> > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > > > > > canetti
> > > > > > Sent: Sunday, July 31, 2005 9:29 PM
> > > > > > To: George Gross
> > > > > > Cc: [e-mail]; [e-mail];
> > Rmt@ietf. org
> > > > > > Subject: Re: [MSEC] Re: [Rmt] Comments on TESLA source
> > authentication in
> > > > > > theALC and NORM protocols:
> > draft-faurite-rmt-tesla-for-alc-norm-00.txt
> > > > > >
> > > > > >
> > > > > >
> > > > > > Faurite, Mike, George, and all -
> > > > > >
> > > > > > A few high-level points regarding the work on
> > standardizing TESLA for
> > > > > > RMT's ALC and NORM:
> > > > > >
> > > > > > First, I agree that this is a very worthwhile endeavor.
> > > > > >
> > > > > > Regarding how/where it should be done. The approach
> > within MSEC so far
> > > > > > wrt the standardization of TESLA was to have:
> > > > > > (a) a single informational document that describes the principles
> > > > > > and the rationale, but without specifying exact parameters, packet
> > > > > > formats, etc. (This is now RFC 4082).
> > > > > > (b) a number of standards-track documents that specify
> > how to use TESLA in
> > > > > > specific settings. Here we currently have the TESLA-SRTP rfc-to-be
> > > > > > (together with the bootstrapping TESLA draft). the plan
> > is to have also a
> > > > > > document that describes how to use TESLA within ESP.
> > (This document is
> > > > > > long overdue. the dead tesla-spec-00 draft that Faurite
> > mentioned can
> > > > > > be regarded as a first draft of this future document.)
> > > > > >
> > > > > > The rationale behind organizing things this way was that
> > TESLA is a
> > > > > > relatively complex and delicate protocol, with several options
> > > > > > and modes that make it hard to specify a single closed
> > protocol that is
> > > > > > not too complex and yet applies to all scenarios. Furthermore, the
> > > > > > experience within MSEC was that it is non-trivial to
> > understand the
> > > > > > security of this protocol and to implement it securely.
> > Therefore, a
> > > > > > separate informational document seemed in place.
> > > > > >
> > > > > > Indeed, as Mike pointed out, this approach is different from RMT's
> > > > > > bulding-block approach. In particular, it doesnt allow
> > for easy "cut and
> > > > > > paste" of a "TESLA block" from one protocol into another.
> > Each protocol
> > > > > > should define its own version of TESLA. Still, it seems
> > appropriate given
> > > > > > the complexity and rich number of options in TESLA (eg,
> > direct/indirect
> > > > > > synchronization, need for chain renewal, method of
> > dealing with dos/packet
> > > > > > buffering, etc.)
> > > > > >
> > > > > > Regarding the present draft.
> > > > > > When Faurite asked the RMT and MSEC chairs a few weeks
> > ago whether to
> > > > > > standardize the present draft within RMT or within MSEC,
> > my response was
> > > > > > that I thought RMT was a more appropriate venue since the
> > main challenge
> > > > > > is to make TESLA fit well within the RMT protocol suite,
> > and MSEC had no
> > > > > > expertise in that. This approach was accepted by the RMT
> > chairs, under the
> > > > > > condition that there will be "security supervision of the
> > draft" by MSEC
> > > > > > folks. I still think that this is the best way to do
> > things. In fact, one
> > > > > > may regard the present draft as a "TESLA building block"
> > for the purpose
> > > > > > of RMT. This would give implementors three alternative
> > ways of using
> > > > > > TESLA: either within SRTP, or within ESP, or as part of
> > the RMT suite.
> > > > > >
> > > > > > I've only read the draft at a high level, without delving
> > into many of the
> > > > > > details. Yet all the choices and descriptions that I read
> > in the draft
> > > > > > were good. One comment is that I'd refer more closely to
> > RFC 4082, to make
> > > > > > it clear in each part how exacly the principles and
> > guidelines of RFC 4082
> > > > > > are implemented. This may give more confidence to readers
> > of this document
> > > > > > which are not familiar with 4082 and the security of TESLA.
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Ran
> > > > > >
> > > > > >
> > > > > > btw, George, there is considerable difference between the
> > key setup stage
> > > > > > for TESLA alone (ie, for message authentication alone)
> > and session setup
> > > > > > using GSAKMP and other group key agreement protocols. In
> > particular, in
> > > > > > the former there is no need to authenticate the receiver,
> > and ther eis no
> > > > > > need to setup a group key.
> > > > > >
> > > > > > On Fri, 29 Jul 2005, George Gross wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > 	I've taken a quick look at the NORM/ALC TESLA
> > draft. It makes a
> > > > > > > good starting point for how to apply TESLA in
> > combination with the RMT
> > > > > > > work. I did not dive into it to get details, but a few high
> > > > > > level comments
> > > > > > > seemed in order:
> > > > > > >
> > > > > > > 1) I have not identified a compelling architectural
> > reason why NORM/ALC
> > > > > > > TESLA needs to be applied in an application specific manner.
> > > > > > Instead, this
> > > > > > > work is a good candidate for inclusion within a set of
> > one or more
> > > > > > > standards track documents that describe how to apply TESLA to
> > > > > > existing and
> > > > > > > emergent MSEC and IPsec standards. In particular, I would
> > > > > > suggest taking a
> > > > > > > look at the draft-ietf-msec-ipsec-extensions-00.txt,
> > particularly the
> > > > > > > service models discussion in the appendix.
> > > > > > >
> > > > > > > 2) the bootstrapping phase of the NORM/ALC TESLA bears a strong
> > > > > > > resemblance to the Internet layer group key management
> > protocols already
> > > > > > > developed in MSEC: GDOI and GSAKMP.  For example, the
> > TESLA bootstrap
> > > > > > > information could become a sub-payload within the
> > GSAKMP Key DownLoad
> > > > > > > payload. By using an existent MSEC GKMP, the group
> > membership and group
> > > > > > > speaker authentication and authorization procedures are
> > largely defined
> > > > > > > and the TESLA feature becomes an extension of a
> > framework. As an aside,
> > > > > > > GSAKMP has a distributed mode of operation that alleviates the
> > > > > > scalability
> > > > > > > problem, and it also a uni-directional mode too (e.g.
> > for satellite).
> > > > > > >
> > > > > > > 3) as part of the same activity, we would need to
> > design a TESLA ESP
> > > > > > > trailer authenticator, with NORM or ALC as the payload.
> > > > > > >
> > > > > > > 4) integration with the MSEC framework has the additional
> > > > > > benefit that the
> > > > > > > unicast NORM repair and congestion notification
> > messages directed at the
> > > > > > > group speaker could be both group and source endpoint
> > authenticated, the
> > > > > > > source authentication using the RSA signatures scheme
> > now in RFC editor
> > > > > > > queue.
> > > > > > >
> > > > > > > 5) The use of one-way hash chains advocated in the
> > NORM/ALC TESLA draft
> > > > > > > may have IPR issues. I'm not a patent attornory, YMMV.
> > > > > > >
> > > > > > > The NORM/ALC TESLA draft is on the MSEC agenda for
> > Paris, but I won't be
> > > > > > > there. So I would hope these discussions could continue on the
> > > > > > MSEC list.
> > > > > > >
> > > > > > > hth,
> > > > > > > 	George
> > > > > > >
> > > > > > >  On Thu, 28 Jul 2005, faurite wrote:
> > > > > > >
> > > > > > > > Mike, thanks a lot for your constructive remarks.
> > > > > > > >
> > > > > > > > Generally speaking, we do agree with all of them. The choices
> > > > > > > > we made have been done with the goal to bootstrap the
> > work (keep
> > > > > > > > in mind it's only a -00 version) and to fill in some missing
> > > > > > > > aspects in current TESLA documents.
> > > > > > > >
> > > > > > > >
> > > > > > > > Let's go into the details, in particular concerning the
> > > > > > > > "split between MSEC and RMT WG".
> > > > > > > >
> > > > > > > >
> > > > > > > > You're right, our I-D could easily be split into
> > several separate
> > > > > > > > documents, some of them being specified in the MSEC
> > WG, and the
> > > > > > > > ALC/NORM instanciation in the RMT WG.
> > > > > > > > This is not the choice we made for the -00 version because we
> > > > > > > > wanted to put forward all the points we believe are
> > needed (and
> > > > > > > > that are missing in current MSEC TESLA documents).
> > > > > > > >
> > > > > > > > For instance:
> > > > > > > >  - boostrap stuff could be moved to a separate "TESLA
> > bootstraping
> > > > > > > >    for ALC/NORM" document (or merged with the current "TESLA
> > > > > > > >    bootstraping for SRTP" document if the authors believe it's
> > > > > > > >    feasible/desireable).
> > > > > > > >
> > > > > > > >  - key chain switching: RFC4082 (TESLA introduction)
> > does not discuss
> > > > > > > >    this possibility of high practical importance. The
> > same is true
> > > > > > > >    for the "TESLA for SRTP" I-D. This is an issue in
> > particular (but
> > > > > > > >    not only) with on-demand ALC sessions of
> > non-predefined duration.
> > > > > > > >    We tried to fix this, but yes, a better solution
> > would be to
> > > > > > > >    have this mechanism described in some MSEC TESLA
> > document since
> > > > > > > >    it could then be used not only for ALC/NORM but
> > also for SRTP...
> > > > > > > >
> > > > > > > >  - time synchronization stuff: RFC4082 and "TESLA for SRTP"
> > > > > > > >    essentially focuss on direct synchronization, which is
> > > > > > > >    not necessarily appropriate in case of ALC
> > (scalability/feedback
> > > > > > > >    problems). So we tried to further clarify how indirect
> > > > > > synchronization
> > > > > > > >    could be done (securely)...
> > > > > > > >    But yes, here also, a better solution would be to
> > have it described
> > > > > > > >    in an MSEC TESLA document.
> > > > > > > >
> > > > > > > > Having it all in the same -00 document was a
> > deliberate choice, but
> > > > > > > > this is questionable, sure. A direct consequence is
> > that this single
> > > > > > > > I-D could not be submitted to both WGs and we've been
> > adviced to send
> > > > > > > > it to RMT and CC it to MSEC. That's why.
> > > > > > > >
> > > > > > > > BTW, an updated "TESLA spec" along the lines of the
> > (dead) I-D:
> > > > > > > >
> > http://www.ece.cmu.edu/~adrian/tesla/draft-ietf-msec-tesla-spec-00.txt
> > > > > > > > that would incorporate the missing points above is
> > clearly missing.
> > > > > > > > Some parts of our I-D is inspired from it, as we explained.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > >    Sebastien/Aurelien/Vincent
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >Comments on TESLA source authentication in the ALC and NORM
> > > > > > protocols:
> > > > > > > > >draft-faurite-rmt-tesla-for-alc-norm-00.txt
> > > > > > > > >
> > > > > > > > >First off, I think that this is a very good thing to try and
> > > > > > standardize, as
> > > > > > > > >TESLA is ideally suited to provide authentication and packet
> > > > > > integrity
> > > > > > > > >protection to ALC and NORM.   Unfortunately, I have a lot of
> > > > > > questions and
> > > > > > > > >issues with the draft, and some are basic questions about
> > > > > > where this work
> > > > > > > > >should be done.
> > > > > > > > >
> > > > > > > > >What I was expecting is a document that describes how to
> > > > > > apply TESLA and
> > > > > > > > >related security features that have been developed in MSEC
> > > > > > that have been
> > > > > > > > >developed in the spirit of a building block to ALC and NORM,
> > > > > > where all the
> > > > > > > > >security issues have been addressed in the TESLA work and it
> > > > > > is simply cut
> > > > > > > > >and paste to put that into the ALC and NORM context.  What I
> > > > > > see instead is
> > > > > > > > >a document that describes a lot of protocol work that has
> > > > > > security aspects
> > > > > > > > >to it that seems more suitable for MSEC.  I’m not sure why
> > > > > > this is, perhaps
> > > > > > > > >because the TESLA specification does not lend itself to
> > > > > > being used as a
> > > > > > > > >building block directly, and perhaps because some of the
> > > > > > other security
> > > > > > > > >protocols have not been addressed by MSEC.  It would be good
> > > > > > though if the
> > > > > > > > >basic security work were done in MSEC, and only applications
> > > > > > of that work
> > > > > > > > >that have no potential to introduce weaknesses in security
> > > > > > were described in
> > > > > > > > >the RMT work that describes how these protocols are applied
> > > > > > to ALC and NORM.
> > > > > > > > >I have been informed that this is the approach taken with
> > > > > > SRTP, i.e., the
> > > > > > > > >work to apply TESLA to SRTP is being done within
> > MSEC, and not AVT.
> > > > > > > > >
> > > > > > > > >As an example, Section 2 describes protocols for
> > time synchronization
> > > > > > > > >between the sender and receivers.  Since the security of
> > > > > > TESLA entirely
> > > > > > > > >relies on time synchronization, the security of this
> > > > > > protocol is of crucial
> > > > > > > > >importance.  Furthermore, it seems that time synchronization
> > > > > > would be a
> > > > > > > > >basic primitive of any protocol that uses TESLA.  Thus, it
> > > > > > seems like the
> > > > > > > > >time synchronization protocols should be work done within
> > > > > > the MSEC group
> > > > > > > > >that can then be leveraged for application work done in RMT,
> > > > > > and it seems
> > > > > > > > >inappropriate for this work to be done in RMT since the
> > > > > > security protocol
> > > > > > > > >experts aren’t there.
> > > > > > > > >
> > > > > > > > >Section 3 on setting TESLA parameters seems to be the type
> > > > > > of thing that one
> > > > > > > > >would expect in this draft.  However, even in this section,
> > > > > > there is very
> > > > > > > > >little reference and tie-in with the TESLA RFC, and thus it
> > > > > > would be good to
> > > > > > > > >tighten this section up and refer to the appropriate
> > sections and
> > > > > > > > >definitions used in TESLA in this section and use the
> > > > > > protocols that have
> > > > > > > > >been standardized in TESLA.   A related comment is that it
> > > > > > should be said
> > > > > > > > >somewhere in this draft incorporates the TESLA RFC and
> > > > > > inherits all of the
> > > > > > > > >terminology of the TESLA RFC.
> > > > > > > > >
> > > > > > > > >The bulk of Section 3 defines the format of bootstrap
> > > > > > information signature
> > > > > > > > >fields and authentication tags, and many related parameters.
> > > > > >  It seems like
> > > > > > > > >this format and information should all be defined in the
> > > > > > TESLA RFC, or if
> > > > > > > > >not in a related RFC within MSEC.  If this is all new to
> > > > > > this draft and not
> > > > > > > > >described in the TESLA RFC then this seems like a lot of new
> > > > > > > > >formatting/information to be adding beyond TESLA, and I
> > > > > > would feel a lot
> > > > > > > > >more comfortable if this work were done in MSEC.
> > > > > > > > >
> > > > > > > > >There are a number of other technical comments that could be
> > > > > > made, but I
> > > > > > > > >think the high level issue of how to split the work between
> > > > > > MSEC and RMT
> > > > > > > > >should be solved before addressing lower level
> > technical issues.
> > > > > > > > >
> > > > > > > > >Regards,
> > > > > > > > >Michael Luby
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >_______________________________________________
> > > > > > > > >Rmt mailing list
> > > > > > > > >[e-mail]
> > > > > > > > >https://www1.ietf.org/mailman/listinfo/rmt
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > msec mailing list
> > > > > > > > [e-mail]
> > > > > > > > http://six.pairlist.net/mailman/listinfo/msec
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > msec mailing list
> > > > > > > [e-mail]
> > > > > > > http://six.pairlist.net/mailman/listinfo/msec
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Rmt mailing list
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/rmt
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
>
>

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