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

[Christian Hopps <[e-mail]>]

I really don't understand the extreme back pressure against using ESP the way it was designed. The next-header field is supposed to identify the payload, it does so for every other payload ESP carries. Any other solution to somehow infer the payload type some other way *has* to be seen as a hack. Why do we need a hack?

The fact that using a payload identifier the way ESP intended also allows us to do things like handle receipt of said payload without extra configuration, or use the payload outside of ESP are just benefits from good design, they aren't indicative of doing something incorrectly, the opposite in fact. They also shouldn't even be needed to justify using ESP the way it was designed to be used.

This is all very strange to me, this want to not use the next-header field to, you know, identify the next header.

Thanks,
Chris.


> On Oct 14, 2020, at 5:55 AM, Tero Kivinen <[e-mail]> wrote:
> 
> Valery Smyslov writes:
>> Hi Tero,
>> 
>>>> I'm not advocating ike vs ike-less, just trying to have a comprehensive
>>>> solution.  One example ikeless usecase is captured by the YANG model in
>>>> last call:
>>>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09
>>> 
>>> Which will require similar behavior from the IPsec part than IKE,
>>> meaning you can't really change any parameters on the fly for existing
>>> SAs. You can't change for example the ciphers of the existing SA, and
>>> expect that to work.
>> 
>> In fact, unlike changing e.g. cipher on the fly, that is not
>> possible, because the cipher used is not present in the ESP packet,
>> so that you cannot distinguish two ESP packets with different
>> ciphers, you can distinguish tunnel packets from IPTFS packets on
>> receiving side (by analyzing Next Header), so technically the
>> proposed switching is workable. That said, I fully agree with you
>> that it is a very bad idea and must be prohibited, at least for
>> traditional IPsec.
> 
> I have never understood why the IPTFS packets needs to be identified
> by the Next Header. We do not include cipher algorithm in the ESP
> packet, so that is known by the SA information. We could do exactly
> same for the IPTFS, i.e., if all packets inside the specific SA is
> always IPTFS packets, then there is no need to identify whether IPTFS
> is used or not in the Next Header field, and there would be no need to
> allocate new IP protocol number for this.
> 
> If the reason we need new IP protocol number is just because they want
> to be able to this switching of the IPTFS on in the middle of the
> IPsec SA when NOT using IKE, then I think that is not very good reason
> for allocating new IP protocol number.
> 
>> I care less about other use cases (I recall that authors wanted
>> to use IPTFS not only for IPsec, but as more generic
>> mechanism to pack several IP packets into one).
> 
> I would like to understand what these other use cases are and how they
> affect the use case for IPsec. I mean if those use cases are just "we
> want to make generic mechanism" without any specific use cases, there
> is no need to think about the Early allocation of the IP protocol
> number.
> 
>> So, I may leave with this option if it will be explicitly prohibited
>> for traditional IPsec.
> 
> And if interoperability testing etc of the IPTFS in the IPsec use case
> is done using IKE, and in that case we do not need new IP protocol
> number, as we can know from the IPsec SA whether IPTFS is enabled or
> not. There is no need to know that per packet basis. And In that case
> IP protocol number allocation can be later, when other uses cases
> emerge.
> 
>> IKE-less (l2nsf) use case is a corner case, I tend to agree with you
>> that it should be prohibited for this case too.
> 
> Definitely. Actually I think the i2nfs document should probably say
> something about changing SAD stucture during on the fly. I would
> expect that most of the implementations in kernel do not really allow
> easy way of modifying the replay window or things like that while the
> SA is being used. In normal case there is no need to ever set the for
> example replay window, it will start from all zeros when SA is
> created, and automatically updated after that. Other things like
> sequence numbers or IV can cause serious security issues if they are
> modified wihtout following specific rules.
> 
> With my quick check of the i2nfs draft I did not see whether it has
> any text saying those things are create once, and after that read only
> or not. I think it should have that kind of text somewhere....
> --
> [e-mail] <mailto:[e-mail]>