Hi Tony, could be interesting to investigate - but there is also a bunch of security nodes in between the border router and the endpoints, usually the border router IGP is separated by a firewall (using only static routing) from the internal IGP domain. So the firewall should be part of this and pass ND messages, and at the same time ensure that this are valid messages and no bogus DDoS attempts. I need to study ND...
About the renumbering issue - I believe that is not possible to automate it that much. I have been involved lately in a topology change at a data center, the network part and workstations are easy to renumber and also some servers. But when you are dealing with DMZ hosts you are hitting a super-massive pain point, especially when the DMZ server is use for business-to-business solution for partners. These servers are protected by firewalls at both ends, so when you are changing the IP address you have to schedule a service window not only for the enterprise but also for the partners - you and all the affected partners has to change firewall rules at the very same moment. And with several servers this will take time...and expenses.... This is another reason why enterprises are eager to have PI-addresses (multi-homed or not) their firewall rule base remain intact though the ISP is replaced It would be wonderful if the firewall rules is based only on the identifiers - get rid of the locator information in the rules. Then the enterprise could change the locator values and no need to worry about their partner connections, much less costs is caused by topology changes. And also to outsource your services to a cloud provider would be much easier - no L2 connectivity is needed from the enterprise to the cloud provider during transition phase - instead the identifier of the service is pointed to another location in DNS when it is started at the cloud provider. But I'm afraid that the security part in ILNP is too weak to convince the security architects that you could build your security rules only on identifier information - think that HIP is in better position here (and that's why I haven't added an identifier to hIPv4). I could be wrong about this... To summarize, if the security solutions could be build on identifier information renumbering would be a no-brainier compared what we have today. Also this has nothing to do with Internet routing scalability, we are now in the enterprise domain but if you can find cost saving issues at the enterprise domain you will catch the attention of the upper management and get this thing started :-) -- patte On Mon, Jun 7, 2010 at 8:47 PM, Tony Li <[email protected]> wrote: > > > Patrick, > > Here's another approach: > > Leverage the existing link state IGP. Each border router knows the locator > prefixes that it gets via its ISP. If it's link to the ISP is up, then it > injects those prefixes into the IGP. > > Now, each router in the domain collects these prefixes as part of its SPF > pass through the link state database. It then uses an extension to ND to > advertise the associated locators to its neighbors. (How to xlate a prefix > into a specific locator is TBD). > > Hosts now listen to these locators in normal ND RA messages and sends > updates to DNS if it chooses to update its locator set. > > Taking our example, suppose that the link to ISP B fails. Then the B router > withdraws the locator from its IGP advertisement. This in turn causes ND > to remove the B locator from ND. The hosts then transition their locators. > > Note that domain renumbering automatically falls out of this approach. ;-) > > Another outstanding question is how this can be done without turning this > into a DDOS attack on the DHS server. > > Tony > > > > On 6/7/10 7:49 AM, "Patrick Frejborg" <[email protected]> wrote: > >> Tony & Joel, >> >> outbound traffic is the topic that I'm trying to have a discussion on, >> sort of "first mile traffic engineering" at an enterprise. >> >> I'm taking this scenario a little bit further, the link between >> attachment point B and the corresponding ISP goes down - then we have >> a black hole because nor the host neither the DNS system is aware of >> the link failure. One way to overcome this situation would be to >> create a "link state protocol" between ILNP border routers and the DNS >> , e.g. if the upstream link fails the DNS becomes aware of this and >> once DNS is aware of this situation it updates the records, updates >> its own clients so they can send out ICMP messages to their >> correspondents. This sounds a little bit scary to create a dynamic >> protocol between the routing system and DNS - I'm not really >> comfortable with this approach but let us have a look on the option. >> >> For outbound traffic from client A via either attachment point B, C >> and D you would use today the 0/0 route concept towards one of the >> attachment points, in this case B. From there you would use local >> preferences to go out via the preferred border router - but this is >> today prefix based. So if you could add a new attribute for ILNP, i.e. >> "local identifier preference" to iBGP and each identifier can be given >> an own value you can direct outbound traffic per host to either >> attachment points B, C and D (and achieve load balancing). But to >> minimize administrative tasks you should be able to set the metric of >> the "local identifier preference" at one place, e.g. DNS which then >> informs the border routers how hosts should use the attachment >> points. So perhaps a "link and identifier state protocol" is needed >> between the routing system and DNS .... >> >> I'm still not happy what this "link and identifier state protocol" approach. >> >> If I have three attachment points I would prefer to use all three >> points concurrently for each host, i.e. a multipath transport protocol >> would be great. >> We have had SCTP for a while but is not widely deployed and I believe >> the reason is that it cumbersome and expensive to deploy a multipath >> enabled enterprise network from client A to the attachment points B, C >> and D. You need to have three separate networks, three identical >> security architectures that needs to have the same security rules - >> the economics are not there - it just become too challenging to build, >> maintain and troubleshoot. >> >> And I'm afraid that MPTCP will have the same problem to get deployed >> in an enterprise network for the very same reasons - mobility is a >> different issue >> >> If ILNP could have a shim header where the host A sets the preferred >> outgoing attachment point you could create a "first mile traffic >> engineering" solution, i.e. you can establish three separate paths >> from client A to the attachment points B, C and D. Some routers in >> between needs to able to read the shim header and switch the packets >> to the correct paths. The border router for the initiator shouldn't >> rewrite the locator, instead the border router in front of the >> responder would swap the locator headers (as in hIPv4). The outcome >> would be that the hosts are located by an edge locator value and one >> or several core locator values - the great thing with this approach is >> that the economics for multipath transport protocols arrives. Only one >> NIC on the hosts, only one local network at the enterprise and also >> one security architecture - which could be build upon the identifier >> values and _not_ on the locators. But then you should be able to >> protect your identifier from being stolen, and here I haven't made my >> mind up - should I trust ILNP that it will protect my identifier or >> should I prefer HIP to take care of the identifier...... >> Also, it seems that "link and identifier state protocol" between the >> routing system and DNS is no longer needed - responsibility to solve >> the black hole issue is on the transport protocol. >> >> Thoughts? Also, I might have missed something... >> >> -- patte >> >> On Fri, Jun 4, 2010 at 12:44 AM, Joel M. Halpern <[email protected]> >> wrote: >>> I believe that Patrick is asking about outbound traffic routing, not >>> inbound. >>> >>> Which is very reasonable question to ask. >>> >>> Unfortunately, until we are prepared to make a much larger set of changes, >>> we do not have the tools to allow a host to choose which outbound site >>> connection is used by the hosts outbound traffic. (There are many use cases >>> which would like those capabilities, but we have not found a good way to >>> deliver them.) >>> >>> yours, >>> Joel >>> >>> Tony Li wrote: >>>> >>>> >>>> On 6/4/10 5:21 AM, "Patrick Frejborg" <[email protected]> wrote: >>>> >>>>> A question regarding ILNP and multi-homing scenario. >>>>> The primary path from A towards Internet goes via attachment point B >>>>> and this is announced in DNS. Then ISP taking care of attachment point >>>>> B have some performance problems and the service is not good enough >>>>> for host A - he decides to switch to attachment point C and updates >>>>> DNS. But how does the packet get routed from host A to attachment >>>>> point C instead of B in large enterprise network where there could be >>>>> a lot of routers and some security nodes between the host and the >>>>> attachment points? >>>>> I don't want to tweak the local routing domain but when I change the >>>>> DNS records host A should start to use new attachment point (C), some >>>>> other hosts might still use the old one (B). >>>> >>>> >>>> In ILNP, a host controls how packets arrive by changing the locators that >>>> are advertised. Outbound, intra-domain packet routing is separate, and >>>> COULD be based on the hosts source locator, but this is a separate >>>> enhancement that we could make. >>>> >>>> Once the host updates DNS with the C locator, it should also concurrently >>>> send ICMP locator updates to its active correspondents and inform them of >>>> the C locator. >>>> Tony >>>> >>>> >>>> _______________________________________________ >>>> rrg mailing list >>>> [email protected] >>>> http://www.irtf.org/mailman/listinfo/rrg >>>> >>> > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
