On Thu, Jun 10, 2010 at 11:36 PM, RJ Atkinson <rja.li...@gmail.com> wrote: > > On 10 Jun 2010, at 15:48 , Patrick Frejborg wrote: >>> Hmm. >>> >>> It isn't really "having an external partner update their ACL >>> or firewall rules", but instead using learned local-knowledge >>> (knowledge that can be authenticated !) to locally update >>> local ACL or firewall rules. >>> >>> That is, the ruleset remains whatever was locally chosen, >>> it is just that as the location change is learned >>> and then the same locally-specified rule is applied >>> to the same locally-specified node/site, >>> at the remote node/site's new location. >>> >>> There are multiple authentication mechanisms for those >>> ICMP Locator Updates: >>> - non-cryptographic session nonces are always used >>> - cryptographic authentication of the packet (IPsec AH) >>> can optionally be used >> >> This is a little bit controversial, for the routing architecture the >> IP address is divided into identifier&locator values, but in order to >> traverse security architectures both are glued again together as an IP >> address - making one architecture scaling better but the other one >> becomes more complex. > > I don't understand what you are trying to say just above. > Your use of the word "this" is perhaps where I get lost. >
Sorry, my bad. What I'm trying to say here is that in the network arena we are trying to separate the identifier and locator mechanisms completely, it shouldn't matter if you change network attachment point the sessions stays up with the help of the identifier. But when it comes to security nodes you are suggesting the locator and identifier are tied together in order to be verified against security rules. I find that a little bit conflicting - in network separate locator and identifier but in security nodes go ahead and overload. Back to the example, For a partner connection over a VPN, do I really care about the location information, does it add any value for me? When a new incoming session is hitting my firewall the fw should check the FQDN with the help of the identifier - if the identifier lookup at DNSSEC returns a FQDN that matches the FQDN in my rule I allow the session to go to my B2B server (where I could still use IPsec to do the final authentication). Once the session is verified the fw should monitor transport parameters and the locator values - if e.g. locator value changes then the fw needs to check the identifier/FQDN again before allowing the session to continue. Or use the nonce method. Does this make sense? Having said that, however it could be useful to have locator as an optional parameter in the firewall though the primary authentication is based upon identifier/FQDN. E.g. if there are services that should only be reached when you are attached to the office network you would also use the locator value together with identifier/FQDN verification. But I would use this only when I have control over the locator value - here you have a location aware firewall solution. Having n*external partner sessions coming into my firewall configuring dynamically locator values in the ruleset gives me cold feet. Instead the same level of verification can be fetched over one connection to my DNSSEC server that have reliable connections to other DNSSEC systems. Hope this clarify... -- patte _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
