Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options

["Max Pritikin (pritikin)" <[e-mail]>]

Toerless, I suggest breaking this thread into two. I’m only responding to the first half of your msg below,

> On Dec 3, 2015, at 6:43 PM, Toerless Eckert (eckert) <[e-mail]> wrote:
> 
> As promised during call: 
> 
> Proposed Discovery phase for AN-Bootstrap:
> 
> 1. Mandatory: Discovery of bootstrap-proxy link-local
> 
>   I think this should be via GRASP, but GRASP may not want to provide what i think is
>   best, so let me maybe first describe what i think is best, independent
>   of what protocol we use and solicit feedback on it and then we can discuss
>   with GRAP if/how to fit it there:
> 
>   IMHO, i would let the proxy periodically (30 secs)

Is it acceptable that a new device sits for 30s before joining? Should this be shorter? Longer? What criteria do we use to choose (see below before answering). 

> just announce that its providing
>   AN enrollment proxy function via link-local IPv6 multicast. Maybe with port-number
>   and protocol (EST over IPv6 link-local ) as parameters so it's extensible.
> 
>   Why ?
> 
>   I don't want to make the proxy more attackable than it needs to be. Anything
>   that it needs to respond to is something it can be attacked with. Unsolicited
>   periodic link-local multicast that do not need/want any response are really hard to attack.
> 
>   I don't want the enrolling device to be more attackable than necessarily.
>   Arguably such a greenfield device may be more attackable than a configured
>   device. An unconfigured device that periodically broadcasts "hey, i am unconfigured
>   and look for a proxy server" (especially when powered on in a non-AN enviroment)
>   is the best victim ever to do a port-scan etc. pp.  on (or just find the console
>   interface). And just because a vendor has added autonomic networking doesn't mean
>   he has now also fixed all security for all OS services many of which may not even be
>   off by default but would likely be configured off by security sensitive operators. 
> 
>   Sure, could an attacker find a greenfield device by also broadcasting the
>   link-local "i am an AN-proxy" messages ? But now you have an active attacker.
>   And for example, we could include in the periodic announcements a timestamp
>   signed with the proxies domain certificate. Thats something the attacker
>   can not fake. The greenfield device may not be able to figure out
>   whose link-local multicast to trust, but the real an-proxy can listen to someone
>   else multicasting itself as a proxy. And if thats not from another proxy in the
>   same AN domain, then this could trigger an alert to ops (syslog or trap).
>   And of course the greenfield device should not trust an L2 unicasted "i am proxy"
>   message, because that might be a trick from an attacker to not be seen by a real proxy
>   on the same (wired) LAN.

This is a solid argument in favor of casting the AN new device as the “responder” for the protocol exchange. 

> 
>   So, i think we can use GARP DISCOVER for this periodic multicast,

Multicast DNS supports multicast “unsolicited” responses and also specifically states that peers cache these. So the basic behavior you are requesting is fundamentally available from mDNS as well. This is a design choice for Anima but I doesn’t seem to dramatically impact our choice of discovery protocols.

I do note that mDNS s8.3 indicates that:
"  A Multicast DNS responder MUST NOT send announcements in the absence
   of information that its network connectivity may have changed in some
   relevant way.  In particular, a Multicast DNS responder MUST NOT send
   regular periodic announcements as a matter of course.”
It would be interesting to understand why they felt a need to prohibit the type of behavior you’re looking for. Perhaps their concerns here impact the choice of 30s arbitrarily made above. 

> only that
>   GARP DISCOVER really wants to see a GARP reply, but in our case we really
>   just want the greenfield device to immediately connect to our EST TCP port,
>   no need for any further chat before doing that. So thats where we'd need to have
>   the discuss with GARP folks what they think. 
> 
>   Also comparison with mDNS as we discussed it:
>     - code size: We need GRASP for more functions in AN beside discovery,
>       we do not need mDNS for anything in AN, so on IoT devices we would save
>       code size. TBD: Size of an mDNS stack (note: We MAY want "normal" DNS,
>       so the code size for mDNS may not be that large as a delta on top of
>       "normal" DNS).

