IPsec workshop at netdev01?

IPsec workshop at netdev01?

[Steffen Klassert]

Is there any interest in doing an IPsec workshop at netdev01?

This mail is to probe if we can gather enough discussion topics to run
such a workshop. So if someone is interested to attend and/or has a
related discussion topic, please let me know.

The idea to do this workshop came yesterday, so I'm still collecting
topics I'm interested in. Some things that came immediately to my mind
are:

- Our IPsec policy/state lookups are still hashlist based on slowpath with
  a flowcache to do fast lookups for traffic flows we have already seen.
  This flowcache has similar issues like the ipv4 routing chache had.
  Is the flowcache an appropriate lookup method on the long run or should
  we at least think about an additional alternative lookup method?

- We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
  comes up from time to time. Some solutions were proposed in the past
  but all had problems. The current behaviour is broken if someone tries
  to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
  this right somehow or is it better to just return an error in this case?

- Changing the system time can lead to unexpected SA lifetime changes. The
  discussion on the list did not lead to a conclusion on how to fix this.
  What is the best way to get this fixed?
  
- The IPsec policy enforcement default is to allow all flows that don't
  match a policy. On systems with a high security level it might be
  intersting to configurable invert the default from allow to block. With
  the default to block configured, we would need allow policies for all
  packet flows we accept. Some people would be even interested in a knob
  to enforce a certain default behaviour until the next reboot. Is this
  reasonable? How far can we get here?

- A more general thing: How complete is our IPsec implementation? Are there
  things that should be implemented but we don't have it?

Re: IPsec workshop at netdev01?

[Jamal Hadi Salim]

On 01/06/15 05:19, Steffen Klassert wrote:
> Is there any interest in doing an IPsec workshop at netdev01?
>



> This mail is to probe if we can gather enough discussion topics to run
> such a workshop. So if someone is interested to attend and/or has a
> related discussion topic, please let me know.
>

For the record I would attend if you had it.
Additional topic that maybe of interest is:
on hardware offload of crypto as well as keying(RSA etc).
I know we have some stuff in place - but a lot of these new
devices are going on tangents doing their own thing. So perhaps
some guidance would help. That specific topic maybe overlapping
with the BOF Shrijeet is organizing - but there we are still
talking about L2/3 and ACLs and an ipsec discussion could
be, at the moment, off topic.

cheers,
jamal

Re: IPsec workshop at netdev01?

[Florian Westphal]

Steffen Klassert <steffen.klassert@secunet.com> wrote:
> - We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
>   comes up from time to time. Some solutions were proposed in the past
>   but all had problems. The current behaviour is broken if someone tries
>   to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
>   this right somehow or is it better to just return an error in this case?

FWIW I think
http://patchwork.ozlabs.org/patch/49465/

came closest to achieving full CONFIG_COMPAT support; since netlink is
no longer async now I'm not sure we'd still need additonal 32-compat syscalls
to make compat work for all cases.

So "its ugly as hell" is probably the only problem that is hard to avoid ;-)

Re: IPsec workshop at netdev01?

[Steffen Klassert]

On Tue, Jan 06, 2015 at 06:00:26PM +0100, Florian Westphal wrote:
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
> > - We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
> >   comes up from time to time. Some solutions were proposed in the past
> >   but all had problems. The current behaviour is broken if someone tries
> >   to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
> >   this right somehow or is it better to just return an error in this case?
> 
> FWIW I think
> http://patchwork.ozlabs.org/patch/49465/
> 
> came closest to achieving full CONFIG_COMPAT support; since netlink is
> no longer async now I'm not sure we'd still need additonal 32-compat syscalls
> to make compat work for all cases.
> 
> So "its ugly as hell" is probably the only problem that is hard to avoid ;-)

Yeah, and it will be no fun to maintain it...

So the question is still, do we really need/want it or should we
tell that this is not supported. We just can't leave it as it is.
We allow to configure with 32 bit tools, but the result is crap.

Re: IPsec workshop at netdev01?

[Florian Westphal]

Steffen Klassert <steffen.klassert@secunet.com> wrote:
> On Tue, Jan 06, 2015 at 06:00:26PM +0100, Florian Westphal wrote:
> > Steffen Klassert <steffen.klassert@secunet.com> wrote:
> > > - We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
> > >   comes up from time to time. Some solutions were proposed in the past
> > >   but all had problems. The current behaviour is broken if someone tries
> > >   to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
> > >   this right somehow or is it better to just return an error in this case?
> > 
> > FWIW I think
> > http://patchwork.ozlabs.org/patch/49465/
> > 
> > came closest to achieving full CONFIG_COMPAT support; since netlink is
> > no longer async now I'm not sure we'd still need additonal 32-compat syscalls
> > to make compat work for all cases.
> > 
> > So "its ugly as hell" is probably the only problem that is hard to avoid ;-)
> 
> Yeah, and it will be no fun to maintain it...

Not sure, you'd have to make sure that no new attributes introduce need
to add another compat hack.

The best argument against supporting it is that this problem
has existed for so long that there arguably isn't much demand
(else, such patch would have been merged years ago).

