Thanks for your reasonable note, Hannes. On Wed, 25 Aug 2004, Tschofenig Hannes wrote: > - there have been a number of discussions about the bandwidth broker > concept in the past and the disadvantages are known. (my personal > opinion) if it boils down to the protocol details then the > difference between the rsvp architecture with a pep/pdp and a > bandwidth broker is not hudge. the central entity which performs the > authorization (or policy) decision was already mentioned. BB concept applied in which scope? BB model, as with intserv model, does not work (even well) across administrative boundaries. Those disadvantages are well known. Were those disadvantages related to that, or something else? > - from a signaling protocol point of view there is little difference between > path-coupled and path-decoupled signaling in many cases. even path-decoupled > signaling is path-coupled in some sense - you do not want to signal your > messages to networks where the data traffic will never flow through. one big > difference is the discovery mechanism. you are certainly right with your > observation that you could use a number of different discovery mechanisms to > communicate with devices along the path. if we can learn something from rsvp > with this respect then it should that multiple mechanisms for discovering an > node along the path has to be supported - not only router alert options. i > think such a decision would increase the number of usage scenarios. The point is, if you just signal to a "broker" in the network you're visiting (discovered in the same manner, e.g., as the recursive DNS servers), it will know if you send it source, destination pair whether the traffic goes beyond its control or not, and that avoids unnecessary signalling (and signalling attempts). Avoiding the unnecessary attempts is actually IMHO pretty important for multiple reasons. > btw, you might not know about the path-decoupled signaling (pads) bof (see > http://www.ietf.org/ietf/03mar/pads.txt) where people spoke about reusing > path-coupled signaling protocols in order to provide path-decoupled > signaling. It's interesting to note that there has been a BoF, but I'd be interested as to why folks spoke about reusing the path-coupled signalling (of course, it can be used for the lack of a better protocol); too bad the BoF didn't submit any slides or minutes. > - denial of service issues with the router alert option: it is true that > router alert option processing is slower than packets which do not have the > router alert option set. however, i am not sure whether this is truely a big > issue based on the most recent information i saw (see > http://www.welzl.at/research/projects/ip-options/). Processing is indeed slower .. 10% or 30% is significant. But what I'm really worried about is that IP router alert -like options are options which a hardware implementation cannot process. An attacker can just specify an undefined router alert option which forces the processing to go to the slow path (instead of ASICs etc., it must be put on the CPU), and overload the processing of the router that way. That's not good. That can naturally be mitigated by rate-limiting the IP options to some small value, but such would effectively disable the processing of options, and require that you're able to match on those options. In other words, anything which has to be forwarded that requires CPU processing seems bad to me.. Btw, you might be interested that in PMTUD WG session at IETF60 where Michael Welzl proposed using IP options for PMTUD, Mark Allman (AFAIR) reminded of someone (him?) conducting tests on how big percentage of hosts respond or not when there are IP options. Michael's presentation (http://www.ietf.org/proceedings/04aug/slides/pmtud-4.pdf) already said that 30% were ignored you completely (not just the IP option!), but I think when conducting tests against web servers, this was even smaller. I don't know whether this is caused by broken firewalls or what, but that certainly seemed to be showstopper at least for IP options -based PMTUD. Doesn't the same apply to NSIS if you'd like to do it end-to-end? > furthermore, i always had the impression that other mechanisms even > introduce more denial of service risks. for example: if you have your > bandwidth broker example then you need to deal with dos issues against this > device as well (and there are plenty of them). basically, you need to > address denial of service issues at any place, regardless of the specific > solution. IMHO the risks are very different. With IP router alert -based mechanisms, you need to address the DoS risks in all the routers in the world. With BB like centralized models, you just need to address then in BB-like boxes: that's probably around 1%-5% of the number of boxes where you need to do that, and that box is dedicated to just processing on protocol, so it should be easier to build protocol-specific anti-DoS measures. > - firewall issues: you argue that an operator might not allow users to open > pinholes. why not? if you authenticate and authorize users then you can make > a decision which user is allowed to open a pinhole. furthermore, you already > do it today with more complex mechanisms based on sip signaling and midcom. Certainly, the operator can make a policy decision who can do it. And many protocols do create holes. But the protocols don't ask the firewall administrator whether they're allowed to do it or not; the methods just use tricks (e.g., open an outbound session, and tunnel traffic inbound through it) to pass the firewall whether that's intended or not, right? There could be some applicability to allow certain users, by policy, to create pinholes (in such a manner that the administrator could override it) in the firewall in the pre-determined small port range (e.g., the hosts would still not be able to request pinholes for TCP/80, but only for e.g., certain kind of SIP usage), but for something more general than that.. I doubt it. > it would be worth to have a discussion on the following issue: > * path-coupled signaling is very benefitial if you have complex topologies > where routing symmetry causes packets towards different destination > addresses to hit different firewalls/nats. melinda shore raised this issue > in midcom (i guess for the first time). you can find her draft at > http://www.watersprings.org/pub/id/draft-shore-friendly-midcom-01.txt. I think you could actually address at least 95% of this if you just supply (source,destination pair) to someone who has the copy of the (IGP) routing data and can calculate what the path would be like. The rest 5% would be caused by policy-based custom routing (typically only applies at the edge, so not an issue) and hosts with multiple interfaces which send packets out through wrong interface with incorrect source addresses. > * will people deploy firewalls in the future? (particularly since people > tunnel everything through http)? (my personal opinion is yes, they will.) I also think yes, though I'm still hoping that some breakthroughs in host-based firewalls w/ centralized policy process would obviate the need for getting smarter edge firewalls. > - nat issues: why do you think that nat handling is trickier? in fact the > case of a data receiver being behind a nat is (based on our investigations) > rather a nice case since you are assured that the data packets traverse this > nat (if you publish the obtained ip address, transport protocol + port as > your contact address). with a data receiver behind a firewall (in case of > complex topologies and routing asymmetry) things are more complicated > (without making additional assumptions). There are a number of NATs which behave different ways, as described in draft-jennings-midcom-stun-results-01.txt. With a firewall, you just need to enter one pass rule to enable a service. With NAT state, you might need one for each peer (port) that must traverse inbound through it, unless you would be inserting some kind of "forwarder" state. > you mention some ipv6 specific > solutions that would fix the problem automatically. could you please > elaborate? I meant solutions like Teredo (draft-huitema-v6ops-teredo-02.txt) and similar other configured tunneling schemes which traverse NATs which will be able to provide non-NAT'ed IPv6 access, obviating the need for NAT traversal. > - you mention a few issues with regard to qos and charging. this is a > complex issue which we (engineers) are not really good in making a decision. > i have read a number of papers by prof. odlyzko (see for example > http://www.dtc.umn.edu/~odlyzko/doc/pricing.architecture.pdf). these papers > are nice to read but it is hard to estimate how individual issues raised in > these documents influence our work (and even in which time frame). I totally agree that this is a complex issue, but I remain amazed that there are still people who want to try to solve a complex issue irregardless of its complexity even if there is history which seems to indicate that it's likely that it isn't going anywhere. Instead, I would have been more happier if I had noticed that the folks would be working on more easier tasks of the complex problem in a piecemeal manner (e.g., the issues with qos and limiting at the first hop, or at the predetermined constrained hops at the local site). Trying to solve a broad problem might lead the problem being solved with such means that the solution is never going to be widely deployed to meet its original goals, and the effect is that we don't have any realistic solution in the end. If a slightly different approach would cause wider penetration on the really crucial issues (e.g., the issues in the first hop, etc.), then we would possibly be much better off in general. That's my concern: (IMHO) it'd be better to concentrate on the easier issues *only*. End-to-end (without the constrains on where the ends are) signalling is not something that can be solved in a manner that it would actually be used without reinventing the Internet architecture. Concentrating on the easier issues only would be better, and not seeking (again, after RSVP :) the holy grail of telecom/research QoS people, end-to-end signalling for reservations. There's also smaller amount of economical/operational aspects to worry about, as there are clearer areas of applicability and use for 1st hop/predetermined constrained hops case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf