<div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div dir="ltr">Thank you very much Martin, very useful (and prompt) feedback. We'll follow up if necessary.<div><br></div><div style>Darin</div><div style>

<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 6, 2012 at 2:38 PM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Darin,<br>
<div class="im"><br>
> However, we've made some local patches to Pluto that we'll need to<br>
> re-evaluate and drop obsolete ones, re-implement necessary ones in<br>
> Charon, or maybe come up with better solutions, hopefully upstream.<br>
<br>
</div>>       * <a href="http://crosbug.com/16252" target="_blank">crosbug.com/16252</a>: initialize supplementary groups<br>
<br>
I think porting this to charon shouldn't be a problem, as it uses the<br>
same user/group switching as pluto.<br>
<br>
>       * <a href="http://crosbug.com/24476" target="_blank">crosbug.com/24476</a>: disable peer ID check<br>
<br>
If I understand correctly, this just accepts any identity the responder<br>
uses? If yes, this can be achieved by setting "rightid=%any".<br>
<br>
However, keep in mind that this has security implications; if you trust<br>
a CA certificate, any peer with a valid certificate can act as a<br>
responder, as we don't check the identity. This is why you usually want<br>
to enforce a strict identity.<br>
<br>
>       * <a href="http://crosbug.com/25675" target="_blank">crosbug.com/25675</a>: disable XAUTH ID<br>
<br>
State handling is completely different in charon than in pluto, so I'm<br>
not sure if this still applies. We currently always send the XAuth<br>
vendor ID in the first ISAKMP message. But this shouldn't be hard to<br>
change if it is problematic. However, from the bug report it's not clear<br>
to me why the responder sends an XAuth request while we negotiated PSK<br>
authentication.<br>
<br>
>       * <a href="http://crosbug.com/32738" target="_blank">crosbug.com/32738</a>: ISAKMP commit bit<br>
<br>
I don't have enough information to comment on this; it might or might<br>
not be an issue with charon.<br>
<div class="im"><br>
> Do you think some of these issues can be addressed properly upstream,<br>
> to ease the upgrade path?<br>
<br>
</div>Yes, we'd be happy to help you fixing these issues and integrate it<br>
upstream. We don't have much third party equipment on the responder side<br>
to test against, though.<br>
<br>
Kind regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>