Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Hi Lou,

Valery, 

>    If IKE is used to negotiate using IP-TFS, then such switching MUST NOT take place.

I read this added line as saying you can switch from tunnel to TFS, I think you mean that use of TFS is controlled via IKE.  How about?

   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1.

              I think the text is still a bit ambiguous,  since previous sentence uses a normative SHOULD
              to support switching from tunnel to IPTFS and the proposed text doesn’t forbid this
              behavior explicitly if IKE is used. I’d like to see more explicit language for IKE case.
              How about:

   If IKE is used to negotiate using IP-TFS, then use of
   TFS is controlled per Section 5.1, and thus the option of switching
   to IP-TFS receive-side operation on receipt of the first IP-TFS payload
   MUST NOT be used.

              Feel free to change the text keeping its sense...

              Regards,
              Valery.

Lou

On 10/13/2020 10:37 AM, Valery Smyslov wrote:

Valery,

How about this:

OLD
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload.

NEW
   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created 
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.

I can live with MAY, but would prefer SHOULD.

Does this work for you?

              Yes, with the following addition.

   Receive-side operation of IP-TFS does not require any per-SA
   configuration on the receiver; as such, for tunnels created 
   without IKE, an IP-TFS implementation
   SHOULD support the option of switching to IP-TFS receive-side
   operation on receipt of the first IP-TFS payload for tunnels.
   If IKE is used to negotiate using IP-TFS, then such switching
   MUST NOT take place.

              With this addition I don’t mind having SHOULD for ike-less case.

              Regards,
              Valery.

Lou

On 10/13/2020 10:06 AM, Valery Smyslov wrote:

I can live with MAY.

OK, but it must be negotiable in any case if you plan to use it with IKE.
Otherwise we'll get black holes.

On 10/13/2020 9:16 AM, Valery Smyslov wrote:

If you badly need this feature, then please make it MAY and negotiable,
so that people can ignore it. SHOULD is too strong for it,
leaving it non-negotiable is just unacceptable, IMHO.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec