Hey Paul and Valery,
> Hi Paul,
>
> > > It's a good question. My idea is that each application document must
> > > define this, as well as the order of INTERMEDIATE exchanges, if it
> > > matters. So, I assume that by default each application will utilize
> > > its own INTERMEDIATE , but some
>
> [I snipped some text to make message more readable]
>
Same here :-)
> > The important thing I'd like to mention:
> > I think, if we can avoid an issue by design - by excluding an option
> > we don't necessarily need - we should do that and not the other way
> around.
>
> I don't see it's
>>> I would think it quite differently. Each protocol extension just puts
>>> payloads in the IKE_SA_INIT and once that one becomes too big, the
>>> IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE.
>>> This document defines what goes into IKE_SA_INIT, so the rest (eg new
> > I would think it quite differently. Each protocol extension just puts
> > payloads in the IKE_SA_INIT and once that one becomes too big, the
> > IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE.
> > This document defines what goes into IKE_SA_INIT, so the rest (eg new
>
In that case, isn't the effort of having to explicitly specify every single
case actually the
same as if every of these documents would simply specify it's own exchange that
takes place between IKE_SA_INIT and IKE_AUTH?
What is the advantage of using INTERMEDIATE then, instead of just rolling
Hi Paul,
> > It's a good question. My idea is that each application document
> > must define this, as well as the order of INTERMEDIATE exchanges,
> > if it matters. So, I assume that by default each application
> > will utilize its own INTERMEDIATE , but some applications could
> > benefit from
>> It's a good question. My idea is that each application document
>> must define this, as well as the order of INTERMEDIATE exchanges,
>> if it matters. So, I assume that by default each application
>> will utilize its own INTERMEDIATE , but some applications could
>> benefit from piggybacking.
If there is a chance that this is a potential thread (and I fear
it'll be impossible to proof the opposite), my feeling is
that the document should say that IKE_INTERMEDIATE MUST NOT be
supported without the support of at least one document defining the
payload. >>>
On Thu, 21 Mar 2019, Valery Smyslov wrote:
It's a good question. My idea is that each application document
must define this, as well as the order of INTERMEDIATE exchanges,
if it matters. So, I assume that by default each application
will utilize its own INTERMEDIATE , but some applications
Hi Tobias,
> Hi Valery,
>
> >> If there is a chance that this is a potential thread (and I fear it'll be
> >> impossible to proof the opposite), my
> >> feeling is that the document should say that IKE_INTERMEDIATE MUST NOT be
> >> supported without the
> >> support of at least one document
[I snipped some text to make message more readable]
> > > I know that the main motivation for IKE_INTERMEDIATE is PQKE, but I
> > > don't feel that we're at a point where we can actually say for sure
> > > that this is the one and only way for PQKE and, thus, I'd prefer
> > IKE_INTERMEDIATE to be
Hi Valery,
>> If there is a chance that this is a potential thread (and I fear
>> it'll be impossible to proof the opposite), my
>> feeling is that the document should say that IKE_INTERMEDIATE MUST
>> NOT be supported without the
>> support of at least one document defining the payload.
> That
ner than
> > just saying it could be anything. I'd actually prefer what I mentioned
> > above, not allowing IKE_INTERMEDIATE to be implemented without
> another document defining the actual payload.
>
> Exactly, except that I'd s/implemented/used. You can implement a pu
+1 on adopting this draft.
Kind regards
Andreas
On 13.03.19 04:30, Tero Kivinen wrote:
> This document has been stable for some time, and I think it is ready
> to go forward. Because of that I will start one week long WG
> adoptation call for this draft which will expire end of next week
>
izing it.
Regards,
Valery.
> In any case, if we can discuss/change that after adoption, I'm completely
> fine and support adoption.
>
> >
> > > If the WG thinks that this is not an issue or can be solved after
> > > adoption, we support adoption and we were about to
if we can discuss/change that after adoption, I'm completely fine
and support adoption.
>
> > If the WG thinks that this is not an issue or can be solved after
> > adoption, we support adoption and we were about to show and discuss
> > some details on that (and other PQKE related stuff) in a present
; -Ursprüngliche Nachricht-----
> > Von: IPsec Im Auftrag von Panos Kampanakis
> > (pkampana)
> > Gesendet: Donnerstag, 14. März 2019 20:07
> > An: 'Tero Kivinen' ; ipsec@ietf.org
> > Betreff: Re: [IPsec] WG adoptation call for
> draft-smyslov-ipsecme-ikev2-aux-
gt; Tobias
>
>> -----Ursprüngliche Nachricht-----
>> Von: IPsec Im Auftrag von Panos Kampanakis
>> (pkampana)
>> Gesendet: Donnerstag, 14. März 2019 20:07
>> An: 'Tero Kivinen' ; ipsec@ietf.org
>> Betreff: Re: [IPsec] WG adoptation call for
> draft-smyslov-ipsecme
potential)
issue before the adoption call ends.
Regards
Tobias
> -Ursprüngliche Nachricht-
> Von: IPsec Im Auftrag von Panos Kampanakis
> (pkampana)
> Gesendet: Donnerstag, 14. März 2019 20:07
> An: 'Tero Kivinen' ; ipsec@ietf.org
> Betreff: Re: [IPsec] WG adoptat
+1 on adopting this draft.
-Original Message-
From: IPsec On Behalf Of Valery Smyslov
Sent: Thursday, March 14, 2019 4:38 AM
To: 'Tero Kivinen' ; ipsec@ietf.org
Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
Hi,
as author of the document I (obviously
Hi,
as author of the document I (obviously) support its adoption.
It's a building block for QSKE solution (at least how the WG sees it now)
so I think we should adopt it.
Regards,
Valery.
> This document has been stable for some time, and I think it is ready
> to go forward. Because of that I
This document has been stable for some time, and I think it is ready
to go forward. Because of that I will start one week long WG
adoptation call for this draft which will expire end of next week
(2019-03-22).
If you have any reasons why this should not be adopted as WG document,
send email to
22 matches
Mail list logo
