Hi Dave,
we've already incorporated Paul Wouters' comments in the draft on github.
The only thing that stops us publishing it is Paul's promise to
review the rest of the document (from Sections 7 up to the end).
I've just sent him a reminder asking if he could do it within the next
few days.
BTW
On Mon, 6 Jun 2016, Valery Smyslov wrote:
> When it has good reasons :-)
>
> Seriously, consider the situation when the responder finds itself
> under attack and switches to only respond to IKE_SA_RESUME
> requests. In this case it will leave legitimate clients without
> resumption ticket
All three devices also run an SSL-VPN, so you can just go to https:// to
see who owns them.
The first one will also tell you the vendor as they didn’t customize the
landing page…
> On 22 Jun 2016, at 7:11 PM, Paul Wouters wrote:
>
>
> Hi,
>
> One of my machines is seeing a continous stream
On Wed, 22 Jun 2016, Waltermire, David A. (Fed) wrote:
At IETF 95 the chairs took an action to issue a call for adoption on
draft-fluhrer-qr-ikev2-01 based on WG interest in the concept described by the
draft. This call is long overdue.
This is the official call for adoption of
https://datat
The IPSECME WG has placed draft-fluhrer-qr-ikev2 in state
Call For Adoption By WG Issued (entered by David Waltermire)
The document is available at
https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/
___
IPsec mailing list
IPsec@ietf.org
https://
At IETF 95 the chairs took an action to issue a call for adoption on
draft-fluhrer-qr-ikev2-01 based on WG interest in the concept described by the
draft. This call is long overdue.
This is the official call for adoption of
https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ as an IPSecME
Paul and Valery,
We are extremely close on wrapping up this draft. This thread appears to be all
that remains before sending the draft to the IESG. Can you guys wrap up the
final minor wording changes this week?
Valery, once agreement is reached on the text changes, can you post an updated
dra
For the adoption call on draft-pauly-ipsecme-tcp-encaps, 7 individuals
responded with support for adoption, with no concerns raised during the call.
Some of these responses indicated a desire to implement the final solution, and
to provide reviews.
Thank you to everyone who provided feedback.
Hi,
One of my machines is seeing a continous stream of NAT-T keepalive probes
for which we have no state (and for which we had no state for days or
weeks or ever). These always seem to come in sets of 3 probes at once,
every 20 seconds. And oddly enough on port 500, not 4500. Containing
the 1 by
Hi Linda:
> El 20 jun 2016, a las 15:41, Linda Dunbar escribió:
>
> Rafa,
>
> I see that your draft has identified multiple cases of SDN controlled IPSec
> tunnel.
>
> As I2NSF focus on specifying the data models for the Flow Security Policies,
> the controller "Proactively" setting up t
10 matches
Mail list logo
