Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

2019-04-02 Thread Valery Smyslov
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

Re: [IPsec] [I2nsf] 答复: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

2019-04-02 Thread Hu, Jun (Nokia - US/Mountain View)
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

Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

2019-04-02 Thread Daniel Migault
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

Re: [IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

2019-04-02 Thread Paul Wouters
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

[IPsec] draft-ietf-ipsecme-implicit-iv-06 - key length is missing

2019-04-02 Thread Valery Smyslov
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

Re: [IPsec] 答复: [I2nsf] 答复: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

2019-04-02 Thread Alvaro Retana
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

[IPsec] 答复: [I2nsf] 答复: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

2019-04-02 Thread Xialiang (Frank, Network Standard & Patent Dept)
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

Re: [IPsec] [I2nsf] 答复: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

2019-04-02 Thread Robert Raszuk
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