Subject: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Apr 2019 21:19:15 +0300

In the Prague meeting we had two options how to send information what
kind of address families are supported [1]:

1) IP6_ONLY_ALLOWED and IP4_ONLY_ALLOWED status notifications which
   are sent whenever only one address family is supported. I.e., if
   only one address family is supported, then IP*_ONLY_ALLOWED is
   sent. If both address families are supported, then no status code
   is sent. This is what current draft proposes.

2) ADDITINAL_ADDRESS_FAMILY_POSSIBLE status notification which is used
   when other address family than currently returned could also be
   used. I.e., if no address was assigned, then this status
   notification tells that trying with other address family works, and
   if address was assigned from one address family this tells that
   another request with another address family can also work. 

In the meeting we did not have clear concensus [2] on which of them
are better. The option 2 is closer to what we currently have in
RFC7296 for ADDITIONAL_TS_POSSIBLE.

Both of the options seems to work, and I think people think the
differences are so small, that they do not care. So unless people
object soon, I think we will keep whatever is in the draft, as I
seemed to be only one who thought the other option would be clearer.

[1] See slides 6 and 7 of
    https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04
[2] https://datatracker.ietf.org/doc/minutes-104-ipsecme/
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 17 Apr 2019 10:48:07 +0300

Hi, 

I was thinking of another alternative design (well, it's a small modification
of a current one). Instead of defining IP4_ONLY_ALLOWED and IP6_ONLY_ALLOWED,
define IP4_ALLOWED and IP6_ALLOWED. The semantics would be a positive
assertion that this particular AF allowed, without any concerns with the other AF.

In this case, the behavior would be as follows:

Requested @Init	Supported @Resp	Assigned 		Returned Notification

IPv4			IPv6			None			IP6_ALLOWED

IPv6			IPv6			IPv6			IP6_ALLOWED

IPv6			IPv4			None			IP4_ALLOWED

IPv4			IPv4			IPv4			IP4_ALLOWED

IPv4 and IPv6	IPv6			IPv6			IP6_ALLOWED

IPv4 and IPv6	IPv4			IPv4			IP4_ALLOWED

IPv4 and IPv6	IPv6 or IPv4		IPv6 or IPv4		IP4_ALLOWED, 
			(Policy-based)				IP6_ALLOWED

IPv4 and IPv6	IPv6 and IPv4	IPv6 and IPv4	IP4_ALLOWED, 
									IP6_ALLOWED

An (mostly theoretical) advantage of this design is that if some new AF appears
(well, I understand that it's unlikely in the foreseen future, but who knows),
the design will work w/o changes, we only need to define a new <AF>_ALLOWED
notification.

Regards,
Valery.

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

---

From: <[email-masked]>
Date: Wed, 17 Apr 2019 11:30:11 +0000

Hi Velery, 

Works for me. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:[email-masked]] De la part de Valery Smyslov
> Envoyé : mercredi 17 avril 2019 09:48
> À : 'Tero Kivinen'; [email-masked]
> Objet : Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> 
> Hi,
>

---

From: <[email-masked]>
Date: Mon, 29 Apr 2019 13:28:56 +0000

Hi Tero, all,

I went with an updated version which takes into account the feedback from Valery. The updated version is available at: 
https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-03 

Can you please put this version in the WGLC? Thanks.

Cheers,
Med

> De : IPsec [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : mercredi 17 avril 2019 13:30
> À : Valery Smyslov; 'Tero Kivinen'; [email-masked]
> > >     https://datatracker.ietf.org/meeting/104/materials/slides-104-
> ipsecme-
> > chair-slides-04

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Apr 2019 12:10:48 -0400

I would prefer no notify if the request was fulfilled and to only send a notify if a request could not be fulfilled. Since clients can ask for both that should cover things. If a client isn’t asking for ipvX, I see no need to answer that ipvX is supported too.

Paul

Sent from mobile device

> On Apr 17, 2019, at 03:48, Valery Smyslov <[email-masked]> wrote:
> 
> Hi, 
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 30 Apr 2019 09:10:17 +0300

Hi Paul,

> I would prefer no notify if the request was fulfilled and to only send a notify if a request could not be fulfilled.
> Since clients can ask for both that should cover things. If a client isn’t asking for ipvX, I see no need to answer
> that ipvX is supported too.

That would make sending these notifies dependent on the content of request.
So, the tradeoff is whether saving eight bytes justifies complication of state machine.

Regards,
Valery.

---

From: <[email-masked]>
Date: Tue, 30 Apr 2019 06:17:51 +0000

Hi Paul, 

The responder does not know if the initiator is dual-stack or not. For example, an initiator can be instructed by policy to make use of separate requests. 

The returned notification code(s) will drive the subsequent of the initiator: ask for an additional AF, for example.  

Blindly returning the notification simplifies the behavior at the responder and optimizes the load on the server in some cases (e.g., IPv6-only responder receiving a subsequent request for IPv4). 

Cheers,
Med

> De : IPsec [mailto:[email-masked]] De la part de Paul Wouters
> Envoyé : lundi 29 avril 2019 18:11
> À : Valery Smyslov
> Cc : [email-masked]; Tero Kivinen
> I would prefer no notify if the request was fulfilled and to only send a
> notify if a request could not be fulfilled. Since clients can ask for both
> that should cover things. If a client isn’t asking for ipvX, I see no need to
> answer that ipvX is supported too.
> 
> Paul
> 
> Sent from mobile device
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Apr 2019 09:39:52 -0400 (EDT)

> The responder does not know if the initiator is dual-stack or not. For example, an initiator can be instructed by policy to make use of separate requests.

Why would the initiator that is allowed by policy to do both v4 and v6
not ask for both at once?

I don't see the "use of separate requests" as a real use case. Can you
explain how this would actually happen in a real world?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Apr 2019 09:42:39 -0400 (EDT)

> That would make sending these notifies dependent on the content of request.

Yes, like all CP payloads?

> So, the tradeoff is whether saving eight bytes justifies complication of state machine.

It's not about saving bytes for me, but about the logic and simplicity
on the wire. If a client isn't asking for v6, why tell them about our
v6 capabilities?

I see that quite different from "if you want compression, it is
available". The address family is a much more fundamental property
of an IPsec tunnel. It's not a bell or whistle.

Paul

---

From: <[email-masked]>
Date: Tue, 30 Apr 2019 14:06:01 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Paul Wouters [mailto:[email-masked]]
> Envoyé : mardi 30 avril 2019 15:40
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> Objet : RE: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> 
> > The responder does not know if the initiator is dual-stack or not. For
> example, an initiator can be instructed by policy to make use of separate
> requests.
> 

[Med] I do fully agree that requesting both when supported would be straightforward, but I'm afraid that some implementations may not follow that behavior. Such implementations may do that:
* for arbitrary reasons given that existing specs do not forbid such separate requests.
* or, in some contexts such cellular devices, mimic a similar behavior for requesting separate PDP contexts instead of a dual-stack one.

FWIW, this is exactly why we use this wording in the draft: 

   If the initiator is dual-stack, it MUST include both address families
   in its request (absent explicit policy/configuration otherwise).

> explain how this would actually happen in a real world?

[Med] See the cases above. There is also the case of a responder that wants (for policy reasons) requests to be made as separate IKE SAs. For this case, requests will need to be done separately.