[Swan] Explicit failure shunt for opportunistic connections

[Paul Wouters]

On Thu, 9 Jan 2014, markd lists wrote:

> Hoping someone can help me understand the behaviour of an policy group based OE setup (0.0.0.0/0 in private-or-clear). Specifically what
> happens when there are no TXT or IPSECKEY RR for either host.

It should insert a /32 to /32 %pass eroute in the most common case, but
it does depend on the contents of the /etc/ipsec.d/policies/* files.
Normally, 0/0 is in the "privateorclear" meaning try private, fall back
to clear. I see those in your output, eg:

> 12         10.236.54.8/32     -> $ip_of_my_local_dns_server_1/32  => %pass

That shows 12 cleartext packets to your local nameserver.

> I've been trying to simulate a "default fail open" scenario where neither of host A or host B have TXT or IPSECKEY published RSA keys.
> My understanding was that specifying failureshunt=passthrough on conn private-or-clear would install a %pass rule on ipsec eroute when
> OE attempts failed. This contradicts what I am seeing in pluto.log.
> 
> I see the initial acquire-pfkey caused by the connection attempt
> 
> | add bare shunt 0x7f631eb121d0 10.236.54.8/32:0 --0--> 10.236.33.242/32:0 => %hold 0    %acquire-pfkey
> initiate on demand from 10.236.54.8:0 to 10.236.33.242:0 proto=0 state: fos_start because: acquire
> 
> .. connection private-or-clear#0.0.0.0/0 being chosen
> 
> | find_connection: looking for policy for connection: 10.236.54.8:0/0 -> 10.236.33.242:0/0
> | find_connection: conn "private-or-clear#0.0.0.0/0" has compatible peers: 10.236.54.8/32 -> 0.0.0.0/0 [pri: 16777229]
> | find_connection: comparing best "private-or-clear#0.0.0.0/0" [pri:16777229]{0x7f631eb20c10} (child none) to
> "private-or-clear#0.0.0.0/0" [pri:16777229]{0x7f631eb20c10} (child none)
> | find_connection: concluding with "private-or-clear#0.0.0.0/0" [pri:16777229]{0x7f631eb20c10} kind=CK_TEMPLATE
> | creating new instance from "private-or-clear#0.0.0.0/0"
> | initiate on demand from 10.236.54.8 to 10.236.33.242 new state: fos_start with ugh: ok
> 
> .. TXT lookup and failure for our explicitly specified leftid (purposefully not in DNS)

Note that you are looking at what we now call the "old OE" code. The
idea of the new OE code is that no such logic exists within the IKE
daemon, but that external events (eg triggered by a DNS server plugin)
will instruct pluto to setup something specific.

> | DNS query 7 for TXT for is01.infrasec.orion.altus. (gw: @is01.infrasec.orion.altus)
> | * processed 0 messages from cryptographic helpers
> | next event EVENT_PENDING_DDNS in 23 seconds
> | next event EVENT_PENDING_DDNS in 23 seconds
> |
> | * processed 0 messages from cryptographic helpers
> | next event EVENT_PENDING_DDNS in 23 seconds
> | next event EVENT_PENDING_DDNS in 23 seconds
> |
> | *received adns message
> | asynch DNS answer 7 no TXT record for is01.infrasec.orion.altus.
> 
> .. IPSECKEY lookup and failure

Note that IPSECKEY was never fully implemented. Only TXT records (and
the old-style KEY records from before KEY was restricted to internal-DNS
only and renamed to DNSKEY)

> | continuing from failed DNS lookup for our IPSECKEY record, 10.236.54.8 to 10.236.33.242: no TXT record for is01.infrasec.orion.altus.
> initiate on demand from 10.236.54.8:0 to 10.236.33.242:0 proto=0 state: fos_our_txt because: our IPSECKEY record
> | find_connection: looking for policy for connection: 10.236.54.8:0/0 -> 10.236.33.242:0/0
> | find_connection: conn "private-or-clear#0.0.0.0/0" has compatible peers: 10.236.54.8/32 -> 0.0.0.0/0 [pri: 16777229]
> | find_connection: comparing best "private-or-clear#0.0.0.0/0" [pri:16777229]{0x7f631eb20c10} (child none) to
> "private-or-clear#0.0.0.0/0" [pri:16777229]{0x7f631eb20c10} (child none)
> | find_connection: concluding with "private-or-clear#0.0.0.0/0" [pri:16777229]{0x7f631eb20c10} kind=CK_TEMPLATE
> | creating new instance from "private-or-clear#0.0.0.0/0"
> | started looking for secret for @is01.infrasec.orion.altus->(none) of kind PPK_RSA
> | actually looking for secret for @is01.infrasec.orion.altus->(none) of kind PPK_RSA
> | line 1: key type PPK_RSA(@is01.infrasec.orion.altus) to type PPK_RSA
> | 1: compared key (none) to @is01.infrasec.orion.altus/ (none) -> 2
> | 2: compared key (none) to @is01.infrasec.orion.altus/ (none) -> 2
> | line 1: match=2
> | best_match 0>2 best=0x7f631eb1fa60 (line=1)
> | concluding with best_match=2 best=0x7f631eb1fa60 (lineno=1)
> 
> and finally a "no explicit failure shunt" message and removal of the hold shunt (where I assumed a %pass rule would be installed)

It should yes, doesn't it, passed on the "ipsec eroute" command I see
below, it does?

Note this code path has not been tested since about 2005. It must have
suffered some bit rot. We are looking at a different way of implementing
things now, and are hoping to have some proof of concept code and an
internet draft out in 2-3 weeks. (We are specifically meeting to work
on this in Sna Francisco next week)

Paul