Hi Tero,
Valery Smyslov writes:
The problem, that the draft is not solving, is the situation,
when one of the peers has more than one private key, each
for different signature algorithm. This may happen if in deployed
VPN there is a need to move from one signature alg
to another (for any reason
Valery,
>>> I suggest to change this as following. Instead of
>>> adding IKE registry, listing hash algorithms,
>>> add registry listing combinations of hash&signature
>>> algorithms, as listed in Appendix A.
>>> So, the registry would look like:
>>>
>>> RESERVED 0
Hi Johannes,
Your proposal creates exactly the issue which the draft is trying to
solve: The lack of flexibility by relying on IPsec
code points for the signature algorithm (as opposed to using existing OIDs
commonly used in certificates and CMS) and
the coupling of signing algorithms and sign
Hi Valery,
>
> As far as I remember, the main problem was that Auth Method field in AUTH
> Payload
> was only 8 bits and its codepoints coupled signature with particular hash.
Well, this was the initial problem, but then Yoav had the great idea of
generalizing the mechanism by using the OIDs in
Although there is a spirited, useful discussion going on between three or four
participants, we could certainly use more reviewers for this WG document.
Please send any comments to the list, and feel free to hop into the threads
already running. Thanks!
--Paul Hoffman
__
Hi Paul,
Sorry for the late reply.
You seem to assume that SPIs are random. This is not mandated by IKEv2
and in practice it is usually, but not always, the case. See
http://www.ietf.org/mail-archive/web/ipsec/current/msg06563.html
Thanks,
Yaron
On 2013-10-22 18:35, Paul Wouters wro
Hi
I think the draft is in good shape and is almost ready for publication. There
is a bunch of grammatical issues with it, but I think the RFC editor is much
better at fixing those than most of us.
Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based
on RFC 2460), and
On 10/24/2013 10:45 PM, Valery Smyslov wrote:
...
You're using existing IKE messages *and* existing timeouts to
determine when there is a problem. A separate timer would be useful,
if only to allow you to decouple fragment retransmission from IKE
transaction retries.
No, the timeouts are diff
On 2013-10-25 23:05, Yoav Nir wrote:
Hi
[...]
Section 2.5.1 recommends using 1280-byte max IP datagram size for
IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big
difference between those two RFCs is not some technical difference
between IPv6 and IPv4, but that the former w
On Oct 25, 2013, at 11:23 PM, Yaron Sheffer wrote:
>>
>> Section 2.5.1 recommends using 1280-byte max IP datagram size for
>> IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big
>> difference between those two RFCs is not some technical difference
>> between IPv6 and IPv4, but
10 matches
Mail list logo