i686 userland with x86_64 kernel should be rare nowadays, and
x32 seems to require 8byte aligned 64bit integers so that would work
as-is.

> So the question is still, do we really need/want it or should we
> tell that this is not supported. We just can't leave it as it is.
> We allow to configure with 32 bit tools, but the result is crap.

Perhaps one could add only some of the patches from that series,
i.e. allow xfrm netlink to detect when its dealing with a message
from i686 task (so it can fail right away)?

Re: IPsec workshop at netdev01?

[Fan Du]

于 2015年01月06日 18:19, Steffen Klassert 写道:
> Is there any interest in doing an IPsec workshop at netdev01?
>
> This mail is to probe if we can gather enough discussion topics to run
> such a workshop. So if someone is interested to attend and/or has a
> related discussion topic, please let me know.
>
> The idea to do this workshop came yesterday, so I'm still collecting
> topics I'm interested in. Some things that came immediately to my mind
> are:
>
> - Our IPsec policy/state lookups are still hashlist based on slowpath with
>    a flowcache to do fast lookups for traffic flows we have already seen.
>    This flowcache has similar issues like the ipv4 routing chache had.
>    Is the flowcache an appropriate lookup method on the long run or should
>    we at least think about an additional alternative lookup method?
>
> - We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
>    comes up from time to time. Some solutions were proposed in the past
>    but all had problems. The current behaviour is broken if someone tries
>    to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
>    this right somehow or is it better to just return an error in this case?

Before a clean solution show up, I think it's better to warn user in some way
like http://patchwork.ozlabs.org/patch/323842/ did. Otherwise, many people
who stuck there will always spend time and try to fix this issue in whatever way.

> - Changing the system time can lead to unexpected SA lifetime changes. The
>    discussion on the list did not lead to a conclusion on how to fix this.
>    What is the best way to get this fixed?

I rise this issue long ago before, the culprit is SA lifetime is marked by wall clock.
In a reasonable way it should be marked as monotonic boot time(counting suspend time
as well). Then every thing will be work correctly. I have such a patch works correctly.
EXCEPT: SA migration, where SA lifetime comes from outside.
I didn't look at SA migration part though, so any comments? Steffen


-- 
No zuo no die but I have to try.

Re: IPsec workshop at netdev01?

[Nicolas Dichtel]

Le 07/01/2015 13:55, Florian Westphal a écrit :
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
>> On Tue, Jan 06, 2015 at 06:00:26PM +0100, Florian Westphal wrote:
>>> Steffen Klassert <steffen.klassert@secunet.com> wrote:
>>>> - We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
>>>>    comes up from time to time. Some solutions were proposed in the past
>>>>    but all had problems. The current behaviour is broken if someone tries
>>>>    to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
>>>>    this right somehow or is it better to just return an error in this case?
>>>
>>> FWIW I think
>>> http://patchwork.ozlabs.org/patch/49465/
>>>
>>> came closest to achieving full CONFIG_COMPAT support; since netlink is
>>> no longer async now I'm not sure we'd still need additonal 32-compat syscalls
>>> to make compat work for all cases.
>>>
>>> So "its ugly as hell" is probably the only problem that is hard to avoid ;-)
>>
>> Yeah, and it will be no fun to maintain it...
>
> Not sure, you'd have to make sure that no new attributes introduce need
> to add another compat hack.
>
> The best argument against supporting it is that this problem
> has existed for so long that there arguably isn't much demand
> (else, such patch would have been merged years ago).
In fact, there is regularly some proposals to fix this, but I think that
nobody has taken the time to make a patch that satisfies everybody.
There is certainly a number of "private" patch for this problem, hence it
can be good to have a consensus on this topic.


Regards,
Nicolas

Re: IPsec workshop at netdev01?

[Steffen Klassert]

On Fri, Jan 09, 2015 at 01:30:38PM +0800, Fan Du wrote:
> 于 2015年01月06日 18:19, Steffen Klassert 写道:
> >
> >- We still lack a 32/64 bit compatibiltiy layer for IPsec, this issue
> >   comes up from time to time. Some solutions were proposed in the past
> >   but all had problems. The current behaviour is broken if someone tries
> >   to configure IPsec with 32 bit tools on a 64 bit machine. Can we get
> >   this right somehow or is it better to just return an error in this case?
> 
> Before a clean solution show up, I think it's better to warn user in some way
> like http://patchwork.ozlabs.org/patch/323842/ did. Otherwise, many people
> who stuck there will always spend time and try to fix this issue in whatever way.

Yes, this is the first thing we should do. I'm willing to accept a patch :)

> 
> >- Changing the system time can lead to unexpected SA lifetime changes. The
> >   discussion on the list did not lead to a conclusion on how to fix this.
> >   What is the best way to get this fixed?
> 
> I rise this issue long ago before, the culprit is SA lifetime is marked by wall clock.
> In a reasonable way it should be marked as monotonic boot time(counting suspend time
> as well). Then every thing will be work correctly. I have such a patch works correctly.
> EXCEPT: SA migration, where SA lifetime comes from outside.
> I didn't look at SA migration part though, so any comments? Steffen

I have not looked into this for longer. So I can not comment on it
now, but I could be prepared for discussion on netdev01.