This is where the real value/difference discussion comes in. I guess we could build an avahi library and see how much the entire thing takes or how big pieces of it are. 

>     - Number of packet exchanges (TBD: not clear how much this is a real
>       problem, mDNS may optimize here): mDNS exchange is logical three step:
>       PTR RR lookup -> SRV, TXT RR lookup, AAAA lookup
>     - mDNS being a query/reply exchange wouldn't have the security properties
>       i described above. Unless you abuse it and engineer an MDNS unsolicited
>       announce periodically with all the four RRs included.

As noted above this doesn’t look problematic. The real issue is that they found it important to prohibit this type of behavior and we should understand why before adopting your proposed initiator model. 

> And i guess
>       one could define a TXT RR with the signed timestamp. Aka: I could probably
>       do the same thing i was describing above also with mDNS. Not sure if
>       mDNS people would like that…

For a DNS based solution I guess DNSsec integration would be logical. I’m not sure I like any approach where we try to cram security into the discovery protocol — the truth is that we don’t have sufficient information to trust crypto methods in the response/broadcast information until after we complete bootstrapping at which point its relatively moot. Instead we can cut to the heart of your security value by tracking "locator-option” information seen and freaking out if an unexpected one was seen (assuming GRASP). 

More broadly: 

In return I worry about forcing GRASP to be used for any bootstrapping. Yes, I recognize this is reasonable for Anima but its still a valid concern as doing so really ties bootstrapping to anima when it doesn’t need to be.

I’m also worried that GRASP implementations assume a secure transport later via ACP or TLS and don’t find the current language in s3.3.1 and s3.3.2 to be very clear about what happens when these are not used. I prefer an approach where we can clearly provide a bright line and state that “this exchange is not secure”. Running Grasp in both modes is unclear and confusing.

- max

> 
> 2. If 1. failed:  OPTIONAL Discovery of bootstrap proxy via L3
> 
>   Does not need to be supported on all AN devices, but only those that
>   want to be able to auto-bootstrap when connected to some "IP-network/Internet"
>   connection. Would also like comments from Kent because his draft/use-cases
>   will likely have a lot of overlap/opinions here.
> 
>   a) Try to get (routed) IPv6/IPv4 address. IPv4 by DHCP, IPv6 SLAAC and/or DHCP.
> 
>   b) If address via DHCP request DHCP option holding AN bootstrap parameter
>      TBD: Option 124/125. Maybe Ralph Droms can quickly point to best practices
>      from IETF standards perspective, else i need to dig more for what i've seen
>      as best practices.
> 
>   c) If DHCP successfull, DHCP reply will provide IP/IPv6 address or domain-name
>      of bootstrap proxy. Connect to it.
> 
>      This case will allow you to connect to a proxy in the customer network
>      (aka: network that generates the DHCP reply). This option will not work
>      when connecting to the Internet.
> 
>   d) If using SLAAC (IPv6): TBD. Need to ask IPv6 experts if IPv6 RA etc. 
>      can usefully provide add-on info like DHCP can (don't think so).
> 
>   e) If DHCP and/or SLAAC fail to find bootstrap proxy, use DNS:
> 
>   f) DHCP/SLAAC should have provided local <domain>.
>      Look up autonomic-bootstrap-proxy.<domain> A/AAAA addresses (depending
>      on whether device has IPv4 and/or IPv6 address from a). Connect to
>      that IPv4/IPv6 address of bootstrap server.
> 
>   g) OPTIONAL:
>      If f) has failed, create domain-name <name>.<vendor>.
> 
>      This connects to proxy in the internet operated by device vendor,
>      which is the only option when connecting directly to the Internet,
>      where no DHCP option is possible (from owner) and where you do not
>      get a useful DNS prefix (but just DNS prefix from SP).
> 
>      Of course this only needs to be implemented if vendor is happy to 
>      operate (or outsource) such a proxy on the Internet. So it's even more optional
>      then the whole L3 bootstrap option overall.
> 
> Removed: I am somewhat a fan of link-local IPv4 (they're cute), but i really
> don't see a reason for them: The proxy also needs to support AN functions anyhow,
> so it will always be able to do IPv6.
> 
>   a) 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap