> On May 11, 2020, at 11:03 AM, Christian Hopps wrote:
>
>> On May 11, 2020, at 9:56 AM, Neale Ranns (nranns) wrote:
>>
>> On 11/05/2020 14:28, "Christian Hopps" wrote:
>
>>
>> Is it *really* that big a deal to have a logical interface represent a
>> tunnel mode SA? It actually seems
istian Hopps
>> Date: Sunday 10 May 2020 at 14:33
>> To: "Neale Ranns (nranns)"
>> Cc: Christian Hopps , vpp-dev
>> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
>>
>>> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io
>>> wro
uot;
> Cc: Christian Hopps , vpp-dev
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
>
> > On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io
wrote:
> >
> >
> >
> > Hi Chris,
> >
>
> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns) wrote:
>
>
>
> From: on behalf of Christian Hopps
> Date: Sunday 10 May 2020 at 14:33
> To: "Neale Ranns (nranns)"
> Cc: Christian Hopps , vpp-dev
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
&g
From: on behalf of Christian Hopps
Date: Sunday 10 May 2020 at 14:33
To: "Neale Ranns (nranns)"
Cc: Christian Hopps , vpp-dev
Subject: Re: [vpp-dev] IPsec tunnel interfaces?
> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io
> wrote:
>
>
>
> Hi Ch
Just a general followup in case tl;dr
The point of traffic flow security/confidentiality is to hide the effects of
the user traffic on the secure tunnel output. With IPTFS there is a complete
decoupling so that one cannot infer anything about the encapsulated traffic
from the IPsec tunnel data
> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io
> wrote:
>
>
>
> Hi Chris,
>
>
> > Are there other properties of a tunnel mode SA that you need that are lost
> > with this approach?
>
> I need to use tunnel mode SAs provided by IKEv2. Transport mode is an
> optional (normally
Hi Chris,
> Are there other properties of a tunnel mode SA that you need that are lost
> with this approach?
I need to use tunnel mode SAs provided by IKEv2. Transport mode is an optional
(normally on-the-wire IKEv2 negotiated) feature of IPsec. These tunnel mode SAs
will have IPTFS enabled
On May 8, 2020, at 3:57 AM, Neale Ranns via lists.fd.io
wrote:
>
>
>
> From: on behalf of Christian Hopps
> Date: Thursday 7 May 2020 at 23:27
> To: "Neale Ranns (nranns)"
> Cc: Christian Hopps , vpp-dev
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
&
From: on behalf of Christian Hopps
Date: Thursday 7 May 2020 at 23:27
To: "Neale Ranns (nranns)"
Cc: Christian Hopps , vpp-dev
Subject: Re: [vpp-dev] IPsec tunnel interfaces?
> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> On
> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> On 07/05/2020 16:55, "Christian Hopps" wrote:
>
>
>
>> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote:
>>
>>
>> Hi Chris,
>>
>> They were replaced by ipip interfaces protected by SAs:
>>
Hi Chris,
On 07/05/2020 16:55, "Christian Hopps" wrote:
> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> They were replaced by ipip interfaces protected by SAs:
> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
>
> the
> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> They were replaced by ipip interfaces protected by SAs:
> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
>
> the tunnel always adds encap. You can configure your SA to add additional
> encap if you want.
Ok, but
Is there a way to keep ipsecX naming, use of ipipX for ipsec tunnels seems to
be confusing for many people...
> On 7 May 2020, at 14:15, Neale Ranns via lists.fd.io
> wrote:
>
>
> Hi Chris,
>
> They were replaced by ipip interfaces protected by SAs:
>
Hi Chris,
They were replaced by ipip interfaces protected by SAs:
https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
the tunnel always adds encap. You can configure your SA to add additional encap
if you want.
/neale
From: on behalf of Christian Hopps
Date: Wednesday 6 May 2020 at 14:32
To:
15 matches
Mail list logo
