Re: IPv6/NDP/IPsec breakage in -current

[Markus Friedl]

> Am 25.10.2016 um 17:13 schrieb Mike Belopuhov :
> 
> 
> There are apparently some discussions in infomational RFCs regarding
> this issue.  For instance https://tools.ietf.org/html/rfc3756 
>  states:
> 
>   More specifically, the currently used key agreement protocol, IKE,
>   suffers from a chicken-and-egg problem [8]: one needs an IP address
>   to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are
>   required to configure an IP address.
> 
> Which goes one step further: how to protect all ND in general, but is
> still applicable in our situation.  There were attempts to protect ND
> in alternative way, e.g. SEND (https://tools.ietf.org/html/rfc3971 
> ).
> FreeBSD has picked up on it and has had a SoC project which seems to
> be integrated right now:
> 
>   https://wiki.freebsd.org/SOC2009AnaKukec 
> 
>   https://www.freebsd.org/cgi/man.cgi?query=send=4 
> 
> 
> Would it be possible for us to disable the check and always set saddr6
> to NULL for now?

Fine w/me.

Or we could check if the packet has been IPsec encapsulated
and set saddr6 to NULL in this case.

Re: iwm won't connect to hidden networks.

[Stefan Sperling]

On Tue, Oct 25, 2016 at 01:52:22PM -0500, rhubarbpie...@gmail.com wrote:
> 
> This may seem strange, but iwm won't connect to my witless network if I have
> "Hidden" enabled in my cable modem.
> 
> The command I use to connect is:
> 
>ifconfig iwm0 nwid "NetworkNameHere" wpakey "PasswordHere"
>dhclient iwm0
> 
> The error I receive is:
> 
>iwm0: no link ... sleeping

Perhaps it will work if we make the firmware send a probe request
to the hidden SSID? Please try again with the diff below.

