<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">

Hi Martin,

<div><br>

</div>

<div>Yes indeed, i was. Thanks for your response. I think I understand better what you meant.</div>

<div>

<blockquote type="cite">So the question is: Why does Anyconnect send a configuration payload in IKE_SA_INIT? Even if it might not be explicitly disallowed, the configuration payload is certainly not used here as intended in RFC5996.</blockquote>

<div><br>

</div>

<div>Actually RFC 5996 states:</div>

<div>"Unrecognized or unsupported attributes MUST be ignored in both requests and responses."</div>

<div>

<pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always;"> <a href="https://tools.ietf.org/html/rfc5996#section-3.15.1">3.15.1</a>. Configuration Attributes .........................<a href="https://tools.ietf.org/html/rfc5996#page-110">110</a></pre>

<div><br>

</div>

</div>

<div>So, my understanding is an RFC compliant devices would just ignore this particular instance, instead of rejecting the connection.</div>

<div><br>

</div>

<blockquote type="cite">As said, working around this issue might be possible, but I don't think it makes much sense given the mentioned Cisco EULA restrictions.</blockquote>

<div><br>

</div>

<div>You're right, I was just doing some research on my end regarding some other things when I came across your post and I was curious about it. Thanks for the clarification. :)</div>

<br>

<div>Regards,<br>

--<br>

Atri Basu<br>

Cisco Systems TAC - VPN Group<br>

Mon - Fri : 8AM - 4PM Eastern (US)<br>

Direct Phone: +1 (919) 991-9531<br>

E-mail: <a href="mailto:atbasu@cisco.com">atbasu@cisco.com</a><br>

</div>

<br>

On Apr 22, 2014, at 3:19 AM, Martin Willi <<a href="mailto:martin@strongswan.org">martin@strongswan.org</a>> wrote:<br>

<br>

<blockquote type="cite">Atri,<br>

<br>

<blockquote type="cite">I notice you mention in your response that strongswan is rejecting an<br>

unencrypted payload that it expects to be encrypted.<br>

</blockquote>

<br>

I assume you are referring to the one-and-a-half year old discussion at<br>

[1]?<br>

<br>

<blockquote type="cite">However, this particular attribute is included in Message 1 which can't<br>

be encrypted. So why is strongswan expecting the payload to be<br>

encrypted?<br>

</blockquote>

<br>

While this is true, strongSwan still rejects an unencrypted<br>

configuration payload message. It just does not expect a configuration<br>

payload in IKE_SA_INIT.<br>

<br>

So the question is: Why does Anyconnect send a configuration payload in<br>

IKE_SA_INIT? Even if it might not be explicitly disallowed, the<br>

configuration payload is certainly not used here as intended in RFC5996.<br>

<br>

As said, working around this issue might be possible, but I don't think<br>

it makes much sense given the mentioned Cisco EULA restrictions.<br>

<br>

Regards<br>

Martin<br>

<br>

[1]<a href="https://lists.strongswan.org/pipermail/users/2012-December/004064.html">https://lists.strongswan.org/pipermail/users/2012-December/004064.html</a><br>

<br>

</blockquote>

<br>

</div>

</body>

</html>