iked(8) prevents inet6 communication

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

iked(8) prevents inet6 communication

David Dahlberg-2
>Synopsis:      iked installs ipsec flow which prevents inet6 communication
>Category:      system
>Environment:
        System      : OpenBSD 6.3
        Details     : OpenBSD 6.3-current (GENERIC.MP) #80: Sun Jul  1 12:22:16 MDT 2018
                         [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP

        Architecture: OpenBSD.amd64
        Machine     : amd64
>Description:
        iked(8), if configured for IPv4 only - or even not configured at all
        installs the following ipsec flow upon startup:
                flow esp out from ::/0 to ::/0 type deny
        This flow effectively prevents any further IPv6 communication.
        Noticed this when I configured iked(8) as (IPv4) VPN gateway on my
        home router. Basically the whole IPv6 networking broke.
        I noticed this behaviour on 6.3, but it affects -current as well.
>How-To-Repeat:
        ipsecctl -s flow
        touch /etc/iked.conf && chmod 600 /etc/iked.conf
        iked -dv
        ^C
        ipsecctl -s flow
>Fix:
        Do not use iked, if using inet6.
        "ipsecctl -F" or something more specific after startup might work too.

dmesg:
OpenBSD 6.3-current (GENERIC.MP) #80: Sun Jul  1 12:22:16 MDT 2018
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8260673536 (7877MB)
avail mem = 8001175552 (7630MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xacbfd000 (66 entries)
bios0: vendor LENOVO version "N14ET34W (1.12 )" date 02/04/2016
bios0: LENOVO 20BSCTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.46 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2095.16 MHz
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf8000000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 3 (EXP1)
acpiprt3 at acpi0: bus 4 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 10 (EXP6)
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
acpipwrres1 at acpi0: NVP3, resource for PEG_
acpipwrres2 at acpi0: NVP2, resource for PEG_
acpitz0 at acpi0: critical temperature is 128 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpicmos0 at acpi0
"LEN0071" at acpi0 not configured
"LEN0048" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "00HW002" serial   511 type LiP oem "LGC"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
"SMO1200" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
acpivideo0 at acpi0: VID_
acpivout at acpivideo0 not configured
acpivideo1 at acpi0: VID_
cpu0: Enhanced SpeedStep 2095 MHz: speeds: 2201, 2200, 2100, 2000, 1800, 1700, 1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 2560x1440, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi
xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 9 Series MEI" rev 0x03 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel I218-V" rev 0x03: msi, address 54:ee:75:4f:fe:1d
azalia1 at pci0 dev 27 function 0 "Intel 9 Series HD Audio" rev 0x03: msi
azalia1: codecs: Realtek ALC292
audio0 at azalia1
ppb0 at pci0 dev 28 function 0 "Intel 9 Series PCIE" rev 0xe3: msi
pci1 at ppb0 bus 3
ppb1 at pci0 dev 28 function 1 "Intel 9 Series PCIE" rev 0xe3: msi
pci2 at ppb1 bus 4
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi
ppb2 at pci0 dev 28 function 5 "Intel 9 Series PCIE" rev 0xe3: msi
pci3 at ppb2 bus 10
ahci0 at pci3 dev 0 function 0 "Samsung SM951 AHCI" rev 0x01: apic 2 int 16, AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, SAMSUNG MZHPV256, BXW2> SCSI3 0/direct fixed naa.5002538900000000
sd0: 244198MB, 512 bytes/sector, 500118192 sectors, thin
pcib0 at pci0 dev 31 function 0 "Intel 9 Series LPC" rev 0x03
ichiic0 at pci0 dev 31 function 3 "Intel 9 Series SMBus" rev 0x03: apic 2 int 18
iic0 at ichiic0
pchtemp0 at pci0 dev 31 function 6 "Intel 9 Series Thermal" rev 0x03
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
wsmouse1 at pms0 mux 0
pms0: Synaptics clickpad, firmware 8.1, 0x1e2b1 0x943300
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
Unclaimed register detected before reading register 0x23a0
uhidev0 at uhub0 port 1 configuration 1 interface 0 "Yubico Yubikey NEO OTP+U2F" rev 2.00/3.43 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub0 port 1 configuration 1 interface 1 "Yubico Yubikey NEO OTP+U2F" rev 2.00/3.43 addr 2
uhidev1: iclass 3/0
uhid0 at uhidev1: input=64, output=64, feature=0
uhidev2 at uhub0 port 5 configuration 1 interface 0 "ELAN Touchscreen" rev 2.00/0.13 addr 3
uhidev2: iclass 3/0, 68 report ids
ums0 at uhidev2 reportid 1: 1 button, tip
wsmouse2 at ums0 mux 0
uhid1 at uhidev2 reportid 2: input=64, output=0, feature=0
uhid2 at uhidev2 reportid 3: input=0, output=31, feature=0
uhid3 at uhidev2 reportid 4: input=19, output=0, feature=0
uhid4 at uhidev2 reportid 10: input=0, output=0, feature=1
ums1 at uhidev2 reportid 68
ums1: mouse has no X report
ugen0 at uhub0 port 6 "Validity Sensors VFS5011 Fingerprint Reader" rev 1.10/0.78 addr 4
ugen1 at uhub0 port 7 "Intel Bluetooth" rev 2.01/0.01 addr 5
uvideo0 at uhub0 port 8 configuration 1 interface 0 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.00/0.29 addr 6
video0 at uvideo0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006> SCSI2 0/direct fixed
sd1: 244190MB, 512 bytes/sector, 500102858 sectors
root on sd1a (4f8e712f8e5cd277.a) swap on sd1b dump on sd1b
iwm0: hw rev 0x210, fw ver 16.242414.0, address 34:02:86:88:91:c2

usbdevs:
Controller /dev/usb0:
addr 1: super speed, self powered, config 1, xHCI root hub(0x0000), Intel(0x8086), rev 1.00
 addr 2: full speed, power 30 mA, config 1, Yubikey NEO OTP+U2F(0x0114), Yubico(0x1050), rev 3.43
 addr 3: full speed, self powered, config 1, Touchscreen(0x012d), ELAN(0x04f3), rev 0.13
 addr 4: full speed, power 100 mA, config 1, VFS5011 Fingerprint Reader(0x0017), Validity Sensors(0x138a), rev 0.78, iSerialNumber d83eca1fbf52
 addr 5: full speed, self powered, config 1, Bluetooth(0x0a2a), Intel(0x8087), rev 0.01
 addr 6: high speed, power 500 mA, config 1, Integrated Camera(0xb45d), Chicony Electronics Co.,Ltd.(0x04f2), rev 0.29, iSerialNumber 0x0001

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stefan Sperling-5
On Tue, Jul 03, 2018 at 12:47:20PM +0200, [hidden email] wrote:

> >Synopsis:      iked installs ipsec flow which prevents inet6 communication
> >Category:      system
> >Environment:
>         System      : OpenBSD 6.3
>         Details     : OpenBSD 6.3-current (GENERIC.MP) #80: Sun Jul  1 12:22:16 MDT 2018
>                          [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>         Architecture: OpenBSD.amd64
>         Machine     : amd64
> >Description:
>         iked(8), if configured for IPv4 only - or even not configured at all
>         installs the following ipsec flow upon startup:
>                 flow esp out from ::/0 to ::/0 type deny
>         This flow effectively prevents any further IPv6 communication.
>         Noticed this when I configured iked(8) as (IPv4) VPN gateway on my
>         home router. Basically the whole IPv6 networking broke.
>         I noticed this behaviour on 6.3, but it affects -current as well.
> >How-To-Repeat:
>         ipsecctl -s flow
>         touch /etc/iked.conf && chmod 600 /etc/iked.conf
>         iked -dv
>         ^C
>         ipsecctl -s flow
> >Fix:
>         Do not use iked, if using inet6.
>         "ipsecctl -F" or something more specific after startup might work too.
>

Not a bug.  This behaviour is intentional and avoids VPN traffic leakage.
See RFC 7359 and the iked(8) man page. Use the -6 option (risks leakage),
or configure explicit flows for your IPv6 networks.

----------------------------
revision 1.14
date: 2012/11/29 15:08:08;  author: reyk;  state: Exp;  lines: +6 -3;
Prevent VPN traffic leakages in dual-stack hosts/networks.
See http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages.

We forcibly block IPv6 traffic by loading a "flow esp out from ::/0 to
::/0 type deny" unless the protocol is used in any of the flows.  Note
that this will block any IPv6 traffic, superseding routes and pf, on
the host by default when iked is running with IPv4 flows only.  This
auto-blocking feature can be disabled by specifying the "-6" command
line flag to iked.

Thanks to Fernando Gont.

ok mikeb@
=============================================================================

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

David Dahlberg-2
Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> Not a bug.  This behaviour is intentional and avoids VPN traffic
> leakage.
> See RFC 7359 and the iked(8) man page. Use the -6 option (risks
> leakage),

Then sorry for the noise. I extensively seached for documentation of
this behaviour - apparently using the wrong keywords.

Cheers,
David

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stefan Sperling-5
On Tue, Jul 03, 2018 at 01:34:09PM +0200, David Dahlberg wrote:

> Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> > Not a bug.  This behaviour is intentional and avoids VPN traffic
> > leakage.
> > See RFC 7359 and the iked(8) man page. Use the -6 option (risks
> > leakage),
>
> Then sorry for the noise. I extensively seached for documentation of
> this behaviour - apparently using the wrong keywords.
>
> Cheers,
> David
>

I think the documentation could be improved.

Would you be able to send a patch for the iked man page which
explicitly mentions VPN traffic leakage and RFC 7359 (in the
STANDARDS section, perhaps)?

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stuart Henderson
On 2018/07/03 13:42, Stefan Sperling wrote:

> On Tue, Jul 03, 2018 at 01:34:09PM +0200, David Dahlberg wrote:
> > Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> > > Not a bug.  This behaviour is intentional and avoids VPN traffic
> > > leakage.
> > > See RFC 7359 and the iked(8) man page. Use the -6 option (risks
> > > leakage),
> >
> > Then sorry for the noise. I extensively seached for documentation of
> > this behaviour - apparently using the wrong keywords.
> >
> > Cheers,
> > David
> >
>
> I think the documentation could be improved.
>
> Would you be able to send a patch for the iked man page which
> explicitly mentions VPN traffic leakage and RFC 7359 (in the
> STANDARDS section, perhaps)?
>

It would easily be missed if only looking at iked.conf(5), but iked(8) seems
reasonably clear?

   The options are as follows:

   -6      Disable automatic blocking of IPv6 traffic.  By default, iked blocks
           any IPv6 traffic unless a flow for this address family has been
           negotiated.  This option is used to prevent VPN traffic leakages on
           dual stack hosts.


Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stefan Sperling-5
On Tue, Jul 03, 2018 at 12:54:36PM +0100, Stuart Henderson wrote:

> On 2018/07/03 13:42, Stefan Sperling wrote:
> > On Tue, Jul 03, 2018 at 01:34:09PM +0200, David Dahlberg wrote:
> > > Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> > > > Not a bug.  This behaviour is intentional and avoids VPN traffic
> > > > leakage.
> > > > See RFC 7359 and the iked(8) man page. Use the -6 option (risks
> > > > leakage),
> > >
> > > Then sorry for the noise. I extensively seached for documentation of
> > > this behaviour - apparently using the wrong keywords.
> > >
> > > Cheers,
> > > David
> > >
> >
> > I think the documentation could be improved.
> >
> > Would you be able to send a patch for the iked man page which
> > explicitly mentions VPN traffic leakage and RFC 7359 (in the
> > STANDARDS section, perhaps)?
> >
>
> It would easily be missed if only looking at iked.conf(5), but iked(8) seems
> reasonably clear?
>
>    The options are as follows:
>
>    -6      Disable automatic blocking of IPv6 traffic.  By default, iked blocks
>            any IPv6 traffic unless a flow for this address family has been
>            negotiated.  This option is used to prevent VPN traffic leakages on
>            dual stack hosts.
>

No, this is not good enough. That last sentence is rather misleading (-6 *allows*
for leakage since it disables blocking). "RFC 7359" should be mentioned since
it provides a wealth of context the man page cannot provide (to be fair, this
RFC number wasn't yet available when this feature was first committed).
It might also make sense to add a brief sentence in DESCRIPTION which already
lists other related RFCs.

If iked.conf doesn't mention this behaviour, it probably should.

I'm only making a fuss because this is not the first time I have seen
someone stumble over this as an "issue", and because it's a small task we
can delegate and offer up as an opportunity for contributing a patch :)

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

David Dahlberg-2
In reply to this post by Stefan Sperling-5
Am Tuesday, den 03.07.2018, 13:42 +0200 schrieb Stefan Sperling:
> Would you be able to send a patch for the iked man page which
> explicitly mentions VPN traffic leakage and RFC 7359 (in the
> STANDARDS section, perhaps)?

No problem; VPN leakage is already mentioned. As you mentioned, it is
slightly ambiguous.

Yet in my case the problem was more that I did not expect something
there. Would I have read about the "-6" option, I would have understood
the significance.

My problem was that I silently expected native OpenBSD daemons not have
a lot of startup options (appart from the usual "-dnv"). Indeed, I even
scanned iked(8) to find the "-ST" flags to reduce the noise.

So I was expecting to find rather something in iked.conf(5) or maybe a
sysctl or something with "man -k any=flow" or "any=policy".

I am not this much of an expert of mdoc(7), but other man pages declare
flows with ".Ic". "Internal or interactive command" does not sound
really correct though.

A "preview" of the patch follows.
A file without the mangled line breaks is available here:
https://cloud.dahlberg.cologne/index.php/s/55HzfcHcrosC6CD

Index: sbin/iked/iked.8
===================================================================
RCS file: /cvs/src/sbin/iked/iked.8,v
retrieving revision 1.20
diff -u -p -u -r1.20 iked.8
--- sbin/iked/iked.8    27 Mar 2017 10:06:41 -0000      1.20
+++ sbin/iked/iked.8    3 Jul 2018 12:30:44 -0000
@@ -59,9 +59,11 @@ The options are as follows:
 Disable automatic blocking of IPv6 traffic.
 By default,
 .Nm
-blocks any IPv6 traffic unless a flow for this address family has been
-negotiated.
-This option is used to prevent VPN traffic leakages on dual stack
hosts.
+blocks any IPv6 traffic unless a
+.Ic flow
+for this address family has been negotiated.
+This option disables VPN traffic leakages prevention on dual stack
hosts
+(RFC 7359).
 .It Fl D Ar macro Ns = Ns Ar value
 Define
 .Ar macro

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

David Dahlberg-2
In reply to this post by Stefan Sperling-5
Am Tuesday, den 03.07.2018, 14:20 +0200 schrieb Stefan Sperling:
> "RFC 7359" should be mentioned since
> it provides a wealth of context the man page cannot provide [..]
> It might also make sense to add a brief sentence in DESCRIPTION which
> already
> lists other related RFCs.

It as it is not the main functionality, I would not put it more
prominently as IKEv2, ISAKMP and IKE. That STANDARDS mentions only the
first one is IMHO alright.

>
> If iked.conf doesn't mention this behaviour, it probably should.
>
> I'm only making a fuss because this is not the first time I have seen
> someone stumble over this as an "issue"

Some mention in the debug output might help also:

Index: sbin/iked/pfkey.c
===================================================================
RCS file: /cvs/src/sbin/iked/pfkey.c,v
retrieving revision 1.59
diff -u -p -u -r1.59 pfkey.c
--- sbin/iked/pfkey.c   27 Nov 2017 18:39:35 -0000      1.59
+++ sbin/iked/pfkey.c   3 Jul 2018 12:54:30 -0000
@@ -1550,6 +1550,7 @@ pfkey_init(struct iked *env, int fd)
                return;
 
        /* Block all IPv6 traffic by default */
+       log_info("%s: blocking all IPv6 traffic by default", __func__);
        pfkey_blockipv6 = 1;
        if (pfkey_block(fd, AF_INET6, SADB_X_ADDFLOW))
                fatal("pfkey_init: failed to block IPv6 traffic");

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stefan Sperling-5
In reply to this post by David Dahlberg-2
On Tue, Jul 03, 2018 at 02:39:10PM +0200, David Dahlberg wrote:

> Am Tuesday, den 03.07.2018, 13:42 +0200 schrieb Stefan Sperling:
> > Would you be able to send a patch for the iked man page which
> > explicitly mentions VPN traffic leakage and RFC 7359 (in the
> > STANDARDS section, perhaps)?
>
> No problem; VPN leakage is already mentioned. As you mentioned, it is
> slightly ambiguous.
>
> Yet in my case the problem was more that I did not expect something
> there. Would I have read about the "-6" option, I would have understood
> the significance.
>
> My problem was that I silently expected native OpenBSD daemons not have
> a lot of startup options (appart from the usual "-dnv"). Indeed, I even
> scanned iked(8) to find the "-ST" flags to reduce the noise.
>
> So I was expecting to find rather something in iked.conf(5) or maybe a
> sysctl or something with "man -k any=flow" or "any=policy".
>
> I am not this much of an expert of mdoc(7), but other man pages declare
> flows with ".Ic". "Internal or interactive command" does not sound
> really correct though.

I don't think any markup is required for "flow" in this context.
The iked.conf(5) page uses .Ic only when referring to "flow" as a syntax
keyword, as opposed to the concept of an "IPsec flow".

> A "preview" of the patch follows.
> A file without the mangled line breaks is available here:
> https://cloud.dahlberg.cologne/index.php/s/55HzfcHcrosC6CD
>
> Index: sbin/iked/iked.8
> ===================================================================
> RCS file: /cvs/src/sbin/iked/iked.8,v
> retrieving revision 1.20
> diff -u -p -u -r1.20 iked.8
> --- sbin/iked/iked.8    27 Mar 2017 10:06:41 -0000      1.20
> +++ sbin/iked/iked.8    3 Jul 2018 12:30:44 -0000
> @@ -59,9 +59,11 @@ The options are as follows:
>  Disable automatic blocking of IPv6 traffic.
>  By default,
>  .Nm
> -blocks any IPv6 traffic unless a flow for this address family has been
> -negotiated.
> -This option is used to prevent VPN traffic leakages on dual stack
> hosts.
> +blocks any IPv6 traffic unless a
> +.Ic flow
> +for this address family has been negotiated.
> +This option disables VPN traffic leakages prevention on dual stack

Grammar: This should say "leakage", not "leakages"

Apart from the above points, this change looks like an improvement to me.
Could you send a fixed version?

> hosts
> +(RFC 7359).
>  .It Fl D Ar macro Ns = Ns Ar value
>  Define
>  .Ar macro
>

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Sebastian Benoit-3
In reply to this post by David Dahlberg-2
David Dahlberg([hidden email]) on 2018.07.03 14:39:10 +0200:

> Am Tuesday, den 03.07.2018, 13:42 +0200 schrieb Stefan Sperling:
> > Would you be able to send a patch for the iked man page which
> > explicitly mentions VPN traffic leakage and RFC 7359 (in the
> > STANDARDS section, perhaps)?
>
> No problem; VPN leakage is already mentioned. As you mentioned, it is
> slightly ambiguous.
>
> Yet in my case the problem was more that I did not expect something
> there. Would I have read about the "-6" option, I would have understood
> the significance.
>
> My problem was that I silently expected native OpenBSD daemons not have
> a lot of startup options (appart from the usual "-dnv"). Indeed, I even
> scanned iked(8) to find the "-ST" flags to reduce the noise.
>
> So I was expecting to find rather something in iked.conf(5) or maybe a
> sysctl or something with "man -k any=flow" or "any=policy".
>
> I am not this much of an expert of mdoc(7), but other man pages declare
> flows with ".Ic". "Internal or interactive command" does not sound
> really correct though.
>
> A "preview" of the patch follows.
> A file without the mangled line breaks is available here:
> https://cloud.dahlberg.cologne/index.php/s/55HzfcHcrosC6CD
>
> Index: sbin/iked/iked.8
> ===================================================================
> RCS file: /cvs/src/sbin/iked/iked.8,v
> retrieving revision 1.20
> diff -u -p -u -r1.20 iked.8
> --- sbin/iked/iked.8    27 Mar 2017 10:06:41 -0000      1.20
> +++ sbin/iked/iked.8    3 Jul 2018 12:30:44 -0000
> @@ -59,9 +59,11 @@ The options are as follows:
>  Disable automatic blocking of IPv6 traffic.
>  By default,
>  .Nm
> -blocks any IPv6 traffic unless a flow for this address family has been
> -negotiated.
> -This option is used to prevent VPN traffic leakages on dual stack
> hosts.
> +blocks any IPv6 traffic unless a
> +.Ic flow
> +for this address family has been negotiated.
> +This option disables VPN traffic leakages prevention on dual stack
> hosts

disable a leakages sounds funny, you can prevent or block it. Better:

The default behaviour to block all IPv6 traffic is to prevent VPN traffic leakages
on dual stack hosts (see RFC 7359).

Or just use the original line + rfc.

> +(RFC 7359).
>  .It Fl D Ar macro Ns = Ns Ar value
>  Define
>  .Ar macro
>

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Theo de Raadt-2
In reply to this post by Stefan Sperling-5
Stefan Sperling <[hidden email]> wrote:

> On Tue, Jul 03, 2018 at 12:54:36PM +0100, Stuart Henderson wrote:
> > On 2018/07/03 13:42, Stefan Sperling wrote:
> > > On Tue, Jul 03, 2018 at 01:34:09PM +0200, David Dahlberg wrote:
> > > > Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> > > > > Not a bug.  This behaviour is intentional and avoids VPN traffic
> > > > > leakage.
> > > > > See RFC 7359 and the iked(8) man page. Use the -6 option (risks
> > > > > leakage),
> > > >
> > > > Then sorry for the noise. I extensively seached for documentation of
> > > > this behaviour - apparently using the wrong keywords.
> > > >
> > > > Cheers,
> > > > David
> > > >
> > >
> > > I think the documentation could be improved.
> > >
> > > Would you be able to send a patch for the iked man page which
> > > explicitly mentions VPN traffic leakage and RFC 7359 (in the
> > > STANDARDS section, perhaps)?
> > >
> >
> > It would easily be missed if only looking at iked.conf(5), but iked(8) seems
> > reasonably clear?
> >
> >    The options are as follows:
> >
> >    -6      Disable automatic blocking of IPv6 traffic.  By default, iked blocks
> >            any IPv6 traffic unless a flow for this address family has been
> >            negotiated.  This option is used to prevent VPN traffic leakages on
> >            dual stack hosts.
> >
>
> No, this is not good enough. That last sentence is rather misleading (-6 *allows*
> for leakage since it disables blocking). "RFC 7359" should be mentioned since
> it provides a wealth of context the man page cannot provide (to be fair, this
> RFC number wasn't yet available when this feature was first committed).
> It might also make sense to add a brief sentence in DESCRIPTION which already
> lists other related RFCs.
>
> If iked.conf doesn't mention this behaviour, it probably should.
>
> I'm only making a fuss because this is not the first time I have seen
> someone stumble over this as an "issue", and because it's a small task we
> can delegate and offer up as an opportunity for contributing a patch :)

This default behaviour is terrible.

Please re-read the report.  Apparently just starting iked without -6
breaks *entirely unrelated* v6 traffic.

If that is the case, what is going on here is unacceptable.

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stefan Sperling-5
In reply to this post by Stefan Sperling-5
On Tue, Jul 03, 2018 at 02:57:40PM +0200, Stefan Sperling wrote:
> Apart from the above points, this change looks like an improvement to me.
> Could you send a fixed version?

A new patch was provided off-list by David and I have just committed it.

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Stuart Henderson
In reply to this post by Theo de Raadt-2
On 2018/07/03 07:35, Theo de Raadt wrote:

> Stefan Sperling <[hidden email]> wrote:
>
> > On Tue, Jul 03, 2018 at 12:54:36PM +0100, Stuart Henderson wrote:
> > > On 2018/07/03 13:42, Stefan Sperling wrote:
> > > > On Tue, Jul 03, 2018 at 01:34:09PM +0200, David Dahlberg wrote:
> > > > > Am Tuesday, den 03.07.2018, 13:29 +0200 schrieb Stefan Sperling:
> > > > > > Not a bug.  This behaviour is intentional and avoids VPN traffic
> > > > > > leakage.
> > > > > > See RFC 7359 and the iked(8) man page. Use the -6 option (risks
> > > > > > leakage),
> > > > >
> > > > > Then sorry for the noise. I extensively seached for documentation of
> > > > > this behaviour - apparently using the wrong keywords.
> > > > >
> > > > > Cheers,
> > > > > David
> > > > >
> > > >
> > > > I think the documentation could be improved.
> > > >
> > > > Would you be able to send a patch for the iked man page which
> > > > explicitly mentions VPN traffic leakage and RFC 7359 (in the
> > > > STANDARDS section, perhaps)?
> > > >
> > >
> > > It would easily be missed if only looking at iked.conf(5), but iked(8) seems
> > > reasonably clear?
> > >
> > >    The options are as follows:
> > >
> > >    -6      Disable automatic blocking of IPv6 traffic.  By default, iked blocks
> > >            any IPv6 traffic unless a flow for this address family has been
> > >            negotiated.  This option is used to prevent VPN traffic leakages on
> > >            dual stack hosts.
> > >
> >
> > No, this is not good enough. That last sentence is rather misleading (-6 *allows*
> > for leakage since it disables blocking). "RFC 7359" should be mentioned since
> > it provides a wealth of context the man page cannot provide (to be fair, this
> > RFC number wasn't yet available when this feature was first committed).
> > It might also make sense to add a brief sentence in DESCRIPTION which already
> > lists other related RFCs.
> >
> > If iked.conf doesn't mention this behaviour, it probably should.
> >
> > I'm only making a fuss because this is not the first time I have seen
> > someone stumble over this as an "issue", and because it's a small task we
> > can delegate and offer up as an opportunity for contributing a patch :)
>
> This default behaviour is terrible.
>
> Please re-read the report.  Apparently just starting iked without -6
> breaks *entirely unrelated* v6 traffic.
>
> If that is the case, what is going on here is unacceptable.
>

That is exactly what was intended with the 2012/11/29 commit.
This is the scenario it tries to avoid:

- user has a vpn for 0.0.0.0/0 on a host with the intention of
diverting all traffic from that machine over VPN

- at some point later, host gains an IPv6 address and default
route

- now there is traffic to v6-capable hosts which is sent directly
and in the clear rather than via vpn

Whether it's acceptable or not I can't say, but it's working exactly
as expected/advertised. If this is changed, we should probably add
"flow esp out from ::/0 to ::/0 type deny" to examples/iked.conf
with some description.


Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Reyk Floeter-2
On Tue, Jul 03, 2018 at 03:06:34PM +0100, Stuart Henderson wrote:

> > If that is the case, what is going on here is unacceptable.
> >
>
> That is exactly what was intended with the 2012/11/29 commit.
> This is the scenario it tries to avoid:
>
> - user has a vpn for 0.0.0.0/0 on a host with the intention of
> diverting all traffic from that machine over VPN
>
> - at some point later, host gains an IPv6 address and default
> route
>
> - now there is traffic to v6-capable hosts which is sent directly
> and in the clear rather than via vpn
>
> Whether it's acceptable or not I can't say, but it's working exactly
> as expected/advertised. If this is changed, we should probably add
> "flow esp out from ::/0 to ::/0 type deny" to examples/iked.conf
> with some description.
>
>

A dual-homed host should not have IPsec on v4 and "open" v6 at the
same time; the leakage is a real risk.  I did add it intentionally;
we've discussed it in depth when the problem was reported by Gont.

In other words: I don't think that people spend much or any thought on
the problem when they enable v4-IPsec on a dual-homed host; they would
be open for the attack.  Putting this as a note into
/etc/examples/iked.conf and not turning it on by default is almost
useless.

My suggestion:
1. Fix the manpage as suggested (but add the RFC in the STANDARDS section)
2. Add a log_debug() (only visible when running iked in foreground/verbose)
3. Fix iked to really only load the deny flow if no IPv6 is configured!

The 3rd one used to be the case: iked only installed the
"deny-all-IPv6" flow when there was no IPv6 configured in iked.conf.
This seems to be broken as my tests still get the deny flow even if I
add an IPv6 flow or peer configuration in iked.conf.  It is a real bug
that has to be fixed.  I can look at it at the hackathon if nobody
beats me to it.

We can also think about tweaking the semantics, like only blocking
non-local traffic, but this is very difficult to achieve.

Reyk

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

David Dahlberg-2
Am Tuesday, den 03.07.2018, 19:01 +0200 schrieb Reyk Floeter:
> A dual-homed host should not have IPsec on v4 and "open" v6 at the
> same time; the leakage is a real risk.  I did add it intentionally;
> we've discussed it in depth when the problem was reported by Gont.

I guess with "dual-homed" you meant "dual-stacked"?

Yes, I see the problem. It mostly applies mostly to "IPsec clients"
which are usually not multi-homed.

> Putting this as a note into
> /etc/examples/iked.conf and not turning it on by default is almost
> useless.

This would also be the wrong place. Flow definitions go to ipsec.conf,
a file that's otherwise primarily used for isakmpd.

A better place for the "documentation only" solution would be
iked.conf(5), analogous to the PACKET FILTERING section. PACKET
FILTERING already includes an alternative solution which uses pf
instead of flows:

  block on ix0
  pass  in on ix0 proto udp from 192.168.3.2 to 192.168.3.1 \
  port {500, 4500}
  pass out on ix0 proto udp from 192.168.3.1 to 192.168.3.2 \
  port {500, 4500}
  pass  in on ix0 proto esp from 192.168.3.2 to 192.168.3.1
  pass out on ix0 proto esp from 192.168.3.1 to 192.168.3.2

> My suggestion:
> 1. Fix the manpage as suggested (but add the RFC in the STANDARDS
> section)

Yes, but having read the RFC, it should not be implied that RFC 7359
would demands this behaviour. Probably more along the lines of this:

  iked tries prevent leakage of IPv6 traffic in situations where only
  an IPv4 tunnel has been configured on dual-stacked systems (compare
  RFC 7359). This is achieved by installing an IPsec "deny" policy
  which blocks all IPv6 traffic. Blocking of IPv6 is the default
  behavior, if iked is not started with -n and no IPv6 policies are
  configured in iked.conf(5).

  The options are as follows:

  -6 Disable automatic blocking of IPv6 traffic

> 2. Add a log_debug() (only visible when running iked in
> foreground/verbose)

ACK.

> 3. Fix iked to really only load the deny flow if no IPv6 is
> configured!
>
> The 3rd one used to be the case: iked only installed the
> "deny-all-IPv6" flow when there was no IPv6 configured in iked.conf.

This behaviour would be "unless a policy for this address family has
been configured". It is slightly but significantly different than the
current documented behaviour "unless a flow for this address family has
been negotiated" and also makes more sense.

BTW, a behaviour a bit more in line with the RFC would be to block IPv6
only if there is an IPv4 default policy and no IPv6 policy.

Cheers,
David

Reply | Threaded
Open this post in threaded view
|

Re: iked(8) prevents inet6 communication

Reyk Floeter-2
Hi,

after some discussions, we found a better approach and a way to improve this. Please hold on for a few days.

Reyk

> Am 03.07.2018 um 21:42 schrieb David Dahlberg <[hidden email]>:
>
> Am Tuesday, den 03.07.2018, 19:01 +0200 schrieb Reyk Floeter:
>> A dual-homed host should not have IPsec on v4 and "open" v6 at the
>> same time; the leakage is a real risk.  I did add it intentionally;
>> we've discussed it in depth when the problem was reported by Gont.
>
> I guess with "dual-homed" you meant "dual-stacked"?
>
> Yes, I see the problem. It mostly applies mostly to "IPsec clients"
> which are usually not multi-homed.
>
>> Putting this as a note into
>> /etc/examples/iked.conf and not turning it on by default is almost
>> useless.
>
> This would also be the wrong place. Flow definitions go to ipsec.conf,
> a file that's otherwise primarily used for isakmpd.
>
> A better place for the "documentation only" solution would be
> iked.conf(5), analogous to the PACKET FILTERING section. PACKET
> FILTERING already includes an alternative solution which uses pf
> instead of flows:
>
>  block on ix0
>  pass  in on ix0 proto udp from 192.168.3.2 to 192.168.3.1 \
>      port {500, 4500}
>  pass out on ix0 proto udp from 192.168.3.1 to 192.168.3.2 \
>      port {500, 4500}
>  pass  in on ix0 proto esp from 192.168.3.2 to 192.168.3.1
>  pass out on ix0 proto esp from 192.168.3.1 to 192.168.3.2
>
>> My suggestion:
>> 1. Fix the manpage as suggested (but add the RFC in the STANDARDS
>> section)
>
> Yes, but having read the RFC, it should not be implied that RFC 7359
> would demands this behaviour. Probably more along the lines of this:
>
>  iked tries prevent leakage of IPv6 traffic in situations where only
>  an IPv4 tunnel has been configured on dual-stacked systems (compare
>  RFC 7359). This is achieved by installing an IPsec "deny" policy
>  which blocks all IPv6 traffic. Blocking of IPv6 is the default
>  behavior, if iked is not started with -n and no IPv6 policies are
>  configured in iked.conf(5).
>
>  The options are as follows:
>
>  -6 Disable automatic blocking of IPv6 traffic
>
>> 2. Add a log_debug() (only visible when running iked in
>> foreground/verbose)
>
> ACK.
>
>> 3. Fix iked to really only load the deny flow if no IPv6 is
>> configured!
>>
>> The 3rd one used to be the case: iked only installed the
>> "deny-all-IPv6" flow when there was no IPv6 configured in iked.conf.
>
> This behaviour would be "unless a policy for this address family has
> been configured". It is slightly but significantly different than the
> current documented behaviour "unless a flow for this address family has
> been negotiated" and also makes more sense.
>
> BTW, a behaviour a bit more in line with the RFC would be to block IPv6
> only if there is an IPv4 default policy and no IPv6 policy.
>
> Cheers,
> David
>