Subject: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jan 2019 16:21:26 +0200

[email-masked] writes:
> First of all, I'd like to thank all those of you who commented
> during the ipsecme meeting on this draft. This is exactly the
> feedback I was looking for.  
> 
> The message I got from the WG after watching the recording is to
> reduce the number of requested codes which I did in -02. This is
> almost close to what is suggested by Valery and Tero. I hope that
> this issue is now closed.  

Sorry, for taking this long to come back to this, but I think it is
still too complicated.

We have following cases:

1) Initiator only supports/wants one address family, and it requests
it. If responder supports that address family it will give address
from that address family. If it also supports another family it may
return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. If responder does not
support address family requested it will return
INTERNAL_ADDRESS_FAILURE (and perhaps include
ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with
another address family).

2) Initiator is dual stack and requests both address families. If
responder support both in same IKE SA, it will return address for
both. If it only supports one at time then it returns address for that
and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that making
another IKE SA will allow asking another set addresses.

Also I do not think making it MUST to include those notifications is
something we want to do here. I think the responder MAY include them
if it feels like, but of course 3gpp can then make their own
requirements that this feature must be supported there...

I.e., ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification indicates
that regardless whether your request succeeded or failed, the
responder would support another address family than what you asked (if
request failed), or what was returned (if request succeeded).

As addresses are part of the IKE SA, I guess that if initiator asks
for both, but do get only one of them and also got status of
ADDITIONAL_ADDRESS_FAMILY_POSSIBLE, then it needs to make new IKE SA
and request that another address family in that another IKE SA.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 29 Jan 2019 15:01:30 +0000

Hi Tero, 

Thank you for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Tero Kivinen [mailto:[email-masked]]
> Envoyé : mardi 29 janvier 2019 15:21
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : IPsecME WG
> Objet : [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt
> 

[Med] Let's see what is complicated with these two codes. 

> from that address family.

[Med] Yes.

 If it also supports another family it may
> return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too.

[Med]  An initiator which is interested to receive both would naturally include both in its initial request.    

 If responder does not
> ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with

[Med] This is more complicated compared to the current design in the draft which allows to return a status code. The initiator will then know whether it has to retry with another address family. 

> both.

[Med] Yes, but we need also to cover this case: 

   o  An initiator asks for both IPv4 and IPv6 addresses, but only one
      address family can be assigned by the responder for policy
      reasons.

The initiator needs to know why only one address is assigned so that it does not retry; hence the two separate codes. 

 If it only supports one at time then it returns address for that
> another IKE SA will allow asking another set addresses.

[Med] I'm afraid this is more complicated compared with the current design which assumes that an initiator which interested to receive both AFs will include both in the initial request.

> something we want to do here.

[Med] From an interoperability standpoint, MUST is justified here. No? 

 I think the responder MAY include them

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jan 2019 20:36:55 +0200

[email-masked] writes:
> [Med]  An initiator which is interested to receive both would
> naturally include both in its initial request.

This was case 1, where the initiator does not want two, it only wants
one in this IKE SA, and if it supports two, it wants to make them
separate IKE SAs because of policy reasons. The case 2 is when
initiator asks for both. 

> 
> >  If responder does not support address family requested it will
> > return INTERNAL_ADDRESS_FAILURE (and perhaps include
> [Med] This is more complicated compared to the current design in the
> draft which allows to return a status code. The initiator will then
> know whether it has to retry with another address family.

I do no see any difference here. Only thing is that we do not have two
status codes (IP6_ONLY_ALLOWED, IP4_ONLY_ALLOWED), we have only one
(ADDITIONAL_ADDRESS_FAMILY_POSSIBLE), and that the logic is reversed.
I.e., in your case you return one of the two possible status codes if
no other address family than what was requested can be given, in my
proposal I would return the address of requested address family and
status notification telling that another address family would also be
possible.

In both cases if the responder can return some address family it will
return that in configuration payload, if not it will return
INTERNAL_ADDRESS_FAILURE.

As there can only be IP4_ONLY_ALLOWED or IP6_ONLY_ALLOWED but never
both, what is the point of having two status codes?

> The initiator needs to know why only one address is assigned so that
> it does not retry; hence the two separate codes.

Initiator will know that it can get the address from the family that
the responder returned. If there is no
ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no
other family is possible, thus there is no point of trying to retry.

If ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is returned (along with the
actual ip addresses from one address family), then initiator knows it
can retry. 

> > and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that
> > making another IKE SA will allow asking another set addresses.
> 
> [Med] I'm afraid this is more complicated compared with the current
> design which assumes that an initiator which interested to receive
> both AFs will include both in the initial request.

If Initiator and responder both support both address families, then no
special status codes are needed, normal RFC7296 processing is fine.

Only case where special status cases are needed in this case 2 (where
initiator requests both address familieis), is when responder only
supports two address families as separate IKE SAs. In that case for
first request it will return addresses from one of the address
familiies, and indicate that another address family would also be
possible by adding ADDITIONAL_ADDRESS_FAMILY_POSSIBLE. When initiator
sees that it can create another IKE SA, and request addresses from
that other address family over that.

This is similar than ADDITIONAL_TS_POSSIBLE in RFC7296. I.e.,
responder narrowed things down in traffic selectors because of policy
reasons, but there would be another possible set of traffic selectors
which could be used if requested separately. 

> [Med] From an interoperability standpoint, MUST is justified here. No? 

No, as current implementations do not do that, thus this would make
all existing implementations not conforming to this, and would most
likely also require version number upgrade from the 2.0 to something
larger, so other end would know whether other end supports this
new MUST or not.

Anyways we always leave that kind of decisions to the policy, i.e.,
even if the implementation is dual-stack, it might not want to request
both addresses, if it only needs one.

Also you cannot really have MUST do xxx, except yyy. That would be
SHOULD, but in this case I think MAY is better. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 30 Jan 2019 09:30:35 +0000

Hi Tero, 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 29 janvier 2019 19:37
> Objet : RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt
> 
> I do no see any difference here.

[Med] The difference is that the status codes in the draft reflect the capabilities of the responder independently of the address assignment. 

 Only thing is that we do not have two
> both, what is the point of having two status codes?

[Med] If we reason in terms of AF capabilities/policies, codes for each AF is straightforward.

> other family is possible, thus there is no point of trying to retry.

[Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a request which already asked for both AFs?

> SHOULD, but in this case I think MAY is better.

[Med] If we want more deterministic behaviors of initiators and more interoperability, MAY is too weak. SHOULD would be OK.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Jan 2019 22:42:26 +0200

[email-masked] writes:
> [Med] The difference is that the status codes in the draft reflect
> the capabilities of the responder independently of the address
> assignment.

That would be fine, if the responder could return this information
before the initiator would do configuration request, so initiator
could adjusts its request accordingly, but that would require moving
those status notifications to IKE_SA_INIT, and for various reasons we
try to keep that as small as possible, so I do not think that is
correct place for those notifications. 

> [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a
> request which already asked for both AFs?

Nope. We do that with other cases too. I.e., initiator did request for
both address families, but responder said he want to do those as
separate IKE SAs, and returned addresses for only one address family.
The status notification indicates that initiator might create another
IKE SA and request another address family in there.

If it is not there, it will just have to cope with the address family
it got in the response.

This is same as what we do with ADDITIONAL_TS_POSSIBLE.

> [Med] If we want more deterministic behaviors of initiators and more
> interoperability, MAY is too weak. SHOULD would be OK.

I would expect this is something that will be dictated by policy
anyways, and unless policy says otherwise implementation that will
support both address families always asks for both (I mean why not).
So I do not think there is any real difference in MAY or SHOULD.
Neither one of them can give any suggestion to the adminstrator making
the policy, he will decided what to configure regardless what we do
here in our documents. 

I still think MAY would be correct, but I do not complain if people in
the WG think SHOULD is better.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 31 Jan 2019 07:17:06 +0000

Hi Tero, 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 30 janvier 2019 21:42

[Med] That wasn't my point. My comment is that the codes are static even if they are made during address configuration. That is: 
(1) An IPv4-only responder will always include IP4_ONLY_ALLOWED independently of the request (IPv4, IPv6, IPv4 and IPv6).
(2) An IPv6-only responder will always include IP6_ONLY_ALLOWED independently of the request.
(3) A dual-stack responder configured with an IPv4 preference will always include IP4_ONLY_ALLOWED in a response to a dual-stack request.
(4) A dual-stack responder configured with an IPv6 preference will always include IP6_ONLY_ALLOWED in a response to a dual-stack request. 

The behavior of the initiator is more deterministic, e.g., when case (1) is encountered:
    - An IPv6 initiator will stop trying asking for IPv6 addresses.
    - A dual-stack initiator who asked for both won't try with a separate request for IPv6
    - A dual-stack initiator who asked first for IPv4 won't sent a request for IPv6
    - A dual-stack initiator who asked first for IPv6 will send a request for IPv4

Now consider that ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is to be defined, this code will returned with the following conditions: 

(a) An IPv4-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE only if the initiator asked for IPv6.
(b) An IPv6-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE only if the initiator asked for IPv4.
(c) A dual-stack responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if the initiator asked for both, but for policy matters only one AF can be assigned per request. 

The behavior of the initiator is less deterministic, e.g., case (c): A dual-stack initiator who asked for both but got only IPv6 or IPv4 does not know why the other address is not assigned. It will then send a request to try to get an address. 

Protocols with rich error codes makes it easier to adjust the behavior, to diagnostic, etc. 

> separate IKE SAs, and returned addresses for only one address family.

[Med] OK, I see, this is doing the same job as what we used to have in -01:

   o  SINGLE_AF_SUPPORTED: This status type indicates that only a single
      address family can be assigned per request, not both.  This status
      type is returned when an initiator requested both IPv4 and IPv6
      addresses/prefixes in the same request, but only a single address
      family can be assigned per request by the responder.

      The address family preference is defined by a policy that is local
      to the responder.

      If a responder receives a request for both IPv4 and IPv6 address
      families, it replies with the preferred address family and
      includes SINGLE_AF_SUPPORTED notification status type.  Upon
      receipt of this status type, the initiator MAY re-issue another
      configuration request to ask for an additional address family.
 
I have removed that code because the message I got from the working group is to reduce the number of codes.