[IPsec] IPsec profile feedback wanted (draft autonomic control plane)

[hope its fine to cross-post ipsec and ipsecme given how one is concluded, but may have more long-time subscribers] We're looking for opinions about an IPsec profile for "Autonomic Control Plane" draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of: https://raw.githubuserconte

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Tue, Feb 25, 2020 at 10:17:30PM +0200, Yoav Nir wrote: > ipsec is this group???s mailing list. I don???t know that there even is an > ipse...@ietf.org Yepp. Silly me. Didn't check that ipsecme was keeping the old mailing list name. > I read a little more. Hope you do

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Michael: Yoav talked about the non-GRE case. On Tue, Feb 25, 2020 at 05:44:10PM -0500, Michael Richardson wrote: > > Yoav Nir wrote: > > The profile specifies that the ACP nodes should use tunnel mode (when > > GRE is not used), because: IPsec tunnel mode is required because the > >

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Thanks. I think ACP has no specific encoding preference for the exchanged certificates, but we do of course MUST support BRSKI enrolled certificate (chains), and i think PKS#7 is MTI there (Michael ?). Can PKS#7 certificate chains be converted locally into any potential other possible IKEv2 suppo

Re: [IPsec] terminology check: "modern IPsec protocol suite"

Does IPsec not also include AH as an option still ? On Thu, Apr 09, 2020 at 09:02:12AM +0300, Valery Smyslov wrote: > Hi, > > > > draft-ietf-taps-transport-security is currently in IESG evaluation, and in > > > its description of IKEv2 with ESP it asserts that "IKEv2 [RFC7296] and ESP > > > [RFC4

Re: [IPsec] terminology check: "modern IPsec protocol suite"

Haha. So you have to choose whether you want a title that a Muggle understand or not ;-) Cheers Toerless On Thu, Apr 09, 2020 at 07:07:00PM -0400, Paul Wouters wrote: > L > > On Apr 9, 2020, at 18:56, Toerless Eckert wrote: > > > > ???Does IPsec not also include

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Seems as if the reply to this sub-thread was overlooked, sorry. In the ACP, a node has multiple IPsec connection, each of which acts like a virtual link to another node and each of them will carry IPv6 packets with arbitrary IPv6 source and destination adresses. So the ideal, most compact option

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Wed, Jun 17, 2020 at 01:59:18PM -0400, Paul Wouters wrote: > On Wed, 17 Jun 2020, Toerless Eckert wrote: > > > These two choices are somewhat arbitrary, i am sure some vendor > > not following this draft will later come and complain that he > > prefers GRE in tunnel

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

there is a mismatch. One could call that configuration "unwilling". ACP draft does not even have a notion of "unwilling", just "incapable". Cheers Toerless Every router allows you to configure whether an On Wed, Jun 17, 2020 at 04:01:25PM -0400, Paul

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Wed, Jun 17, 2020 at 05:07:48PM -0400, Paul Wouters wrote: > On Wed, 17 Jun 2020, Toerless Eckert wrote: > > > Given how you are focussing on this aspect, > > can i assume that you are happy with the everything > > else in the suggested text ? > > I don't k

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > The RFC states: > >The USE_TRANSPORT_MODE notification MAY be included in a request >message that also includes an SA payload requesting a Child SA. It >requests that the Child SA use transport mode rather than tunnel mod

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

not was WG chair. ;-)) > Toerless Eckert writes: > > On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote: > > > The RFC states: > > > > > >The USE_TRANSPORT_MODE notification MAY be included in a request > > >message that also i

[IPsec] Interop with microsoft CA (was: IPsec profile feedback wanted (draft autonomic control) plane)

Picking up some leftover open points. On Wed, Feb 26, 2020 at 03:10:55PM -0500, Paul Wouters wrote: > Actually we do. We had to add pkcs7 to ikev2 to be compatible with some > windows deployments when intermediate certificates were being sent. On > top of that, Microsoft did it wrong, as the forma

[IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

In ACP, we use IKEv2 between peers without assumed methods to retrieve certificates from "external" sources like http repositories. And CA most likely will have non-public Trust Anchor (TA) (enterptrise PKI). Imagine a large multi-tenant network infrastructure (office building, skyscraper) where

Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

On Fri, Jun 19, 2020 at 01:10:37PM -0400, Paul Wouters wrote: > > So i am tentatively adding the following text: > > > > CERTREQ MUST be used to indicate the ACP TA hashes. This helps the peer > > in selecting the ACP certificate in case it has certificates also from > > other TA. It is RECOMMEN

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Thanks, Valery let me pick up the one point i have no clear text solution for yet. On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote: > Hi Toerless, [...] > Well, the example you provided doesn't work. In IKEv2 first > the responder sends a list of TA (hashes) he has in a CERTREQ pay

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Inline On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote: > On Jun 21, 2020, at 22:22, Toerless Eckert wrote: > > > > ???Thanks, Valery > > > > let me pick up the one point i have no clear text solution for yet. > > > >> On Fri, Feb 28

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Mon, Jun 22, 2020 at 05:51:16PM +0300, Valery Smyslov wrote: > Hi Ben, > > > It's not quite "you know who you are talking to based on IP", but more of > > "under this precondition, you know that the peer should be part of the same > > ACP domain, and thus using the same TA as you". But you don

Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

On Mon, Jun 22, 2020 at 05:42:00PM +0300, Valery Smyslov wrote: > And I think that prohibiting sending CERTREQ is really bad idea for the > profile. > The better idea is to require ignoring CERTREQ content on receipt if you > think > it's not useful in your use case, but not banning sending it.

Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

On Fri, Jun 26, 2020 at 04:40:53PM +0300, Tero Kivinen wrote: > Michael Richardson writes: > > Unless we can convince various people otherwise, the TA will all be > > private enterprise/ISP CAs. > > And for some reason those same private enterprise/ISP people are > exactly those who say that we ca

Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

Thanks a lot, Tero for all your time responding, inline On Tue, Jun 30, 2020 at 10:26:26PM +0300, Tero Kivinen wrote: > I still consider sending TA certificate ever completely useless > thing, that just wastes bytes. Luckily it was not me alone who wanted that feature but it was triggered by Mic

[IPsec] IPsec NSA recommendations 108

https://media.defense.gov/2020/Jul/02/2002355501/-1/-1/0/CONFIGURING_IPSEC_VIRTUAL_PRIVATE_NETWORKS_2020_07_01_FINAL_RELEASE.PDF No Swans mentioned ;-( ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Tero: Re: Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

On Tue, Jul 21, 2020 at 10:54:25AM -0400, Michael Richardson wrote: > > Sometimes the problem is that there are devices there which do not > > support ECDSA at all, which means you are stuck with RSA for both root > > and EE for all devices. With CERTREQ some parts of the network can >

Re: [IPsec] leading versus trailing ICV

On Thu, Aug 06, 2020 at 08:22:28PM +0300, Tero Kivinen wrote: > William Allen Simpson writes: > > > So it might make sense to have the ICV at the end because it is > > > likely cache hot when needed. > > > > But after removing padding for these stream algorithms, then the ICV is > > very likely no

Re: [IPsec] GDOI and G-IKEv2 payloads

How would someone today do the equivalent of RFC8052 with G-IKEv2 ? On Mon, Feb 05, 2024 at 04:06:11AM +, Fries, Steffen wrote: > Hi, > > I've got a question regarding the relation of G-IKEv2 and GDOI. > > I realized that G-IKEv2 will be the successor of GDOI and would have a > question reg

Re: [IPsec] GDOI and G-IKEv2 payloads

Well... There may be connection between progressing the draft and these extensions. Given how extensions to GDOI where also done by other SDOs, i would like to understand if G-IKEv2 has done the best to make extensions as painless as possible, especially for adopting extensions previously exi

Re: [IPsec] GDOI and G-IKEv2 payloads

On Wed, Feb 07, 2024 at 11:02:33AM +0300, Valery Smyslov wrote: > Hi Toerless, [snip] > I don't think core specification should define how all existing extensions > of an older protocol could be mapped to the current one, but few general > words could be added. I was imagining: a) A table where

[IPsec] Multi-access interfaces (with IPsec)

I want to describe (in some draft) the use of a virtual multi-access interface that is mapped to multiple p2p associations (eg: IPsec). Which i think is a pretty standard option in industry implementations, eg: in hub routers for hub & spoke deployments. Is there any good RFC reference that expla