On Thu, Jun 10, 2010 at 1:54 PM, RJ Atkinson <[email protected]> wrote:
> This turns out to be trivial, because the partner > will always send an ICMP Locator Update message, > which can be authenticated, to provide the new > Locator values. > > Since the seecurity appliance is along the path > from source to destination, the security appliance > will always see the ICMP Locator Update message > and can update the set of valid Locator bindings > by itself instantly.[1] > > We talk about this in one of the MILCOM papers > in more detail than I am writing down in this note. > Our example in that paper relates to NAT and updating > the NAT session state, but there is no fundamental > difference between updating NAT session state and > updating an ACL rule. Couldn't open this one http://www.cs.st-andrews.ac.uk/~saleem/papers/2009/milcom2009/milcom2009-rab2009.pdf Firefox reported it broken However, it could be hard to sell this to the security officers, i.e. having an external partner updating their ACL or firewall rules automatically.... > >> It seems that the firewalls should move towards >> DNS based filtering solutions. > > Yes, and that is true even if none of the Routing RG > proposals get adopted, because it mitigates risks > in the current deployed Internet. I'm starting to get sold on this approach - when you design an enterprise architecture you need to create security zones. If you could align the DNS zone names together with security zones, having security nodes verifying incoming sessions to the security zone by the identifier and DNSSEC the renumbering would be a breeze after that. Take an example, you have departments 1 & 2 with their dedicated services dep1&dep2 and user groups 1 & 2. Also some common services is provided for both departments. You set DNS zones dep1.foo.com, dep2.foo.com, user1.foo.com, user2.foo.com and common.foo.com. Separate the users from the services by a identifier&DNSSEC enabled firewall. You set up following rules in the firewall: - user1.foo.com allowed to access dep1.foo.com, needed ports - user2.foo.com allowed to access dep2.foo.com, IPsec - user1 and user2.foo.com allowed to access common.foo.com, needed ports Now user1 and user2 can be located anywhere inside the enterprise network, no need to separate the users in separate VLANs&VRFs. The firewall verifies the user based upon the identifier value that is checked via DNSSEC that has been updated during the logon to the enterprise network. If there is a common service between user1 and user2 groups, e.g. VoIP or Video the service is located in the common.foo.com zone but the RTP stream between user1&user2 takes the shortest path in the network since there is no VLAN&VRF separation with checkpoint somewhere far in between the users 1&2 Also user1 can't listen and steel data from user2 group when they accessing dep2 services, only IPsec is allowed for those sessions. Is there any papers available around this kind of a solution? Or is this a brain damaged approach? > This is no longer true. The bandwidth pressures created > by various "smart phones" mean that mobile phone operators > are quite keen to encourage their users to migrate to WiFi > if they roam to an area with good WiFi coverage (for example), > at least for data traffic (Handoffs of voice telephony traffic > to WiFi is still in flux in the marketplace). > Think the reason is that the current TDM connections are too expensive and gets filled by data that is not generating much revenue. This model could change back once carrier ethernet is available, they should be much much cheaper than the TDM connections. -- patte _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
