Re: AD review: draft-ietf-rmt-simple-auth-for-alc-norm, part I
Vincent Roca <[email protected]> Fri, 8 Jul 2011 12:29:19 +0200
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
--===============6809705594389743219==
Content-Type: multipart/alternative; boundary=Apple-Mail-2--1046205547
--Apple-Mail-2--1046205547
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
David, all,
I've just updated the simple-auth-for-alc-norm I-D in order to implement
the anti-replay protection feature, as I have suggested end of May.
Summary:
- anti-replay MUST be used in case of combined signature/group MAC,
otherwise replaying a valid packet is an easy way to bypass the =
"light"
group MAC filtering.
- anti-replay has been added to the other authentication schemes, as
an option. Their use is however RECOMMENDED.
- using NORM "sequence number" feature to provide anti-replay is
no longer considered as suitable, given the small field size (16 =
bits).
It is therefore RECOMMENDED to use the anti-replay feature of this=20
I-D.
- the ALC protocol is more robust in front of replay attacks, there's
just a small risk when using certain EXT_TIME LCT header extensions.
This is now clarified.
All the comments have been considered, as explained below.
Regards,
Vincent
On May 27, 2011, 13:58, Vincent Roca wrote:
> Hello David,
>=20
> First of all, I need to apologize for this very late answer...
>=20
> A major issue (that was completely overlooked) is the replay
> protection limits with both NORM and ALC protocols:=20
> - in case of NORM, because NORM's seqnum is a 16-bit field which
> quickly wraps...
> - in case of ALC because there's no seqnum and using the
> TOI/SBN/ESI information (i.e. what I had in mind) does not enable
> to detect replay attacks reliably.
> Now the problem is that a replayed packet with a combined
> digital signature/group MAC will always pass the group MAC
> check, and therefore each replayed packet will require a
> signature verification. That's very bad!
>=20
> I can't find any effective solution: checking the TOI/SBN/ESI
> first, then the group MAC, then the signature is not sufficient
> since a sender may send the same encoding symbol several
> times. Relying on the congestion control header fields (e.g., WEBRC
> has the {channel #|pkt seq #} fields that may be used to that
> purpose) is not a universal solution.
>=20
> My proposal: add a dedicated "seq" field within the EXT_AUTH
> header. We can also take advantage of the reserved 12 bits to
> increase this field size to 32+12=3D44 bits and therefore reduce
> the wrapping to 0 risk. What do you think? This would be a very
> clean solution to the problem.
>=20
> Here is an example (with the combined scheme). Of course we
> can do the same with the other schemes:
>=20
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | HET (=3D1) | HEL | ASID | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
> | anti-replay sequence number (seq) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> ~ ~
> | Signature |
> + +-+-+-+-+-+-+-+-+
> | | Padding |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Group MAC |
> ~ ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> Please find below my answers to the other comments.
> I've prepared an updated version of the I-D:
>=20
> =
http://planete.inrialpes.fr/people/roca/doc/draft-ietf-rmt-simple-auth-for=
-alc-norm-04a.html
> =
http://planete.inrialpes.fr/people/roca/doc/draft-ietf-rmt-simple-auth-for=
-alc-norm-04a.txt
>=20
> Thanks a lot for your careful and very useful review.
> Regards,
>=20
> Vincent
>=20
> ---
>=20
> > AD review, part I, of draft-ietf-rmt-simple-auth-for-alc-norm-03
> >=20
> > In the abstract:
> > "Because ... well suited to low data sessions."
> > "If this approach also ... medium data rate sessions."
> > "Because ... not group members."
> > ", and is useful ... members."
> > I recommend this analysis and conclusion text be in the meat of the
> > document, not in the abstract.=20
>=20
> Done. Indeed, it seems more appropriate to have it in the bulk of the =
document.
>=20
>=20
> > section 1
> > s/check check/check/
>=20
> Done.
>=20
>=20
> > "Reliability ..." does this refer to alc, or norm, or both? If both,
> > it might be good to separate this from the preceding sentences. If =
not
> > both, then the paragraph should be restructured to be clear what =
text
> > refers to ALC and what refers to NORM.
>=20
> In this sentence, reliability refers to ALC. This is now made =
explicit.
>=20
>=20
> > I'm on the secdir and I have no idea what "true auth" means. If =
there
> > is a true auth, is there also a "false auth"? I recommend this be
> > reworded to use acceptable security terminology. You might find =
better
> > terminology in RFC4949.
>=20
> You're right, the wording is inappropriate. The goal was to =
distinguish
> group level security (where an insider attack, within the group, =
cannot
> be identified) from per-sender security. We have clarified both the
> text and the table.
>=20
>=20
> > "when seeking for higher security levels" might be better reworded.
>=20
> Removed. Since we provide an explicit example just after, there's no
> ambiguity.
>=20
>=20
> > the discussion of "group Message Authentication Codes" has no
> > definition of what this is, and no reference, just an assertion of
> > what it is well-suited to. It might be better to describe the
> > solutions and give references. The analysis and conclusions might be
> > better later in the document.=20
>=20
> I've added a reference to the section where group MAC is defined.
>=20
>=20
> > I don't know what "Immediate auth" means.
>=20
> Right. I've changed this by "Non delayed authentication" in the
> table and have added a sentence in the bullet to explain what
> this means.
>=20
>=20
> > You use the same 4-bit ASID for multiple schemes and then use an
> > out-of-band mechanism to associate the actual scheme to the ASID. =
Why
> > not use distinct ASIDs to identify the Authentication Scheme? I read
> > 5776, 5.1 but this doesn't explain why this OOB approach is taken.
> > Please add some text to explain why this is done this way.
>=20
> The reason is historic.
> I initially thought of having a fixed (i.e. IANA registered) mapping
> between ASID values and the actual mechanisms. The WG preferred to
> have a dynamic mapping, which requires to have this OOB communication.
> However I don't remember all the details, but there's in particular
> the restrictions associated to the 4-bit field size.
>=20
>=20
> > The security considerations (here and in 5776) do not discuss the
> > potential vulnerabilities of this OOB startup association to ASID.
>=20
> Right. I've added a dedicated section in the "Security Considerations"
> to REQUIRE this to be communicated in a secure way. What this means
> depends of course on the nature of this OOB mechanism.
>=20
>=20
> > in 1.1, the second paragraph has analysis "which is useful to =
mitigate
> > ..." but this section is supposed to be about scope, not doing
> > analysis and drawing conclusions.
>=20
> You're right, at this moment this is a gratuitous affirmation.
> I've removed this "which is useful to mitigate..." sentence.
> It will be clarified later on.
>=20
>=20
> > paragraphs 4 and 5 of section 1.1 are not about the scope of this
> > document.
>=20
> Removed.
>=20
>=20
> > section 1.2 is a about terminology, and belongs in the terminology
> > section (1.3)
>=20
> Moved as suggested.
>=20
>=20
> > Do we really need all these abbreviations?=20
> > n_k is used 8 times in the document. 3 uses are in defining the =
term.
> > Three use both key length and n_k: "key length, n_k,". In the table,
> > it is parenthetical "key size (n_k)". In the one case where it used
> > separate from "key length" or "key size", you could have simply used
> > "key length".
>=20
> I've removed n_k altogether and replaced it by its definition.
>=20
>=20
> > K_pub and K-Priv are each used three times - once to define it and
> > twice in text. Just saying "using the private key" and "using the
> > public key" would have been fine.=20
>=20
> Removed and replaced by their definition.
>=20
>=20
> > K-g is used 7 times - once to define it, twice it is used with "the
> > shared group key, K-g,", once it used as "the K-g group key". Twice =
it
> > is used as "compute the group MAC, using K_g". Using "the group key"
> > would have been just fine.
>=20
> Removed and replaced by their definition.=20
>=20
>=20
> > In section 2.1, the signtaurew field is mentioned. It would be good =
to
> > show the message format before discussing its fields.
> >=20
> > The second paragraph of 2.1 (in fact, most of 2.1) doesn't seem to =
be
> > about "principles"; it seems to be about processing.
> >=20
> > It strikes me that these sections would be better organized as 1)
> > format (which has the fields that are manipulated during =
processing),
> > 2) parameters (which must be initialized before processing), and 3)
> > processing.
>=20
> Good idea. I've changed this section accordingly as well as that of
> the other authentication schemes.
>=20
> =20
> > in 7.1, you discuss digital signatures. But what if digital =
signatures
> > are not used? i.e. group MAC mode?
>=20
> Right. The paragraph has been reorganized to clarify this.
> Additionally, I've extended the RECOMMENDATION to limit the number
> of authentication checks per time unit under attack situations (or
> presumed so) to all the authentication schemes.
>=20
>=20
> > in 7.2.1=20
> > s/memoryless/stateless/
>=20
> Done.
>=20
>=20
> > Can replay be used as a DoS attack, consuming resources?
>=20
> Yes (see the beginning of this email). That's a very good point!
>=20
>=20
> > in 7.2.2, It is RECOMMENDED - why not MUST? (especially the last)
>=20
> This section will be completely re-written if we add a dedicated
> anti-replay sequence number.
>=20
>=20
> > in 7.2.3, "will be silently discarded" - if this is normative
> > behavior, please use MUST. If this will happen because it is =
specified
> > elsewhere, then please provide a reference (per RFCXXXX, the message
> > will be silently discarded."
>=20
> This section will be completely re-written if we add a dedicated
> anti-replay sequence number.
>=20
>=20
> > in 7.2.3, "has no impact since this objetc is probably already =
marked
> > ..." Does it have no impact even if it is NOT marked? What impact
> > would it have if it wrere not marked?
>=20
> This section will be completely re-written if we add a dedicated
> anti-replay sequence number.
>=20
> > are "close session" and "close object" the only control packets?
>=20
> This section will be completely re-written if we add a dedicated
> anti-replay sequence number.
>=20
>=20
> > in 7.2.3, last paragraph, it is RECOMMENDED that the shared group =
key
> > is changed across sessions. RECOMMENDED is equivalent to SHOULD; =
when
> > is it acceptable to not follow this RECOMMENDATION?
>=20
> This paragraph (ALC) and that of NORM will remain in any case, so
> it's worth clarifying this point.
>=20
> My answer: when we don't care about security at all.
> If security is a concern, the MUST is preferable. That being said,
> I'm not sure the NORM/ALC/LCT RFCs REQUIRE that different sessions
> use different {"source_id"; "instance_id"} or {sender's IP address;
> Transport Session Identifier (TSI)} tuples. I need to check...
>=20
>=20
> > I plan to do a more detailed review of technical sections 2,3,4 and =
5.
> >=20
> >=20
> > David Harrington
> > Director, IETF Transport Area
> > [email protected] (preferred for ietf)
> > [email protected]
> > +1 603 828 1401 (cell)
--Apple-Mail-2--1046205547
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>David, all,</div><div><br></div><div>I've just updated =
the simple-auth-for-alc-norm I-D in order to =
implement</div><div>the anti-replay protection feature, as I have =
suggested end of =
May.</div><div><br></div><div>Summary:</div><div><br></div><div>- =
anti-replay MUST be used in case of combined signature/group =
MAC,</div><div> otherwise replaying a valid packet is an easy =
way to bypass the "light"</div><div> group MAC =
filtering.</div><div><br></div><div>- anti-replay has been added to the =
other authentication schemes, as</div><div> an option. Their =
use is however RECOMMENDED.</div><div><br></div><div>- using NORM =
"sequence number" feature to provide anti-replay =
is</div><div> no longer considered as suitable, given the =
small field size (16 bits).</div><div> It is therefore =
RECOMMENDED to use the anti-replay feature of =
this </div><div> I-D.</div><div><br></div><div>- the ALC =
protocol is more robust in front of replay attacks, =
there's</div><div> just a small risk when using certain =
EXT_TIME LCT header extensions.</div><div> This is now =
clarified.</div><div><br></div><div>All the comments have been =
considered, as explained =
below.</div><div>Regards,</div><div><br></div><div> =
Vincent</div><div><br></div><div><br></div><div>On May 27, 2011, 13:58, =
Vincent Roca wrote:</div><div><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Hello David,<br><br>First of =
all, I need to apologize for this very late answer...<br><br>A major =
issue (that was completely overlooked) is the replay<br>protection =
limits with both NORM and ALC protocols: <br>- in case of NORM, =
because NORM's seqnum is a 16-bit field which<br> quickly =
wraps...<br>- in case of ALC because there's no seqnum and using =
the<br> TOI/SBN/ESI information (i.e. what I had in mind) does not =
enable<br> to detect replay attacks reliably.<br>Now the =
problem is that a replayed packet with a combined<br>digital =
signature/group MAC will always pass the group MAC<br>check, and =
therefore each replayed packet will require a<br>signature verification. =
That's very bad!<br><br>I can't find any effective solution: checking =
the TOI/SBN/ESI<br>first, then the group MAC, then the signature is not =
sufficient<br>since a sender may send the same encoding symbol =
several<br>times. Relying on the congestion control header fields (e.g., =
WEBRC<br>has the {channel #|pkt seq #} fields that may be used to =
that<br>purpose) is not a universal solution.<br><br>My proposal: add a =
dedicated "seq" field within the EXT_AUTH<br>header. We can also take =
advantage of the reserved 12 bits to<br>increase this field size to =
32+12=3D44 bits and therefore reduce<br>the wrapping to 0 risk. What do =
you think? This would be a very<br>clean solution to the =
problem.<br><br>Here is an example (with the combined scheme). Of course =
we<br>can do the same with the other schemes:<br><br><font =
class=3D"Apple-style-span" face=3D"'Courier =
New'"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+<br> | HET (=3D1) | HEL =
| ASID | =
=
|<br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
=
+<br> | =
anti-replay sequence number (seq) =
=
|<br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+<br> | =
=
=
|<br> ~ =
=
=
~<br> | =
=
Signature =
|<br> + =
=
=
+-+-+-+-+-+-+-+-+<br> | =
=
| =
Padding =
|<br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+<br> | =
Group MAC =
=
|<br> ~ =
=
=
=
~<br> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+<br></font><br>Please find below my answers to the other =
comments.<br>I've prepared an updated version of the =
I-D:<div><br></div><div><a =
href=3D"http://planete.inrialpes.fr/people/roca/doc/draft-ietf-rmt-simple-=
auth-for-alc-norm-04a.html">http://planete.inrialpes.fr/people/roca/doc/dr=
aft-ietf-rmt-simple-auth-for-alc-norm-04a.html</a></div><div><a =
href=3D"http://planete.inrialpes.fr/people/roca/doc/draft-ietf-rmt-simple-=
auth-for-alc-norm-04a.txt">http://planete.inrialpes.fr/people/roca/doc/dra=
ft-ietf-rmt-simple-auth-for-alc-norm-04a.txt</a></div><div><br>Thanks a =
lot for your careful and very useful =
review.<br>Regards,<br><br> =
Vincent<br><br>---<br><br>> AD review, part I, of =
draft-ietf-rmt-simple-auth-for-alc-norm-03<br>> <br>> In the =
abstract:<br>> "Because ... well suited to low data =
sessions."<br>> "If this approach also ... medium data rate =
sessions."<br>> "Because ... not group members."<br>> ", and is =
useful ... members."<br>> I recommend this analysis and conclusion =
text be in the meat of the<br>> document, not in the =
abstract. <br><br>Done. Indeed, it seems more appropriate to have =
it in the bulk of the document.<br><br><br>> section 1<br>> =
s/check check/check/<br><br>Done.<br><br><br>> "Reliability ..." does =
this refer to alc, or norm, or both? If both,<br>> it might be good =
to separate this from the preceding sentences. If not<br>> both, then =
the paragraph should be restructured to be clear what text<br>> =
refers to ALC and what refers to NORM.<br><br>In this sentence, =
reliability refers to ALC. This is now made explicit.<br><br><br>> =
I'm on the secdir and I have no idea what "true auth" means. If =
there<br>> is a true auth, is there also a "false auth"? I recommend =
this be<br>> reworded to use acceptable security terminology. You =
might find better<br>> terminology in RFC4949.<br><br>You're right, =
the wording is inappropriate. The goal was to distinguish<br>group level =
security (where an insider attack, within the group, cannot<br>be =
identified) from per-sender security. We have clarified both the<br>text =
and the table.<br><br><br>> "when seeking for higher security levels" =
might be better reworded.<br><br>Removed. Since we provide an explicit =
example just after, there's no<br>ambiguity.<br><br><br>> the =
discussion of "group Message Authentication Codes" has no<br>> =
definition of what this is, and no reference, just an assertion =
of<br>> what it is well-suited to. It might be better to describe =
the<br>> solutions and give references. The analysis and conclusions =
might be<br>> better later in the document. <br><br>I've added a =
reference to the section where group MAC is defined.<br><br><br>> I =
don't know what "Immediate auth" means.<br><br>Right. I've changed this =
by "Non delayed authentication" in the<br>table and have added a =
sentence in the bullet to explain what<br>this means.<br><br><br>> =
You use the same 4-bit ASID for multiple schemes and then use an<br>> =
out-of-band mechanism to associate the actual scheme to the ASID. =
Why<br>> not use distinct ASIDs to identify the Authentication =
Scheme? I read<br>> 5776, 5.1 but this doesn't explain why this OOB =
approach is taken.<br>> Please add some text to explain why this is =
done this way.<br><br>The reason is historic.<br>I initially thought of =
having a fixed (i.e. IANA registered) mapping<br>between ASID values and =
the actual mechanisms. The WG preferred to<br>have a dynamic mapping, =
which requires to have this OOB communication.<br>However I don't =
remember all the details, but there's in particular<br>the restrictions =
associated to the 4-bit field size.<br><br><br>> The security =
considerations (here and in 5776) do not discuss the<br>> potential =
vulnerabilities of this OOB startup association to ASID.<br><br>Right. =
I've added a dedicated section in the "Security Considerations"<br>to =
REQUIRE this to be communicated in a secure way. What this =
means<br>depends of course on the nature of this OOB =
mechanism.<br><br><br>> in 1.1, the second paragraph has analysis =
"which is useful to mitigate<br>> ..." but this section is supposed =
to be about scope, not doing<br>> analysis and drawing =
conclusions.<br><br>You're right, at this moment this is a gratuitous =
affirmation.<br>I've removed this "which is useful to mitigate..." =
sentence.<br>It will be clarified later on.<br><br><br>> paragraphs 4 =
and 5 of section 1.1 are not about the scope of this<br>> =
document.<br><br>Removed.<br><br><br>> section 1.2 is a about =
terminology, and belongs in the terminology<br>> section =
(1.3)<br><br>Moved as suggested.<br><br><br>> Do we really need all =
these abbreviations? <br>> n_k is used 8 times in the document. =
3 uses are in defining the term.<br>> Three use both key length and =
n_k: "key length, n_k,". In the table,<br>> it is parenthetical "key =
size (n_k)". In the one case where it used<br>> separate from "key =
length" or "key size", you could have simply used<br>> "key =
length".<br><br>I've removed n_k altogether and replaced it by its =
definition.<br><br><br>> K_pub and K-Priv are each used three times - =
once to define it and<br>> twice in text. Just saying "using the =
private key" and "using the<br>> public key" would have been =
fine. <br><br>Removed and replaced by their =
definition.<br><br><br>> K-g is used 7 times - once to define it, =
twice it is used with "the<br>> shared group key, K-g,", once it used =
as "the K-g group key". Twice it<br>> is used as "compute the group =
MAC, using K_g". Using "the group key"<br>> would have been just =
fine.<br><br>Removed and replaced by their =
definition. <br><br><br>> In section 2.1, the signtaurew field =
is mentioned. It would be good to<br>> show the message format before =
discussing its fields.<br>> <br>> The second paragraph of 2.1 =
(in fact, most of 2.1) doesn't seem to be<br>> about "principles"; it =
seems to be about processing.<br>> <br>> It strikes me that =
these sections would be better organized as 1)<br>> format (which has =
the fields that are manipulated during processing),<br>> 2) =
parameters (which must be initialized before processing), and 3)<br>> =
processing.<br><br>Good idea. I've changed this section accordingly as =
well as that of<br>the other authentication =
schemes.<br><br> <br>> in 7.1, you discuss digital signatures. =
But what if digital signatures<br>> are not used? i.e. group MAC =
mode?<br><br>Right. The paragraph has been reorganized to clarify =
this.<br>Additionally, I've extended the RECOMMENDATION to limit the =
number<br>of authentication checks per time unit under attack situations =
(or<br>presumed so) to all the authentication schemes.<br><br><br>> =
in 7.2.1 <br>> =
s/memoryless/stateless/<br><br>Done.<br><br><br>> Can replay be used =
as a DoS attack, consuming resources?<br><br>Yes (see the beginning of =
this email). That's a very good point!<br><br><br>> in 7.2.2, It is =
RECOMMENDED - why not MUST? (especially the last)<br><br>This section =
will be completely re-written if we add a dedicated<br>anti-replay =
sequence number.<br><br><br>> in 7.2.3, "will be silently discarded" =
- if this is normative<br>> behavior, please use MUST. If this will =
happen because it is specified<br>> elsewhere, then please provide a =
reference (per RFCXXXX, the message<br>> will be silently =
discarded."<br><br>This section will be completely re-written if we add =
a dedicated<br>anti-replay sequence number.<br><br><br>> in 7.2.3, =
"has no impact since this objetc is probably already marked<br>> ..." =
Does it have no impact even if it is NOT marked? What impact<br>> =
would it have if it wrere not marked?<br><br>This section will be =
completely re-written if we add a dedicated<br>anti-replay sequence =
number.<br><br>> are "close session" and "close object" =
the only control packets?<br><br>This section will be completely =
re-written if we add a dedicated<br>anti-replay sequence =
number.<br><br><br>> in 7.2.3, last paragraph, it is RECOMMENDED that =
the shared group key<br>> is changed across sessions. RECOMMENDED is =
equivalent to SHOULD; when<br>> is it acceptable to not follow this =
RECOMMENDATION?<br><br>This paragraph (ALC) and that of NORM will remain =
in any case, so<br>it's worth clarifying this point.<br><br>My answer: =
when we don't care about security at all.<br>If security is a concern, =
the MUST is preferable. That being said,<br>I'm not sure the =
NORM/ALC/LCT RFCs REQUIRE that different sessions<br>use different =
{"source_id"; "instance_id"} or {sender's IP address;<br>Transport =
Session Identifier (TSI)} tuples. I need to check...<br><br><br>> I =
plan to do a more detailed review of technical sections 2,3,4 and =
5.<br>> <br>> <br>> David Harrington<br>> =
Director, IETF Transport Area<br>> <a =
href=3D"mailto:[email protected]">[email protected]</a> (preferre=
d for ietf)<br>> <a =
href=3D"mailto:[email protected]">dbharrington@huaweisymante=
c.com</a><br>> +1 603 828 1401 =
(cell)<br></div></div></blockquote></div><br></body></html>=
--Apple-Mail-2--1046205547--
--===============6809705594389743219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt
--===============6809705594389743219==--