Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Apr 2019 06:29:48 -0400 (EDT)

On Thu, 28 Mar 2019, Tobias Heider wrote:

> On 3/28/19 5:18 PM, Tero Kivinen wrote:
>> Tobias Heider: ??
> The question I asked was:
> The draft already says that INTERMEDIATE can not be used without another
> document
> that specifies what payloads are sent in INTERMEDIATE. Why can't that
> additional
> document also define it's own exchange ID for that instance of
> INTERMEDIATE instead of using
> the same ID for different things.

Because that would not allow different things needing a round trip from
re-using the same exchange, and lead to more latency/roundtrips ?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 1 Apr 2019 14:40:39 +0300

> re-using the same exchange, and lead to more latency/roundtrips ?

That's one of the reasons. 

Regards,
Valery.

> Paul
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tobias Heider <[email-masked]>
Date: Mon, 1 Apr 2019 13:42:28 +0200

I don't think that would make a difference to how it is now.

The INTERMEDIATE draft explicitly allows to specify more than one
roundtrip, and leaves
the order of those exchanges to the documents introducing the new
roundtrips
(if I got Valery right the newer one is supposed to explicitly state how
it interacts with the older).

If I wrote a draft today that adds a single large Notify in an
INTERMEDIATE exchange,
it would not be obvious how it would interact with e.G. the hybrid KE
that adds up to 7
additional INTERMEDIATE roundtrips.
I would have to explicitly specify in my draft that this additional
Notify is always added to the first
INTERMEDIATE specified in the Hybrid KE, if I wanted it to be there.
Otherwise it could be added to any
of the INTERMEDIATES in that draft, or to a new INTERMEDIATE before all
hybrid KE ones, or to a new
INTERMEDIATE after the hybrid KEs...

If I have to specify how the new Notify interacts with any of the
previous INTERMEDIATES,
I don't think it is much more work to specify how it interacts with the
same if they have different names.
It would maybe even make it clearer to some point.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Apr 2019 07:46:29 -0400 (EDT)

> the order of those exchanges to the documents introducing the new

It allows it, but that does not mean we want things to go in serial
when they could go in parallel :)

> additional INTERMEDIATE roundtrips.

The draft should be clear on how to handle that. It should not depend
on having its payload in the very first INTERMEDIATE (since then all new
things would always all need to be there and at some point we are full
again)

> INTERMEDIATE specified in the Hybrid KE, if I wanted it to be there.

I don't think we would allow you to do that. Because if another draft
insisted on the same thing, who gets to win?

> INTERMEDIATE after the hybrid KEs...

Yes. ping pong for everyone :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 1 Apr 2019 14:56:31 +0300

Hi Tobias,

in your example you may specify in your draft that your Large Notify
MUST be sent before sent before some other Large Notify and MAY be sent 
in the same INTERMEDIATE, as the third large Notify, etc.

In this case if your wish to send Large Notify 1 and Large Notify 3, you
may send them together in a single exchange, then Large Notify 2 in next exchange. 
If you don't support say Large Notify 3, you will first send Large Notify 1 then Large Notify 2. Etc.

In other words, some applications may allow combining data in a single INTERMEDIATE
with data from some other drafts, others may require their own INTERMEDIATE. That's the reason 
that having single exchange type is more flexible than separate exchange type
for every application.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 1 Apr 2019 15:02:22 +0300

> insisted on the same thing, who gets to win?

The RFCs are always being published in serial :-)
So, my idea that every new application RFC must define its relative
order in regard to all already published application RFCs
and whether piggybacking with each of them is allowed.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Apr 2019 08:07:26 -0400 (EDT)

> The RFCs are always being published in serial :-)

We have clusters :)

> and whether piggybacking with each of them is allowed.

Joking aside, I do feel it is important that the intermediate exchange
is a general concept, and should have the least amounts of hooks and
order of payloads or what not. I do not think it is a good idea to
insist on building a linked list of RFCs/payloads. The generic model of
IKE is payloads can be in any order. And if a payload won't fit in the
first intermediary exchange, it should be able to send it in the next
one without knowing anything about the other things going on.

Of course, there are exceptions, such as if we need QSKE before our new
imaginary payloads, but than those payloads might belong better in
IKE_AUTH.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 1 Apr 2019 16:03:35 +0300

> > The RFCs are always being published in serial :-)

That's not a problem, cluster members are well aware of each other :-)

> one without knowing anything about the other things going on.

I don't like this, as this complicates responder's state machine.
The responder should know what it would receive next 
(with some flexibility, of course). So, if initiator splits payload
into several exchange, the responder must be prepared to this,
so it must be stated in some application draft whether splitting this particular
payload over several exchanges is OK and under what conditions.

> imaginary payloads, but than those payloads might belong better in

So, you still have to have some exceptions?

I don't think we disagree in general. I'd only rather to avoid anarchy 
as much as possible. It doesn't mean that the order of intermediates
must be fixed, it just must be specified what is OK and what isn't. 
So, if for some application it doesn't matter whether its data is sent first or last, 
it must be stated so. If for other the order is important, it also must be stated.
If neither of published (so far) RFCs specifies ordering, you can 
perform exchanges in any order (as in your dream), if some specify, their order
must be honored.

Regards,
Valery.