Hi Paul,
> > and define a default key length for the case when it is absent (e.g. 256
> > bits).
>
> Do not do this. There are broken implementations and interop issues on
> this already by broken clients who don't send or omit to send KEY_LENGTH
> (old versions of us included).
I don't buy
However the use case does drive the design of the protocol, e.g. for SDN case,
you might want separate every part of Ipsec (or other type of encryption)
tunnel config so that controller has the flexibility to provision each of them
differently on different node, and if you want to use BGP as
Hi,
Thanks Valery for your comment. My reading of the draft is that it only
focuses on the generation of the nonce and leave the remaining to 4306 [1].
The use of a code points different from 4306 is to indicate the implicit IV
- as opposed to a new transform. In this case, the negotiation of the
On Tue, 2 Apr 2019, Valery Smyslov wrote:
and define a default key length for the case when it is absent (e.g. 256 bits).
Do not do this. There are broken implementations and interop issues on
this already by broken clients who don't send or omit to send KEY_LENGTH
(old versions of us
Hi,
It's a bit late, since WGLC for the draft is already over, but hope it's not
too late.
While re-reading of the draft I realized, that it's completely silent on the
necessity
of Key Length attribute in newly defined transforms. AES accepts keys
of different sizes, so there must be a way to
On April 2, 2019 at 5:21:09 AM, Xialiang (Frank, Network Standard & Patent
Dept) (frank.xiali...@huawei.com) wrote:
[Trimmed individual addresses and consolidated (sec-ads, i2nsf-chairs) to
avoid a bounce + bess-chairs + rtg-ads.]
Hi!
Thank you all for the discussion. I’m replying to this
Hi Robert,
Thanks for further clarification, it helps for me.
Again, I think the key point is not the original use case, but the function
gaps each draft can fill in.
B.R.
Frank
发件人: Robert Raszuk [mailto:rras...@gmail.com]
发送时间: 2019年4月2日 16:32
收件人: Xialiang (Frank, Network Standard & Patent
Hi Frank,
This draft does not talk about distributing any security related
parameters. Maybe the name is a bit confusing as for some it means to be
IPSec related.
We have discussed the draft in Prague and agreed to also extend it with
other types of secure encap.
I have not discussed it with