On Tue, 5 Apr 2016, Tero Kivinen wrote:
One thing I noticed, that in the section 4.1 we do not mention "2 -
Shared Key Message Integrity Code" at all. This is actually mandated
in the RFC7296 section 4, so we should most likely add it as MUST.
Anybody objecting that change. If not I will
Paul Wouters writes:
> Looks good except the new iot block needs some english nits fixups.
Provide text, or hunt me down, and make me do the fixes :-)
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Tero Kivinen writes:
> Check it out and with this I think it might be ready for the WGLC.
One thing I noticed, that in the section 4.1 we do not mention "2 -
Shared Key Message Integrity Code" at all. This is actually mandated
in the RFC7296 section 4, so we should most likely add it as MUST.
Here is new version of the RFC4307bis. This includes changes from
Valery
(http://www.ietf.org/mail-archive/web/ipsec/current/msg10410.html)
except I did not change the AEAD/non-AEAD text in the section 3.2. The
current document still says that PRF and AUTH algorithms SHOULD be
same if non-AEAD
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions of the
IETF.
Title : Algorithm Implementation Requirements and Usage
Guidance for IKEv2
Authors : Yoav Nir
Hi, Tommy.
The changes look fine, although I’m still not convinced we even need the TLS.
But that’s for another thread.
We foresee that most TCP encapsulation is likely to be in on port 443. I think
TCP encapsulation of IKEv2/IPsec should be easily distinguishable from other
types of traffic
Hello,
At our meeting yesterday, we agreed that we want one more revision of
draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group
adoption to clear up a few concerns.
Here are the changes we’re planning:
1. Reconcile the length field size with 3GPP’s recommendation (sent
Replying to myself...
I’ve been told off-list that it didn’t make sense to introduce the hot, new
algorithm as a MAY. The only reason I’m suggesting this is that there are
currently no implementations to interop with, and no EdDSA certificates where
the public keys might come from. My main
