<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1499155436;
mso-list-type:hybrid;
mso-list-template-ids:-1332047312 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1675957516;
mso-list-type:hybrid;
mso-list-template-ids:776921156 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I was actually intentionally vague, because I was first trying to elicit history, opinions, etc. about the current state of things.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In particular:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Am I correct in understanding the background behind OpenSSL and Zebra/Quagga/FRR? Is it believed that licensing issues which prevented redistribution in the past are resolved now?<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Is there a common expectation as to whether FRR is generally built with, or without, OpenSSL linkage today? (Distribution packaging varies: for example in Fedora this build flag is
enabled, but in Debian it is disabled.)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Are there strong feelings for or against having cryptographic algorithms embedded in the FRR source code? (Faster execution by using a specific implementation; larger security footprint
to be concerned with monitoring within this project; easier to build and port FRR to other platforms by reducing the number of external dependencies; trickier to avoid potential function name collisions between FRR and system libraries; etc.)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2">Are there strong feelings for or against the use of OpenSSL specifically in FRR today? (It’s a widely installed dependency of other software; it’s overkill for the very limited degree
to which FRR uses it; it is likely to be ported to platforms that other libraries are not; it has a more involved API that has changed over time; etc.)<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(So far it seems like – all other things being equal – there would generally be a preference against embedding and maintaining these algorithms in FRR.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">David<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Donald Sharp <donaldsharp72@gmail.com> <br>
<b>Sent:</b> Thursday, June 1, 2023 7:20 AM<br>
<b>To:</b> Christian Hopps <chopps@chopps.org><br>
<b>Cc:</b> Ward, David - 0665 - MITLL <david.ward@ll.mit.edu>; dev@lists.frrouting.org<br>
<b>Subject:</b> Re: [dev] Updating internal crypto implementation<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In theory, I am more than happy with having more security options in FRR, especially if some generic functions we are using can be taken out of FRR and the code maintenance can be taken care of by some other library.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I guess where I have been hesitating to respond is the sentence `Can we update...`. I am not sure if I should read the sentence as either:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">a) David Ward is saying I will do the work to update this code<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">b) The we implies that someone should just pick this up from the community and run with the idea.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If (a) then I say go for it, David! For this work, though, I would want to see a plan of action for how this is going to be done in the code base. Mainly so that the 2-3 people within the FRR community who really really care about how
this is done won't come back and say do it completely differently and your and our time is not wasted.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">if (b) then I say that's a great idea! Unfortunately due to how open source development is done, until some business has a use case for this expanded functionality, this idea is going to languish.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Finally if you are going to do option (a), please feel free to privately send me email( or come talk to us on slack ) and we can get the ball rolling on helping you get the work done.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">donald<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jun 1, 2023 at 6:31 AM Christian Hopps <<a href="mailto:chopps@chopps.org">chopps@chopps.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
Hi David,<br>
<br>
Add "Is there someone will to do the work and maintain the code?" to the non-library options. The answer to that q. very well could be "no" in which case the library is definitely the way to go. :)<br>
<br>
Thanks,<br>
Chris.<br>
<br>
"Ward, David - 0665 - MITLL" <<a href="mailto:david.ward@ll.mit.edu" target="_blank">david.ward@ll.mit.edu</a>> writes:<br>
<br>
> FRR has an "internal" implementation of the MD5 and SHA-256 algorithms,<br>
> including HMAC functions for both. [1] This code is under a BSD license, and<br>
> provides an alternative to linking FRR against OpenSSL, for which there were<br>
> historical (?) issues around GPL incompatibility. Several routing protocols use<br>
> one of these hash algorithms.<br>
><br>
> ospf6d was extended last year to support the OSPFv3 Authentication Trailer (RFC 7166), which may use any of HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. [2] The choice of algorithm is limited unless FRR has been compiled with OpenSSL support.<br>
><br>
> Can we update FRR's internal crypto implementation in order to overcome this limitation? For example:<br>
> * Gnulib provides a drop-in version of each of the algorithms mentioned above for inclusion in open-source projects, available under LGPL 2.1.<br>
> * FreeBSD has adapted Colin Percival's SHA-256 implementation to support the other SHA-2 algorithms (but without the HMAC functions - which would seem straightforward to adapt).<br>
> * Or should FRR rely on an external library for these functions instead? Should it allow the use of something other than OpenSSL, such as Libgcrypt?<br>
><br>
> Thanks in advance,<br>
><br>
> David<br>
><br>
><br>
> [1] The SHA-256 implementation was written by Colin Percival, originally for FreeBSD. His current version seems to be here:<br>
> <a href="https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c" target="_blank">
https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c</a><br>
><br>
> [2] ospf6d also supports the use of HMAC-MD5 here, despite this not being specified in RFC 7166.<o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>