Re: [Editorial Errata Reported] RFC4666 (4475)
David Laight <[email protected]> Wed, 16 Sep 2015 09:30:09 +0000
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
--===============0602974966990351867==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary=_000_063D6719AE5E284EB5DD2968C1650D6D1CB9591EAcuExchaculabco_
--_000_063D6719AE5E284EB5DD2968C1650D6D1CB9591EAcuExchaculabco_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
(Sorry I=92m forced to top post)
It would be interesting to know what has actually been implemented.
(No one will have generated 32 byte alignment.)
We=92d assumed that the parameter length excluded any required pad, and tha=
t
the diagram showed it because this was one place where padding was likely t=
o be needed.
Indeed how many implementations actually support the key management message=
s.
AFAICT the main commercial implementation of M3UA still uses RFC 3332.
If the length of this parameter includes these pad bytes, then what should =
you do
if a zero is followed by a non-zero byte?
David
There's a clear statement on page 32 of RFC 4666 that indicates that the "P=
arameter Length does not include any padding octets".
Even though SI parameter specification violates this "rule", it is quite pl=
ausible that there may be a number of implementations that may have followe=
d this specification with padding octets.
Thus, how practical would it be to indicate that there will be no padding f=
or SI parameter that does not contain multiple of four SIs, considering tha=
t we may end up converting a number of compliant implementations into a sc=
ore of non-compliant ones.
I think that changing 32-byte to 32-bit alignment is much safer (and consid=
erably cheaper) option.
Kind regards
V/
--_000_063D6719AE5E284EB5DD2968C1650D6D1CB9591EAcuExchaculabco_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">(Sorry I=92m forced to to=
p post)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">It would be interesting t=
o know what has actually been implemented.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">(No one will have generat=
ed 32 byte alignment.)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">We=92d assumed that the p=
arameter length excluded any required pad, and that<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">the diagram showed it bec=
ause this was one place where padding was likely to be needed.<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Indeed how many implement=
ations actually support the key management messages.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">AFAICT the main commercia=
l implementation of M3UA still uses RFC 3332.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">If the length of this par=
ameter includes these pad bytes, then what should you do<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">if a zero is followed by =
a non-zero byte?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"> &=
nbsp; David<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<p class=3D"MsoNormal">There's a clear statement on <i>page 32</i> of <i>RF=
C 4666</i> that indicates that the "<b><i>Parameter Length does not in=
clude any padding octets</i></b>".<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">Even though SI parameter specification violates this=
"rule", it is quite plausible that there may be a number of impl=
ementations that may have followed this specification with padding octets.<=
o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Thus, how practical would it be to indicate that the=
re will be
<b>no padding</b> for SI parameter that does not contain multiple of four S=
Is, considering that we may end up converting a number of c=
ompliant implementations into a score of non-compliant ones.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I think that changing 32-byte to 32-bit alignment is=
much safer (and considerably cheaper) option.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class=3D"MsoNormal">Kind regards<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">V/<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div><span style=3D"color: #484830; font-family: Tahoma; font-size: xx-smal=
l;">Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, M=
K1 1PT, UK<br />Registration No: 1397386 (Wales)</span></div>
<div>
<p align=3D"center"><span style=3D"color: #008000; font-family: Arial;"><sp=
an style=3D"font-size: xx-small;"><span style=3D"font-family: Webdings;">P =
</span><strong>Please consider the environment and don't print this e-mail =
unless you really need to</strong></span></span></p>
</div></body>
</html>
--_000_063D6719AE5E284EB5DD2968C1650D6D1CB9591EAcuExchaculabco_--
--===============0602974966990351867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran
--===============0602974966990351867==--