This diff probably breaks 'ifconfig iwm0 scan' while associated though, since
now the firmware filters out beacons with a different SSID and you'll only
see the current SSID when scanning while associated (at last that's what
it did last time I tried, which is why this code is wrapped in #if 0).

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.144
diff -u -p -r1.144 if_iwm.c
--- if_iwm.c8 Oct 2016 14:37:48 -   1.144
+++ if_iwm.c25 Oct 2016 19:34:29 -
@@ -4487,10 +4487,8 @@ iwm_lmac_scan_fill_channels(struct iwm_s
chan->iter_count = htole16(1);
chan->iter_interval = 0;
chan->flags = htole32(IWM_UNIFIED_SCAN_CHANNEL_PARTIAL);
-#if 0 /* makes scanning while associated less useful */
if (n_ssids != 0)
chan->flags |= htole32(1 << 1); /* select SSID 0 */
-#endif
chan++;
nchan++;
}
@@ -4516,10 +4514,8 @@ iwm_umac_scan_fill_channels(struct iwm_s
chan->channel_num = ieee80211_mhz2ieee(c->ic_freq, 0);
chan->iter_count = 1;
chan->iter_interval = htole16(0);
-#if 0 /* makes scanning while associated less useful */
if (n_ssids != 0)
chan->flags = htole32(1 << 0); /* select SSID 0 */
-#endif
chan++;
nchan++;
}

Re: IPv6/NDP/IPsec breakage in -current

[Mike Belopuhov]

On Thu, Oct 13, 2016 at 21:43 +0200, Markus Friedl wrote:
>
> > Am 13.10.2016 um 13:06 schrieb Christian Weisgerber :
> >
> >> After the second m_makespace():
> >>
> >>+--+-+  +--+  ++-+
> >>| IPv6 | ESP |  | IPv6 |  | ICMPv6 | ESP |
> >>+--+-+  +--+  ++-+
> >>
> >> With m_inject(), it would instead be something like this:
> >>
> >>+--++-+  +--+  +
> >>| IPv6 || ESP |  | IPv6 |  | ICMPv6  ...
> >>+--++-+  +--+  +
> >
> > Found it.  It's this snippet of nd6_ns_output() that handles those
> > mbuf chains differently:
> >
> >454 if (ln && ln->ln_hold) {
> >455 hip6 = mtod(ln->ln_hold, struct ip6_hdr *);
> >456 /* XXX pullup? */
> >457 if (sizeof(*hip6) < ln->ln_hold->m_len)
> >458 saddr6 = >ip6_src;
> >459 else
> >460 saddr6 = NULL;
> >461 } else
> >462 saddr6 = NULL;
> >
> > Did this only ever work by accident?
>
> ok, to get it right, the following is the difference:
>
> with m_inject() the first mbuf always contains the 40 byte ipv6 header
> while with m_makespace() it also contains the ESP header.
>
> so with m_inject() the ln_hold->m_len is 40 and since this is
> exactly the size of hip6, the code falls back to saddr6 = NULL.
>
> IMHO the code should use <= and not <:
>if (sizeof(*hip6) <=  ln->ln_hold->m_len)
> but then your example will also fail with the old m_inject() code.
>

I agree with the above.

> If this intended address selection is indeed correct then we
> need to figure out if a bypass flow for NDP is necessary, or
> if NDP should always bypass IPsec (but what about bringing NDP
> over IPsec?)
>

There are apparently some discussions in infomational RFCs regarding
this issue.  For instance https://tools.ietf.org/html/rfc3756 states:

   More specifically, the currently used key agreement protocol, IKE,
   suffers from a chicken-and-egg problem [8]: one needs an IP address
   to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are
   required to configure an IP address.

Which goes one step further: how to protect all ND in general, but is
still applicable in our situation.  There were attempts to protect ND
in alternative way, e.g. SEND (https://tools.ietf.org/html/rfc3971).
FreeBSD has picked up on it and has had a SoC project which seems to
be integrated right now:

   https://wiki.freebsd.org/SOC2009AnaKukec
   https://www.freebsd.org/cgi/man.cgi?query=send=4

Would it be possible for us to disable the check and always set saddr6
to NULL for now?

> With IPv4 this problem does not exist, because ARP packet are not IP
> packets, so they are not matched by the IPsec flow.
>
> -m

iked: Cannot send requests after rekeying IKE SA

[Thomas Klute]

>Synopsis:  iked: Cannot send requests after rekeying IKE SA
>Category:  system
>Environment:
System  : OpenBSD 6.0
Details : OpenBSD 6.0-current (LOCAL) #0: Mon Oct 24 10:01:22 CEST 
2016
 
t...@openbsd.my.domain:/usr/src/sys/arch/amd64/compile/LOCAL

Architecture: OpenBSD.amd64
Machine : amd64
>Description:

If iked is configured to rekey the IKE SA (ikelifetime option),
sending requests ends up broken after the first rekeying. Messages
like "ikev2_msg_send: CREATE_CHILD_SA request from any to any msgid 0,
432 bytes" (second rekeying attempt, see log below) indicate that the
local and remote addresses of the new IKE SA are not intialized
correctly. Despite this, iked can respond to requests from the peer.

>How-To-Repeat:

1. Configure iked as a responder with ikelifetime > 0. The very short
value in the example iked.conf below (10 seconds) is chosen to make
reproduction fast.

2. Start iked with this configuration. The log below was created using
"iked -dvv".

3. Initiate an IKE SA from a suitable peer and wait for rekeying to
happen. I've used the Strongswan conftest framework with a
configuration that closes the IKE SA after 120 seconds, note that the
DELETE message is processed correctly.

>Fix:

Unknown.


iked.conf:
ikev2 "test" passive ipcomp esp from 172.25.128.5/32 to 172.24.2.42/32 \
peer any \
ikesa enc aes-256 auth hmac-sha2-256 group modp2048 \
childsa enc aes-256 auth hmac-sha1 group modp2048 \
srcid "/CN=ike-test.example.com/C=DE" \
ikelifetime 10


iked log:
ca_privkey_serialize: type RSA_KEY length 1192
ca_pubkey_serialize: type RSA_KEY length 270
ikev2 "test" passive esp from 172.25.128.5/32 to 172.24.2.42/32 local any peer 
any ikesa enc aes-256 prf hmac-sha2-256,hmac-sha1 auth hmac-sha2-256 group 
modp2048 childsa enc aes-256 auth hmac-sha1 group modp2048 srcid 
/CN=ike-test.example.com/C=DE ikelifetime 10 lifetime 10800 bytes 536870912 rsa
iked.conf: loaded 1 configuration rules
config_getpolicy: received policy
config_getpfkey: received pfkey fd 3
ca_reload: loaded ca file x509.pem
config_getcompile: compilation done
config_getsocket: received socket fd 4
config_getsocket: received socket fd 5
config_getsocket: received socket fd 6
config_getsocket: received socket fd 7
ca_reload: /CN=Testing Authority
ca_reload: loaded 1 ca certificate
ca_reload: loaded cert file ike-test.pem
ca_validate_cert: /CN=ike-test.example.com/C=DE ok
ca_reload: local cert type X509_CERT
config_getocsp: ocsp_url none
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
ikev2_recv: IKE_SA_INIT request from initiator 172.24.2.42:500 to 
172.25.128.5:500 policy 'test' id 0, 544 bytes
ikev2_recv: ispi 0x0cffe25e7be83b8b rspi 0x
ca_x509_name_parse: setting 'CN' to 'ike-test.example.com'
ca_x509_name_parse: setting 'C' to 'DE'
ikev2_policy2id: srcid ASN1_DN//CN=ike-test.example.com/C=DE length 50
ikev2_pld_parse: header ispi 0x0cffe25e7be83b8b rspi 0x 
nextpayload SA version 0x20 exchange IKE_SA_INIT flags 0x08 msgid 0 length 544 
response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 136
ikev2_pld_sa: more than one proposal specified
ikev2_pld_sa: more 2 reserved 0 length 44 proposal #1 protoid IKE spisize 0 
xforms 4 spi 0
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256
ikev2_pld_xform: more 0 reserved 0 length 8 type DH id MODP_2048
ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 264
ikev2_pld_ke: dh group MODP_2048 reserved 0
ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 36
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP
ikev2_nat_detection: peer source 0x0cffe25e7be83b8b 0x 
172.24.2.42:500
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP
ikev2_nat_detection: peer destination 0x0cffe25e7be83b8b 0x 
172.25.128.5:500
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 16
ikev2_pld_notify: protoid NONE spisize 0 type SIGNATURE_HASH_ALGORITHMS
ikev2_pld_notify: signature hash SHA1 (1)
ikev2_pld_notify: signature hash SHA2_256 (2)
ikev2_pld_notify: signature hash SHA2_384 (3)
ikev2_pld_notify: signature hash SHA2_512 (4)
ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 8
ikev2_pld_notify: protoid NONE spisize 0 type REDIRECT_SUPPORTED
sa_state: INIT -> SA_INIT
ikev2_sa_negotiate: score 4
sa_stateok: SA_INIT flags