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

From: Paul Wouters <[email-masked]>
Date: Thu, 2 May 2019 14:25:10 -0400 (EDT)

On Tue, 30 Apr 2019, [email-masked] wrote:

>> Why would the initiator that is allowed by policy to do both v4 and v6
>> not ask for both at once?
>
> [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.

Do we currently have a large scale implementation issue, or are you
predicting that this may happen in the future. While I am okay with
doing it if it fixes a large deployment issue, I'm not okay with it
to pre-emptively support expected implementation issues.

>  Such implementations may do that:
> * for arbitrary reasons given that existing specs do not forbid such separate requests.

So what is the problem with bad implementations doing bad things? Why
would this notify tell them to do things differently next time?

> * or, in some contexts such cellular devices, mimic a similar behavior for requesting separate PDP contexts instead of a dual-stack one.

Is this actually happening at scale, or is this just a feared bad way
things will get implemented?

>> 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?
>
> [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.

If the "policy reason" is there, why would a notify change their
behaviour? If they are already sending a v4 and a separate v6
request, what value does the notify add?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 May 2019 14:28:24 -0400 (EDT)

On Tue, 30 Apr 2019, Valery Smyslov wrote:

>> 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.

I wouldn't call that complicated the state machine. You are not adding
new states or transitions, and you already keep a list of received
payloads for this state/exchange I hope :P

Paul

---

From: <[email-masked]>
Date: Fri, 3 May 2019 06:57:52 +0000

Hi Paul, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters [mailto:[email-masked]]
> Envoyé : jeudi 2 mai 2019 20:25
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> Objet : Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> 
> > [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.
> 
> So what is the problem with bad implementations doing bad things?

[Med] This may double the load on the responder. Sending systematically a second request while a responder will discard it because it does support only one AF is suboptimal (think about IPv6-only voice over WLAN for example).

 Why
> would this notify tell them to do things differently next time?

[Med] The notification message will provide an information to the initiator whether it is useful or not to send a request for the other AF.

> 
> > * or, in some contexts such cellular devices, mimic a similar behavior for
> requesting separate PDP contexts instead of a dual-stack one.
> 
> > [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.
> 

[Med] I'm not sure to understand your comment. The policy is at the responder side. The responder will honor one AF per request. Returning the supported AFs to the initiator will trigger a separate request from the initiator to get the other AF (if needed).

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 6 May 2019 09:02:05 +0300

> payloads for this state/exchange I hope :P

True, I wasn't precise enough. The complication is that in the current approach
the responder sends these notifications blindly, sending them doesn't depend
on the content of CP request.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 May 2019 10:42:34 -0400 (EDT)

> on the content of CP request.

RFC 7296 found that argument weak :)

    Note that no recommendations are made in this document as to how an
    implementation actually figures out what information to send in a
    response.  That is, we do not recommend any specific method of an
    IRAS determining which DNS server should be returned to a requesting
    IRAC.

For example, you can always reply with INTERNAL_IP4_DNS and INTERNAL_IP4_NBNS
if the client is requesting only an INTERNAL_IP6_ADDRESS and either
these first two CFG payloads or not. But I hope you added "complicated code"
to not send those :)

sub-optimal clients get sub-optimal answers.

Paul